Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2017-04-27
17:22:18 cdent shipped
17:22:26 mordred cdent: the delay is mostly just that publication jobs run just like any other one, so it's gotta get queued up, wait for a node to become available, then get built and published
17:22:45 cdent elmiko: while you lunch, I will dine
17:22:51 elmiko cdent: enjoy =)
17:23:21 cdent mordred: ah, I hadn't really considered that the publish jobs would get a new node. makes sense now
17:48:13 gouthamr edleafe: Re: '<edleafe> Heat will have to find a new liaison, <edleafe> Manilla too'
17:49:01 gouthamr edleafe: manila had two liaisons, now it's one. however, more the merrier, i can ask for more people to help out
18:25:55 edleafe gouthamr: Ah, I misunderstood the email. Thanks for the clarification!
18:26:33 edleafe gouthamr: And we always welcome more participation
18:27:20 gouthamr edleafe: yep. i'll bring this up in the manila meeting soon :)
18:59:59 dtroyer Shall we do an OSC meeting? #openstack-meetin now-ish
19:18:47 mordred dtroyer: so - on the skip validating front, I've got this: https://review.openstack.org/#/c/438196/ - which TOTALLY skips that stuff until it's requested
19:19:05 mordred dtroyer: last we chatted about it you liked the idea but thought it was too soon / too much stuff still to unwind
19:19:24 mordred dtroyer: do you think its time to start tugging at that thread again? or still hold off for a bit?
19:20:41 dtroyer I was hoping the stuff jamielennox started that we talked about in ATL was going to handle that and I haven't gotten back to it yet
19:22:23 dtroyer so I forgot about that, and given what I've just unwound in OSC in prep for 1.27.0 I may be ready to go there now
19:22:29 mordred oh cool
19:22:42 mordred I'll get those two patches cleaned up and resubmitted for you
19:22:48 mordred and we can see how far off they are
19:23:12 dtroyer cool. I want to get the next OSC release out early next week, will dive in deeper after that
19:23:54 mordred something just broke shade's legacy functional test jobs
19:24:01 mordred which is the next thing _I_ get to look in to
20:24:50 openstackgerrit Brian Curtin proposed openstack/python-openstacksdk master: Port unversioned Version resources to resource2 https://review.openstack.org/460735
20:36:06 openstackgerrit Dean Troyer proposed openstack/python-openstackclient master: Fix Nova-net netowrk commands https://review.openstack.org/460679
20:55:00 efried o/
20:55:39 efried mordred Gonna be multitasking the nova mtg in 5, FYI.
20:57:16 mordred efried: me too - I'm still in this glorious phone call
20:57:59 efried mordred Cool, I'll just dump my questions and we can discuss as thread manager allows.
20:58:04 mordred sweet
20:59:47 efried So I noodled around with os-client-config a little bit. I found that I could get all the known ClientConfig instances - so first question is: how do I figure out which one to use? Or to know which one to get_one_cloud() for?
20:59:59 efried (or is that the wrong starting point entirely?)
21:00:32 efried Second, I found I couldn't do anything service_catalog-y with a CloudConfig unless I also supplied an auth somehow. I can set up the auth (by loading from conf options), but it's not clear me where/how I'm supposed to hand it off to the CloudConfig.
21:12:59 mordred efried: gotcha. good questions - SO - part of the issue is that the interfaces you're talking about in occ are oriented towards end-users
21:13:14 mordred efried: I put this together: https://review.openstack.org/#/c/439120/
21:13:27 mordred efried: which needs to be finished
21:14:07 mordred efried: but the idea there woudl be to give you some nice factory functions that you could use to pass in your CONF object and the other context you have at the calling points in nova
21:14:31 mordred and have it return you either a ksa.adapter or a glanceclient.Client or a neutronclient.Client or whatever is appropriate
21:23:34 efried dtroyer If interested, here's where it's coming from: https://review.openstack.org/#/c/458257/
21:25:11 dtroyer efried: thanks. my concerns are much more about policy and expectations than code itself, learned from experience. there's a reason I don't want most oslo bits in clients, they make server-side assumptions
21:26:33 mordred dtroyer: oh yah - I definitely agree about oslo and clients
21:27:21 efried dtroyer Mainly the issue that prompted this discussion was that we want to be able to divine an appropriate list of service_type values to try successively to discover the endpoint for a given conf group, if they don't set a service_type in their conf.
21:27:27 mordred dtroyer: in this case my suggestion was coming basically from seeing the amount of boilerplate (that's getting it wrong in several places) inside of nova when they're creating their clients to talk to the other services
21:27:43 efried Exactly, the point of this blueprint.
21:28:37 mordred dtroyer: the _basic_ thought was to make few functions that skip any processing of envvars or clouds.yaml files and only work via python-level parameters
21:28:55 dtroyer sure, and maybe some of that needs to be extracted. my worry is the constant tension between client and service versions and dependencies and expectations. I once thought the SDK should be so damn good that all of the services should use it too. bad idea. really bad idea in the real world
21:29:59 mordred dtroyer: yup. totally agree with the concern
21:30:00 dtroyer mordred: that requires a discipline we have yet to be able to maintain within a lib.
21:30:10 efried Baby steps, we can start by putting the boilerplate in one place (and hopefully getting it right); and then later offload more of that functionality to o-c-c (and/or service-types-authority) as appropriate.
21:30:16 dtroyer I'm onboard with the idea, just don't think o-c-c is the place fro shared client/service code
21:30:31 mordred to be fair - I think with the ksa patch efried wrote, we might be able to just deal with it all with some repeated patterns
21:30:41 mordred efried: ++
21:30:55 mordred yah. I think the register_adapter_options in ksa is key
21:31:11 dtroyer ksa is a good example of us actually pulling this off. it'll take that level of discipline for dependencies and interfaces
21:31:17 mordred and then using session.get_endpoint
21:31:37 efried mordred With the exception of the "guess service_types for your group if not specified" thing, I have everything I need with the ksa patch.
21:31:45 efried That part is still the hole.
21:31:54 mordred because there's a few of the logic things nova needs that are in occ now but I think we may be close to being able to say that ksa should understand
21:32:11 efried I guess, back to baby steps, I can make service_type required for now...?
21:32:33 efried I don't think that'll make jaypipes happy, tho
21:32:34 mordred oh - yes - service_type is/should be required
21:32:38 mordred oh - wait
21:32:43 mordred hang on - context switching
21:32:51 efried ...in the conf
21:32:58 mordred I think we can put the thing you're talking about in like you have it now in the nova patches
21:33:16 efried okay, just a hardcoded dict of group: service_types in nova.utils?
21:33:17 mordred I _eventually_ think we should move that little bit to ksa - but we need a broader buy-in on that
21:33:19 mordred yah
21:33:23 efried Okay, cool.
21:33:35 efried So then the remaining gap is fleshing that guy out.
21:33:44 mordred it's basically a duplicate of code we have in occ too - but it's very small code - so we can improve the duplication over time
21:34:13 efried I don't begin to know what the comprehensive mapping should be there. Also didn't see it (except for some funky cinder stuff) in occ. Can you point me to it?
21:34:29 mordred that's pretty much it
21:34:36 mordred it's the funky cinder stuff
21:34:47 mordred there's also a mapping for mistral - but you don't need to worry about that one
21:34:49 efried (I gather than "funky cinder stuff" is often redundant)
21:34:57 mordred all the rest of them have one and only one service-type
21:35:11 mordred dtroyer: you saw they're talking about a new service-typefor cinder right?
21:35:20 efried would that be block-storage?
21:35:22 mordred yah
21:35:52 dtroyer mordred: I recall that from long ago, didn't know it was active again.
21:36:02 dtroyer I'm hoping it'll never gain a version?
21:36:31 efried dtroyer https://review.openstack.org/#/c/436178/
21:36:52 efried Active today
21:44:16 mordred dtroyer: I did make a new patch to the consume-discovery patch covering the sad pile of multiple types
21:44:55 mordred dtroyer: https://review.openstack.org/#/c/460654/
22:06:30 jamielennox mordred, efried: sorry was in a meeting, yea, it's probably too much to make every client subclass something from keystoneauth
22:06:41 jamielennox though the idea of a base useful client has come up a few times before
22:07:12 jamielennox mostly i was just trying to say i'm fine to have the pure adapter loading stuff because i know mordred wants that for os-c-c and shade
22:07:51 jamielennox but for most uses we just need a way for novaclient to say that it passes all these options through from Client.__init__ to keystoneauth
22:19:55 mordred jamielennox: yup - totally agree
22:20:03 mordred jamielennox: an I _think_ that's the intent here
22:28:12 mordred jamielennox: btw - you are probably one of the only other people on planet who can actually review this: https://review.openstack.org/#/c/459405/ for accuracy or intent
22:28:44 mordred jamielennox: so I'd love your feedback - although for the love of all that is holy don't start reading it until you're in a frame of mind that wants to bepunched in the face repeatedly for quite a while
22:29:02 openstackgerrit Dean Troyer proposed openstack/python-openstackclient master: Nova net functional tests round 1 https://review.openstack.org/460356
22:29:09 jamielennox mordred: ok, that's not in my current pre-coffee state
22:29:13 mordred nope
22:29:17 mordred not even close :)
22:31:47 mordred jamielennox: specific things of concern are that it doesn't describe user-visible behavior changes from that ksa is doing now, and that if we added support to ksa for the additional things described we could do so without introducing behavior changes (although might possibly introduce an additional api call somewhere that the user wouldn't notice)
23:41:14 openstackgerrit Dean Troyer proposed openstack/python-openstackclient master: Nova net functional tests round 1 https://review.openstack.org/460356
23:41:15 openstackgerrit Dean Troyer proposed openstack/python-openstackclient master: Nova net functional tests round 2 https://review.openstack.org/460777

Earlier   Later