| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-05-20 | |||
| 08:17:37 | openstackgerrit | yanpuqing proposed openstack/python-openstackclient master: Client should parse string to boolean for valuse 'is_domain' https://review.opendev.org/660038 | |
| 10:10:27 | openstackgerrit | yanpuqing proposed openstack/python-openstackclient master: Client should parse string to boolean for valuse 'is_domain' https://review.opendev.org/660038 | |
| 10:28:22 | openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: WIP rework statistics reporting https://review.opendev.org/659841 | |
| 12:05:56 | openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: WIP rework statistics reporting https://review.opendev.org/659841 | |
| 13:41:51 | openstackgerrit | Dean Troyer proposed openstack/python-openstackclient master: Batch up minor cleanups for release https://review.opendev.org/659982 | |
| 13:48:07 | efried | mordred: ...or today? | |
| 13:51:42 | mordred | efried: yes! | |
| 13:51:50 | mordred | efried: today is a great day to discuss such things | |
| 13:52:00 | efried | (gtema, dustinc, dtantsur) | |
| 13:52:39 | efried | mordred: So today we have oslo.config for e.g. [placement]=>ks_loading.get_{auth|session|adapter}_config_opts | |
| 13:53:00 | efried | I'm thinking we could inject [placement]cloud_region=<str> | |
| 13:53:12 | efried | (is it called a "cloud region", this section in clouds.yaml?) | |
| 13:53:50 | efried | The code looking at that config section will use the presence of 'cloud_region' to decide whether to use the ksa opts or look at clouds.yaml. | |
| 13:54:28 | efried | that's... pretty much it. | |
| 13:55:13 | mordred | yes - I think that's about right. and I think maybe what we want is a function similar to get_{}_config_opts in sdk that ads the parameter | |
| 13:55:43 | efried | yeah, that would work. Except it's only one opt, so meh? | |
| 13:55:46 | mordred | (the section and parameter in sdk is just called "cloud" - a CloudRegion object is a cloud + a region_name | |
| 13:56:04 | efried | oh, okay. I definitely want to be told what a good name for the opt is. | |
| 13:56:23 | mordred | yeah - might just be meh - mostly thinking about how we can make it easy for other non-nova services to follow the lead | |
| 13:56:29 | dtantsur | cloud_name is probably fine | |
| 13:56:34 | efried | 'cloud' might be a bit too broad. But I don't know ... | |
| 13:56:49 | mordred | well - cloud is what is used everywhere else such a value is consumed | |
| 13:57:08 | mordred | so while I do wish we'd named it better ... probably more confusing for the oslo opt to be different | |
| 13:58:02 | efried | I can live with 'cloud'. I don't think we have anything else in nova that'll conflict, at least. | |
| 13:58:35 | mordred | oh - also - fwiw, if there is only one cloud entry defined in clouds.yaml, the won't need to put a cloud= setting in nova.ini | |
| 13:58:54 | efried | Yeah, but then we would have no way to know that we're looking for clouds.yaml instead of ksa opts. | |
| 13:59:36 | mordred | efried: this is a good point, actually | |
| 13:59:51 | efried | And I'm an opt conservative - fewer options rather than more wherever possible - so I'd like to avoid use_clouds_yaml = $bool; cloud = <str:optional> | |
| 14:00:03 | mordred | efried: and in fact, we ignore clouds.yaml files in the current patch - so we'll probably want someone to be explicit anyway so we can avoid avoiding the file | |
| 14:00:14 | mordred | ++ | |
| 14:00:25 | mordred | I agree = no use_clouds_yaml = $bool | |
| 14:00:35 | efried | cool, so here's another angle: | |
| 14:00:45 | efried | eventually I think we probably want to deprecate and remove the ksa oslo.config stuff entirely. | |
| 14:01:07 | efried | And the theory behind clouds.yaml is more like define-once... | |
| 14:01:25 | efried | so eventually I would think we want to have the 'cloud' option defined in just one place in nova.conf, rather than in every section. | |
| 14:01:40 | efried | Because presumably one nova wouldn't want different services to talk to different clouds? | |
| 14:03:08 | efried | so like [DEFAULT]cloud=$str, or a section that somehow denotes [shit-the-sdk-uses] | |
| 14:03:48 | mordred | yes. I think this is spot on | |
| 14:04:07 | efried | Would rather not put it in [DEFAULT] I guess; suggestions for what to call that second thing? | |
| 14:04:24 | efried | Is [openstacksdk] too crazy? | |
| 14:04:48 | efried | want something that makes sense from an operator pov, not sure that's it. | |
| 14:05:57 | mordred | yeah. I'm not sure it is either. maybe [openstackapi]? or just [openstack] ? | |
| 14:06:33 | efried | again my initial reaction is "too broad", but letting it settle for a sec, maybe it's the right thing. | |
| 14:06:39 | mordred | efried: do we think people still might want to make multiple accounts for nova to use to talk to things? | |
| 14:06:50 | efried | see, I don't know that answer. | |
| 14:07:04 | efried | But there's another wrinkle to bring up, so maybe I'll mention that and we can come back to --^ in a sec. | |
| 14:07:43 | mordred | like - I'd love to deprecate per-service options - but I could see deployers maybe being unhappy with a design that there's only one account for nova to use? | |
| 14:07:43 | efried | It's this: some operations, like glance stuff, are done at the behest of the user - using the user's auth token. Other things, like ironic, are done with an admin auth, pulled from the config. | |
| 14:08:00 | mordred | yah | |
| 14:08:09 | efried | and for extra craziness, there's other stuff - neutron - where sometimes it's user and sometimes it's admin. | |
| 14:08:45 | mordred | we've got a connect_as method to allow starting with an existing connection and connecting with a new set of credentials | |
| 14:08:49 | efried | This is probably just a matter for careful coding on the nova side, because I assume I can create my Connection with whatever auth ... | |
| 14:08:50 | efried | yeah. | |
| 14:08:59 | efried | well, in this case it's going to be the other way around. | |
| 14:09:08 | efried | Get session/adapter from clouds.yaml, but use <this> auth. | |
| 14:09:12 | mordred | yes | |
| 14:09:41 | mordred | that's right -we might have to adapt the connect_as to understand being handed an auth - but in general that's how that should work | |
| 14:09:53 | efried | okay | |
| 14:10:11 | mordred | so you'll have a "get me the connectino I use to talk to neutron" and then, now that I have that, please get me a connection that uses all of those details but with $auth object | |
| 14:10:35 | mordred | (that way things like version discovery cache get shared :) ) | |
| 14:10:58 | efried | Yes, or just two separate connection objects. Construct one by saying "go to clouds.yaml section X" and the other by saying "go to clouds.yaml section X but use <this auth> instead" | |
| 14:11:09 | efried | mm, yeah, or that. | |
| 14:11:32 | efried | so, details to be worked out, but I think we agree on the broad strokes and it all sounds possible. | |
| 14:11:58 | efried | so back to 'multiple accounts'... since we're going to need to have a transition period anyway, we could have [openstack]cloud=$str and then per-section overrides of the same name to allow the multiple accounts. | |
| 14:12:28 | efried | I need to look into whether I can reliably/easily detect whether ksa auth options are present, though. | |
| 14:12:57 | efried | because if [openstack]cloud=$str and [placement]$ksa_opts, I need to use the latter | |
| 14:13:23 | efried | I think I've seen this done based on detecting the `auth_type` option, but not sure if that's the accepted/canonical way to do it. | |
| 14:13:24 | efried | and | |
| 14:13:24 | mordred | efried: ++ per section overrides | |
| 14:13:32 | efried | that doesn't work if we're doing the user auth thingy. | |
| 14:13:45 | efried | because then they just need session/adapter opts | |
| 14:13:46 | mordred | hrm. | |
| 14:13:51 | efried | which possibly all default... | |
| 14:14:01 | mordred | well ... so - if they have a default cloud | |
| 14:14:39 | mordred | and then like [placement]$ksa_opts - when that gets passed to the CloudRegion constructor those [placement]$ksa_opts will be like parameter overrides to whatever is defined in clouds.yaml | |
| 14:15:19 | mordred | which 99% of the time should be correct - since the default clouds.yaml will contain correct info like "where is my keystone" that is very unlikely to be different for placement | |
| 14:15:38 | efried | mmph | |
| 14:15:52 | mordred | so I *think* it should Just Work | |
| 14:15:56 | efried | The programmer in me likes the power/flexibility that offers | |
| 14:16:08 | efried | but I'm concerned about the complexity and especially the test surface | |
| 14:16:21 | efried | Yes, it should Just Work, but the devil is in the details. | |
| 14:16:27 | efried | Like what happened early on with interface... | |
| 14:16:46 | mordred | yeah - I mean, the testing of that combo is covered sdk side (it's just the natural behavior) ... BUT - I agree, making sure semantically we're testing that it makes sense in the nova context might get fun | |
| 14:17:04 | efried | I would like to be able to KISS. But I'm not sure if we can do that without removing capabilities. | |
| 14:17:09 | mordred | we could also just make a rule that you can't mix the two | |
| 14:17:39 | efried | so, you're not allowed to have [openstack]cloud=$str *and* [section]$ksa_opts | |
| 14:17:40 | mordred | like, if you list a default cloud, or a cloud entry for a service - you cannot also specify parameters directly in the nova.ini | |
| 14:17:42 | mordred | yeah | |
| 14:17:59 | efried | but you *can* have [openstack]cloud=$str and [section]cloud=$other_str | |
| 14:18:02 | mordred | yes | |
| 14:18:16 | efried | we still need a way to detect $ksa_opts are present | |
| 14:18:29 | efried | or just say that's unsupported and ignore them when cloud is specified. | |
| 14:18:36 | efried | yeah, that ^ | |
| 14:18:41 | mordred | yeah. | |
| 14:18:46 | efried | okay, this works. | |
| 14:19:06 | mordred | well - or we can detect that in the sdk method and throw an error/warning if we detect both | |
| 14:19:41 | mordred | *waves hands* | |
| 14:19:48 | efried | I was thinking I'd be taking different code paths into init'ing the Connection depending on whether 'cloud' is present' | |
| 14:20:04 | efried | one uses your new 'get oslo.config opts' method. The other just looks at clouds.yaml | |
| 14:20:07 | efried | they don't meet. | |