Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use the owner Id only in the workspace RuntimeIdentity (#8859) #9274

Merged
merged 3 commits into from
Mar 30, 2018

Conversation

davidfestal
Copy link
Contributor

What does this PR do?

This PR removes the ownerName attribute of the RuntimeIdentity class, to keep only the ownerId according to what was requested in the following discussion.
This is done while taking care of still using the owner name when it was previously used (in the container name, etc...)

All the tests pass, and the Che server + workspace start works correctly on Openshift DevCluster.

What issues does this PR fix or reference?

This fixes issue #8859

Release Notes

Nothing to add in the release notes, since it's internal refactoring

Docs PR

Nothing to add in the docs, since it's internal refactoring.

Signed-off-by: David Festal <dfestal@redhat.com>
@codenvy-ci
Copy link

Can one of the admins verify this patch?

@davidfestal
Copy link
Contributor Author

ci-test

Copy link

@garagatyi garagatyi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should not add UserDao and instead should use user ID as owner value.

@skabashnyuk @sleshchenko WDYT?

@@ -60,7 +70,12 @@ public String getActiveEnv() {

@Override
public String getOwner() {
return context.getIdentity().getOwnerName();
try {
User user = userDao.getById(context.getIdentity().getOwnerId());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it is good to return owner name or owner id here. Let's document that owner id will be returned in Runtime class and just return it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it is good to return owner name or owner id here

Let's be clear, returning the ownerId here is just a way to gracefully manage an abnormal and exceptional case. Maybe we could just throw an exception instead.

Let's document that owner id will be returned in Runtime class and just return it.

That's quite an impacting change, no ?
Change the meaning of value from a plain user name to an ID (opaque to the user), in a location that is used in many places (even in the RuntimeDto). This will surely produce some behavior changes, also in the UI and for the end-user.

That seems strange to me.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we could just throw an exception instead.

You can try to do it but I think it might be difficult with current classes hierarchy

Change the meaning of value from a plain user name to an ID (opaque to the user), in a location that is used in many places (even in the RuntimeDto).

Makes sense. But I think using username there is a mistake that was done because of docs lack.
@gazarenkov should be right person who knows what is supposed to be there.

If user id then I think we should try to change it and run QA tests. I guess clients don't use it and everything will be OK 😉

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we agreed in your previous PR that we should do this change. I don't think that clients use it somehow now. But running tests, indeed, should verify this.

containerConfig.setContainerName(
containerNameGenerator.generateContainerName(
identity.getWorkspaceId(),
containerConfig.getId(),
identity.getOwnerName(),
userName,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd say that using owner id here is even better. @garagatyi WDYT?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so the container naming strategy will change ? Doesn't it have any impact on UI for the end-user ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think no. The only one person who sees it is Che Admin using docker CLI. @garagatyi Am I right?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that container name is the only place. And it doesn't make much sense to keep username there if it costs us something.

@codenvy-ci
Copy link

ci-test build report:
Build details
Test report
selenium tests report data
docker image: eclipseche/che-server:9274
https://github.com/orgs/eclipse/teams/eclipse-che-qa please check this report.

@benoitf benoitf added kind/enhancement A feature request - must adhere to the feature request template. status/code-review This issue has a pull request posted for it and is awaiting code review completion by the community. labels Mar 29, 2018
... instead of the owner name.

As requested by @sleshchenko in comment
#9274 (comment)

Signed-off-by: David Festal <dfestal@redhat.com>
... as request by @garagatyi in this comment:
#9274 (comment)

Signed-off-by: David Festal <dfestal@redhat.com>
@davidfestal
Copy link
Contributor Author

ci-test

@davidfestal
Copy link
Contributor Author

@sleshchenko @garagatyi I made the 2 changes you requested to remove the use of the UserDao. I've ran the full build locally with tests and everything was OK.

Let's see what integration tests say about this change from the user name to the user Id in the runtime definition...

@codenvy-ci
Copy link

ci-test build report:
Build details
Test report
selenium tests report data
docker image: eclipseche/che-server:9274
https://github.com/orgs/eclipse/teams/eclipse-che-qa please check this report.

@davidfestal
Copy link
Contributor Author

@sleshchenko @garagatyi In the second build (after UserDao removal), there are slightly more selenium tests failing, but I don't see how new failures are obviously related to this change.

Could you have a look please and approve this PR is it's really OK ?

@sleshchenko
Copy link
Member

I think there are some unstable tests. @eclipse/eclipse-che-qa Could you please check them, maybe it is needed to run selenium tests one more time?

Copy link

@garagatyi garagatyi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good

Copy link
Member

@sleshchenko sleshchenko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe that your changes are not the reason of the failed tests.
LGTM

@davidfestal davidfestal merged commit c19ccdc into master Mar 30, 2018
@benoitf benoitf removed the status/code-review This issue has a pull request posted for it and is awaiting code review completion by the community. label Mar 30, 2018
@benoitf benoitf added this to the 6.4.0 milestone Mar 30, 2018
@davidfestal davidfestal deleted the RuntimeIdentity-refactoring branch March 30, 2018 12:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement A feature request - must adhere to the feature request template.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants