Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2017-04-27
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
#openstack-sdks - 2017-04-28
11:57:41 openstackgerrit Dean Troyer proposed openstack/python-openstackclient master: Nova net functional tests round 1 https://review.openstack.org/460356
11:57:42 openstackgerrit Dean Troyer proposed openstack/python-openstackclient master: Nova net functional tests round 2 https://review.openstack.org/460777
14:40:12 EmilienM dtroyer, stevemar: hey ! https://review.openstack.org/#/c/459660/ broke TripleO CI
14:40:23 EmilienM (as you can see in the job results)
14:40:29 openstack Launchpad bug 1687032 in tripleo "Exception raised: 'ClientManager' object has no attribute 'auth'" [Critical,Triaged]
14:40:29 EmilienM https://bugs.launchpad.net/tripleo/+bug/1687032
14:44:28 dtroyer EmilienM: I'm not familiar with tripleo jobs & logs, can you point me to the error? I haven't found it yet…
14:44:50 EmilienM dtroyer: hey, so the error is visible here: http://logs.openstack.org/15/359215/94/check-tripleo/gate-tripleo-ci-centos-7-ovb-nonha/38a2082/console.html#_2017-04-28_12_17_38_245239
14:45:24 EmilienM dtroyer: but I need to enable --debug to the tripleoclient to know exactly where it failed in tripleo (heatclient? mistralclient? osc?) - I'm on it now
14:45:28 dtroyer that doesn't really tell me anything… what command is being executed?
14:45:30 EmilienM I just found useful to share this feedback
14:45:33 dtroyer ok
14:45:40 EmilienM yeah I don't have much clue now, i'm working on it
14:46:07 dtroyer sure, thanks. to he honest I had not even looked at this job yet, I'm still chasing the nova-net breakage from novaclient 8.0.0
14:46:54 EmilienM dtroyer: i'm debugging with https://review.openstack.org/#/c/457037/
14:47:00 EmilienM I'll post results here later
14:47:10 dtroyer thanks
14:47:15 openstackgerrit Dean Troyer proposed openstack/python-openstackclient master: Nova net functional tests round 2 https://review.openstack.org/460777
14:47:36 EmilienM dtroyer: i'm going to propose a revert just to see if it pass tripleo jobs, so I can confirm this is the patch. Don't merge it and ignore it please.
14:47:52 dtroyer ok
14:48:10 openstackgerrit Emilien Macchi proposed openstack/osc-lib master: DNM - Revert "Tell ClientManager when auth is required" https://review.openstack.org/461069
17:41:14 openstackgerrit Merged openstack/keystoneauth master: Uncomment warning-is-error for doc building https://review.openstack.org/459673
17:41:32 openstackgerrit Merged openstack/python-openstackclient master: Nova net functional tests round 1 https://review.openstack.org/460356
17:42:13 openstackgerrit Merged openstack/python-openstackclient master: Nova net functional tests round 2 https://review.openstack.org/460777
17:45:47 openstackgerrit Dean Troyer proposed openstack/python-openstackclient master: Nova net functional tests round 3 https://review.openstack.org/461113
17:47:53 openstackgerrit Monty Taylor proposed openstack/os-client-config master: Fix interactions with keystoneauth from newton https://review.openstack.org/461114
17:53:19 mordred dtroyer: tiny little regression in our latest release. I'm 100% certain the only thing it's affecting is shade's non-voting legacy functional tips job which tests shade + tip of library branch against a stable/newton cloud
17:53:39 mordred dtroyer: it's such an absurd combination I was almost tempted to just work around it in shade's test definition

Earlier   Later