| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-10-12 | |||
| 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 | dtroyer | I re-write release notes before a release to make then have at least a similar voice | |
| 20:40:58 | smcginnis | Will get that going right now... | |
| 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 | 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:53:57 | dtroyer | anyway, enough from me, back to setting up docs for the flock-o-birds | |
| 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 | |
| 20:56:01 | smcginnis | dtroyer: Good luck with the release. | |
| 20:56:08 | mordred | \o/ | |
| 20:57:56 | dtroyer | thanks guys, we've got 12 days so no crunching sounds from behind… yet… | |
| 20:58:50 | smcginnis | dtroyer: It's probably completely different than what we've got here, but let me know if you run into anything I can help with. | |
| 21:00:56 | dtroyer | smcginnis: not completely different, I didn't want to invent new, mostly we're just not doing a bunch of things. But I'm finding I may regret choosing 'r/' for the release branch prefix. Many of the exiting tools assume 'stable/' | |
| 21:02:26 | dtroyer | like we don't publish anything other than docs, the final release is really just the tags in git. but the docs… whee! I'm learning a LOT | |
| 21:02:44 | smcginnis | Heh, yeah. I think it's sprinkled everywhere assuming stable/ | |
| 21:03:29 | dtroyer | I'm trying to decide if it is too late to change. Maybe for this release it is but it's also basically an alpha release. MAybe for the one in MArch we will change it… | |
| 21:04:23 | smcginnis | You may end up having changed enough by that point not to, but if we ever think there may be some convergence point in the future between these, it might make sense to try to stay with stable. | |
| 21:04:34 | smcginnis | Not sure if that's a realistic thing or not. | |
| 21:05:07 | smcginnis | But at least picking up future release automation changes from openstack, it might make it easier if there's less to tweak in adopting it. | |
| 21:06:48 | dtroyer | honestly the convergence I see is possibly taking a project or two and making them look even more like OpenStack projects, they might be useful for your average Joe Cloud too… | |
| 21:07:23 | smcginnis | Yeah, hopefully that's the case. | |
| 21:07:28 | dtroyer | I am stealing^H^H^H^Hborrowing as much as I can, thanks for all the fish! | |
| 21:08:50 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Add stackviz processing to functional tests https://review.openstack.org/610167 | |
| 21:15:08 | smcginnis | I would definitely do the same. | |
| 21:22:25 | samueldmq | hi, is there a description of what each one of SDK's gate jobs does? | |
| 21:22:28 | samueldmq | mordred: ^ | |
| 21:23:13 | samueldmq | it's not too hard to have an idea with the job name, but I was wondering if I could confirm that somehow | |
| 21:37:05 | openstackgerrit | Merged openstack/os-client-config master: Change python3.5 job to python3.7 job on Stein+ https://review.openstack.org/610051 | |