Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2018-10-12
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
12:52:26 mordred yah
12:52:42 mordred now - to be fair - we'd eventually catch that when trying to raise the constraints
12:52:56 samueldmq great powers, great responsibility
12:53:05 mordred but yeah - exactly
12:53:08 mordred better safe than sorry
12:53:13 samueldmq mordred: is there a test first thing for raising contraints?
12:53:24 mordred there is
12:53:42 mordred a patch gets submitted to openstack/requirements raising the constraints, and that runs devstack jobs too
12:54:03 samueldmq awesome. ci in openstack is quite impressive
12:54:06 mordred \o/
12:54:16 samueldmq :D
13:56:51 openstackgerrit Merged openstack/openstacksdk master: Fix list_recordsets to deal with top-level key https://review.openstack.org/600441
15:35:15 mnaser mordred: in my triaging ... https://github.com/ansible/ansible/issues/36286 seems like a REALLY weird bug
15:37:32 mnaser i dunno.. it doesnt make sense that shade would do that
15:37:39 mnaser but maybe there is behaviour that does that?
15:42:50 mordred mnaser: I can't think of any - that's super strange
15:44:14 mnaser mordred: yeah.. weird :\
15:44:23 mnaser i wonder if like somehow ansible is filtering things
16:29:13 mnaser mordred: do you know if ansible modules has a 'rule' of supporting a certain range of openstack clouds?
16:29:33 mnaser i.e. https://github.com/ansible/ansible/issues/24786 seems to be probably because it's against a kilo deployment
16:29:45 mnaser so not sure if there's some "we aim to support X openstack releases"
21:52:08 mordred mnaser: the general support policy is mostly based on that of openstacksdk - which is "all of them"

Earlier   Later