| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-23 | |||
| 13:34:03 | dansmith | pabelanger: I imagine it comes from not confusing the user about why they PUT a new keypair and can't suddenly use it to log into all the instances they've booted with that keypair | |
| 13:34:12 | dansmith | several other cloud-like platforms I know of have the same rule | |
| 13:38:10 | pabelanger | dansmith: I can understand that, but POST / PUT seem to be well documented on there behaviours. And other resources in nove do support PUT actions /servers and /quotas come to mind | |
| 13:38:27 | dansmith | but not flavors for the same reason | |
| 13:38:49 | dansmith | servers and quotas update doesn't affect something else, right? | |
| 13:39:02 | dansmith | like if I'm allowed to make a change to a server, I'm not affecting another server elsewhere | |
| 13:39:38 | pabelanger | sure, but the same could be said about an SSH key, if only used for a single server | |
| 13:39:38 | dansmith | one server does not reference another, nor does quota have such a link | |
| 13:40:12 | dansmith | but if you have it for one server and you change that key, it no longer matches what is in the server | |
| 13:40:27 | mriedem | ^ is definitely like flavors, | |
| 13:40:36 | mriedem | and we store the keypair in the instance in the db like flavors | |
| 13:41:05 | dansmith | yup | |
| 13:41:39 | pabelanger | The issue we are having is, if we need to rotate keys for nodepool (infra-root-keys in nova), we need to do a 2 step approach. This means, when we delete the key, nodepool starts failing to create new servers until we create infra-root-keys again. And since we do this via automation, it is difficult to do this process without causing an outage for nodepool | |
| 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 | 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:07 | mriedem | like proxying volume type | |
| 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 | dansmith | mriedem: right | |
| 14:21:15 | mriedem | target_cell mutates the thing that's passed everywhere | |
| 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 | mriedem | or just leave it and point it out in the commit message in this one | |
| 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: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 | |