Monday, 2019-05-20

*** ricolin has joined #openstack-sdks02:14
*** whoami-rajat has joined #openstack-sdks03:11
*** dave-mccowan has quit IRC03:58
*** e0ne has joined #openstack-sdks05:31
*** Luzi has joined #openstack-sdks05:45
*** e0ne has quit IRC06:02
*** cshen has joined #openstack-sdks06:26
*** slaweq has joined #openstack-sdks06:39
*** TheJulia has quit IRC06:47
*** vdrok has quit IRC06:47
*** Shrews has quit IRC06:47
*** Shrews has joined #openstack-sdks06:47
*** vdrok has joined #openstack-sdks06:47
*** TheJulia has joined #openstack-sdks06:47
*** johnsom has quit IRC06:48
*** guilhermesp has quit IRC06:48
*** amito has quit IRC06:48
*** guilhermesp has joined #openstack-sdks06:48
*** amito has joined #openstack-sdks06:48
*** johnsom has joined #openstack-sdks06:48
*** ralonsoh has joined #openstack-sdks06:57
*** zigo has joined #openstack-sdks07:09
*** yolanda_ has quit IRC07:13
*** yolanda_ has joined #openstack-sdks07:20
openstackgerrityanpuqing proposed openstack/python-openstackclient master: Client should parse string to boolean for valuse 'is_domain'
*** dtantsur|afk is now known as dtantsur07:35
*** tosky has joined #openstack-sdks07:35
*** e0ne has joined #openstack-sdks07:48
*** jpena|off is now known as jpena07:52
*** gtema has joined #openstack-sdks08:04
openstackgerrityanpuqing proposed openstack/python-openstackclient master: Client should parse string to boolean for valuse 'is_domain'
*** jangutter has joined #openstack-sdks08:18
*** holser_ has joined #openstack-sdks08:20
*** gtema has quit IRC08:24
*** gtema has joined #openstack-sdks08:27
*** holser_ has quit IRC08:59
*** ricolin has quit IRC09:19
*** holser_ has joined #openstack-sdks09:21
*** holser_ has quit IRC09:21
*** holser_ has joined #openstack-sdks09:22
*** cdent has joined #openstack-sdks09:46
*** ttsiouts has joined #openstack-sdks09:54
openstackgerrityanpuqing proposed openstack/python-openstackclient master: Client should parse string to boolean for valuse 'is_domain'
*** ttsiouts has quit IRC10:23
openstackgerritArtem Goncharov proposed openstack/openstacksdk master: WIP rework statistics reporting
*** holser_ has quit IRC10:33
*** gtema has quit IRC10:38
*** cshen has quit IRC10:52
*** yolanda_ has quit IRC11:04
*** yolanda_ has joined #openstack-sdks11:08
*** cshen has joined #openstack-sdks11:09
*** cshen has quit IRC11:15
*** jpena is now known as jpena|lunch11:25
*** cshen has joined #openstack-sdks11:35
*** cshen has quit IRC11:41
*** cshen has joined #openstack-sdks11:44
*** gtema has joined #openstack-sdks11:49
*** bobh has joined #openstack-sdks11:51
*** dave-mccowan has joined #openstack-sdks12:04
openstackgerritArtem Goncharov proposed openstack/openstacksdk master: WIP rework statistics reporting
*** bobh has quit IRC12:10
*** bobh has joined #openstack-sdks12:12
*** bobh has quit IRC12:16
*** jpena|lunch is now known as jpena12:22
*** dave-mccowan has quit IRC12:48
*** Guest84310 has joined #openstack-sdks13:05
*** Guest84310 is now known as redrobot13:06
*** jroll has quit IRC13:25
*** jroll has joined #openstack-sdks13:26
*** gtema has quit IRC13:34
openstackgerritDean Troyer proposed openstack/python-openstackclient master: Batch up minor cleanups for release
efriedmordred: ...or today?13:48
mordredefried: yes!13:51
mordredefried: today is a great day to discuss such things13:51
efried(gtema, dustinc, dtantsur)13:52
efriedmordred: So today we have oslo.config for e.g. [placement]=>ks_loading.get_{auth|session|adapter}_config_opts13:52
efriedI'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
efriedThe 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
efriedthat's... pretty much it.13:54
mordredyes - 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 parameter13:55
efriedyeah, 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_name13:55
efriedoh, okay. I definitely want to be told what a good name for the opt is.13:56
mordredyeah - might just be meh - mostly thinking about how we can make it easy for other non-nova services to follow the lead13:56
dtantsurcloud_name is probably fine13:56
efried'cloud' might be a bit too broad. But I don't know ...13:56
mordredwell - cloud is what is used everywhere else such a value is consumed13:56
mordredso while I do wish we'd named it better ... probably more confusing for the oslo opt to be different13:57
efriedI can live with 'cloud'. I don't think we have anything else in nova that'll conflict, at least.13:58
mordredoh - also - fwiw, if there is only one cloud entry defined in clouds.yaml, the won't need to put a cloud= setting in nova.ini13:58
efriedYeah, but then we would have no way to know that we're looking for clouds.yaml instead of ksa opts.13:58
mordredefried: this is a good point, actually13:59
efriedAnd 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
mordredefried: 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 file14:00
mordredI agree = no use_clouds_yaml = $bool14:00
efriedcool, so here's another angle:14:00
efriedeventually I think we probably want to deprecate and remove the ksa oslo.config stuff entirely.14:00
efriedAnd the theory behind clouds.yaml is more like define-once...14:01
efriedso 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
efriedBecause presumably one nova wouldn't want different services to talk to different clouds?14:01
efriedso like [DEFAULT]cloud=$str, or a section that somehow denotes [shit-the-sdk-uses]14:03
mordredyes. I think this is spot on14:03
efriedWould rather not put it in [DEFAULT] I guess; suggestions for what to call that second thing?14:04
efriedIs [openstacksdk] too crazy?14:04
efriedwant something that makes sense from an operator pov, not sure that's it.14:04
mordredyeah. I'm not sure it is either. maybe [openstackapi]? or just [openstack] ?14:05
efriedagain my initial reaction is "too broad", but letting it settle for a sec, maybe it's the right thing.14:06
mordredefried: do we think people still might want to make multiple accounts for nova to use to talk to things?14:06
efriedsee, I don't know that answer.14:06
efriedBut there's another wrinkle to bring up, so maybe I'll mention that and we can come back to --^ in a sec.14:07
mordredlike - 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
efriedIt'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
efriedand for extra craziness, there's other stuff - neutron - where sometimes it's user and sometimes it's admin.14:08
mordredwe've got a connect_as method to allow starting with an existing connection and connecting with a new set of credentials14:08
efriedThis 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
efriedwell, in this case it's going to be the other way around.14:08
efriedGet session/adapter from clouds.yaml, but use <this> auth.14:09
mordredthat's right -we might have to adapt the connect_as to understand being handed an auth - but in general that's how that should work14:09
mordredso 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 object14:10
mordred(that way things like version discovery cache get shared :) )14:10
efriedYes, 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
efriedmm, yeah, or that.14:11
efriedso, details to be worked out, but I think we agree on the broad strokes and it all sounds possible.14:11
efriedso 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
efriedI need to look into whether I can reliably/easily detect whether ksa auth options are present, though.14:12
efriedbecause if [openstack]cloud=$str and [placement]$ksa_opts, I need to use the latter14:12
efriedI 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
mordredefried: ++ per section overrides14:13
efriedthat doesn't work if we're doing the user auth thingy.14:13
efriedbecause then they just need session/adapter opts14:13
efriedwhich possibly all default...14:13
mordredwell ... so - if they have a default cloud14:14
mordredand 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.yaml14:14
mordredwhich 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 placement14:15
mordredso I *think* it should Just Work14:15
efriedThe programmer in me likes the power/flexibility that offers14:15
efriedbut I'm concerned about the complexity and especially the test surface14:16
efriedYes, it should Just Work, but the devil is in the details.14:16
efriedLike what happened early on with interface...14:16
mordredyeah - 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 fun14:16
efriedI would like to be able to KISS. But I'm not sure if we can do that without removing capabilities.14:17
mordredwe could also just make a rule that you can't mix the two14:17
efriedso, you're not allowed to have [openstack]cloud=$str *and* [section]$ksa_opts14:17
mordredlike, if you list a default cloud, or a cloud entry for a service - you cannot also specify parameters directly in the nova.ini14:17
efriedbut you *can* have [openstack]cloud=$str and [section]cloud=$other_str14:17
efriedwe still need a way to detect $ksa_opts are present14:18
efriedor just say that's unsupported and ignore them when cloud is specified.14:18
efriedyeah, that ^14:18
efriedokay, this works.14:18
*** cdent has quit IRC14:18
mordredwell - or we can detect that in the sdk method and throw an error/warning if we detect both14:19
mordred*waves hands*14:19
efriedI was thinking I'd be taking different code paths into init'ing the Connection depending on whether 'cloud' is present'14:19
efriedone uses your new 'get oslo.config opts' method. The other just looks at clouds.yaml14:20
efriedthey don't meet.14:20
mordredah. 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 to14:20
mordredbut I'm fine either way14:20
efriedoh, I see.14:20
mordredmostly thinking it woud be good if heat and similar folks adopt the same system and the deployer semantics are all the same14:21
efriedyeah, that makes sense to me.14:21
efriedwe'll need a config gen entrypoint14:22
mordredooh! hey - what if we made a get_oslo_options method in sdk that14:22
mordredthat does get14:23
mordredmy god. what is happening to my IRC client.14:23
efriedI thought it was a magnetic <Enter> key14:23
mordredanyway - 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 for14:24
mordredis that too one-stop-shop?14:24
efriedIMO yes14:24
mordredwe can always add one later if we fine we're copy-pasta across services :)14:24
efriedwell, yes, which is really what we have today.14:25
efriedI 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-sdks14:26
*** holser_ has joined #openstack-sdks14:27
efriedI'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
efriedanother 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
efriedWell, I was hoping to be able to avoid writing a spec, but the text in 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
efriedI'll have to sort out which bits will be on the sdk side and which bits on the nova side.14:32
efriedYou guys don't really use specs in sdk yet?14:32
mordredno - not really enough people to warrant it14:33
dtantsurwe're using design-in-production approach14:33
mordredbut - 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
efriedokay, that wfm. I'll just have to put big notes for nova people to not stress about those sections :)14:34
mordredjust a big note telling them to not stress in general14:35
efriedPut that on the front page of the docs.14:35
efriedDON'T PANIC14:35
efriedsomeone famous said that already14:35
efriedThanks 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 too14:36
efriedwhat's secure.yaml?14:36
mordredso that if they want to put passwords in a more restricted file, they acn14:36
mordred(people get twitchy about passwords)14:36
efriedI would think the nova docs would just point to the sdk docs14:37
mordredefried: good call14:38
efriedso why have a separate file? Would it have like different perms or something?14:39
efriedone of my colleagues actually brought up the idea of being able to encrypt the file with the passwords in it.14:39
mordredyeah - 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
mordredalso might make things nicer for people using k8s - you can put the secure.yaml in a k8s secret14:40
efriedthere's a mechanism to use certificates rather than passwords, right?14:40
efriedoh, yeah, next section down.14:40
mordredI think?14:40
mordredso that's probably a better way to deal with service-to-service secrets14:41
mordredmany many options :)14:41
efriedshrug, 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 IRC14:43
efriedbtw, 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
efriedProbably when we've done away with all the clients14:43
efriedI 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
efriedI guess I don't see why not.14:44
efriedokay, speculation has reached point of diminishing returns. I'll go off and try to crystallize this. Thanks again.14:45
mordredefried: \o/ ... crystalization14:52
*** Luzi has quit IRC15:09
*** slaweq has quit IRC15:48
*** ricolin has joined #openstack-sdks15:55
*** ricolin has quit IRC16:22
*** dave-mccowan has joined #openstack-sdks16:29
*** slaweq has joined #openstack-sdks16:45
*** jangutter has quit IRC16:50
*** cdent has quit IRC17:03
*** slaweq has quit IRC17:07
*** e0ne has quit IRC17:07
*** jpena is now known as jpena|off17:07
*** dtantsur is now known as dtantsur|afk17:08
*** ttsiouts has joined #openstack-sdks17:15
*** efried has quit IRC17:19
*** ttsiouts has quit IRC17:20
*** efried has joined #openstack-sdks17:22
*** slaweq has joined #openstack-sdks17:29
*** ralonsoh has quit IRC17:31
*** slaweq has quit IRC17:43
*** e0ne has joined #openstack-sdks18:45
*** e0ne has quit IRC18:57
openstackgerritDean Troyer proposed openstack/python-openstackclient master: Remove deprecated volume commands and args
*** slaweq has joined #openstack-sdks19:42
*** toabctl has quit IRC19:43
*** whoami-rajat has quit IRC20:19
*** holser_ has quit IRC20:46
*** ttsiouts has joined #openstack-sdks20:55
*** ttsiouts has quit IRC21:34
*** ttsiouts has joined #openstack-sdks21:49
*** ttsiouts has quit IRC21:54
*** slaweq has quit IRC21:57
*** slaweq has joined #openstack-sdks22:08
*** slaweq has quit IRC22:13
*** tosky has quit IRC22:15
*** ttsiouts has joined #openstack-sdks22:23
*** bobh has joined #openstack-sdks22:31
*** slaweq has joined #openstack-sdks22:39
*** slaweq has quit IRC22:44
*** bobh has quit IRC22:46
*** efried has quit IRC23:22
*** efried has joined #openstack-sdks23:23
*** ttsiouts has quit IRC23:35
*** ttsiouts has joined #openstack-sdks23:50
openstackgerritDean Troyer proposed openstack/osc-lib master: Add FakeModule from OSC

Generated by 2.15.3 by Marius Gedminas - find it at!