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

Fix issues for GCE when running CloudBlockStoreServiceTestCase. #121

Merged
merged 1 commit into from
Jun 21, 2018

Conversation

baizhang
Copy link
Collaborator

Hi @nuwang @afgane @chiniforooshan @mbookman,

This pull request fixes a few issues for GCE when running CloudBlockStoreServiceTestCase. Specifically,

  1. Make the delete method for GCEVolume and GCESnapshot synchronous (waiting for the operation to complete before returning).
  2. Add resource description handling for GCEVolume and GCESnapshot
  3. Check the validity of the name for name setter method.
  4. Disable the renaming checks, since GCE does not support resource renaming after it is created.
  5. Add cache_discovery=False to suppress error "ImportError: file_cache is unavailable when using oauth2client >= 4.0.0" (link).

Thank you!

@ghost ghost assigned baizhang Apr 28, 2018
@ghost ghost added the in progress label Apr 28, 2018
@coveralls
Copy link

Coverage Status

Coverage remained the same at ?% when pulling 6d4fd4d on baizhang:gce into e229400 on gvlproject:gce.

4 similar comments
@coveralls
Copy link

Coverage Status

Coverage remained the same at ?% when pulling 6d4fd4d on baizhang:gce into e229400 on gvlproject:gce.

@coveralls
Copy link

coveralls commented Apr 28, 2018

Coverage Status

Coverage remained the same at ?% when pulling 6d4fd4d on baizhang:gce into e229400 on gvlproject:gce.

@coveralls
Copy link

Coverage Status

Coverage remained the same at ?% when pulling 6d4fd4d on baizhang:gce into e229400 on gvlproject:gce.

@coveralls
Copy link

coveralls commented Apr 28, 2018

Coverage Status

Coverage remained the same at ?% when pulling 6d4fd4d on baizhang:gce into e229400 on gvlproject:gce.

Copy link
Contributor

@nuwang nuwang left a comment

Choose a reason for hiding this comment

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

LGTM @baizhang. Some minor comments.

# In GCE, the name of the volume is provided by the client when
# initially creating the resource. The name cannot be changed after
# the volume is created.
cb.log.warning("Setting volume name after it is created is not "
Copy link
Contributor

Choose a reason for hiding this comment

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

@baizhang Can we use a label/tag to track the name instead? In cloudbridge, the name is just a user provided friendly name, and is therefore, changeable. So we could do something similar to what's done for description below? (unless it's super inefficient, and requires a new http request)

Copy link
Collaborator

Choose a reason for hiding this comment

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

Hi @nuwang -

In #44, where we landed was:

@nuwang - your proposal seems reasonable to me:

Use the disk name field for name (with the specified character and inability to rename restrictions)
Use labels for the disk description field. GCE implementation will convert spaces to underscores

Please review the discussion. Do the premises of the discussion in that PR still hold or do we need to revisit?

Thanks,

-Matt

Copy link
Contributor

Choose a reason for hiding this comment

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

@mbookman Thanks for pointing to that. Going through that discussion through, I can't find why exactly we decided to go with the GCE name for the 'name' field, instead of using a label, but I think there was some important reason? As I recall, @afgane raised an issue - something to do with potential mismatches between the original name given at creation time and a later rename perhaps? It would be good to record what it is for future reference.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I believe that the main issue that we landed on was that there would become disconnects between what the user sees in Galaxy vs. what they see in the Cloud console (or gcloud compute ... list).

The user would change the name in Galaxy and when they looked in Google Cloud, they'd see the old name.

There was also a problem of enforcing uniqueness. You could have multiple users create and rename Galaxy hosts to be "my-galaxy". Going to the Cloud console, you wouldn't see two instances named "my-galaxy", you'd have to know how to view the labels.

These same reasons apply to different Cloud resources. The feeling at the time was that it was better to have restrictions on naming such that Galaxy and Cloud were in sync. Only if there was a real clamor for the ability to rename did it seem worth creating this potential disconnect between Galaxy/Cloud.

Copy link
Collaborator

Choose a reason for hiding this comment

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

And - not all Cloud resource support labels. So we could potentially end up with a hodge podge of resources which did support renames vs. those that did not.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Hi @nuwang, @afgane - where would you like to go with this issue?

Thanks!

Copy link
Contributor

Choose a reason for hiding this comment

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

@mbookman Sorry, I had missed this comment. Right, that was the issue - thanks for penning it down. I guess we still haven't figured out a way to make this consistent across all providers, since, as it stands now, a rename will fail silently for GCE only. Let's leave this as is for now, since it's not a major issue, and hopefully, figure out a way to make things uniform across all providers if and when needed?

disk=self.name)
.execute())
self._provider.wait_for_operation(
response, zone=self._provider.default_zone)
Copy link
Contributor

Choose a reason for hiding this comment

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

@baizhang Is there a specific reason to block till the delete is complete?? I think ideally, the delete call shouldn't block. I believe the tests handle this already, and wait for the delete to complete.

Copy link
Contributor

Choose a reason for hiding this comment

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

This is the only issue that remains - should we just go ahead and merge it and we can sort this issue out later since it isn't a blocker?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Thanks for your review, @nuwang !

I agree. Let's go ahead and merge this one first. And I will work on a non-blocking delete method in a separate pull request.

# the snapshot is created.
cb.log.warning("Setting snapshot name after it is created is not "
"supported by this provider.")

Copy link
Contributor

@nuwang nuwang May 3, 2018

Choose a reason for hiding this comment

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

Same as for Volume name. The name should ideally be editable. In GCE, I guess the 'name' maps more to cloudbridge's id.

@nuwang nuwang merged commit b9984c1 into CloudVE:gce Jun 21, 2018
@ghost ghost removed the in progress label Jun 21, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants