Earlier  
Posted Nick Remark
#openstack-nova - 2017-05-23
13:42:18 mriedem why not create the new key first and then delete the old key?
13:42:21 mriedem duplicates i guess
13:42:22 mriedem on the name
13:42:31 dansmith how can you use this for key rotation if it doesn't cause the existing servers to change the key they use?
13:42:45 dansmith mriedem: or just date your keys
13:42:55 mriedem i'm married
13:42:56 dansmith date *stamp* before you go there :)
13:42:58 dansmith dammit
13:44:49 pabelanger the SSH key, infra-root-keys is only used when (humans) need to log into a test node and debug it. We are okay with old nodes still using the first key, because up to 2 hours later the server is deleted.
13:46:18 dansmith okay so why not just create a new datestamped key?
13:47:03 dansmith pabelanger: anyway, you asked _why_ and I think that's why. I think it would be confusing to enable changing them at this point, but if you want to propose it we can discuss I suppose
13:47:19 mriedem i'm asking in ops too to see if users are asking for this
13:47:28 mriedem non-infra users let me say
13:47:31 mriedem infra are users too!
13:47:52 pabelanger So, to rotate this out today, we'd need to do the following:
13:48:06 pabelanger 1) update clouds_layout.yaml with new key: http://git.openstack.org/cgit/openstack-infra/system-config/tree/playbooks/clouds_layouts.yml#n35
13:48:15 pabelanger land and merge (30mins)
13:48:21 dansmith mriedem: even if they are, we should decide whether we think it breaks our model or not
13:48:59 mriedem dansmith: sure, i'd just like to know if this is one of those things everyone has been secretly wanting forever and just no one asked
13:49:07 mriedem like proxying volume type
13:49:07 pabelanger 2) Replace infra-root-keys with new keyname in nodepool.yaml: http://git.openstack.org/cgit/openstack-infra/project-config/tree/nodepool/nodepool.yaml (~78 entries)
13:49:09 dansmith mriedem: aye
13:49:21 pabelanger review and merge
13:49:23 mriedem dansmith: see my ML thread on volume type from late last night?
13:49:54 dansmith pabelanger: or build your system to list your keys and choose the one with the highest serial number at the point of each build right?
13:49:55 dansmith mriedem: no
13:50:40 mriedem it's a hoot and a half
13:50:42 pabelanger dansmith: sure, but as an operator I really only want 1 key at 1 time
13:51:21 pabelanger managing more then one is possible, but something not in our current workflows with other cloud settings.
13:51:28 openstackgerrit Sean Dague proposed openstack/nova master: WIP: request_id passing to neutron https://review.openstack.org/467242
13:54:38 efried dansmith Not sure if you saw esberglu's --strict change go by: https://review.openstack.org/#/c/467218/
13:54:58 dansmith efried: I did not
13:55:00 efried dansmith He's gonna fold it into our CI to prove it works. Should have that result by EOD or sooner.
13:55:10 efried dansmith I took the liberty of adding you to the review ;-)
13:55:13 dansmith mriedem: I just replied to your comments but if you want to chat here or in a hangout now, I'm ready
13:55:17 dansmith efried: heh okay
13:57:40 mriedem dansmith: i've got to take maya to school, will ping when i'm back
13:57:54 dansmith okay
13:57:58 efried mriedem That review you asked me for last night - done.
14:12:27 alex_xu sfinucan: thanks, just +w
14:12:42 sfinucan alex_xu: Ta
14:20:56 mriedem dansmith: in your replies, when you say global context, you mean modifying the single context object that's being passed around everywhere, right?
14:21:02 mriedem it's not an actual 'global'
14:21:15 mriedem target_cell mutates the thing that's passed everywhere
14:21:15 dansmith mriedem: right
14:21:17 mriedem ok
14:21:18 dansmith shared context or something
14:21:21 mriedem right
14:21:30 mriedem "Maybe it's because we targeted the same context that was used in _lookup_instance and so when we target it here, it's modifying instance._context by reference?"
14:21:33 mriedem was my attempt at saying the same
14:21:41 dansmith okay
14:22:05 mriedem dansmith: ok on to https://review.openstack.org/#/c/458634/13/nova/conductor/manager.py@846
14:22:13 mriedem is that only here because it will be a failure later?
14:22:17 mriedem if not done now?
14:23:16 dansmith mriedem: yeah, but that's the same for the rest of the patch
14:23:27 dansmith it's all calling convention changes so I can change the behavior of the target function and have things continue to work
14:23:40 dansmith I could put any of this in the next patch, but I'm just trying to separate things
14:24:03 mriedem sure, but the difference is the rest of the patch is already using target_cell
14:24:10 mriedem that's why everyone is thrown off on that particular change
14:24:23 acormier Quick ?: Is it possible to configure a subnet of compute nodes in Openstack to use Ceph RBD backend? Or do all nodes have to move over in wholesale?
14:24:33 mriedem subset
14:24:39 mriedem acormier: answer is yes
14:25:07 dansmith mriedem: okay I guess it seems like exactly the same to me
14:25:18 dansmith mriedem: but if you really want it broken out then I will
14:26:06 mriedem i'd prefer it lives in the patch that it's going to be needed otherwise it fails
14:27:00 mriedem dansmith: last thing, so you do plan on changing https://review.openstack.org/#/c/458634/13/nova/objects/host_mapping.py to use the yielded cctxt?
14:27:04 mriedem when creating the host mappings i mean,
14:27:08 mriedem even though the api db connection is the same
14:27:15 dansmith I answered that one didn't I?
14:27:31 mriedem you replied,
14:27:36 mriedem but i'm not sure it answered my question
14:27:54 dansmith okay, yes I've already got it changed locally
14:27:59 mriedem ok
14:28:08 mriedem that wasn't obvious if the patch wasn't WIPed or something
14:28:19 mriedem anywho, that's it
14:28:34 mriedem dansmith: can we still be friends?
14:29:06 dansmith mriedem: so, moving those conductor changes into the patch that changes context.py will make that match go from "one functional change and the associated test changes" to "one real code change, an ancillary code change and several test changes"
14:29:18 dansmith can I just move it into another patch and explain in the commit message or something?
14:29:23 mriedem sure
14:29:25 dansmith I really want that context switch patch to be really tight
14:29:54 dansmith okay, I totally don't understand why that's different than having it in the first patch, but I'll do it anyway :)
14:29:54 mriedem or just leave it and point it out in the commit message in this one
14:30:03 mriedem the fact 3 people had to ask about it,
14:30:05 mriedem means it's not clear
14:30:13 mriedem so just point it out in the commit message
14:30:18 dansmith if that's good enough then I'd like that option
14:30:25 mriedem fine by me
14:30:43 mriedem melwitt: it's 7:30am, i assume you're 2 hours into addressing https://review.openstack.org/#/c/446239/
14:30:57 mriedem because i want to +2 that one
14:41:21 mriedem alex_xu: replied in https://review.openstack.org/#/c/459569/
14:42:48 mriedem alex_xu: Kevin_Zheng: jaypipes: why is this a 403 and not a 409? https://review.openstack.org/#/c/464548/5/nova/api/openstack/compute/servers.py
14:42:58 mriedem i thought we normally handled over quota as 409 in the api
14:43:46 openstackgerrit Daniel Pawlik proposed openstack/nova master: Add `hide_hypervisor_id` image property https://review.openstack.org/459753
14:44:05 mriedem nevermind, i guess at some point those were switched to 403
14:44:30 melwitt mriedem: yeah, I got most of it done yesterday and I'm stuck on a unit test of all things. hope I'll get past that soon
14:44:55 Kevin_Zheng mriedem: I did a search and I saw it was handled in that way somewhere else
14:45:05 mriedem Kevin_Zheng: yeah me too, i didn't realize that was changed
14:45:56 Kevin_Zheng Btw, I tired to cherry pick it to N but seems conflicting
14:46:17 mriedem then you have to do it manually using git cherry-pick -x
14:46:35 mriedem resolve the merge conflict locally, and leave a note in the commit message about what the conflict was

Earlier   Later