Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-09-21
16:04:12 sdague efried: so, I think the answer ends up being roughly
16:04:23 sdague glance, cinder, barbican, keystone always act as user
16:04:41 sdague ironic always from conf, because nova is the ironic multi tenancy solution
16:04:51 sdague and neutron, it depends on the operation
16:05:31 efried sdague Okay. For that first set: You already pushed for glance to be able to get the auth from context, so not c). Should we b) allow conf override or just a) always use context?
16:05:59 sdague efried: for glance, I don't think so
16:06:13 sdague I can't think of a case where we should "sudo" on image things
16:06:27 sdague or that image things have to happen outside of a user context
16:07:08 sdague we should, whenever possible, really operate in the user context of the user token we got, because it ensures we don't have an unintended priv escalation
16:07:26 sdague ironic is a special case, ironic doesn't have regular users
16:07:31 dansmith edleafe: sanity check my tome of words on that review?
16:07:38 efried (It's worth noting that part of the mission statement of this bp was consistency. Sigh.)
16:08:09 mordred efried, sdague: "optionally wrapped in a service token" doesn't need nova-specific creds does it?
16:08:21 edleafe dansmith: on a call and an IRC meeting, so it'll be later
16:08:29 dansmith edleafe: sure
16:08:54 efried mordred It's just service_auth.get_auth_plugin(context)
16:09:00 sdague mordred: i foreget exactly what it needs on disk
16:09:08 sdague mordred: it does need some creds
16:09:20 efried oh
16:10:03 efried mordred sdague https://github.com/openstack/nova/blob/master/nova/service_auth.py
16:10:28 efried So it loads up the auth from the [service_user] group.
16:10:51 efried and we get two auths in the thing.
16:10:53 efried yeesh.
16:11:35 mordred so - you need at least some of the ksa settings for each service no matter what
16:11:51 efried Only if CONF.service_user.send_service_user_token is set
16:11:56 mordred like you need the adapter options and probably the session options - so it's really just a question of whether the authoptions are included right?
16:13:22 efried mordred Yeah, that's what we're discussing - whether we should even register the auth options in groups where that service can be contacted using the user context auth.
16:16:02 mordred nod. well - consistency notwithstanding, I'd vote for not registering conf options if we're not ever going to use them - otherwise someone is going to configure them and then be confused why they're not used
16:17:16 mordred but I defer to smarter nova humans
16:17:46 sdague mordred: ++ lets keep things trimmed down
16:18:03 sdague efried: it's probably going to be worth writing a doc section on configuring nova with other services as well
16:18:11 sdague because I agree there is confusion here
16:20:11 efried sdague Cool. edmondsw brought this up in the spec review, and I addressed it with a brief parenthetical, but it has become a bigger thing quite suddenly. Worth a delta to the spec, you think? (It just merged.)
16:20:48 sdague efried: I'm ok if it's just admin docs as part of the work
16:20:53 efried rgr
16:23:08 sdague mordred: on https://review.openstack.org/#/c/488137/17/nova/utils.py@1309
16:23:30 sdague is the service types library not encoding this in python?
16:23:47 sdague like, I'd kind of expect that to be happening all behind the scenes
16:25:14 efried sdague Without a session param, it's pretty lightweight: https://github.com/openstack/os-service-types/blob/master/os_service_types/service_types.py#L51
16:25:15 mordred sdague: yes- os-service-types is - os-service-types didn't make it in to the keystoneauth release for pike, so we need to add that now that queens is open
16:25:37 efried Almost all of the work is done at import time, actually.
16:25:46 efried https://github.com/openstack/os-service-types/blob/master/os_service_types/service_types.py#L22
16:26:06 mordred efried: yah, I think it's actually fine for this cycle - the contents really do not change frequently - and CERTAINLY not for the services that nova cares about
16:26:19 efried The race would be harmless. I can take the lock out.
16:26:20 mordred so we can get live-update landed as a follow on
16:26:24 sdague um... https://github.com/openstack/os-service-types/blob/master/os_service_types/service_types.py#L59 ? closet network call?
16:26:53 edmondsw efried sdague mordred to be clear, long-term I think we'll need auth conf options for everything. But we don't today
16:26:56 sdague that seems like something people should have to opt into
16:26:58 mordred sdague: yah - it's there - but the keystoneauth consumption of the library at least at first will not pass a session
16:27:01 mordred sdague: yup
16:27:36 efried sdague The opt-in is by passing a `session` param.
16:27:43 mordred sdague: so when we land the next patch to ksa to consume that, nova can just switch to always passing the correct/official type to keystoneauth and keystoneauth will dtrt
16:28:16 mordred we'll make sure subsequent turning on of remote access/ network calls is appropriately opt-in when we add it
16:28:30 sdague I'm actually not super clear why the remote part is there
16:28:48 efried to get a fresh copy of the service-types-authority data
16:29:05 efried os-service-types ships with a cached copy
16:29:18 openstackgerrit Merged openstack/os-vif master: Update reno for stable/pike https://review.openstack.org/488671
16:29:19 sdague I thought the point of this was a no requirements version which we rev every time there is a service types update
16:29:29 sdague so people just replace it with the new one
16:29:42 efried Yup. Unless they don't.
16:29:50 sdague if they don't, then they don't
16:30:05 openstackgerrit Merged openstack/os-traits master: Update reno for stable/pike https://review.openstack.org/488669
16:30:09 sdague closet network calls that could end up with very interesting results or random network hangs
16:30:15 sdague don't seem useful
16:30:46 sdague like https://github.com/openstack/os-service-types/blob/master/os_service_types/service_types.py#L59 under some circumstances can hang forever
16:31:06 mordred sdague: yah - I don't actually think it's useful for nova to opt-in to the fetch behavior
16:31:53 efried Hence the comment in the nova change
16:32:03 sdague mordred: sure, but I'm not super clear where it's a good idea to put a potentially arbitrary delay into anyone's code path
16:32:35 sdague I get that it's clever, but the potential failure domains get huge
16:32:57 openstackgerrit Eric Fried proposed openstack/nova master: nova.utils.get_ksa_adapter() https://review.openstack.org/488137
16:33:07 efried sdague mordred ^ updated to remove lock
16:33:08 mordred sdague: totally. this is why it will always be opt-in
16:33:09 openstackgerrit Merged openstack/nova master: Restore '[vnc] vnc_*' option support https://review.openstack.org/505831
16:33:58 sdague mordred: ok. I'm still not sure why it's useful, but I've said my piece :)
16:34:07 mordred efried: yah- I think honestly you could just initialize the _SERVICE_TYPES at the top and have it done at import
16:34:38 efried mordred Considering that ost loads the local file at import time (which I didn't realize) I think you're right.
16:34:38 sdague having spent a couple of months discovering requests can hang forever on simple get calls depending on what's happening on the network, which was locking up 1/3 of my smart home devices, I'm super twitchy on it
16:36:03 openstackgerrit Eric Fried proposed openstack/nova master: nova.utils.get_ksa_adapter() https://review.openstack.org/488137
16:36:10 efried mordred Did that ^
16:37:57 sdague efried: +2
16:38:03 efried thanks!
16:38:26 openstackgerrit Sean Dague proposed openstack/nova master: Support qemu >= 2.10 https://review.openstack.org/505673
16:39:19 mriedem efried: stephenfin: you guys did that fancy scheduler call flow diagram. i will pay a shiny nickel to whoever can make this live migration call flow into a docs diagram https://photos.app.goo.gl/Q8JdpjM0PZhAzsv32
16:39:51 sdague cburgess: https://review.openstack.org/#/c/505673 - live snapshot by default
16:41:40 dansmith mriedem: lol
16:41:48 dansmith how ... analog of you
16:42:03 mriedem dansmith: i think i'm just going to slap that into our official docs
16:42:17 mriedem "Technical reference deep dive > live migration > THIS"
16:42:27 dansmith heh
16:43:05 openstackgerrit Elod Illes proposed openstack/nova master: Add instance.interface_detach notification https://review.openstack.org/506284
16:43:49 mriedem if only i were on the twitters
16:44:17 sdague mriedem: that is a solvable problem
16:45:18 efried mriedem What does "cast" mean?
16:45:44 efried async invocation?
16:46:28 mriedem rpc cast
16:46:29 mriedem vs call
16:46:42 mriedem which is important to understand the hot potato between the computes during live migration
16:46:51 mriedem especially if you love rpc timeouts
16:46:59 mriedem because your instance has 20 ports and 20 volumes attached to it
16:47:09 mriedem and token timeouts

Earlier   Later