| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-05-20 | |||
| 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. | |
| 14:20:43 | mordred | ah. I mean - you could totally do that - but since the default cloud entry is also coming from oslo.config - if we put it in the sdk get_oslo_config method, then it would be really easy for other folks to adopt to | |
| 14:20:46 | mordred | but I'm fine either way | |
| 14:20:58 | efried | oh, I see. | |
| 14:21:23 | mordred | mostly thinking it woud be good if heat and similar folks adopt the same system and the deployer semantics are all the same | |
| 14:21:49 | efried | yeah, that makes sense to me. | |
| 14:22:08 | efried | we'll need a config gen entrypoint | |
| 14:22:42 | mordred | ooh! hey - what if we made a get_oslo_options method in sdk that | |
| 14:22:50 | mordred | gah | |
| 14:23:08 | mordred | that does get | |
| 14:23:18 | mordred | my god. what is happening to my IRC client. | |
| 14:23:31 | efried | I thought it was a magnetic <Enter> key | |
| 14:24:13 | mordred | anyway - that does the get_{auth,session,adapter}_config_opts - and also adds the [openstack]cloud and [service]cloud options - and takes a list of service-type to determine which services it should do the ksa opts loading for | |
| 14:24:30 | mordred | is that too one-stop-shop? | |
| 14:24:40 | efried | IMO yes | |
| 14:24:43 | mordred | kk | |
| 14:24:55 | mordred | we can always add one later if we fine we're copy-pasta across services :) | |
| 14:24:55 | efried | though... | |