| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-12-04 | |||
| 05:05:47 | openstackgerrit | jichenjc proposed openstack/nova master: downgrade when host does not support capabilities https://review.opendev.org/697228 | |
| 05:47:26 | openstackgerrit | Brin Zhang proposed openstack/nova-specs master: Support re-configure deleted_on_termination in server https://review.opendev.org/580336 | |
| 06:46:55 | openstackgerrit | OpenStack Proposal Bot proposed openstack/nova master: Imported Translations from Zanata https://review.opendev.org/694717 | |
| 07:37:35 | openstackgerrit | jichenjc proposed openstack/nova master: libvirt: avoid cpu check at s390x arch https://review.opendev.org/696228 | |
| 07:56:29 | openstackgerrit | Luyao Zhong proposed openstack/nova master: support live migration with vpmems https://review.opendev.org/687856 | |
| 09:08:52 | openstackgerrit | Sundar Nadathur proposed openstack/nova master: ksa auth conf and client for Cyborg access https://review.opendev.org/631242 | |
| 09:08:52 | openstackgerrit | Sundar Nadathur proposed openstack/nova master: Add Cyborg device profile groups to request spec. https://review.opendev.org/631243 | |
| 09:08:53 | openstackgerrit | Sundar Nadathur proposed openstack/nova master: Define Cyborg ARQ binding notification event. https://review.opendev.org/692707 | |
| 09:08:53 | openstackgerrit | Sundar Nadathur proposed openstack/nova master: Create and bind Cyborg ARQs. https://review.opendev.org/631244 | |
| 09:08:54 | openstackgerrit | Sundar Nadathur proposed openstack/nova master: Compose accelerator PCI devices into VM's domain XML. https://review.opendev.org/631245 | |
| 09:08:54 | openstackgerrit | Sundar Nadathur proposed openstack/nova master: Delete ARQs for an instance when the instance is deleted. https://review.opendev.org/673735 | |
| 09:08:55 | openstackgerrit | Sundar Nadathur proposed openstack/nova master: Add cyborg tempest job. https://review.opendev.org/670999 | |
| 09:57:38 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Remove remaining nova-network quotas https://review.opendev.org/697152 | |
| 09:57:38 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Remove use of legacy 'FloatingIP' object https://review.opendev.org/697153 | |
| 09:57:39 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Remove use of legacy 'Network' object https://review.opendev.org/697154 | |
| 09:57:39 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Remove use of legacy 'SecurityGroup' object https://review.opendev.org/697155 | |
| 09:57:40 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Remove unused nova-network objects https://review.opendev.org/697156 | |
| 09:57:40 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Follow-up for I12a96ea659ed402cc4d1bd52a50e2e16042b6372 https://review.opendev.org/697252 | |
| 09:59:10 | stephenfin | bauzas: Care to get some of that nova-net removal goodness in ya this morning? https://review.opendev.org/#/c/696503/ | |
| 09:59:21 | bauzas | stephenfin: I could | |
| 10:36:49 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/rocky: block_device: Copy original volume_type when missing for snapshot based volumes https://review.opendev.org/697260 | |
| 10:37:12 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/queens: block_device: Copy original volume_type when missing for snapshot based volumes https://review.opendev.org/697261 | |
| 11:34:58 | openstackgerrit | Thierry Carrez proposed openstack/nova master: Remove unused rootwrap filters https://review.opendev.org/697134 | |
| 12:34:38 | gibi | gmann: if you have time, this tempest fix would help with some of the tempest failures in CI https://review.opendev.org/#/c/682964 | |
| 12:42:59 | efried | o/ gibi stephenfin, lend me your ears for a moment? | |
| 12:43:38 | gibi | efried: I'm here but expect me to dissapeare randomly as I'm at the doctor's waiting room | |
| 12:44:25 | lyarwood | efried: I also think stephenfin is AFK at lunch at the moment btw | |
| 12:46:16 | efried | okay, thanks, I'll just leave this here then: | |
| 12:46:16 | efried | I'm working on this virtual TPM thing, trying to get the spec approved. | |
| 12:46:16 | efried | https://review.opendev.org/#/c/686804/ | |
| 12:46:16 | efried | Dan helped me get it to this point, but doesn't like some of the remaining oddness around snapshot-related operations. | |
| 12:46:16 | efried | However, he has implied that he won't stand in the way if others can get behind it. | |
| 12:46:17 | efried | So... gibi and stephenfin, can you get behind it? | |
| 12:47:12 | gibi | efried: opened the spec. Let's see how ugly is the snapshot part | |
| 12:55:57 | efried | gibi: I can tldr it for you: | |
| 12:55:57 | efried | The vTPM belongs to the instance, not the image. So you can't do things like createImage to clone the VM and expect the vTPM to be cloned. (IMO this is sensible. Don't copy my security stuff around, please.) | |
| 12:57:03 | gibi | yeah that seems reasonable. Do not leak secrete data between clones | |
| 12:57:38 | efried | Similarly, if you do a rebuild, you keep your vTPM; you don't get whatever came from the new image. | |
| 12:58:14 | efried | Whatever's in the image might be expecting a given vTPM state that won't exist, but that's up to you to get right. | |
| 12:58:25 | efried | In particular, we *do* save the vTPM state when you do createBackup | |
| 12:59:48 | efried | So if you rebuild from that backup, we'll restore the vTPM as it existed at the point when you did the backup, which ought to maximize the chance that it's in the state the VM is expecting. | |
| 13:01:15 | gibi | Can backups be used to clone a VM ? | |
| 13:01:56 | efried | theoretically, yes, they do almost the same thing as createImage. | |
| 13:02:22 | efried | Documentation would be the key here: If you're backing up, use createBackup; if you're cloning, use createImage. | |
| 13:02:35 | efried | Which is what ops should be doing anyway, but I'm sure those get abused frequently today. | |
| 13:03:44 | efried | I think createBackup tries to maintain one image at a time, deleting the previous one any time you create a new one. Otherwise it's not different than createImage. | |
| 13:03:55 | gibi | I see | |
| 13:05:33 | efried | So the other two main quirks of concern are: | |
| 13:05:33 | efried | - Evacuate doesn't restore your vTPM, sorry. | |
| 13:05:33 | efried | - You have to do stuff as the instance owner. (IMO this is also good: my vTPM is secure stuff, I don't even want the admin to have access to it.) | |
| 13:06:35 | gibi | doesn't shared disk + evacuate could keep the vTMP file? or the vTPM file is somewhere far from the instance disk? | |
| 13:06:43 | efried | the latter :( | |
| 13:07:03 | efried | the vTPM is maintained by libvirt | |
| 13:07:10 | efried | not in the instance | |
| 13:07:13 | gibi | OK so it is some obscure location that the deployer won't share between compute hosts | |
| 13:07:17 | efried | well | |
| 13:07:36 | gibi | anyhow this could be a future improvement in libvirt + nova | |
| 13:07:39 | efried | the location is well known (though I'm not sure there's a contract that it won't change at some point) | |
| 13:07:51 | efried | theoretically it may be possible for that directory to be shared | |
| 13:07:55 | gibi | ack | |
| 13:08:13 | efried | but that would be up to the deployer to figure out, and I'm not going to do anything in nova to try to support (or prevent) it. | |
| 13:08:20 | gibi | sure | |
| 13:08:23 | gibi | make sense | |
| 13:08:53 | gibi | when you say "You have to do stuff as the instance owner" you mean nova needs to act in behalf of the instance owner to manage the vTPM or what is the stuff there? | |
| 13:09:59 | efried | correct | |
| 13:10:39 | efried | Nova needs to unlock the vTPM by defining a secret to libvirt when the guest is created | |
| 13:10:57 | efried | and, because security, the secret is owned by the instance owner; even the admin can't get at it. | |
| 13:11:45 | gibi | does it mean that the admin cannot delet the VM either? | |
| 13:11:51 | efried | Probably the most awkward of these areas is if you reboot the hypervisor, your VMs won't boot until the owner of the VM goes to boot them. | |
| 13:12:01 | efried | Hm, interesting question. | |
| 13:12:21 | efried | The admin won't be able to delete the secret in barbican, or the backup in swift | |
| 13:12:30 | efried | but we don't have to make those error conditions. | |
| 13:12:50 | efried | So the instance could still be destroyed, but those artifacts would be leaked in that case and the owner would have to go clean them up manually. | |
| 13:12:52 | gibi | but then it means we leave junk around | |
| 13:13:25 | efried | I'm not too sure how barbican/swift work in that regard. Maybe policy allows admins to delete things even if they don't own them. I guess that would make sense. | |
| 13:13:57 | gibi | can we have some way out of this. I accep that the admin cannot read or write the vTPM data but cannot even delete when the user is potentially long gone? | |
| 13:14:12 | efried | yeah, I don't know that answer. | |
| 13:14:37 | gibi | ok, noting it down in the spec as question | |
| 13:14:38 | efried | Note that the folks asking for this (VMG) aren't actually using barbican, they have their own home-grown key manager. | |
| 13:15:27 | efried | So I imagine they would be able to control that aspect of things. | |
| 13:16:19 | efried | I can find out whether swift has a similar policy capability. Thinking about it, I would imagine they do. It would only make sense that the admin, who could theoretically shut the whole thing down, should have the ability to delete individual bits, as long as they can't "see" them while they're doing it. | |
| 13:17:23 | gibi | ack, that could be a way out | |
| 13:18:17 | efried | Okay, so given all of that, do you think it is reasonable to support this thing, with proper documentation of these quirks? | |
| 13:18:51 | gibi | the next step that the admin does is draining a compute to do some maintenance. I see that live migration works. that is good. It would be nice to have a way to cold migrate a VM even if it loses the vTPM data in the process | |
| 13:19:18 | gibi | efried: I'm hesitant, as this is raw at the edges | |
| 13:19:36 | gibi | let me go through the spec. | |
| 13:19:41 | efried | cold migrate works | |
| 13:19:45 | gibi | ohh | |
| 13:19:47 | gibi | coolio | |
| 13:20:04 | efried | and shelve/unshelve (which uses snapshots) so cross-cell resize also works. | |
| 13:21:34 | gibi | OK. let me read the spec, but it seems workable at least. And an admin can only disable the feature by not configuring it in the nova conf | |
| 13:21:44 | gibi | s/only/always/ | |
| 13:22:58 | efried | yup | |
| 13:23:04 | efried | thanks gibi | |
| 13:23:19 | gibi | efried: have fun! | |
| 13:23:23 | efried | enjoy your doc :) | |
| 13:23:33 | gibi | ... a long queue ... | |
| 13:24:06 | gibi | it is the 4th hour I'm queueing... | |
| 13:49:23 | efried | egads | |
| 13:49:39 | efried | Does Hungary have a national health service like the UK? | |