-
Notifications
You must be signed in to change notification settings - Fork 510
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
sharedfilesystems: Add CreateShareFromSnapshotSupport field to Share struct #2191
sharedfilesystems: Add CreateShareFromSnapshotSupport field to Share struct #2191
Conversation
Build succeeded.
|
PTAL @gouthampacha @jtopjian |
@gman0 Thanks for submitting this. Can you provide the Manila API code reference that defines this field? Also, are there any unit tests or acceptance tests that can be included in this PR? |
I suppose you want the API ref in the PR commit message, @jtopjian ? As far as tests are concerned, looks like we could update the fixtures here:
and the assertions here: https://github.com/gophercloud/gophercloud/blob/master/openstack/sharedfilesystems/v2/shares/testing/request_test.go This seems like a simple case where a missing parameter's being added, but the API ref should contain the right response objects to copy over.. |
I was looking for something along the lines of this: https://github.com/openstack/manila/blob/a3aaea91494665a25bdccebf69d9e85e8475983d/manila/api/views/shares.py#L147-L151 If I understand the Manila code correctly, this block of code amends the view/result with the
Yeah, updating fixtures (both the JSON responses and mock structs) should be fine. The important piece here is to keep the fixtures up-to-date in case missing fields cause an issue in the future. Unit tests currently pass because this is a boolean field, which defaults to false, which is the default value when a struct field is omitted, so it's more of a coincidence that the tests are passing. Let me know if this helps or if you have any questions. |
Totally, thank you for the link to the code-hunting doc. That explains what you were looking for. While it's true that this API can be extended/customized, the intent here is to expose the share object that will be common across all conformant openstack clouds.
+1 Thanks for your response
|
Apologies, I was busy yesterday... Thank you both for suggestions around tests and finding the relevant places in src! I'll update the fixtures and their assertions. |
434778e
to
bebec5c
Compare
Build succeeded.
|
@gouthampacha Sorry. I @'d the wrong person yesterday. Thank you both. This looks good to me! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM - thank you!
Thank you! |
Hi @jtopjian just a quick question: from the looks of things it seems gophercloud releases are cca 1 month apart. Are you planning to make July's release still, or is v0.19.0 coming out later? We'd like to use this feature already, so I'd like to know whether we should wait a bit more so we can update our dependencies then, or we should just pin our go.mod to this commit now. |
@gman0 I've just created v0.19.0. Let me know if you need anything else 🙂 |
@jtopjian that's excellent news, thank you! |
This PR adds
CreateShareFromSnapshotSupport
field toShare
struct. It maps tocreate_share_from_snapshot_support
in response.For #2190
Links to the line numbers/files in the OpenStack source code that support the
code in this PR:
https://docs.openstack.org/api-ref/shared-file-system/?expanded=show-share-details-detail#id27