Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-04-18
16:22:45 elmiko dtantsur ++
16:22:47 edleafe We pride ourselves on convincing others to do the work
16:22:56 elmiko XD
16:23:05 efried there's this: https://review.openstack.org/643601 which needs to be cleaned up and have UT added
16:23:14 efried but has been integration-tested and works.
16:23:28 dtantsur efried: I'd really like to get to switching ironic-inspector to use SDK for talking to ironic and swift
16:23:33 efried tl;dr: lets you set up Connection with oslo.config ksa opts instead of clouds.yaml
16:23:34 dtantsur I mean, get to it in Train
16:23:53 dtantsur efried: I'm very much in favor of that. very.
16:23:55 efried ...so we can make the transition transparent to operators initially.
16:24:24 efried and then there's this: https://review.openstack.org/#/c/643664/ which introduces the plumbing for sdk in nova
16:24:42 efried and the patch on top of it https://review.openstack.org/#/c/642899/ which starts the process of swapping out calls into ironicclient.
16:24:56 efried idea being to stack several of those ^ up until we can rip out ironicclient entirely.
16:25:09 efried (from nova)
16:25:38 efried I've got a new guy helping out with the nova things
16:25:45 efried but could use some help on the sdk side
16:25:58 efried there's the patch noted above, already started, could use closure
16:26:00 mordred yeah. I'll definitely be digging in to help
16:26:14 mordred and I need to finish that patch as soon as I can finish up all the meetings I've been stuck in this week
16:26:15 efried and then there's a need for a fixture to facilitate testing on the nova side
16:26:30 efried mordred: Totally understood, I was actually fishing for other volunteers to help :)
16:26:57 dtantsur efried: note that future openstacksdk 0.26 will add patch_node for ironic, which will substantially simplify transition (no need to get rid of patcher right away)
16:26:58 efried here's a story for the fixtures: https://storyboard.openstack.org/#!/story/2005475
16:27:12 efried dtantsur: ack, good to know.
16:27:36 efried So
16:27:49 efried besides soliciting help if possible for the sdk items noted above
16:28:03 efried it would be nice if the API SIG (or whoever) could lend support to this idea in general.
16:28:16 efried because nova cores are old and crusty and afraid of change
16:28:23 efried and sdk is shiny and new and fancy
16:28:39 efried Any questions, comments, etc?
16:29:14 dtantsur efried: what kind of support would you imagine?
16:29:38 dtantsur esp. around making old nova cores a bit less crusty?
16:29:47 efried I dunno. Looking for opportunities to tell key people that this is a good idea?
16:30:00 edleafe efried: Sure, I'm sure that my opinion will sway the Nova cores. It *always* does!
16:30:06 efried heh
16:30:13 efried well actually
16:30:16 dtantsur we should have had a Forum session
16:30:27 mordred yeah
16:30:37 efried it sort of dovetails with the (ill-fated) community goal for osc.
16:30:40 mordred well - tim bell has consistently raised his hands in support of this
16:30:46 mordred iirc
16:30:53 mordred so - I think we just say "tim bell says it's a good idea"
16:31:00 dtantsur ++ should work
16:31:02 mordred because nobody wants to argue with tim bell
16:31:21 efried Using sdk over python-*client or even raw ksa in $project could be a community goal.
16:31:23 mordred I mean - *I* don't want to argue with tim and I like arguing with anybody
16:31:38 dtantsur heh
16:31:42 elmiko efried: fwiw, i think the api sig could definitely help with moving the discussions forward and provide solid support in that respect. as the others have noted, i'm not sure how much we could lend in terms of coding or contributions to nova.
16:31:43 mordred efried: yeah - but I'd honestly still focus it on using sdk - even if people just want to use raw ksa
16:31:57 openstackgerrit Ed Leafe proposed openstack/api-sig master: Add document describing consuming version discovery https://review.openstack.org/459405
16:31:58 mordred largely because it'll help us align on operator-centric config
16:32:08 edleafe elmiko: dtantsur: ^^ rebase the version discovery doc
16:32:15 dtantsur many thanks edleafe!
16:32:23 mordred efried: and if people don't want to use the object layer of sdk in their code - that's fine ... they can still just do things like conn.compute.get('/servers')
16:32:40 efried mordred: ack, that's been my thinking. I alluded to that in the nova blueprint
16:32:47 mordred ++
16:32:52 elmiko edleafe: ack, thanks
16:32:56 efried e.g. I don't think placement has any object model code in sdk, right?
16:33:04 mordred nope, not to my knowledge
16:33:17 mordred so I think nova would just be using conn.placement.get('/things')
16:33:28 dtantsur I think the biggest reason to NOT use ironicclient is that we largely screwed microversioning there :)
16:33:30 efried but we ought to be able to swap out the ksa adapter with Connection.placement and not have to do much else except some fixture stuff.
16:33:31 efried yes.
16:33:38 mordred efried: exactly
16:34:03 dtantsur and this is also my argument against recommending people to use raw ksa: microversioning requires careful handling..
16:34:04 efried during transition, operators can continue using ksa oslo.config opts, but can cut over to clouds.yaml any time they want
16:34:49 efried okay, dtantsur and mordred these arguments are going to be helpful.
16:35:10 efried Because we "just" (queens) got done converting (almost) everything to ksa.
16:35:13 efried except we really didn't
16:35:22 efried we just enabled ksa opts, but are still using clients under the covers
16:35:30 dtantsur ditto for ironic
16:35:40 cdent Is using clouds.yaml going to be a requirement of this thing, or just an option? Because I know that having more than one thing to config has been sad-making for some in the past.
16:36:06 efried cdent: mordred wrote a patch to enable oslo.config ksa opts, so it's an option
16:36:15 cdent kewl
16:36:18 efried https://review.openstack.org/643601
16:36:47 efried I still have an open question
16:36:53 efried about how to bootstrap use of clouds.yaml
16:37:36 efried What I've inferred is that there would be a (single) oslo.config opt (per service-I'm-talking-to) to denote which, um, section of the clouds.yaml to use for that connection.
16:38:20 efried so iow to cut over to clouds.yaml for [service], operator would replace [service].$ksa_opts with [service].use_clouds_yaml_section=admin or similar.
16:38:45 openstackgerrit Merged openstack/api-sig master: Added Placement to the liaisons file https://review.openstack.org/645223
16:38:58 efried and the proj code would pick that up and do Connection(cloud=CONF.service.use_clouds_yaml_section) instead of Connection(oslo_config_stuff)
16:39:05 efried mordred: does that gel with your thinking?
16:39:20 mordred efried: yeah - I think that's likely right - hand waving about the actual details
16:39:23 efried right
16:39:34 efried oh, I am not going to budge on those conf opt names, though.
16:39:49 efried MY bikeshed
16:40:04 efried okay, cool, thanks for the airtime folks.
16:40:29 edleafe efried: we'll mail you the bill
16:40:30 elmiko gladly efried =)
16:40:40 elmiko err... yeah, what edleafe said XD
16:42:42 dtantsur lol
16:44:08 cdent I knew mordred was saucy, but had no idea he was so rude.
16:47:50 edleafe I'm thinking that the image doesn't have pymysql. Does it?
16:48:01 edleafe whoops, wrong channel
16:58:52 edleafe elmiko: ugh, the version discovery rebase is getting a docs error
16:59:10 edleafe I'll see if I can figure that out later. Gotta run for a bit now
17:00:08 elmiko doh
17:00:13 elmiko later o/
17:00:18 elmiko have a good weekend folks =)
17:18:13 openstackgerrit Eric Fried proposed openstack/api-sig master: Add document describing consuming version discovery https://review.openstack.org/459405

Earlier   Later