Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2018-10-12
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
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
21:39:47 smcginnis samueldmq: You should be able to take a look at the logs to see what commands the jobs are running.
21:40:00 smcginnis samueldmq: Or search for the job name in codesearch.openstack.org to track down its definition.
22:41:42 openstackgerrit Merged openstack/python-openstackclient master: Add volume backend capability show command https://review.openstack.org/609122
22:41:44 openstackgerrit Merged openstack/python-openstackclient master: Add volume backend pool list command https://review.openstack.org/608740
22:41:47 openstackgerrit Merged openstack/python-openstackclient master: Allow endpoint filtering on both project and project-domain https://review.openstack.org/608912
23:19:31 samueldmq smcginnis: Awesome. Thanks
#openstack-sdks - 2018-10-13
12:15:13 openstackgerrit Andreas Jaeger proposed openstack/osc-lib master: Do not merge: Testing legacy-tempest-dsvm-neutron-src https://review.openstack.org/610242
12:38:11 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Add stackviz processing to functional tests https://review.openstack.org/610167
12:46:03 mordred samueldmq, smcginnis: we just landed zuul dashboard support for web pages for each job. so, for instance, http://zuul.openstack.org/job/openstacksdk-functional-devstack
12:46:36 mordred samueldmq: it would not be a bad idea to add more explanation into the description fields of our jobs though
12:48:45 samueldmq mordred: that's awesome. infra team always doing a great job
12:49:32 samueldmq mordred: and I agree having a better description would be nice, specially for newcomer willing to understand what we test
12:49:36 mordred ++
12:50:00 mordred like, if you go up the stack a bit, you hit http://zuul.openstack.org/job/devstack-tox-functional - which has a much more verbose description :)
12:50:02 samueldmq mordred: btw why do we need a neutron-grenade job?
12:51:01 mordred because openstacksdk is used in openstackclient which is used in devstack - so we have to make sure patches to openstacksdk don't break the entire gate for everybody :)
12:51:49 samueldmq mordred: aha that's cool. I'm documenting that too
12:52:19 samueldmq if a broken release goes out and is adopted by the ci system. you break the whole openstack ci
12:52:20 mordred awesome

Earlier   Later