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

project id added in test #3378

Closed
wants to merge 9 commits into from
Closed

project id added in test #3378

wants to merge 9 commits into from

Conversation

DaanHoogland
Copy link
Contributor

as per @ustcweizhou's comment: #3377 (comment)

Description

Types of changes

  • Breaking change (fix or feature that would cause existing functionality to change)
  • New feature (non-breaking change which adds functionality)
  • Bug fix (non-breaking change which fixes an issue)
  • Enhancement (improves an existing feature and functionality)
  • Cleanup (Code refactoring and cleanup, that may add test cases)

Screenshots (if appropriate):

How Has This Been Tested?

@ustcweizhou
Copy link
Contributor

I saved test_15_project_tag in a seperated python file, and run it in marvin test
it failed without this change, and succeed with this change.

so this is ok for me. @DaanHoogland @rhtyd

@@ -1756,6 +1756,7 @@ def test_15_project_tag(self):
listall=True,
resourceType='project',
resourceIds=project.id,
projectid=project.id,
Copy link
Member

Choose a reason for hiding this comment

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

I would have expected this to work without specifying project ID. Do you think we need to fix mgmt server instead?

Copy link
Member

Choose a reason for hiding this comment

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

@DaanHoogland Read this https://github.com/apache/cloudstack/pull/3323/files, how about we add a check to read the resource type and use the provided resource ID as account ID when type is project.

Copy link
Contributor

Choose a reason for hiding this comment

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

@rhtyd that should be good.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes, that would work, @rhtyd. I don't think it matters much, as the id is already in the API, but that solution would have less breakage of ecosystem scripting so let's go for 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.

on second thought @rhtyd , you do mean to use the resource ID to get the account ID and not use it as account ID, right? (else I don't understand 😮 )

Copy link
Member

Choose a reason for hiding this comment

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

yes @DaanHoogland, I'm more concerned with existing systems and integrations that may break. And moreover, it breaks the API semantics (we're already passing projectid in the resource ID so why not use 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.

on second thought @rhtyd , it won't work. There is no resource ID unless the project ID is passed as such. in the call there is no information that we can use

            listall=True,
            resourceType='project',
            key=tag_key,

We could get the current account from the call context but that would only satisfy some use-cases. if an admin wants tags for some project they are not in we still need the parameter.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

never mind, i think I was stupid just there ^^. I'll revisit.

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've been mostly busy on other things today but gave it a second look. I think it can be fixed as you suggest in the query service. I will give it a swing soon. I'll remove the java change for now but leave the test in.

@DaanHoogland
Copy link
Contributor Author

I think I just overkilled it. didn't want to spend more time on it.

@DaanHoogland
Copy link
Contributor Author

@ustcweizhou I realize that now. I am confused by @rhtyd 's remark to use the resource ID it would not be the account ID of the owner of the project but the project itself. I don't think we can use that either. We could use it to find the account ID.

@DaanHoogland
Copy link
Contributor Author

note to self; need to do something like:

        Long projectId = cmd.getProjectId() == null ? cmd.getResourceId() : cmd.getProjectId();
        
        _accountMgr.buildACLSearchParameters(caller, null, cmd.getAccountName(), projectId, permittedAccounts, domainIdRecursiveListProject, listAll, false);

but translate cmd.getResourceId() to a Long id (from uuid?)

@ustcweizhou
Copy link
Contributor

getProjectId

@DaanHoogland
looked into the code, resourceId can be id or uuid, both are supported.

@@ -646,7 +646,9 @@

Ternary<Long, Boolean, ListProjectResourcesCriteria> domainIdRecursiveListProject = new Ternary<Long, Boolean, ListProjectResourcesCriteria>(cmd.getDomainId(), cmd.isRecursive(), null);

_accountMgr.buildACLSearchParameters(caller, null, cmd.getAccountName(), cmd.getProjectId(), permittedAccounts, domainIdRecursiveListProject, listAll, false);
Long projectId = cmd.getProjectId() == null ? cmd.getResourceId() : cmd.getProjectId();
Copy link
Contributor

Choose a reason for hiding this comment

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

    public String getResourceId() {
        return resourceId;
    }

Copy link
Contributor

@anuragaw anuragaw left a comment

Choose a reason for hiding this comment

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

Previous approval was based on 1 line change. Need to review again after mutiple changes.

Copy link
Contributor

@anuragaw anuragaw left a comment

Choose a reason for hiding this comment

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

Previous approval was based on 1 line change. Need to review again after new changes.

@rohityadavcloud
Copy link
Member

@DaanHoogland failed following marvin test: (not sure if it's related to the PR)

test_15_project_tag     | marvin.cloudstackExcept | 1.249   | test_tags      |
|                         | ion.CloudstackAPIExcept |         |                |
|                         | ion                     |         |            

try {
projectId = Long.parseLong(resourceId);
} catch (NumberFormatException e) {
projectId = _projectDao.findByUuid(resourceId).getId();
Copy link
Contributor

Choose a reason for hiding this comment

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

What if the uuid is invalid ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

it throws an exception: garbage in, garbage out. should we handle that? I think it is the exception @rhtyd is pointing at. How do you suggest this should be handled?

@rohityadavcloud
Copy link
Member

Ping @DaanHoogland

@rohityadavcloud
Copy link
Member

I'm taking over the failing smoketests/Travis issues here: #3476
Closing on this remark.

@rohityadavcloud rohityadavcloud removed this from the 4.13.0.0 milestone Jul 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants