Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2020-03-05
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)
16:45:53 tosky IMHO
16:46:11 dtroyer I have not followed the latest round closely at all so no idea if it has happened again this time
16:46:20 mordred tosky: yes, I agree
16:46:58 mordred although I will add there is _one_ user-facing thing about sdk transition - and that's that it results in less depends being installed, so it's not a completely irellevant for users
16:47:33 mordred but in terms of osc operational functionality - yeah - it's largely an impl detail that if we do our jobs right nobody will notice
16:49:58 tosky reduced dependency footprint is veeery nice, but really, either you go with distro packages, or pip, or containers, and it's not as important as the functionalities
16:50:21 mugsie mordred: will it though? designate users still have to install the python-designateclient package to get the OSC plugin, same for octavia / trove / $<project>
16:51:16 tosky right, that's different for plugins
16:51:27 tosky but let's not go into the "make everything a plugin" thing :D
16:51:54 mordred I'd like to see less plugins, not more. but I think we've got enough on our plate for now than to think about that for now
16:52:19 mugsie tosky: it is almost like you have seen my newsletter :)
16:52:47 mugsie mordred: yeah, it is a can of worms that is not useful right now I suppose
16:52:58 mordred yup. one thing at a time :)
16:54:09 openstackgerrit Tom Stappaerts proposed openstack/openstacksdk master: Support for stateless security groups https://review.opendev.org/711513
16:57:35 openstackgerrit Tom Stappaerts proposed openstack/python-openstackclient master: Support for stateless security groups https://review.opendev.org/711515
17:00:54 dtroyer mugsie: fwiw I've bought in to the notion that as APIs transition to the SDK putting the CLI in-repo is much less of an obstacle for user experience, which was one of the primary drivers for the plugins. The other driver of course was team autonomy, that part of the decision lies with each team
17:01:38 mordred ++
17:02:58 mordred we've also been having good success in sdk so far with giving core to project-specific people so teams can keep taking care of their own stuff - turns out pepole have large review loads anyway so they don't tend to go reviewing patches broadly where they don't know what's going on
17:03:32 elmiko i'm stepping out, hope you all have a lovely weekend =)
17:03:35 mordred so - over time I think these are areas ripe for exploration - but certainly we shouldn't block parity goals on any of it
17:13:09 mordred dtroyer: I thnik that's a good way to think of potentially pulling thing in tree - as plugins get reworked to be sdk-based, pulling them in tree starts to be less of a combinatorial burden
17:20:31 tosky uhm, why would they be a problem for frige plugins like manila or octavia? It's not like they would need core changes
17:23:53 brtknr mordred: sorry just saw your ping from earlier, I am not super familiar with the CI side of things
17:26:18 brtknr mordred: have you cut a new release yet?
17:26:24 brtknr im just about to propose another fix
17:29:48 smcginnis mordred, dtroyer, tosky: Since getting things into the SDK does simplify things, and as a way to break things into smaller pieces, would it actually make sense to try to have one cycle goal to get everything into the SDK, then another cycle goal after that to have OSC parity and start deprecating the per-service CLIs?
17:30:49 tosky smcginnis: from what I hear around one cycle for SDK parity may not be enough and the current effort may lose momentum, but not up to me
17:34:52 dtroyer smcginnis: I recall that exact discussion previously, I think in Vancouver. I was a bit distracted that week by the introduction of stalingx so I don't recall the particulars. I do agree that keeping those things distinct is important to make community-wide progress
17:35:29 mordred brtknr: I havne't - go for it!
17:36:07 mordred smcginnis: yeah - I think the most important thing is keeping them distinct - otherwise it's too much
17:36:59 mordred smcginnis: I could see value in both directions - there's value in sdk-parity-first - because that also allows exposing to things like ansible and salt- but it has the drawback of not increasing tim bell's happiness
17:38:20 mordred doing osc-parity first would make tim bell happy and would likely be less work for a chunk of people (I think therea re more people with osc plugins than people with comprehensive sdk code) ... but it might result in increasing the surface area of work for a future "now convert osc plugins to sdk" - since there would potentially be _more_ osc plugin code to convert

Earlier   Later