| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-23 | |||
| 12:35:43 | openstackgerrit | Eric Berglund proposed openstack/nova master: Add strict option to discover_hosts https://review.openstack.org/467218 | |
| 12:38:21 | ftersin | mdbooth: i proposed a series, which resolve that problem separately: https://review.openstack.org/#/q/topic:disk_info_processing | |
| 12:50:47 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Exclude deleted service records when calling hyervisor statistics https://review.openstack.org/467220 | |
| 12:56:39 | openstackgerrit | Eric Berglund proposed openstack/nova master: Add strict option to discover_hosts https://review.openstack.org/467218 | |
| 13:00:26 | openstackgerrit | sahid proposed openstack/nova master: libvirt: configure trust mode for vfs https://review.openstack.org/458514 | |
| 13:11:44 | mriedem | ahoy matey | |
| 13:11:49 | mriedem | (s) | |
| 13:11:57 | cdent | is it talk like a pirate day again? | |
| 13:12:12 | asettle | Yar | |
| 13:12:15 | asettle | it is | |
| 13:12:45 | cdent | since I'm in cornwall, I claim authenticity | |
| 13:13:08 | asettle | Please, please tell me you're in Penzance | |
| 13:15:57 | mriedem | dansmith: when you're decent i have some questions about your bottom cells change for target_cell | |
| 13:19:01 | cdent | asettle: sadly right this moment I am in Truro | |
| 13:19:54 | asettle | Truro is nice! | |
| 13:20:02 | asettle | But not Penzance | |
| 13:30:41 | dansmith | mriedem: in the review or you want to ask them here? | |
| 13:31:12 | pabelanger | morning! | |
| 13:31:24 | mriedem | dansmith: either | |
| 13:31:24 | dansmith | mriedem: I still need to follow up with a few more of your earlier comments I think, but removing the object targeting seems to not break anything | |
| 13:31:35 | mriedem | i just went through PS13 | |
| 13:31:39 | dansmith | mriedem: okay well I'm yet to be caffeinated so give me a few | |
| 13:31:45 | mriedem | ok | |
| 13:32:33 | pabelanger | Q: Why is there no PUT /os-keypairs functionality? We have a use case in openstack-infra where we want to update an existing key (to rotate public_keys) but we have to delete / create to achieve this | |
| 13:33:50 | pabelanger | Specifically, this would be for nodepool | |
| 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 | |