Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2020-03-05
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
17:38:55 smcginnis True. But seems like it could make it a little easier for some folks if that got done.
17:39:02 mordred smcginnis: I honestly don't know which I think is the better choice - or would give people the greatest amount of "job well done" satisfaciton
17:39:12 smcginnis And part of my thought was avoiding that extra work too.
17:39:13 mordred yeah
17:39:55 smcginnis Honestly, I'd rather not have a cycle goal for it and just have a clear plan to work towards. Then when things get closer to actually being something that could even be accomplished in one cycle, then make it a goal.
17:43:23 mordred smcginnis: ++
17:43:26 mordred I thnk very much that
18:04:57 openstackgerrit Bharat Kunwar proposed openstack/openstacksdk master: Normalise create_coe_cluster{,_template} results https://review.opendev.org/711526
18:04:59 brtknr mordred: Shrews ^
18:06:48 mordred brtknr: cool. also - please see mailing list - I mayhave just mentioned you ...
18:08:21 brtknr mordred: will do
18:08:45 brtknr btw why is the json encapsulated inside baybodel= in https://review.opendev.org/#/c/711526/1/openstack/tests/unit/cloud/test_coe_clusters.py line 66
18:09:45 mordred brtknr: the validate parameter is for validating json sent to the api call
18:10:06 mordred the normal json parameter is for specifying what the fake http call should return
18:10:39 brtknr the fake http call should return a thing without the baymodel bit
18:10:52 mordred oh- I get yourquestion now
18:11:13 mordred it's entirely possible it's a bug in the test then
18:11:25 brtknr and the validate part i removed because it didnt seem to matter whether it was there or not
18:11:50 mordred brtknr: we might want to keep the validate portion though - the call will still work - but you can see the results if you change the contents of it it should break
18:12:08 mordred it's testing the other side of the interaction - that the sdk call produces the correct payload to send to the server
18:12:36 mordred it's probably not super important in this case since we're not really transforming the input
18:13:59 brtknr ah makes sense
18:30:05 brtknr mordred: here's the weird thing, if i remove the baymodels= in the GET requests, tox -e py36 fails as it expects baymodels= part to be there
18:30:25 brtknr but in post requests, it would rather it was not there
18:38:49 mordred brtknr: does magnum not have a top level baymodels: [] in its list response?
18:39:19 mordred brtknr: https://docs.openstack.org/api-ref/container-infrastructure-management/?expanded=list-all-baymodels-detail#id34
18:39:46 mordred brtknr: GET /baymodels returns {'baymodels': [ {}, {} ] }
18:39:58 mordred so we need the baymodels= there
18:40:49 mordred I agree - inthe response for the POST - there should be no top level baymodel or baymodels
18:40:56 mordred nor in teh request

Earlier   Later