| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-05-20 | |||
| 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 | mordred | efried: ++ per section overrides | |
| 14:13:24 | efried | and | |
| 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 | efried | though... | |
| 14:24:55 | mordred | we can always add one later if we fine we're copy-pasta across services :) | |
| 14:25:05 | efried | well, yes, which is really what we have today. | |
| 14:25:51 | efried | I think it might be too complex anyway, considering we'll also have to have a flag to say "use auth from here or not" | |
| 14:30:22 | efried | I'm actually a little worried that operators will be worried that, if their clouds.yaml section contains auth, we'll use that auth instead of user token. But I guess we have that issue today with neutron anyway. | |
| 14:30:54 | efried | another wrinkle is service_auth. When we use a user token, we wrap it in a service auth token. We could conceivably get that service auth from clouds.yaml too... | |
| 14:32:53 | efried | You guys don't really use specs in sdk yet? | |
| 14:32:53 | efried | I'll have to sort out which bits will be on the sdk side and which bits on the nova side. | |
| 14:32:53 | efried | Well, I was hoping to be able to avoid writing a spec, but the text in https://blueprints.launchpad.net/nova/+spec/openstacksdk-in-nova is already long enough, and I'm going to need to explain what we've just talked about, so... I guess a spec is on the way. | |
| 14:33:18 | mordred | no - not really enough people to warrant it | |
| 14:33:19 | dtantsur | we're using design-in-production approach | |
| 14:33:23 | mordred | yeah | |
| 14:33:44 | mordred | but - I think we'd be happy for design of this to happen in the nova spec and treat the sdk parts of it as an sdk spec :) | |
| 14:34:44 | efried | okay, that wfm. I'll just have to put big notes for nova people to not stress about those sections :) | |
| 14:35:04 | mordred | ++ | |
| 14:35:15 | mordred | just a big note telling them to not stress in general | |
| 14:35:26 | efried | Put that on the front page of the docs. | |
| 14:35:28 | efried | DON'T PANIC | |
| 14:35:33 | efried | someone famous said that already | |
| 14:36:07 | efried | Thanks for the talk, mordred. I'll add y'all to that spec when it exists. o/ | |
| 14:36:20 | mordred | ++ ... we should maybe make sure to point out in nova operator docs that they can have a clouds.yaml and a secure.yaml too | |
| 14:36:33 | efried | o_0 | |
| 14:36:37 | efried | what's secure.yaml? | |
| 14:36:38 | mordred | so that if they want to put passwords in a more restricted file, they acn | |
| 14:36:50 | mordred | (people get twitchy about passwords) | |
| 14:37:54 | efried | I would think the nova docs would just point to the sdk docs | |
| 14:38:08 | mordred | efried: https://docs.openstack.org/openstacksdk/latest/user/config/configuration.html#splitting-secrets | |
| 14:38:17 | mordred | efried: good call | |
| 14:39:10 | efried | so why have a separate file? Would it have like different perms or something? | |
| 14:39:47 | mordred | yeah - or maybe to make config mgmt easier - just put the clouds.yaml directly in git, and then have a secure.yaml that's templated/written out ... | |
| 14:39:47 | efried | one of my colleagues actually brought up the idea of being able to encrypt the file with the passwords in it. | |
| 14:39:56 | efried | mm | |
| 14:40:00 | mordred | also might make things nicer for people using k8s - you can put the secure.yaml in a k8s secret | |
| 14:40:16 | efried | there's a mechanism to use certificates rather than passwords, right? | |
| 14:40:42 | mordred | I think? | |
| 14:40:42 | efried | oh, yeah, next section down. | |
| 14:40:44 | mordred | yeah | |
| 14:41:14 | mordred | so that's probably a better way to deal with service-to-service secrets | |
| 14:41:33 | mordred | many many options :) | |
| 14:42:03 | efried | shrug, up to the operator. Point is, all of the option availability and documentation is owned by sdk, single point of code & reference, which makes nova's life easier. | |