Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2020-03-02
16:53:51 mordred that _is_ the situation most users will encounter - they won't see uuid unless they install an as-yet-unreleased sdk :)
16:54:17 brtknr mordred: is it correct that when a cluster gets *created* then uuid is returned?
16:54:35 brtknr shouldn't the uuid get normalised in the same way for create requests too?
16:54:38 mordred it shouldn't - it should be the same data structure all the time
16:54:40 mordred yup
16:55:07 brtknr ok so thats another bummer, it returns uuid at present
16:55:15 brtknr when cluster get created
16:55:29 mordred wow really?
16:56:09 brtknr yes sorry
16:56:20 mordred so that means we're not running normalize on the result of create - which is sadmaking. maybe we need to do a workaround in the ansible module itself
16:56:53 mordred to grab the id in both cases with a get('id', get('uuid') - then make sure both id and uuid are set in the dict before we return to teh ansible user
16:57:03 mordred cause otherwise this is just a mess for the user
16:58:31 brtknr that is the premise of the patch
16:58:50 brtknr its what i am already proposing we do with that patch
17:00:01 mordred cool. then yes - I think we should land that patch asap
17:00:13 mordred Shrews: ^^ feel like an easy +A? I know you like patches with no context
17:00:25 Shrews so much
17:00:27 brtknr :D
17:00:38 mordred brtknr: oh - actually - one more thing...
17:01:47 mordred brtknr: real quick ... or I can update the patch if you're packing up
17:01:54 mordred brtknr: (left inline comment)
17:02:10 Shrews mordred: let's pretend i haven't read the backscroll yet. is 709734 the thing you referred to?
17:03:08 Shrews that looks doubtful. /me just reads bs
17:03:12 mordred Shrews: yes. and the tl;dr is that normalization of cluster_template dicts is blown and we forgot to add the 'uuid' field back to the dict, but the ansible docs and module refer to uuid not id
17:04:07 mordred there's an sdk fix to add uuid - but of course latest module doesn't mean latest sdk - so there's also a patch to the module to work around the fact that it might not get uuid back - but a user might be expecting it to exist because of the docs saying it's there
17:07:25 brtknr mordred: done
17:07:26 openstackgerrit Bharat Kunwar proposed openstack/ansible-collections-openstack master: os_coe_cluster: Retrive id/uuid correctly https://review.opendev.org/709734
17:08:05 mordred brtknr: thanks!
17:08:16 brtknr is cluster['id'] = cluster['uuid'] = cluster_id okay?
17:08:39 Shrews shouldn't the changelog fragment at least mention the module being fixed? not sure that that is clear when just reading the resulting log
17:08:39 brtknr mordred: or is that bad practice?
17:09:38 brtknr Shrews: done
17:09:39 openstackgerrit Bharat Kunwar proposed openstack/ansible-collections-openstack master: os_coe_cluster: Retrive id/uuid correctly https://review.opendev.org/709734
17:09:43 mordred brtknr: I think it's fine in this case - not sure if pep8 will agree or not :)
17:10:31 brtknr I'm running pep8 locally
17:10:37 brtknr band it succeeds
17:10:58 brtknr Thanks folks
17:11:13 openstackgerrit Lars Kellogg-Stedman proposed openstack/openstacksdk master: Include user_id attribute in volume information https://review.opendev.org/710834
17:11:28 mordred woot. thanks brtknr
17:11:53 mordred larsks: thanks
17:12:12 mordred I think when that and the coe patch above land we should cut a bugfix release
17:12:16 brtknr would be nice to fix the create case too on openstacksdk side for consistency?
17:13:18 Shrews mordred: you'll need to reapply your +2 to 709734
17:13:30 mordred brtknr: yeah, it would
17:13:52 mordred Shrews: done. thanks
17:14:55 mordred brtknr: if you want to do it - it would be adding a normalize call in openstack/cloud/_coe.py in create_cluster_template (and create_cluster) -
17:15:11 mordred brtknr: so like return self._normalize_cluster_template(cluster_template)
17:40:26 openstackgerrit Adam Harwell proposed openstack/python-openstackclient master: Switch image to use SDK https://review.opendev.org/650374
17:40:26 openstackgerrit Adam Harwell proposed openstack/python-openstackclient master: Complete switch from glanceclient to SDK for image service https://review.opendev.org/699416
17:48:11 mordred rm_work: \o/
17:48:34 rm_work ... i believe i still owe something with ospurge too <_<
17:48:44 rm_work my volunteer backlog with SDK/OSC is high T_T
17:49:52 mordred rm_work: well - https://review.opendev.org/#/c/700219/
17:50:45 rm_work yes, but i believe that was superseded by the decisions we made in the meetup in Shanghai :D
17:51:00 rm_work (or is this something else?)
17:51:45 mordred I think this is still aiming at that - but it's entirely possible it's going down the wrong road
17:52:20 rm_work I believe what we said was "just drop-in the ospurge codebase into SDK"
17:52:33 mordred oh right
17:52:36 rm_work and then drop the mic and walk away :D
17:52:50 mordred and I think we keep getting busy ...
17:52:54 rm_work yes.
17:53:01 mordred stupid busy
17:53:18 mordred ok - let me wrap my head around that whole thing this wweek
17:53:38 rm_work my current quest is fixing octavia's AZ handling and compatibility with nova/neutron routed-network stuff, which requires also ... fixing nova/neutron routed-network stuff :D
17:53:43 mordred this is what we get for gtema not being able to come to shanghai - and has nothing to do with me forgetting things at all
17:53:50 rm_work well, it's also not nearly a top priority
17:53:58 rm_work which is the other reason it's been sidelined thus far for me
17:54:01 mordred yeah
17:54:20 mordred and oh goodie - it sounds like you have a wonderful rabbit hole to go down with routed networks :)
17:54:25 rm_work ugh yes
17:54:35 rm_work i was hoping i could take the easy route but i was denied :D
17:55:24 mordred where would the fun in that be?
17:56:15 dtroyer damn, you guys have been busy
17:56:16 mordred it's a dtroyer!
17:56:27 dtroyer where?
17:56:34 mordred ssssh. it's a sekrit
17:56:48 dtroyer oh good, don't let him out of the asylum
17:56:58 mordred I hear he's bringing vegetables
17:57:31 dtroyer he hates vegetables, which is why being vegetarian for 8 years was, um, interesting
17:57:41 mordred mmm. eggs
17:58:00 mordred could I have some eggs with those eggs? maybe with a side of eggs?
17:59:06 dtroyer So I think it is time to acknowledge the clear truth that I'm not going to continue to be working on OSC, not OpenStack for that matter. I owe an apology and major thanks to everyone who has kept the lights on.
17:59:42 mordred dtroyer: that is sad panda - but thanks for your many years of keeping the lights on yourself!
17:59:46 dtroyer I don't have a new job yet, but nothing I am looking at includes room here, unfortunately
18:06:15 rm_work hmm
18:06:34 rm_work is that because you're explicitly not looking at stuff that's related, because you need to GTFO for your sanity? :D
18:06:37 rm_work or just coincidental
18:07:43 dtroyer more coincidental. dis-investment in OpenStack is a real thing and more than just Intel
18:08:22 rm_work I feel like it's just ... shifting
18:08:23 dtroyer but it may be time, too. I almost made it to Nova's 10th birthday, but that's a long time in one place
18:08:24 rm_work but yes
18:12:13 mordred dtroyer: tell me about it - I have certainly never worked 10 years on anything else
18:21:17 rm_work me either!
18:22:34 rm_work I think I'm going on 7 years on openstack now tho :)
18:24:29 dtantsur tosky: dumped some microversion microthoughts to the patch :)
18:25:24 mordred Shrews: https://review.opendev.org/#/c/710823 is the sdk-side of that uuid thing from earlier
18:26:17 dtantsur mordred: will it be too much to ask for a unit test on ^^^?
18:26:46 dtantsur I guess it's a question for brtknr really
18:26:47 rm_work oh hey, good place for this since i'm already here: https://review.opendev.org/#/c/710452/
18:27:12 rm_work need that for senlin ASAP, and will need that to do a conversion for OSC to SDK

Earlier   Later