Earlier  
Posted Nick Remark
#openstack-sdks - 2018-07-03
13:29:55 dtantsur "Dmitry used Microversions and you won't believe what happened next..." AAAaaaaAAAAaaa :D
13:30:45 mordred :)
13:31:25 mordred that one is growing on me
13:31:43 dtantsur mordred: I think #3 (unbearable lightness) is at the right crossing of being fun and acceptable for the audience :)
13:31:55 dtantsur but yes, #2 is so great
13:32:13 mordred \o/
13:32:30 mordred also - white trash fast food is currently closed, so it's maybe not a great metaphor
13:33:22 dtantsur mordred: is it some known thing?
13:34:26 dtantsur I mean, this fast food thing
13:34:49 mordred dtantsur: http://www.whitetrashfastfood.com/ - it's my favorite berlin restaurant (or, it was)
13:35:06 dtroyer frickler: will do… I'm wrapping up osc-lib first then back to osc itself
13:35:38 dtantsur mordred: oh that's pity
13:36:10 mordred yah. I'm hoping it comes back
13:37:00 dtantsur yep. it's not even too far from my place (but in a, well, "funny" neighborhood)
13:37:14 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Only send force parameter to live migration if supported https://review.openstack.org/578960
13:39:20 frickler dtroyer: cool, thx. I also asked a question about handling microversions, not sure whether this has been discussed globally already. mordred and dtantsur might also be interested. https://review.openstack.org/#/c/577768/4/openstackclient/compute/v2/keypair.py@84
13:39:53 dtantsur s/this/his/
13:40:09 Luzi mordred, I have been looking through openstacksdk, but i don't think the openstackcloud class is a suitable place for the signature generator. Where do you think we can add the signature generator class?
13:40:32 dtantsur frickler: well, I left the same comment on an earlier revision
13:41:58 mordred I think that's about as good as one can do before we plumb all the discovery stuff through - since the model there is assuming a configured api version
13:42:22 frickler dtantsur: oh, that was on the other review. but good to see we seem to agree
13:42:29 dtantsur oh, right, another one
13:42:44 dtantsur mordred: cannot we do version = max('2.2', os_compute_api_version) here?
13:43:02 mordred not without checking to see what api versions the remote side supports
13:43:05 dtantsur another thing to consider: we ended up with defaulting --os-baremetal-api-version to the known latest in ironicclient
13:43:30 dtantsur mordred: why not? the requested will fail reasonably if the remote side only supports 2.1, no?
13:44:28 mordred ah - hrm. yeah - I suppose so in this case
13:45:01 dtantsur assuming we can provide a microversion per request in OSC
13:45:20 mordred we can using sdk - not so much with novaclient
13:45:44 dtantsur which one is used by OSC?
13:45:47 mordred *except* - at least in my world, if a user has explicity set a config value for a specific microversion in compute_api_version - I would argue that we should not override that setting
13:46:23 mordred dtantsur: novaclient for now - although at some point we're hoping to get things shifted over to sdk - dean is waiting on a 1.0 from sdk before starting in on that
13:46:28 dtantsur yep, so maybe if os_compute_api_version is None: os_compute_api_version = '2.2' elif os_compute_api_version < '2.2': boom
13:46:51 mordred dtantsur: yah- I think that would be good and upwards compatible with a future where compute_api_version might not be set
13:47:17 mordred (today it'll always be set because of defaults - but once we've got the discovery stuff finished plumbed through, it can start being None and things working)
13:47:45 dtantsur ah, random defaults, similar to 1.6 in ironic? :)
13:47:48 mordred yup
13:48:01 dtantsur * 1.9 in ironicclient and 1.6 in openstacksdk because we LOVE consistency
13:48:08 mordred \o/
13:48:37 mordred well - I've almost got the last discovery patch for sdk written in my head - so hopefully we're almost there
13:48:57 mordred Luzi: hello! yes - I agree, putting it in OpenStackCloud is not the right place ...
13:49:23 mordred Luzi: I've got a half-written patch on my laptop which should make a better place for you to put the generator
13:49:43 mordred Luzi: let me push up the work-in-progress in just a few minutes and see what you think
13:50:21 Luzi mordred, that sounds good :)
13:51:25 mordred Luzi: the generator class itself should probably just go in its own file in openstack/image - and then it should get attached to the image upload code in openstack/image/v1/_proxy and openstack/image/v2/_proxy ... but step 1 is to take the existing image upload logic from openstackcloud and move it to the proxy classes
13:58:45 mordred frickler: speaking of osc patches - https://review.openstack.org/#/c/540541/
14:00:18 dtantsur mordred: any reason Resource does not implement the dict interface? This way it would be compatible with a Munch
14:00:33 dtantsur e.g. I could start returning openstack.baremetal.v1.Node from *machine* calls
14:00:56 mordred dtantsur: that is the _other_ main patch I wanna finish before cutting 1.0
14:01:04 dtantsur very good :)
14:01:46 mordred dtantsur: https://review.openstack.org/#/c/530835/ is the very broken WIP patch for that
14:01:55 dtantsur I want to move *machine* calls to use openstack.baremetal.v1.* stuff internally, but currently they return incompatible result
14:02:07 mordred yup
14:02:13 mordred we share the same goal
14:03:18 dtantsur good
14:03:34 dtantsur I guess currently I can do munchify(node.to_dict()) as an ugly hack
14:04:00 dtantsur but what I'm hitting with my provisioning state patch is that I get a redundant GET call on each conversion between a Munch and a Node
14:04:07 dtantsur which is probably fine for now, but has to be fixed eventually
14:04:16 mordred yah - extra calls seem lame
14:04:26 dtantsur is it acceptable temporary?
14:06:13 mordred dtantsur: I'd be curious to discover why a GET call is being made during the conversion ...
14:07:12 openstackgerrit Monty Taylor proposed openstack/osc-lib master: Use openstack.config for config and Session objects https://review.openstack.org/579139
14:07:13 dtantsur mordred: https://review.openstack.org/#/c/570895/4/openstack/cloud/openstackcloud.py@9400 causes uuid-to-Node conversion
14:07:28 mordred dtroyer: ^^ that patch passes for me locally now, so might be not a waste of your time to review
14:07:37 dtantsur even when this call is used from e.g. register_machine where we already have a Munch
14:07:55 dtantsur because we cannot pass in a Munch, we need a UUID or a Node
14:09:55 mordred if we have a munch, we should be able to make a Node from it without an api call - I'd think Node(**munch_node) would do the trick?
14:10:47 dtantsur good idea, maybe we should generalize it as Resource.from_munch?
14:11:03 dtantsur defaulting to just cls(**munch)
14:12:55 frickler mordred: oh, that makes me wonder whether it'll fix my neutron ssl issues. will check.
14:13:49 mordred dtantsur: good idea - although maybe make it Resource._from_munch for now - since we might not need it once we finish and land the other thing
14:14:23 dtantsur mordred: okay, I'll see what I can do
14:14:42 dtroyer mordred: coolio, will have a look
14:23:42 dtroyer mordred: looks nice, thank you!
14:27:57 mordred dtroyer: yay!
16:11:18 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: Add Resource._from_munch class method https://review.openstack.org/579908
16:11:19 dtantsur mordred: ^^^
16:11:28 dtantsur now let's see if I can get a good use of it
16:11:40 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Use shade create_image method in image proxy layer https://review.openstack.org/579168
16:11:48 mordred dtantsur: neat. I could probably use that in that patch ^^
16:12:52 dtantsur mordred: oh, curious, I'm doing it the other way around in my patch: shade level calling baremetal proxy
16:13:02 dtantsur is there The Right approach here? or just whatever fits?
16:20:02 dtantsur hmm, and should I wire this _from_munch into Proxy._get_resource? so that all proxies support it automagically?
16:20:14 dtantsur this can be dangerous, maybe only for ironic for now..
16:22:47 dtantsur actually, from_munch can probably be implemented using the Body() fields
16:32:18 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: Add Resource._from_munch class method https://review.openstack.org/579908
16:43:29 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: Handle Munch objects in proxies https://review.openstack.org/579908
16:55:15 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: Handle Munch objects in proxies https://review.openstack.org/579908
17:42:37 mordred dtantsur|afk: your way is the better way - we want to get to the shade layer calling the proxy layer rather than the other way around
17:43:37 mordred dtantsur|afk: but for create_image that's going to require some surgery, so I figured invert it for now, then iterate on getting it done right as a followup
20:28:53 openstackgerrit David Shrewsbury proposed openstack-infra/shade master: Fix for passing dict for get_* methods https://review.openstack.org/579974
20:29:12 Shrews that probably could use a test
20:29:43 mordred yah. also - I'm pretty sure pep8 is going to complain about the whitespace
20:32:06 openstackgerrit David Shrewsbury proposed openstack-infra/shade master: Fix for passing dict for get_* methods https://review.openstack.org/579974
20:32:18 Shrews pep8 passed for me
20:33:56 mordred Shrews: cool
20:35:31 Shrews mordred: you want a release note for that?
20:38:51 wacuuu yyy question: are there any plans for sdk in go?
20:42:17 mordred wacuuu: the gophercloud project is basically that
20:42:22 mordred Shrews: nah

Earlier   Later