Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2020-03-04
21:26:09 mordred umbSublime: thak you - that was very helpful debugging info - and I imagine you won't be the only one to hit that
21:31:48 umbSublime That was the easy part ;)
21:36:25 openstackgerrit Monty Taylor proposed openstack/python-openstackclient master: Add bindep file https://review.opendev.org/711055
21:36:25 openstackgerrit Monty Taylor proposed openstack/python-openstackclient master: Build utility image for using osc https://review.opendev.org/711246
22:04:25 openstackgerrit Sam Morrison proposed openstack/python-openstackclient master: Always display direction for security group rules https://review.opendev.org/709017
22:05:19 openstackgerrit Sam Morrison proposed openstack/python-openstackclient master: Always display direction for security group rules https://review.opendev.org/709017
22:22:03 openstackgerrit Merged openstack/ansible-collections-openstack master: Fix H236 and remove exclusion https://review.opendev.org/698066
22:27:00 openstackgerrit Merged openstack/ansible-collections-openstack master: Remove from __future__ lines https://review.opendev.org/698067
22:27:01 openstackgerrit Merged openstack/ansible-collections-openstack master: Test with and assert support for python3 https://review.opendev.org/710641
22:57:07 openstackgerrit Merged openstack/openstacksdk master: Fix: Set image name correctly if filename is not passed https://review.opendev.org/710368
23:19:52 openstackgerrit Merged openstack/openstacksdk stable/train: Handle HTTP errors in add/remove router interface calls https://review.opendev.org/710994
23:19:56 openstackgerrit Merged openstack/openstacksdk stable/train: Fix error handling on add/remove router iface calls https://review.opendev.org/710995
#openstack-sdks - 2020-03-05
00:20:16 openstackgerrit Merged openstack/openstacksdk master: Handle old status-less placement service https://review.opendev.org/711328
10:26:19 dtantsur mordred: yep, as far as I remember, futurist extends stdlib
11:43:29 openstackgerrit Merged openstack/openstacksdk master: Add port property: ip_allocation https://review.opendev.org/711237
12:06:01 mgoddard I think ansible 2.9.6 has broken openstack modules
12:06:12 mgoddard we're seeing this everywhere in kolla:
12:06:15 mgoddard https://b317bafa0db642d61e9b-babe6b68bec526aecbe80deed799da2b.ssl.cf2.rackcdn.com/711295/3/check/kolla-ansible-centos-source/b02cb5e/primary/logs/ansible/deploy
12:06:18 mgoddard py2 and py3
13:30:38 openstackgerrit Merged openstack/openstacksdk master: Implement If-Match support for Neutron resources https://review.opendev.org/710030
13:45:16 frickler mordred: you just got me slightly confused by adding sdk core to osc core, doesn't that preempt the governance patch a bit?
14:00:45 openstackgerrit Merged openstack/openstacksdk master: Include "fields" to "SecurityGroup" query parameters https://review.opendev.org/710820
14:22:52 mgoddard odyssey4me: hi
14:50:22 mordred mgoddard: AWESOME. I'm poking and trying to reproduce the traceback at the moment but havne't been able to yet - might need to hold a test node
14:50:39 mgoddard mordred: I have more info
14:50:48 mordred frickler: yeah - I was in there doing core team update from the mailing list and figured I just go ahead and take care f that too ... might be a little ahead of myself
14:50:51 mgoddard mordred: see my comment on https://github.com/ansible/ansible/pull/67577/files
14:50:56 mgoddard it's an easy fix
14:51:11 mgoddard just patching up kolla then I'll raise a bug in ansible and push a fix
14:51:21 mgoddard seems like everything is breaking this week
14:51:27 mordred aha! cool. and yes - it does seem that way
14:51:57 mordred mgoddard: fwiw - once we've switched the modules to the collection, we can co-gate them on kolla
14:52:03 mordred and prevent stuff like that
14:52:42 mgoddard mordred: I think the existing jobs would have caught it. It was a bit of custom code for 2.8 in a backport
14:52:50 mordred AH
14:52:51 mgoddard looks like no CI for 2.8?
14:53:08 mordred yeah - I don't think we run openstack jobs on stable-2.8 - which is probably a mistake :)
14:53:14 mordred let me go see if I can rectify that
14:54:06 mgoddard that would be nice
14:57:26 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Add ansible stable-2.9 job and run 2.8 and 2.9 https://review.opendev.org/711471
14:58:48 mordred mgoddard: ^^ that - and remote: https://review.opendev.org/711474 Run openstacksdk functional jobs on ansible 2.8 and 2.9
14:59:21 mordred and yeah - if the tests had been hooked up that should have caught that
14:59:49 mordred mgoddard: ping me when you push up the ansible fix and I can lgtm it
15:06:54 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Switch to futurist for concurrency https://review.opendev.org/711301
15:07:10 mordred dtantsur: that one ^^ should be green now
15:08:33 openstackgerrit Monty Taylor proposed openstack/ansible-collections-openstack master: Deal with collection build modifying tree https://review.opendev.org/711033
15:08:39 openstackgerrit Monty Taylor proposed openstack/ansible-collections-openstack master: Fix license metadata https://review.opendev.org/711035
15:08:45 openstackgerrit Monty Taylor proposed openstack/ansible-collections-openstack master: Clean up minor build quibbles https://review.opendev.org/711036
15:12:51 dtantsur nice!
15:12:52 mordred brtknr: the magnum function tests for sdk seem to always be failing - and it seems to be related to detecting magnum: https://4689b6461ef076a1f80e-32e19aab5c30ebc59039fa10c249436d.ssl.cf5.rackcdn.com/711301/1/check/openstacksdk-functional-devstack-magnum/9a10a15/testr_results.html
15:13:30 mordred brtknr: this makes me think our devstack job is not configured properly ... do you know anything about magnum devstack job config?
15:14:24 mordred dtantsur: and yeah - I think that's a nice improvement and should let us make things nicer without making sdk unuable in the services
15:17:50 Shrews oh good. i was also trying to reproduce the strictversion thing without success. glad to page irc back in and see the issue was found
15:18:10 mgoddard mordred: https://github.com/ansible/ansible/pull/68043
15:20:25 rm_work what is the plan for the next SDK release?
15:22:29 mgoddard mordred, Shrews: I'll send something to the ML about ansible 2.8.9. Any [tags] I should use?
15:23:47 rm_work (I ask about the next release, because I need to use the feature I just added in a client change)
15:26:30 mordred brtknr: https://zuul.opendev.org/t/openstack/build/9a10a15e2a2e4af18021948078429d1c/log/job-output.txt#50351 this might have something to do with it - from what I can tell magnum IS running in that cloud
15:26:52 mordred rm_work: I think we're pretty good for a next release - all of the recent things people need have landed - let me double check that
15:27:37 Shrews though maybe i just did
15:32:42 mordred Shrews: yeah - although this one seems weird - it seems like the magnum is completely there and operational - and we're detecting that it's been disabled by config
15:33:31 mordred Shrews: check https://zuul.opendev.org/t/openstack/build/9a10a15e2a2e4af18021948078429d1c/log/job-output.txt#50351
15:34:41 Shrews yep, that's what i saw when i looked at it last. until we make other groups care about supporting their services into sdk/osc instead of expecting us to have deep knowledge on all-the-things, it probably doesn't matter that it's broken
15:35:01 mordred yeah - except randomly today I'm worried that there's some basic sdk bug
15:35:19 mordred because it's _no_ disabled by config in the clouds.yaml
15:35:56 mordred so even if magnum is broken - we're at the very least returning the wrong error here
15:40:55 openstackgerrit Sagi Shnaidman proposed openstack/ansible-collections-openstack master: Add Openstack guidelines spec from Ansible https://review.opendev.org/704558
16:00:46 elmiko API SIG office hour now open \o/
16:01:06 mordred elmiko: does that mean it's time to start drinking?
16:01:43 elmiko hmm, not a bad idea XD
16:12:10 tosky from the flam^H^H^H^Hdiscussion on the list and dtantsur's comment, it seems to me that having OSC autonegotiating the last possible microversion is a good thing, because the high level clients should be user-focused and hide the details
16:12:14 tosky do I get it correctly?
16:12:43 dtantsur o/
16:14:51 elmiko tosky: that makes sense to me, fwiw
16:15:30 elmiko one question though, by "last possible microversion" do you mean the highest version or lowest?
16:16:21 tosky highest - as in "I want all the supported features"
16:20:25 mordred so ...
16:20:49 elmiko tosky: ack, thanks
16:20:56 mordred there's some good scrollback in here from yesterday between me and umbSublime where I explained a slightly altered view of that but which mostly agrees with dtantsur
16:22:05 mordred but the tl;dr is that a) I agree with that as a goal but b) sdk needs to know what the 'latest' microversion it can undersatnd without blowing up is - because if it's expecting a response and a microversion radically changes it, it needs to know how to deal with that
16:22:46 mordred to me this means that we should in fact strict to always get the latest microversion - and in a perfect world part of the process of adding a new microversion to a service would also be coming and adding a quick mv bump to sdk
16:22:55 mordred in many cases those patches to sdk are trivial
16:23:16 mordred and *much* less work than the corresponding work to add the new api feature
16:23:43 mordred but in some cases they might be more complex - and will require a conversation about how to expose the feature in a way that doesn't break people
16:25:29 mordred in some places we're behind and we need to catch up. in other places, like ironic - people like dtantsur are really good about coming in and bumping the max_microversion and adding fields really quickly
16:28:34 openstackgerrit Monty Taylor proposed openstack/python-openstackclient master: Build utility image for using osc https://review.opendev.org/711246
16:31:45 tosky thanks
16:34:00 tosky one thing I'd like to point out for the (probably) upcoming goal of making OSC on par with the custom clients: I think it may makes sense in some cases to decouple the improvements OSC and the migration to SDK, if the latter means waiting on a tons of non-implemented feature
16:34:04 tosky features*
16:34:06 tosky that's it
16:38:40 dtroyer tosky: that point seems to get blurred a lot when this topic comes up so thanks for pointing it out. It may not be the last time it is required
16:39:07 openstackgerrit Merged openstack/ansible-collections-openstack master: Deal with collection build modifying tree https://review.opendev.org/711033
16:39:08 openstackgerrit Merged openstack/ansible-collections-openstack master: Fix license metadata https://review.opendev.org/711035
16:39:09 openstackgerrit Merged openstack/ansible-collections-openstack master: Clean up minor build quibbles https://review.opendev.org/711036
16:39:10 openstackgerrit Merged openstack/ansible-collections-openstack master: Add Openstack guidelines spec from Ansible https://review.opendev.org/704558
16:43:01 mordred dtroyer, tosky: totally agree. I mostly bring up the SDK parts so that as we work on that upcoming goal we keep in mind the above behavior so that we don't add any enw complications
16:43:10 mordred I think it should be fine
16:43:51 mordred because by and large people are already keepig python-*client up to date with their latest microversions - so the process of "add mv to server and also make sure client isn't going to bomb out" is a process humans are already following
16:45:46 dtroyer mordred: right, it isn't so much the mv work itself, more of the way folks have talked about the larger goals and mixing sdk transition with other osc needs, ie cli parity. the goal talk got bogged down a couple of times previously because of that.
16:45:51 tosky mordred: the point is: moving to OSC is one thing; changing the internal implementation of OSC is another process, which is important for the developers, but definitely less relevant for the users (as it should be transparent)

Earlier   Later