| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-08-26 | |||
| 11:47:11 | sean-k-mooney | in what way | |
| 11:47:40 | sean-k-mooney | have a specific bfv_only flag of some kind? per host or cloud wide? | |
| 11:48:25 | sean-k-mooney | noonedeadpunk: im trying to understand if there is a gap that we might need to address beyond having a topic doc on how to use the exisitng feature to do this | |
| 11:48:53 | noonedeadpunk | So yeah, we have `os_compute_api:servers:create:zero_disk_flavor` so maybe option like `os_compute_api:servers:create:local_drive` which by default allowed for everyone | |
| 11:49:27 | noonedeadpunk | but this can be overriden and local_drive can be created only to specific groups of users | |
| 11:49:28 | sean-k-mooney | ah to block flavor creation with root, ephmeral or swap | |
| 11:49:59 | openstackgerrit | Merged openstack/nova stable/ussuri: libvirt: Do not reference VIR_ERR_DEVICE_MISSING when libvirt is < v4.1.0 https://review.opendev.org/747357 | |
| 11:50:00 | sean-k-mooney | the only real issue i see with that is root ephmerla and swap might not be local | |
| 11:50:05 | openstackgerrit | Merged openstack/nova master: Set different VirtualDevice.key https://review.opendev.org/713565 | |
| 11:50:12 | sean-k-mooney | e.g. if you are using ceph for storage | |
| 11:50:25 | noonedeadpunk | And eventually currently I am.... | |
| 11:50:49 | sean-k-mooney | but we proably could add a policy flag for each filed gmann is that a reasonable thing to do? | |
| 11:51:53 | sean-k-mooney | gmann: question i have is it resonable to add a policy flag to restirct creating flavor with non 0 root, swap or ephemeral storage | |
| 11:51:56 | noonedeadpunk | so, if I have ceph backend configured, than max_local_block_devices is not really applicable? | |
| 11:52:12 | sean-k-mooney | noonedeadpunk: more or less yes | |
| 11:52:31 | sean-k-mooney | i think it techniall is still enforced but its not really local | |
| 11:52:48 | noonedeadpunk | ah, ok, then this should work | |
| 11:53:17 | sean-k-mooney | im not sure if the point where we check that option know what storage is configured | |
| 11:53:25 | sean-k-mooney | we might have a skip for the rbd backend | |
| 11:54:29 | sean-k-mooney | noonedeadpunk: storage is one area i understand but avoid so the details are not something i rember and have to lookup each time | |
| 11:55:10 | bauzas | whoops | |
| 11:55:31 | bauzas | gibi: any reason why you based https://review.opendev.org/#/c/742407/4 on top of https://review.opendev.org/#/c/741500/10 ? | |
| 11:55:43 | sean-k-mooney | bauzas: a little over eger to be back :) | |
| 11:56:14 | noonedeadpunk | Ok, so I have the following situation: some of the users, despite we don't have non-zero flavors in terms of disks, some of them still press "do not create volume" button in horizon, which creates ephemeral volume in ceph with size equall to the image size. And then they return crying that all data has been lost in case of some reboot/rebuilt/etc | |
| 11:56:14 | gibi | bauzas: I have no ide how I made that | |
| 11:56:29 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Undeprecate the vmwareapi driver https://review.opendev.org/742407 | |
| 11:56:33 | bauzas | gibi: cool | |
| 11:56:36 | sean-k-mooney | its merged now so it does not really matter | |
| 11:56:45 | sean-k-mooney | the vtpm patch | |
| 11:56:53 | bauzas | yup | |
| 11:57:02 | bauzas | but this was confusing me | |
| 11:57:13 | bauzas | as I was looking at the hairy vtpm series | |
| 11:57:16 | gibi | bauzas: thanks for noticing | |
| 11:57:17 | sean-k-mooney | gibi: you proably were reviewing stephens patch before | |
| 11:57:30 | bauzas | (and gosh, this spec is... terrible https://specs.openstack.org/openstack/nova-specs/specs/victoria/approved/add-emulated-virtual-tpm.html ) | |
| 11:57:35 | gibi | sean-k-mooney: could be | |
| 11:58:05 | sean-k-mooney | hehe its a good way to get extra review :P | |
| 11:58:26 | sean-k-mooney | put random patches into a seriese in the runway | |
| 11:58:31 | gibi | lol | |
| 11:58:43 | gibi | I make a mental note to do it more often | |
| 11:58:44 | gibi | :D | |
| 11:59:17 | sean-k-mooney | with the amount of patches in stephens seriese im not even sure he would notice one more when he is rebaseing them all | |
| 11:59:31 | gibi | :D | |
| 11:59:54 | gibi | btw, stephenfin: I've finished reading and commenting the vtpm series | |
| 12:00:12 | sean-k-mooney | it looks like they are all approved | |
| 12:00:33 | sean-k-mooney | at least for spwan | |
| 12:00:40 | sean-k-mooney | the move operation are still pending | |
| 12:01:00 | gibi | yeah, spawn seems pretty solid to me | |
| 12:01:43 | sean-k-mooney | this will make efried happy to see | |
| 12:03:00 | bauzas | I'm just reviewing the rest of the series | |
| 12:03:32 | bauzas | but honestly, mho is that we tried to be gentlemen with vtpm usage, by overcomplicating what we were providing as a feature :) | |
| 12:03:46 | bauzas | trying to have vtpm instances be pets is nice | |
| 12:04:16 | bauzas | but we're pulling swift and trying to do maths to get whether we can still migrate an emulated file device or not, which overcomplicates things | |
| 12:04:30 | bauzas | but this is what it is, the spec is approved | |
| 12:05:14 | sean-k-mooney | well we try to make it behave like a real server | |
| 12:05:53 | bauzas | this is cloud | |
| 12:06:04 | sean-k-mooney | yep | |
| 12:06:09 | bauzas | most of the operations are admin-managed | |
| 12:06:26 | sean-k-mooney | in a cloud that would be atypical | |
| 12:06:30 | bauzas | so in this case, trying to solve all the problems is nice, but this comes with a cost | |
| 12:06:51 | sean-k-mooney | well one of the proposal was no move operations | |
| 12:06:55 | bauzas | but the ship has sailed. | |
| 12:07:04 | sean-k-mooney | which was very non admin frendly | |
| 12:07:22 | bauzas | I'm okay with creating a fresh new tpm device with move operations | |
| 12:07:32 | bauzas | what I'm struggling with is trying to reuse the existing data | |
| 12:07:43 | bauzas | this should be app-managed | |
| 12:07:44 | sean-k-mooney | the check is pretty simple | |
| 12:07:56 | sean-k-mooney | if anything changes version or type then data is not perserved | |
| 12:08:08 | sean-k-mooney | if the version and type do not change we copy it | |
| 12:08:20 | stephenfin | bauzas: well, don't worry about swift. None of that is done | |
| 12:08:24 | sean-k-mooney | the special case is shelve | |
| 12:08:31 | stephenfin | Is we might never do it. For now, shelve is simply blocked | |
| 12:08:36 | sean-k-mooney | where we ahve to store it somewhere which is swift | |
| 12:09:07 | sean-k-mooney | bauzas: the alternitive was to stick it in glance as a second image | |
| 12:09:31 | sean-k-mooney | or not store it at all | |
| 12:11:28 | bauzas | sean-k-mooney: yup, I saw in the series | |
| 12:11:35 | bauzas | the shelve case is the most complicated | |
| 12:11:50 | bauzas | I also have concerns with rebuild | |
| 12:12:18 | bauzas | trying to reuse the existing backup file is nice, but as a user I'd expect a fresh vTPM device if I rebuild | |
| 12:12:21 | sean-k-mooney | rebuild preseves the data if the version/type of tpm does not change | |
| 12:12:39 | sean-k-mooney | bauzas: that fails the do what hardware does guideline | |
| 12:12:46 | bauzas | this data is ephemeral, right? | |
| 12:12:52 | sean-k-mooney | bauzas: if you reinstall the os on your laptop your tpm is not cleared | |
| 12:13:12 | bauzas | ah, you're right, if you wanna mock the baremetal case | |
| 12:13:26 | bauzas | but in this case, all moves are just data loss | |
| 12:13:56 | bauzas | especially when I read https://specs.openstack.org/openstack/nova-specs/specs/victoria/approved/add-emulated-virtual-tpm.html#migrations-and-their-ilk | |
| 12:13:57 | bauzas | brr... | |
| 12:13:58 | sean-k-mooney | bauzas: one of the usecases for this is storing encyrption keys or certs for authentication | |
| 12:14:29 | sean-k-mooney | so if you have data volumes or use the tpm as a cert store and use rebuild to upgrade your application you would not want to loose that data | |
| 12:14:30 | bauzas | gibi: thoughts on keeping a list of CI maintainers somewhere in https://review.opendev.org/#/c/742407/5 | |
| 12:14:40 | bauzas | gibi: if you have remembrance of anything about this... | |
| 12:14:50 | openstackgerrit | Merged openstack/nova master: Fix indentation nits https://review.opendev.org/746765 | |
| 12:14:56 | openstackgerrit | Merged openstack/nova master: Remove deprecated scheduler filters https://review.opendev.org/744800 | |
| 12:15:04 | sean-k-mooney | bauzas: all move operation in the sepc are currently data perserving | |
| 12:15:21 | sean-k-mooney | bauzas: we just copy the tpm data form one host to another | |
| 12:15:21 | bauzas | I do understand the usecase | |
| 12:15:31 | bauzas | I'm just saying we are adding more than necessary | |
| 12:15:42 | bauzas | but again, the ship has sailed | |
| 12:16:01 | sean-k-mooney | bauzas: well it was felt that without perserving the data on move ops we could not resonably support them | |
| 12:16:02 | openstackgerrit | Merged openstack/nova master: tests: Add helpers for rebuild, cold migrate, and shelve/unshelve https://review.opendev.org/747792 | |