Rh-che: Rh-che should not depend on any other namespace than *-che and user

[ibuziuk]

there should be no checks involved for *-jenkins, *-run, *-stage
NOTE: user namespace, for now, is still planed to exist, so no need to remove "Login to OSO" installer for now

[ibuziuk]

Related fabric8-tenant PR - https://github.com/fabric8-services/fabric8-tenant/pull/761

[ibuziuk]

@alexeykazakov am I correct that PR above still does not contain changes related to the user-namespace removal? e.g. as part of this issue we just need to verify and confirm that che.openshift.io does not depend on stage, run & jenkins namespaces, but would still depend on user and che namespaces

[MatousJobanek]

am I correct that PR above still does not contain changes related to the user-namespace removal? e.g. as part of this issue we just need to verify and confirm that che.openshift.io does not depend on stage, run & jenkins namespaces, but would still depend on user and che namespaces

Yes, the PR contains changes related "only" to -run, -stage, -jenkins namespaces, the user namespace stays there. In other words, for now, it is fine that you verify that che does not depend on the three before-mentioned namespaces - the user namespace can stay in use.
As a next step would be also removing the user namespace, but that is not so critical for now.

[ibuziuk]

sounds good, so the scope of this issue is just to verify that che.openshift.io has no hard dependencies on stage, run, jenkins namespaces which I think already the case cc @alexeykazakov

[MatousJobanek]

I would say not only verify that che.openshift.io has no hard dependencies by just "scanning the code", but also to try it by using an account that has only che and user's namespaces.
As for the user's namespace - this is something that we would like to remove as well in the future, it's just not a priority #1 for now. @alexeykazakov correct me if I'm wrong

[alexeykazakov]

Right. There are two parts.

1. We should make sure that che can work with users with the user and che namespaces only. No jenkins, stage, run. This is a high priority task. I agree with @MatousJobanek that it's worth testing on the che side.
2. Getting rid of user namespace in che too (do not use/relay on it). We should track this issue separately. This is something that we didn't plan initially but it looks like it's something we would like to do.

[ibuziuk]

ok, we are focusing on #1 only as part of this issue. I suppose we would be able to provide an update by the end of the week

[amisevsk]

Che gets namespace data from fabric8 user service through the TenantDataProvider#getUserCheTenantData method.

The two places this method is called are

1. Fabric8WorkspaceEnvironmentProvider, where the namespace is hard-coded to be type "che"
2. RhCheInfraEnvironmentProvisioner, where the namespace is hard-coded to be type "user".

From what I can tell there are no references to the other namespaces in the codebase. As a next step, does someone want to help me in deleting those namespaces from my account?

[alexeykazakov]

From what I can tell there are no references to the other namespaces in the codebase. As a next step, does someone want to help me in deleting those namespaces from my account?

@pbergene or someone from the SD team should be able to help. No one else has enough permissions to do that.

[pbergene]

Sure, will help - just need the relevant information.
From context it looks like -run -stage -jenkins, presumably on 2a for preview for one of @amisevsk's users? What is the username and cluster? Should the tenant db be adjusted @alexeykazakov @MatousJobanek?

[MatousJobanek]

Should the tenant db be adjusted

it depends... it would be great if we could test it with adjusted tenant DB (missing namespace records), but every time when a user logs in to openshift.io, the WIT service sends POST request to tenant service and then the tenant checks for missing namespaces for the given user. When some namespace is missing then tenant service creates it.
In other words, it depends on how you want to test it. If you want to test it using a flow containing also the login step, then the tenant DB cannot be adjusted, otherwise, it provisions the missing namespaces.
@pbergene remove only the namespaces from the cluster and keep the tenant DB as it is for now. If it is only for prod-preview, then I can change the logic of tenant service to not check for missing namespaces as a temporary workaround just for this particular use-case and then bring it back. I have permissions to access the prod-preview DB so I can do the changes in the DB on my own. WDYT @alexeykazakov?

[amisevsk]

On my end, I'm fine with either prod or prod-preview changes, whichever is more convenient for everyone else. Accounts are

• amisevsk-preview on starter-us-east-2a
• amisevsk on starter-us-east-2

[alexeykazakov]

@MatousJobanek I think it's OK to temporally hardcode this workaround for the particular user and revert it as soon as the testing is done.

[pbergene]

@jfchevrette Is around later than me today if this is something you want to move forward on.

[kbsingh]

My understanding is that developers from che have Tier access to the clusters in order to go view the entire product and platform, so should not need to block on SD ( but SD might want to be aware anyway )

[ibuziuk]

@kbsingh no, we do not atm

[MatousJobanek]

@amisevsk I've modified the tenant settings of the account amisevsk-preview in prod-preview. I deleted the three namespaces: amisevsk-preview-jenkins amisevsk-preview-run amisevsk-preview-stage and I also removed the related records from the DB. In other words, your account is in the state where all other accounts should be when we drop the three namespaces and keep only che and user ones. The tenant service in prod-preview should not check for the existence of the missing namespace.

Please, verify the che.openshift.io flows using this account. Feel free to ping me if you face any issues with the tenant namespaces ;-)

[amisevsk]

@MatousJobanek Thank you!

I've tested with the amisevsk-preview account and workspace start seems to have no issues:

• Che 7: Everything is created as expected; workspace fails to start due to ongoing services/routes issue.
• Che 6: Workspace starts without issue.

@ibuziuk I think this issue can be closed.