| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-10-12 | |||
| 13:50:33 | mnaser | mordred: I think spyros (PTL) is usually pretty good about that stuff. I can’t recall his IRC nick off the top of my head | |
| 13:51:01 | mnaser | mordred: strigazi | |
| 13:51:05 | mordred | awesome- thanks! | |
| 13:51:37 | mordred | mnaser: openstack-magnum doesn't seem to be their irc channel ... | |
| 13:55:24 | hansmoleman | dtroyer: i was just reminded of this bug i opened for osc https://storyboard.openstack.org/#!/story/2002158 - curious as to how to handle that. you can't set a volume as read-only while it's being created, but the option is on the volume create CLI. | |
| 13:55:42 | hansmoleman | there is a --wait option on the volume create CLI, so if --wait and --read-only, then wait for it to be available and then make the read-only change? | |
| 13:55:50 | hansmoleman | or make --read-only imply --wait? | |
| 13:56:21 | hansmoleman | oh nvm, i guess there is no --wait option for volume create | |
| 13:56:23 | hansmoleman | that's on server create | |
| 13:56:51 | hansmoleman | welp, i could add --wait to volume create and then build on that for --read-only, but that wouldn't work for anyone using older versions of osc | |
| 14:04:45 | mnaser | mordred: #openstack-containers is the one to look at | |
| 14:25:27 | openstackgerrit | Chuck Short proposed openstack/os-client-config master: Change python3.5 job to python3.7 job on Stein+ https://review.openstack.org/610051 | |
| 14:42:51 | mordred | hansmoleman: does the volume have to be in ready state to have its readonly attribute set? | |
| 14:43:05 | hansmoleman | yeah it has to be available | |
| 14:43:10 | mordred | how fun | |
| 14:43:17 | hansmoleman | $ openstack volume create --size 1 --read-only read-only-vol1 | |
| 14:43:17 | hansmoleman | Failed to set volume read-only access mode flag: Invalid volume: Volume 70539836-fbb9-478d-9cd1-0e733c0eb0cc status must be available to update readonly flag, but current status is: creating. (HTTP 400) (Request-ID: req-ac54552a-3784-4028-8262-8a600844c186) | |
| 14:43:42 | mordred | well - I'd certainly support --read-only implying --wait | |
| 14:43:50 | mordred | because otherwise it's a pretty useless flag | |
| 14:43:57 | hansmoleman | either that or that option just needs to die because it never worked | |
| 14:44:01 | hansmoleman | and was clearly not tested when it was added | |
| 14:44:04 | mordred | yah | |
| 14:44:14 | openstackgerrit | Chuck Short proposed openstack/os-client-config master: Change python3.5 job to python3.7 job on Stein+ https://review.openstack.org/610051 | |
| 14:44:30 | mordred | hansmoleman: I say add a wait, make --read-only imply it, and don't worry about backwards compat bcaues the previous thing never worked | |
| 14:44:35 | hansmoleman | there is no --wait on the volume create CLI, so i figure i can just make --read-only wait and i'll update the help on the option to say if you use this, the command will wait | |
| 14:44:46 | hansmoleman | or that | |
| 14:45:25 | hansmoleman | ok that wfm | |
| 14:47:22 | mordred | \o/ | |
| 14:57:31 | openstackgerrit | Merged openstack/openstacksdk master: cloud: rename with deprecation validate_node -> validate_machine https://review.openstack.org/609399 | |
| 19:19:58 | openstackgerrit | Sean McGinnis proposed openstack/python-openstackclient master: Handle not having cinderclient.v1 available https://review.openstack.org/609473 | |
| 19:52:59 | smcginnis | mordred or dtroyer: If one of you has a few minutes - I have a couple openstack volume command additions with one +2 that I would like to make sure are good before proceeding on more updates. | |
| 19:53:03 | smcginnis | https://review.openstack.org/#/q/owner:sean.mcginnis%2540gmail.com+status:open+project:openstack/python-openstackclient | |
| 19:53:31 | dtroyer | smcginnis: I'll have a look in a bit | |
| 19:54:10 | smcginnis | Thanks dtroyer! | |
| 20:31:24 | dtroyer | smcginnis: around? now that I see both commands I have a question… | |
| 20:31:45 | smcginnis | Sure! | |
| 20:31:50 | dtroyer | I had assumed 'volume backend capability' and 'volume backend pool' were your resource names | |
| 20:32:02 | dtroyer | you added 'volume backend' to commands.rst | |
| 20:32:29 | dtroyer | maybe that should be the resource name and —capability and —pool are attributes? dunno, trying to sort out how to thing about these | |
| 20:33:02 | smcginnis | I think that may be confusing. Thinking though... | |
| 20:34:09 | dtroyer | it isn't obvious to me, but I don't have the data models around the backends in my head either | |
| 20:35:06 | smcginnis | I guess you could look at it that way that a backend has a set of capabilities and one or more pools, so I suppose you could use flags for those attributes of the backend. | |
| 20:35:13 | smcginnis | Doesn't really sit right with me though. | |
| 20:35:21 | dtroyer | will there ever be other verbs for this/these resources? | |
| 20:35:37 | dtroyer | maybe it feels like capabilities are attributes but pools are resources | |
| 20:35:38 | smcginnis | What would be the expected behavior of not providing a flag. List both capabilities and pools? | |
| 20:35:54 | dtroyer | so let's go with what you have… and just update commands.rst to list ehm both separately | |
| 20:36:08 | smcginnis | I don't think there will be any other verbs. At least nothing on the horizon that I can tell. | |
| 20:36:10 | dtroyer | ok, yeah, that seals it, too ambiguous | |
| 20:36:42 | smcginnis | Yeah, I kind of like how unambiguous this turned out after changing directions from where I started off. | |
| 20:36:59 | smcginnis | So I should update commands.rst to have each one separately? | |
| 20:37:30 | smcginnis | And it would just be "openstack volume backend capability" and "openstack volume backend pool", no verbs, right? | |
| 20:38:55 | dtroyer | right… I'm leaving comments | |
| 20:39:27 | smcginnis | OK, great. Would it be OK if I did that in a follow up patch? There's one or two other internal things I would like to clean up too. | |
| 20:40:27 | smcginnis | Guess that's what I get for using one of Monty's release notes as a template. :D | |
| 20:40:42 | dtroyer | that works for me, they both had tweaks needed :) | |
| 20:40:58 | smcginnis | Will get that going right now... | |
| 20:40:58 | dtroyer | I re-write release notes before a release to make then have at least a similar voice | |
| 20:41:15 | dtroyer | ok, if you're going to do a follow-up I'll +W these now | |
| 20:41:23 | smcginnis | Great. Often overlooked, but I think that makes them much easier to consume when projects do that. | |
| 20:43:32 | dtroyer | in the v1 change, is importing from cinderclient.v3 going to be a problem for v2 commands? | |
| 20:45:19 | dtroyer | smcginnis: basically I just want to be sure that importing v3 but not setting microversions keeps us at v2-compat? | |
| 20:45:23 | mordred | smcginnis: never copy from me :) | |
| 20:45:26 | smcginnis | dtroyer: No, the base v3.0 is identical to v2. It's only after additional microversions (>=3.1) that things start to diverge. | |
| 20:45:30 | smcginnis | mordred: ;) | |
| 20:45:36 | dtroyer | ok, good | |
| 20:46:04 | dtroyer | as soon as an SDK 1.0 hits we can start playing with microversions with gusto | |
| 20:46:09 | smcginnis | I thought of going with v2 as the default, but since they are the same and we eventually someday maybe would like to get down to one version, I thought v3 would be best. | |
| 20:46:10 | mordred | discovery landed today | |
| 20:46:17 | mordred | so I'm thinking of cutting an rc next week | |
| 20:46:24 | dtroyer | \o/ | |
| 20:46:35 | mordred | although I just started hitting the existing sdk glance code with a giant stick | |
| 20:46:37 | dtroyer | just when I'm tied up with releasing stx… | |
| 20:46:42 | smcginnis | Great, I was going to ask about mv support. We have a bunch of cinder commands I would like to add but they are for microversioned things. | |
| 20:46:48 | mordred | but - you know - we'll be 1.0 enough for osc :) | |
| 20:46:59 | smcginnis | :) | |
| 20:47:33 | mordred | smcginnis: dtantsur|afk has been doing a decent amount with mv and ironic in sdk - so not only do we support discovering/configuring them - we've even got some examples of doing something with them :) | |
| 20:47:48 | mordred | and - of course - the joy that is live-migrate | |
| 20:48:10 | smcginnis | Perfect, maybe I can take a look at that work and try to contribute some for cinder. | |
| 20:48:14 | mordred | ++ | |
| 20:48:26 | mordred | speaking of - I actually have something in a glance patch i should do for cinder too | |
| 20:49:10 | mordred | namely - adding support for a base proxy class that has shared code - so for places where it's all the same we don't have to duplicate as much | |
| 20:49:17 | mordred | I think that'll be nice for cinder v2/v3 | |
| 20:49:31 | mordred | I may put in the basics and then ask for your eyes on that? | |
| 20:52:22 | dtroyer | fwiw, I explicitly did not do that in OSC so we would never have to decide which version that shared code might affect. I _think_ that is still a good decision, maybe the effects are different at that level… | |
| 20:52:31 | smcginnis | mordred: Perfect, I love reducing code. | |
| 20:52:54 | dtroyer | also, we'll remove cinder v1 with mostly a git rm | |
| 20:53:05 | smcginnis | I think that should be OK here with cinder v2/v3. If they are not the same without microversions, then we messed up. | |
| 20:53:10 | dtroyer | someday when I'm old(er) | |
| 20:53:14 | smcginnis | ;) | |
| 20:53:15 | mordred | dtroyer: yah - I think for the most part it's clearer to read when it's just separate | |
| 20:53:48 | smcginnis | If we can have v2 just duplicate off of v3, then removal should be quick and easy if we ever get to that point. | |
| 20:53:52 | smcginnis | Either way. | |
| 20:53:57 | dtroyer | anyway, enough from me, back to setting up docs for the flock-o-birds | |
| 20:53:57 | mordred | dtroyer: the specific case where I added a base class was so I could do create_image - which is super complex and has logic that applies regardless of version - and then forking logic per-version | |
| 20:54:20 | dtroyer | mordred: ah, makes sense in cases like that | |
| 20:54:22 | mordred | to handle that, I made a BaseImageProxy - and then had image.v1.Proxy and image.v2.Proxy both subclass it | |
| 20:55:25 | mordred | dtroyer: speaking of - when we start ripping out glanceclient - I have a some very shiny image upload code we can take care of | |
| 20:55:27 | openstackgerrit | Sean McGinnis proposed openstack/python-openstackclient master: Address issues from volume backend commands https://review.openstack.org/610161 | |
| 20:55:35 | mordred | andby shiny, I mean dirty dirty dirty nasty dirty | |