| *** ricolin has joined #openstack-sdks | 02:14 | |
| *** whoami-rajat has joined #openstack-sdks | 03:11 | |
| *** dave-mccowan has quit IRC | 03:58 | |
| *** e0ne has joined #openstack-sdks | 05:31 | |
| *** Luzi has joined #openstack-sdks | 05:45 | |
| *** e0ne has quit IRC | 06:02 | |
| *** cshen has joined #openstack-sdks | 06:26 | |
| *** slaweq has joined #openstack-sdks | 06:39 | |
| *** TheJulia has quit IRC | 06:47 | |
| *** vdrok has quit IRC | 06:47 | |
| *** Shrews has quit IRC | 06:47 | |
| *** Shrews has joined #openstack-sdks | 06:47 | |
| *** vdrok has joined #openstack-sdks | 06:47 | |
| *** TheJulia has joined #openstack-sdks | 06:47 | |
| *** johnsom has quit IRC | 06:48 | |
| *** guilhermesp has quit IRC | 06:48 | |
| *** amito has quit IRC | 06:48 | |
| *** guilhermesp has joined #openstack-sdks | 06:48 | |
| *** amito has joined #openstack-sdks | 06:48 | |
| *** johnsom has joined #openstack-sdks | 06:48 | |
| *** ralonsoh has joined #openstack-sdks | 06:57 | |
| *** zigo has joined #openstack-sdks | 07:09 | |
| *** yolanda_ has quit IRC | 07:13 | |
| *** yolanda_ has joined #openstack-sdks | 07:20 | |
| openstackgerrit | yanpuqing proposed openstack/python-openstackclient master: Client should parse string to boolean for valuse 'is_domain' https://review.opendev.org/660038 | 07:25 |
|---|---|---|
| *** dtantsur|afk is now known as dtantsur | 07:35 | |
| *** tosky has joined #openstack-sdks | 07:35 | |
| *** e0ne has joined #openstack-sdks | 07:48 | |
| *** jpena|off is now known as jpena | 07:52 | |
| *** gtema has joined #openstack-sdks | 08:04 | |
| openstackgerrit | yanpuqing proposed openstack/python-openstackclient master: Client should parse string to boolean for valuse 'is_domain' https://review.opendev.org/660038 | 08:17 |
| *** jangutter has joined #openstack-sdks | 08:18 | |
| *** holser_ has joined #openstack-sdks | 08:20 | |
| *** gtema has quit IRC | 08:24 | |
| *** gtema has joined #openstack-sdks | 08:27 | |
| *** holser_ has quit IRC | 08:59 | |
| *** ricolin has quit IRC | 09:19 | |
| *** holser_ has joined #openstack-sdks | 09:21 | |
| *** holser_ has quit IRC | 09:21 | |
| *** holser_ has joined #openstack-sdks | 09:22 | |
| *** cdent has joined #openstack-sdks | 09:46 | |
| *** ttsiouts has joined #openstack-sdks | 09:54 | |
| openstackgerrit | yanpuqing proposed openstack/python-openstackclient master: Client should parse string to boolean for valuse 'is_domain' https://review.opendev.org/660038 | 10:10 |
| *** ttsiouts has quit IRC | 10:23 | |
| openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: WIP rework statistics reporting https://review.opendev.org/659841 | 10:28 |
| *** holser_ has quit IRC | 10:33 | |
| *** gtema has quit IRC | 10:38 | |
| *** cshen has quit IRC | 10:52 | |
| *** yolanda_ has quit IRC | 11:04 | |
| *** yolanda_ has joined #openstack-sdks | 11:08 | |
| *** cshen has joined #openstack-sdks | 11:09 | |
| *** cshen has quit IRC | 11:15 | |
| *** jpena is now known as jpena|lunch | 11:25 | |
| *** cshen has joined #openstack-sdks | 11:35 | |
| *** cshen has quit IRC | 11:41 | |
| *** cshen has joined #openstack-sdks | 11:44 | |
| *** gtema has joined #openstack-sdks | 11:49 | |
| *** bobh has joined #openstack-sdks | 11:51 | |
| *** dave-mccowan has joined #openstack-sdks | 12:04 | |
| openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: WIP rework statistics reporting https://review.opendev.org/659841 | 12:05 |
| *** bobh has quit IRC | 12:10 | |
| *** bobh has joined #openstack-sdks | 12:12 | |
| *** bobh has quit IRC | 12:16 | |
| *** jpena|lunch is now known as jpena | 12:22 | |
| *** dave-mccowan has quit IRC | 12:48 | |
| *** Guest84310 has joined #openstack-sdks | 13:05 | |
| *** Guest84310 is now known as redrobot | 13:06 | |
| *** jroll has quit IRC | 13:25 | |
| *** jroll has joined #openstack-sdks | 13:26 | |
| *** gtema has quit IRC | 13:34 | |
| openstackgerrit | Dean Troyer proposed openstack/python-openstackclient master: Batch up minor cleanups for release https://review.opendev.org/659982 | 13:41 |
| efried | mordred: ...or today? | 13:48 |
| mordred | efried: yes! | 13:51 |
| mordred | efried: today is a great day to discuss such things | 13:51 |
| efried | (gtema, dustinc, dtantsur) | 13:52 |
| efried | mordred: So today we have oslo.config for e.g. [placement]=>ks_loading.get_{auth|session|adapter}_config_opts | 13:52 |
| efried | I'm thinking we could inject [placement]cloud_region=<str> | 13:53 |
| efried | (is it called a "cloud region", this section in clouds.yaml?) | 13:53 |
| 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:53 |
| efried | that's... pretty much it. | 13:54 |
| 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 |
| efried | yeah, that would work. Except it's only one opt, so meh? | 13:55 |
| mordred | (the section and parameter in sdk is just called "cloud" - a CloudRegion object is a cloud + a region_name | 13:55 |
| efried | oh, okay. I definitely want to be told what a good name for the opt is. | 13:56 |
| 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 |
| dtantsur | cloud_name is probably fine | 13:56 |
| efried | 'cloud' might be a bit too broad. But I don't know ... | 13:56 |
| mordred | well - cloud is what is used everywhere else such a value is consumed | 13:56 |
| mordred | so while I do wish we'd named it better ... probably more confusing for the oslo opt to be different | 13:57 |
| efried | I can live with 'cloud'. I don't think we have anything else in nova that'll conflict, at least. | 13:58 |
| 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 |
| efried | Yeah, but then we would have no way to know that we're looking for clouds.yaml instead of ksa opts. | 13:58 |
| mordred | efried: this is a good point, actually | 13:59 |
| 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> | 13:59 |
| 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 |
| mordred | ++ | 14:00 |
| mordred | I agree = no use_clouds_yaml = $bool | 14:00 |
| efried | cool, so here's another angle: | 14:00 |
| efried | eventually I think we probably want to deprecate and remove the ksa oslo.config stuff entirely. | 14:00 |
| efried | And the theory behind clouds.yaml is more like define-once... | 14:01 |
| 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 |
| efried | Because presumably one nova wouldn't want different services to talk to different clouds? | 14:01 |
| efried | so like [DEFAULT]cloud=$str, or a section that somehow denotes [shit-the-sdk-uses] | 14:03 |
| mordred | yes. I think this is spot on | 14:03 |
| efried | Would rather not put it in [DEFAULT] I guess; suggestions for what to call that second thing? | 14:04 |
| efried | Is [openstacksdk] too crazy? | 14:04 |
| efried | want something that makes sense from an operator pov, not sure that's it. | 14:04 |
| mordred | yeah. I'm not sure it is either. maybe [openstackapi]? or just [openstack] ? | 14:05 |
| efried | again my initial reaction is "too broad", but letting it settle for a sec, maybe it's the right thing. | 14:06 |
| mordred | efried: do we think people still might want to make multiple accounts for nova to use to talk to things? | 14:06 |
| efried | see, I don't know that answer. | 14:06 |
| 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 |
| 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 |
| 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:07 |
| mordred | yah | 14:08 |
| efried | and for extra craziness, there's other stuff - neutron - where sometimes it's user and sometimes it's admin. | 14:08 |
| 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 |
| 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 |
| efried | yeah. | 14:08 |
| efried | well, in this case it's going to be the other way around. | 14:08 |
| efried | Get session/adapter from clouds.yaml, but use <this> auth. | 14:09 |
| mordred | yes | 14:09 |
| 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 |
| efried | okay | 14:09 |
| 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 |
| mordred | (that way things like version discovery cache get shared :) ) | 14:10 |
| 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:10 |
| efried | mm, yeah, or that. | 14:11 |
| efried | so, details to be worked out, but I think we agree on the broad strokes and it all sounds possible. | 14:11 |
| 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:11 |
| efried | I need to look into whether I can reliably/easily detect whether ksa auth options are present, though. | 14:12 |
| efried | because if [openstack]cloud=$str and [placement]$ksa_opts, I need to use the latter | 14:12 |
| 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 |
| efried | and | 14:13 |
| mordred | efried: ++ per section overrides | 14:13 |
| efried | that doesn't work if we're doing the user auth thingy. | 14:13 |
| efried | because then they just need session/adapter opts | 14:13 |
| mordred | hrm. | 14:13 |
| efried | which possibly all default... | 14:13 |
| mordred | well ... so - if they have a default cloud | 14:14 |
| 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:14 |
| 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 |
| efried | mmph | 14:15 |
| mordred | so I *think* it should Just Work | 14:15 |
| efried | The programmer in me likes the power/flexibility that offers | 14:15 |
| efried | but I'm concerned about the complexity and especially the test surface | 14:16 |
| efried | Yes, it should Just Work, but the devil is in the details. | 14:16 |
| efried | Like what happened early on with interface... | 14:16 |
| 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:16 |
| efried | I would like to be able to KISS. But I'm not sure if we can do that without removing capabilities. | 14:17 |
| mordred | we could also just make a rule that you can't mix the two | 14:17 |
| efried | so, you're not allowed to have [openstack]cloud=$str *and* [section]$ksa_opts | 14:17 |
| 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 |
| mordred | yeah | 14:17 |
| efried | but you *can* have [openstack]cloud=$str and [section]cloud=$other_str | 14:17 |
| mordred | yes | 14:18 |
| efried | we still need a way to detect $ksa_opts are present | 14:18 |
| efried | or just say that's unsupported and ignore them when cloud is specified. | 14:18 |
| efried | yeah, that ^ | 14:18 |
| mordred | yeah. | 14:18 |
| efried | okay, this works. | 14:18 |
| *** cdent has quit IRC | 14:18 | |
| mordred | well - or we can detect that in the sdk method and throw an error/warning if we detect both | 14:19 |
| mordred | *waves hands* | 14:19 |
| efried | I was thinking I'd be taking different code paths into init'ing the Connection depending on whether 'cloud' is present' | 14:19 |
| efried | one uses your new 'get oslo.config opts' method. The other just looks at clouds.yaml | 14:20 |
| efried | they don't meet. | 14:20 |
| 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 |
| mordred | but I'm fine either way | 14:20 |
| efried | oh, I see. | 14:20 |
| 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 |
| efried | yeah, that makes sense to me. | 14:21 |
| efried | we'll need a config gen entrypoint | 14:22 |
| mordred | ooh! hey - what if we made a get_oslo_options method in sdk that | 14:22 |
| mordred | gah | 14:22 |
| mordred | that does get | 14:23 |
| mordred | my god. what is happening to my IRC client. | 14:23 |
| efried | I thought it was a magnetic <Enter> key | 14:23 |
| 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 |
| mordred | is that too one-stop-shop? | 14:24 |
| efried | IMO yes | 14:24 |
| mordred | kk | 14:24 |
| mordred | we can always add one later if we fine we're copy-pasta across services :) | 14:24 |
| efried | though... | 14:24 |
| efried | well, yes, which is really what we have today. | 14:25 |
| 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:25 |
| *** cdent has joined #openstack-sdks | 14:26 | |
| *** holser_ has joined #openstack-sdks | 14:27 | |
| 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 |
| 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:30 |
| 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:32 |
| efried | I'll have to sort out which bits will be on the sdk side and which bits on the nova side. | 14:32 |
| efried | You guys don't really use specs in sdk yet? | 14:32 |
| mordred | no - not really enough people to warrant it | 14:33 |
| dtantsur | we're using design-in-production approach | 14:33 |
| mordred | yeah | 14:33 |
| 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:33 |
| efried | okay, that wfm. I'll just have to put big notes for nova people to not stress about those sections :) | 14:34 |
| mordred | ++ | 14:35 |
| mordred | just a big note telling them to not stress in general | 14:35 |
| efried | Put that on the front page of the docs. | 14:35 |
| efried | DON'T PANIC | 14:35 |
| efried | someone famous said that already | 14:35 |
| efried | Thanks for the talk, mordred. I'll add y'all to that spec when it exists. o/ | 14:36 |
| 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 |
| efried | o_0 | 14:36 |
| efried | what's secure.yaml? | 14:36 |
| mordred | so that if they want to put passwords in a more restricted file, they acn | 14:36 |
| mordred | (people get twitchy about passwords) | 14:36 |
| efried | I would think the nova docs would just point to the sdk docs | 14:37 |
| mordred | efried: https://docs.openstack.org/openstacksdk/latest/user/config/configuration.html#splitting-secrets | 14:38 |
| mordred | efried: good call | 14:38 |
| efried | so why have a separate file? Would it have like different perms or something? | 14:39 |
| efried | one of my colleagues actually brought up the idea of being able to encrypt the file with the passwords in it. | 14:39 |
| 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 |
| efried | mm | 14:39 |
| mordred | also might make things nicer for people using k8s - you can put the secure.yaml in a k8s secret | 14:40 |
| efried | there's a mechanism to use certificates rather than passwords, right? | 14:40 |
| efried | oh, yeah, next section down. | 14:40 |
| mordred | I think? | 14:40 |
| mordred | yeah | 14:40 |
| mordred | so that's probably a better way to deal with service-to-service secrets | 14:41 |
| mordred | many many options :) | 14:41 |
| 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. | 14:42 |
| *** cshen has quit IRC | 14:43 | |
| efried | btw, staging-wise, I'm thinking nova's stage 1 is zero operator changes, just keep using ksa opts and we'll feed them to sdk under the covers (via your wip patch); and we can transition to clouds.yaml later on. | 14:43 |
| efried | Probably when we've done away with all the clients | 14:43 |
| efried | I would have to think through what it would mean to set up the Connection just to get the endpoint to pass to the client. Whether having clouds.yaml in the mix would even be possible in that scenario. | 14:44 |
| efried | I guess I don't see why not. | 14:44 |
| efried | okay, speculation has reached point of diminishing returns. I'll go off and try to crystallize this. Thanks again. | 14:45 |
| mordred | efried: \o/ ... crystalization | 14:52 |
| *** Luzi has quit IRC | 15:09 | |
| *** slaweq has quit IRC | 15:48 | |
| *** ricolin has joined #openstack-sdks | 15:55 | |
| *** ricolin has quit IRC | 16:22 | |
| *** dave-mccowan has joined #openstack-sdks | 16:29 | |
| *** slaweq has joined #openstack-sdks | 16:45 | |
| *** jangutter has quit IRC | 16:50 | |
| *** cdent has quit IRC | 17:03 | |
| *** slaweq has quit IRC | 17:07 | |
| *** e0ne has quit IRC | 17:07 | |
| *** jpena is now known as jpena|off | 17:07 | |
| *** dtantsur is now known as dtantsur|afk | 17:08 | |
| *** ttsiouts has joined #openstack-sdks | 17:15 | |
| *** efried has quit IRC | 17:19 | |
| *** ttsiouts has quit IRC | 17:20 | |
| *** efried has joined #openstack-sdks | 17:22 | |
| *** slaweq has joined #openstack-sdks | 17:29 | |
| *** ralonsoh has quit IRC | 17:31 | |
| *** slaweq has quit IRC | 17:43 | |
| dustinc | 👍 | 18:16 |
| *** e0ne has joined #openstack-sdks | 18:45 | |
| *** e0ne has quit IRC | 18:57 | |
| openstackgerrit | Dean Troyer proposed openstack/python-openstackclient master: Remove deprecated volume commands and args https://review.opendev.org/612751 | 19:05 |
| *** slaweq has joined #openstack-sdks | 19:42 | |
| *** toabctl has quit IRC | 19:43 | |
| *** whoami-rajat has quit IRC | 20:19 | |
| *** holser_ has quit IRC | 20:46 | |
| *** ttsiouts has joined #openstack-sdks | 20:55 | |
| *** ttsiouts has quit IRC | 21:34 | |
| *** ttsiouts has joined #openstack-sdks | 21:49 | |
| *** ttsiouts has quit IRC | 21:54 | |
| *** slaweq has quit IRC | 21:57 | |
| *** slaweq has joined #openstack-sdks | 22:08 | |
| *** slaweq has quit IRC | 22:13 | |
| *** tosky has quit IRC | 22:15 | |
| *** ttsiouts has joined #openstack-sdks | 22:23 | |
| *** bobh has joined #openstack-sdks | 22:31 | |
| *** slaweq has joined #openstack-sdks | 22:39 | |
| *** slaweq has quit IRC | 22:44 | |
| *** bobh has quit IRC | 22:46 | |
| *** efried has quit IRC | 23:22 | |
| *** efried has joined #openstack-sdks | 23:23 | |
| *** ttsiouts has quit IRC | 23:35 | |
| *** ttsiouts has joined #openstack-sdks | 23:50 | |
| openstackgerrit | Dean Troyer proposed openstack/osc-lib master: Add FakeModule from OSC https://review.opendev.org/660230 | 23:50 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!