Thursday, 2020-03-05

*** slaweq has joined #openstack-sdks00:11
openstackgerritMerged openstack/openstacksdk master: Handle old status-less placement service  https://review.opendev.org/71132800:20
*** slaweq has quit IRC00:27
*** slaweq has joined #openstack-sdks01:11
*** slaweq has quit IRC01:16
*** tkajinam has quit IRC01:49
*** tkajinam has joined #openstack-sdks01:50
*** slaweq has joined #openstack-sdks02:11
*** enriquetaso has joined #openstack-sdks02:14
*** slaweq has quit IRC02:16
*** enriquetaso has quit IRC02:31
*** slaweq has joined #openstack-sdks03:11
*** slaweq has quit IRC03:16
*** slaweq has joined #openstack-sdks04:11
*** slaweq has quit IRC04:16
*** slaweq has joined #openstack-sdks05:11
*** evrardjp has quit IRC05:35
*** evrardjp has joined #openstack-sdks05:35
*** slaweq has quit IRC05:38
*** factor has quit IRC05:47
*** factor has joined #openstack-sdks05:48
*** efried has quit IRC06:07
*** efried1 has joined #openstack-sdks06:07
*** efried1 is now known as efried06:09
*** efried has quit IRC07:22
*** efried has joined #openstack-sdks07:22
*** efried has quit IRC07:23
*** efried has joined #openstack-sdks07:23
*** iurygregory has joined #openstack-sdks07:56
*** tkajinam has quit IRC08:16
*** ralonsoh has joined #openstack-sdks08:22
*** jpena|off is now known as jpena08:26
*** jpich has joined #openstack-sdks09:01
*** Shrews has quit IRC09:07
*** dayou has quit IRC09:07
*** iokiwi has quit IRC09:08
*** irclogbot_2 has quit IRC09:08
*** gtema has joined #openstack-sdks09:08
*** gtema has quit IRC09:15
*** tosky has joined #openstack-sdks09:25
*** sshnaidm|afk is now known as sshnaidm09:37
*** Shrews has joined #openstack-sdks09:43
*** dayou has joined #openstack-sdks09:43
*** iokiwi has joined #openstack-sdks09:43
*** irclogbot_2 has joined #openstack-sdks09:43
*** openstackstatus has quit IRC09:45
*** dtantsur|afk is now known as dtantsur10:24
dtantsurmordred: yep, as far as I remember, futurist extends stdlib10:26
*** slaweq has joined #openstack-sdks11:18
openstackgerritMerged openstack/openstacksdk master: Add port property: ip_allocation  https://review.opendev.org/71123711:43
mgoddardI think ansible 2.9.6 has broken openstack modules12:06
mgoddardwe're seeing this everywhere in kolla:12:06
mgoddardhttps://b317bafa0db642d61e9b-babe6b68bec526aecbe80deed799da2b.ssl.cf2.rackcdn.com/711295/3/check/kolla-ansible-centos-source/b02cb5e/primary/logs/ansible/deploy12:06
mgoddardpy2 and py312:06
*** jpena is now known as jpena|lunch12:09
*** slaweq has quit IRC12:18
*** slaweq has joined #openstack-sdks12:30
*** slaweq has quit IRC12:34
*** jpich has quit IRC12:40
*** jpich has joined #openstack-sdks12:41
*** dave-mccowan has joined #openstack-sdks13:09
*** enriquetaso has joined #openstack-sdks13:25
openstackgerritMerged openstack/openstacksdk master: Implement If-Match support for Neutron resources  https://review.opendev.org/71003013:30
fricklermordred: you just got me slightly confused by adding sdk core to osc core, doesn't that preempt the governance patch a bit?13:45
*** mgariepy has quit IRC13:46
*** mgariepy has joined #openstack-sdks13:52
openstackgerritMerged openstack/openstacksdk master: Include "fields" to "SecurityGroup" query parameters  https://review.opendev.org/71082014:00
mgoddardodyssey4me: hi14:22
*** jpena|lunch is now known as jpena14:29
*** ccamel has joined #openstack-sdks14:41
*** camelCaser has quit IRC14:42
mordredmgoddard: 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 node14:50
mgoddardmordred: I have more info14:50
mordredfrickler: 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 myself14:50
mgoddardmordred: see my comment on https://github.com/ansible/ansible/pull/67577/files14:50
mgoddardit's an easy fix14:50
mgoddardjust patching up kolla then I'll raise a bug in ansible and push a fix14:51
mgoddardseems like everything is breaking this week14:51
mordredaha! cool. and yes - it does seem that way14:51
mordredmgoddard: fwiw - once we've switched the modules to the collection, we can co-gate them on kolla14:51
mordredand prevent stuff like that14:52
mgoddardmordred: I think the existing jobs would have caught it. It was a bit of custom code for 2.8 in a backport14:52
mordredAH14:52
mgoddardlooks like no CI for 2.8?14:52
mordredyeah - I don't think we run openstack jobs on stable-2.8 - which is probably a mistake :)14:53
mordredlet me go see if I can rectify that14:53
mgoddardthat would be nice14:54
openstackgerritMonty Taylor proposed openstack/openstacksdk master: Add ansible stable-2.9 job and run 2.8 and 2.9  https://review.opendev.org/71147114:57
mordredmgoddard: ^^ that - and remote:   https://review.opendev.org/711474 Run openstacksdk functional jobs on ansible 2.8 and 2.914:58
mordredand yeah - if the tests had been hooked up that should have caught that14:59
mordredmgoddard: ping me when you push up the ansible fix and I can lgtm it14:59
openstackgerritMonty Taylor proposed openstack/openstacksdk master: Switch to futurist for concurrency  https://review.opendev.org/71130115:06
mordreddtantsur: that one ^^ should be green now15:07
openstackgerritMonty Taylor proposed openstack/ansible-collections-openstack master: Deal with collection build modifying tree  https://review.opendev.org/71103315:08
openstackgerritMonty Taylor proposed openstack/ansible-collections-openstack master: Fix license metadata  https://review.opendev.org/71103515:08
openstackgerritMonty Taylor proposed openstack/ansible-collections-openstack master: Clean up minor build quibbles  https://review.opendev.org/71103615:08
dtantsurnice!15:12
mordredbrtknr: 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.html15:12
mordredbrtknr: this makes me think our devstack job is not configured properly ... do you know anything about magnum devstack job config?15:13
mordreddtantsur: and yeah - I think that's a nice improvement and should let us make things nicer without making sdk unuable in the services15:14
Shrewsoh good. i was also trying to reproduce the strictversion thing without success. glad to page irc back in and see the issue was found15:17
*** efried is now known as efried_gone15:18
mgoddardmordred: https://github.com/ansible/ansible/pull/6804315:18
rm_workwhat is the plan for the next SDK release?15:20
mgoddardmordred, Shrews: I'll send something to the ML about ansible 2.8.9. Any [tags] I should use?15:22
rm_work(I ask about the next release, because I need to use the feature I just added in a client change)15:23
mordredbrtknr: 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 cloud15:26
mordredrm_work: I think we're pretty good for a next release - all of the recent things people need have landed - let me double check that15:26
* Shrews refrains from grumbling outloud about magnum testing15:27
Shrewsthough maybe i just did15:27
mordredShrews: 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 config15:32
mordredShrews: check https://zuul.opendev.org/t/openstack/build/9a10a15e2a2e4af18021948078429d1c/log/job-output.txt#5035115:33
Shrewsyep, 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 broken15:34
mordredyeah - except randomly today I'm worried that there's some basic sdk bug15:35
mordredbecause it's _no_ disabled by config in the clouds.yaml15:35
mordredso even if magnum is broken - we're at the very least returning the wrong error here15:35
openstackgerritSagi Shnaidman proposed openstack/ansible-collections-openstack master: Add Openstack guidelines spec from Ansible  https://review.opendev.org/70455815:40
elmikoAPI SIG office hour now open \o/16:00
mordredelmiko: does that mean it's time to start drinking?16:01
elmikohmm, not a bad idea XD16:01
toskyfrom 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 details16:12
toskydo I get it correctly?16:12
dtantsuro/16:12
* dtantsur agrees with dtantsur16:12
elmikotosky: that makes sense to me, fwiw16:14
elmikoone question though, by "last possible microversion" do you mean the highest version or lowest?16:15
toskyhighest - as in "I want all the supported features"16:16
*** KeithMnemonic1 has joined #openstack-sdks16:19
mordredso ...16:20
elmikotosky: ack, thanks16:20
mordredthere'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 dtantsur16:20
mordredbut 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 that16:22
mordredto 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 sdk16:22
mordredin many cases those patches to sdk are trivial16:22
mordredand *much* less work than the corresponding work to add the new api feature16:23
*** KeithMnemonic has quit IRC16:23
mordredbut 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 people16:23
mordredin 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 quickly16:25
openstackgerritMonty Taylor proposed openstack/python-openstackclient master: Build utility image for using osc  https://review.opendev.org/71124616:28
toskythanks16:31
toskyone 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 feature16:34
toskyfeatures*16:34
toskythat's it16:34
dtroyertosky: 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 required16:38
openstackgerritMerged openstack/ansible-collections-openstack master: Deal with collection build modifying tree  https://review.opendev.org/71103316:39
openstackgerritMerged openstack/ansible-collections-openstack master: Fix license metadata  https://review.opendev.org/71103516:39
openstackgerritMerged openstack/ansible-collections-openstack master: Clean up minor build quibbles  https://review.opendev.org/71103616:39
openstackgerritMerged openstack/ansible-collections-openstack master: Add Openstack guidelines spec from Ansible  https://review.opendev.org/70455816:39
mordreddtroyer, 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 complications16:43
mordredI think it should be fine16:43
mordredbecause 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 following16:43
dtroyermordred: 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
toskymordred: 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
toskyIMHO16:45
dtroyerI have not followed the latest round closely at all so no idea if it has happened again this time16:46
mordredtosky: yes, I agree16:46
mordredalthough 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 users16:46
mordredbut in terms of osc operational functionality - yeah - it's largely an impl detail that if we do our jobs right nobody will notice16:47
toskyreduced 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 functionalities16:49
mugsiemordred: will it though? designate users still have to install the python-designateclient package to get the OSC plugin, same for octavia / trove / $<project>16:50
toskyright, that's different for plugins16:51
toskybut let's not go into the "make everything a plugin" thing :D16:51
mordredI'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 now16:51
mugsietosky: it is almost like you have seen my newsletter :)16:52
mugsiemordred: yeah, it is a can of worms that is not useful right now I suppose16:52
mordredyup. one thing at a time :)16:52
openstackgerritTom Stappaerts proposed openstack/openstacksdk master: Support for stateless security groups  https://review.opendev.org/71151316:54
openstackgerritTom Stappaerts proposed openstack/python-openstackclient master: Support for stateless security groups  https://review.opendev.org/71151516:57
dtroyermugsie: 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 team17:00
mordred++17:01
mordredwe'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 on17:02
elmikoi'm stepping out, hope you all have a lovely weekend =)17:03
mordredso - over time I think these are areas ripe for exploration - but certainly we shouldn't block parity goals on any of it17:03
mordreddtroyer: 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 burden17:13
toskyuhm, why would they be a problem for frige plugins like manila or octavia? It's not like they would need core changes17:20
*** jpich has quit IRC17:22
brtknrmordred: sorry just saw your ping from earlier, I am not super familiar with the CI side of things17:23
brtknrmordred: have you cut a new release yet?17:26
brtknrim just about to propose another fix17:26
smcginnismordred, 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:29
toskysmcginnis: 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 me17:30
dtroyersmcginnis: 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 progress17:34
*** evrardjp has quit IRC17:35
mordredbrtknr: I havne't - go for it!17:35
*** evrardjp has joined #openstack-sdks17:35
mordredsmcginnis: yeah - I think the most important thing is keeping them distinct - otherwise it's too much17:36
mordredsmcginnis: 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 happiness17:36
mordreddoing 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 convert17:38
smcginnisTrue. But seems like it could make it a little easier for some folks if that got done.17:38
mordredsmcginnis: I honestly don't know which I think is the better choice - or would give people the greatest amount of "job well done" satisfaciton17:39
smcginnisAnd part of my thought was avoiding that extra work too.17:39
mordredyeah17:39
smcginnisHonestly, 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:39
*** dtantsur is now known as dtantsur|afk17:40
mordredsmcginnis: ++17:43
mordredI thnk very much that17:43
openstackgerritBharat Kunwar proposed openstack/openstacksdk master: Normalise create_coe_cluster{,_template} results  https://review.opendev.org/71152618:04
brtknrmordred: Shrews ^18:04
mordredbrtknr: cool. also - please see mailing list - I mayhave just mentioned you ...18:06
brtknrmordred: will do18:08
brtknrbtw why is the json encapsulated inside baybodel= in https://review.opendev.org/#/c/711526/1/openstack/tests/unit/cloud/test_coe_clusters.py line 6618:08
mordredbrtknr: the validate parameter is for validating json sent to the api call18:09
mordredthe normal json parameter is for specifying what the fake http call should return18:10
brtknrthe fake http call should return a thing without the baymodel bit18:10
mordredoh- I get yourquestion now18:10
mordredit's entirely possible it's a bug in the test then18:11
brtknrand the validate part i removed because it didnt seem to matter whether it was there or not18:11
*** slaweq has joined #openstack-sdks18:11
mordredbrtknr: 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 break18:11
mordredit's testing the other side of the interaction - that the sdk call produces the correct payload to send to the server18:12
mordredit's probably not super important in this case since we're not really transforming the input18:12
brtknrah makes sense18:13
*** jpena is now known as jpena|off18:26
brtknrmordred: 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 there18:30
brtknrbut in post requests, it would rather it was not there18:30
mordredbrtknr: does magnum not have a top level baymodels: [] in its list response?18:38
mordredbrtknr: https://docs.openstack.org/api-ref/container-infrastructure-management/?expanded=list-all-baymodels-detail#id3418:39
*** umbSublime has quit IRC18:39
mordredbrtknr: GET /baymodels returns {'baymodels': [ {}, {} ] }18:39
mordredso we need the baymodels= there18:39
mordredI agree - inthe response for the POST - there should be no top level baymodel or baymodels18:40
mordrednor in teh request18:40
mordredhttps://docs.openstack.org/api-ref/container-infrastructure-management/?expanded=create-new-baymodel-detail#id2518:41
*** slaweq has quit IRC18:47
brtknrmordred: nice to see it confirmed18:55
openstackgerritMonty Taylor proposed openstack/openstacksdk master: Fix service_type test for magnum in gate  https://review.opendev.org/71153318:56
openstackgerritBharat Kunwar proposed openstack/openstacksdk master: Normalise create_coe_cluster{,_template} results  https://review.opendev.org/71152618:56
mordredbrtknr, Shrews: ^^ that should fix the magnum tests in the gate18:56
*** ralonsoh has quit IRC18:57
brtknrWow thats a mouthful, I did not know that18:57
mordred(711533 that is)18:57
Shrewsmordred: are we taking bets that the tests still work?   ;)18:58
mordredShrews: nope!18:58
mordredShrews: but - they should at least RUN now and fail as tests :)18:58
mordredbrtknr: https://service-types.openstack.org/service-types.json18:58
mordredor more specifically: https://opendev.org/openstack/service-types-authority/src/branch/master/service-types.yaml#L4118:59
*** slaweq has joined #openstack-sdks18:59
mordredfor normal users it should work to refer by official type or any of the aliases18:59
mordredbut we wrote the has_service to be strict :)18:59
*** slaweq has quit IRC19:04
brtknrmordred: ouch19:08
mordredyah19:30
*** stingrayza has quit IRC20:18
*** stingrayza has joined #openstack-sdks20:19
*** slaweq has joined #openstack-sdks20:48
*** sshnaidm is now known as sshnaidm|afk20:48
*** umbSublime has joined #openstack-sdks20:50
*** enriquetaso has quit IRC20:54
umbSublimeHey another quick question related to os-client-config. I just noticed from the README that it was superceded by the sdk, but I'm not sure how I can reproduce even a basic call like `os_client_config.OpenStackConfig().get_all_clouds()` I just want to have an object representing the clouds.yaml without having to parse it myself20:56
*** johnsom has left #openstack-sdks21:02
umbSublimederr nvm just found it under openstack.config ...21:02
openstackgerritMonty Taylor proposed openstack/openstacksdk master: Set max_microversion to 2.53 for hypervisors  https://review.opendev.org/71129421:08
mordredumbSublime: \o/21:09
mordredumbSublime: yeah - os_client_config moved to openstack.config ... perhaps we should update the readme to point more specifically21:09
openstackgerritMonty Taylor proposed openstack/openstacksdk master: Normalise create_coe_cluster{,_template} results  https://review.opendev.org/71152621:11
mordredShrews, brtknr: my patch above fixed the magnum functional tests - so I added a depends-on between brtknr's patch and mine so we can make sure that doesnt' break functional tests (I'm pretty sure it's ok - but we have green functional tests - so why not!)21:12
*** gtema has joined #openstack-sdks21:17
*** gtema has quit IRC21:22
*** stingrayza has quit IRC21:31
*** stingrayza has joined #openstack-sdks21:31
umbSublimetbh If I would've searched 2 minutes more before posting, it would've been fine. It wouldn't hurt though. (btw thanks for updating topic on the chan)21:32
*** slaweq has quit IRC21:33
umbSublimeis cliff also maintained by the SDK team ?21:56
Shrewsno22:13
mordredShrews: well ...22:14
mordredumbSublime: there is a proposal up to merge the sdk and osc teams - so assuming that goes through (there is currently no dissent) the answer becomes "yes"22:14
Shrewsosc team maintained cliff? heh22:15
ShrewsTIL22:16
*** iurygregory has quit IRC22:18
brtknrmordred Shrews: thanks for the merge!22:22
brtknrglad you fixed the ci too!22:22
brtknrWhat does the magnum job do out of interest?22:23
mordredbrtknr: it makes sure that there is a magnum running in the devstack and then runs the openstacksdk functional tests against that devstack22:24
mordredbrtknr: so - you can totally add magnum related functional tests and they'll run in that job22:24
mordredobviously nested virt makes doing a _lot_ in functional tests somewhat heavy weight - so I don't think we have many magnum related functional tests today22:25
*** tkajinam has joined #openstack-sdks22:45
*** enriquetaso has joined #openstack-sdks23:56

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!