| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-04-23 | |||
| 12:06:46 | gibi | sean-k-mooney, lyarwood: thanks. now I got it. I was confused about what the fakeguestfs replaces | |
| 12:06:46 | gibi | sean-k-mooney, lyarwood: thanks. now I got it. I was confused about what the fakeguestfs replaces | |
| 12:08:43 | lyarwood | yeah sorry it needed calling out in the commit | |
| 12:08:43 | lyarwood | yeah sorry it needed calling out in the commit | |
| 12:10:01 | gibi | no worries | |
| 12:10:01 | gibi | no worries | |
| 12:21:09 | artom | stephenfin, gibi, so I've been thinking about that online data migration for the unshelve with SRIOV port bug... | |
| 12:21:09 | artom | stephenfin, gibi, so I've been thinking about that online data migration for the unshelve with SRIOV port bug... | |
| 12:21:37 | artom | It's not a slam dunk. Could we take some PTG minutes to discuss it? Or hash it out in the review? | |
| 12:21:37 | artom | It's not a slam dunk. Could we take some PTG minutes to discuss it? Or hash it out in the review? | |
| 12:23:13 | sean-k-mooney | i orginally suggested adding it a a nova manage command by the way | |
| 12:23:13 | sean-k-mooney | i orginally suggested adding it a a nova manage command by the way | |
| 12:23:15 | gibi | artom plug it to the end of the etherpad and lets see if we can make it to the end today, | |
| 12:23:15 | gibi | artom plug it to the end of the etherpad and lets see if we can make it to the end today, | |
| 12:23:23 | sean-k-mooney | not an online data migration | |
| 12:23:23 | sean-k-mooney | not an online data migration | |
| 12:23:27 | gibi | artom: if not then we can continue here or in the review | |
| 12:23:27 | gibi | artom: if not then we can continue here or in the review | |
| 12:23:38 | gibi | I don't have the necessary context right now, I have to read the patch first | |
| 12:23:38 | sean-k-mooney | well it is one just not one that you would always run | |
| 12:23:38 | gibi | I don't have the necessary context right now, I have to read the patch first | |
| 12:23:38 | sean-k-mooney | well it is one just not one that you would always run | |
| 12:24:01 | artom | * artom has taken it as a given that we'll never get to the end of the agenda ;) | |
| 12:24:05 | artom | So in the review then! | |
| 12:24:05 | artom | So in the review then! | |
| 12:24:07 | artom | :P | |
| 12:24:07 | artom | :P | |
| 12:24:19 | sean-k-mooney | if we do it as a one off nova manage command it will be backporatble too | |
| 12:24:19 | sean-k-mooney | if we do it as a one off nova manage command it will be backporatble too | |
| 12:24:38 | gibi | review works fine by me | |
| 12:24:38 | gibi | review works fine by me | |
| 12:25:09 | kashyap | sean-k-mooney: gibi: stephenfin: A quick point (which I also noted on the Etherpad, but it can get lost) from yesterday on that emulation thing: | |
| 12:25:09 | kashyap | sean-k-mooney: gibi: stephenfin: A quick point (which I also noted on the Etherpad, but it can get lost) from yesterday on that emulation thing: | |
| 12:25:12 | sean-k-mooney | gibi im going to move my topics to the end of the etherpad. the last ones i have left are less important so if we get to them great | |
| 12:25:12 | sean-k-mooney | gibi im going to move my topics to the end of the etherpad. the last ones i have left are less important so if we get to them great | |
| 12:25:14 | kashyap | QEMU explicitly does *not* consider emulation to be a secure production scenario — "Users with non-virtualization use cases must not rely on QEMU to provide guest isolation or any security guarantees." | |
| 12:25:14 | kashyap | QEMU explicitly does *not* consider emulation to be a secure production scenario — "Users with non-virtualization use cases must not rely on QEMU to provide guest isolation or any security guarantees." | |
| 12:25:15 | gibi | sorry, I don't actually know how to move faster in the agenda without shutting down some people in the room | |
| 12:25:15 | gibi | sorry, I don't actually know how to move faster in the agenda without shutting down some people in the room | |
| 12:25:26 | gibi | sean-k-mooney: that helps, thanks | |
| 12:25:26 | gibi | sean-k-mooney: that helps, thanks | |
| 12:25:48 | kashyap | It could be okay for private cloud setup, if the admin trusts their tenants. The rest of it is in the Etherpad. | |
| 12:25:48 | kashyap | It could be okay for private cloud setup, if the admin trusts their tenants. The rest of it is in the Etherpad. | |
| 12:27:05 | sean-k-mooney | kashyap: tell rackspace that | |
| 12:27:05 | sean-k-mooney | kashyap: tell rackspace that | |
| 12:27:39 | sean-k-mooney | kashyap: as i said most of there cloud ran x86 on power of 5+ years with xen/qemu | |
| 12:27:39 | sean-k-mooney | kashyap: as i said most of there cloud ran x86 on power of 5+ years with xen/qemu | |
| 12:27:46 | gibi | kashyap: I see belmoreira's answer to your point in the etherpad. I think I agree. We can warn our users in the doc that emulation is not for public production, but for private validation | |
| 12:27:46 | gibi | kashyap: I see belmoreira's answer to your point in the etherpad. I think I agree. We can warn our users in the doc that emulation is not for public production, but for private validation | |
| 12:28:03 | sean-k-mooney | gibi: i think it can be use for both | |
| 12:28:03 | sean-k-mooney | gibi: i think it can be use for both | |
| 12:28:13 | sean-k-mooney | we can warn that its considered less secure sure | |
| 12:28:13 | sean-k-mooney | we can warn that its considered less secure sure | |
| 12:28:28 | gibi | sean-k-mooney: can be used does not mean it is not dangerous from security perspective ;) | |
| 12:28:28 | gibi | sean-k-mooney: can be used does not mean it is not dangerous from security perspective ;) | |
| 12:28:48 | gibi | it can be used but the consequnces should be clear | |
| 12:28:48 | gibi | it can be used but the consequnces should be clear | |
| 12:29:27 | sean-k-mooney | kashyap: can you provide a link to a public staement form QEMU to that effect | |
| 12:29:27 | sean-k-mooney | kashyap: can you provide a link to a public staement form QEMU to that effect | |
| 12:29:48 | sean-k-mooney | if we are going to put it in our docs i would like somehting beter then an email or irc transcript | |
| 12:29:48 | sean-k-mooney | if we are going to put it in our docs i would like somehting beter then an email or irc transcript | |
| 12:29:50 | kashyap | sean-k-mooney: I don't have to say it to Rackspace, BTW. They can read the doc I linked in there :) | |
| 12:29:50 | kashyap | sean-k-mooney: I don't have to say it to Rackspace, BTW. They can read the doc I linked in there :) | |
| 12:30:02 | kashyap | sean-k-mooney: https://qemu-project.gitlab.io/qemu/system/security.html#non-virtualization-use-case | |
| 12:30:02 | kashyap | sean-k-mooney: https://qemu-project.gitlab.io/qemu/system/security.html#non-virtualization-use-case | |
| 12:30:25 | kashyap | gibi: Yeah. It can be easily missed w/o loud and clear documentation on that point. | |
| 12:30:25 | kashyap | gibi: Yeah. It can be easily missed w/o loud and clear documentation on that point. | |
| 12:30:53 | sean-k-mooney | kashyap: cool then we can reference that | |
| 12:30:53 | sean-k-mooney | kashyap: cool then we can reference that | |
| 12:31:38 | sean-k-mooney | it seams clear that while it should in principal provide similar protection due to the legacy of not reviewing for security its not considerd as secure as using kvm | |
| 12:31:38 | sean-k-mooney | it seams clear that while it should in principal provide similar protection due to the legacy of not reviewing for security its not considerd as secure as using kvm | |
| 12:32:09 | sean-k-mooney | so really you would need to use selinux and other security mechanisms to provide guest isolation byond qemu | |
| 12:32:09 | sean-k-mooney | so really you would need to use selinux and other security mechanisms to provide guest isolation byond qemu | |
| 12:32:33 | sean-k-mooney | the same selinux rules we apply in the kvm case should add some messure of addtional protection | |
| 12:32:33 | sean-k-mooney | the same selinux rules we apply in the kvm case should add some messure of addtional protection | |
| 12:33:09 | kashyap | SELinux and sVirt will provide protection beyond what QEMU may do. But not all distros are SELinux-capable | |
| 12:33:09 | kashyap | SELinux and sVirt will provide protection beyond what QEMU may do. But not all distros are SELinux-capable | |
| 12:33:37 | sean-k-mooney | ture although apparmor will also provide some protectsion on the debina/ubuntu side | |
| 12:33:37 | sean-k-mooney | ture although apparmor will also provide some protectsion on the debina/ubuntu side | |
| 12:35:15 | sean-k-mooney | by the way i assume we are just going to warn for this whenever using virt-type=qemu too | |
| 12:35:15 | sean-k-mooney | by the way i assume we are just going to warn for this whenever using virt-type=qemu too | |
| 12:35:51 | sean-k-mooney | basically a note for virt_type=qemu and then when we add emulation support refrecne that it will fallback to qemu and that note applies to the emulation case | |
| 12:35:51 | sean-k-mooney | basically a note for virt_type=qemu and then when we add emulation support refrecne that it will fallback to qemu and that note applies to the emulation case | |
| 12:36:49 | sean-k-mooney | we have not warned agaisnt the use of the qemu virt type up to this point and the emulation case is no different to that so if we add something it shoudl be consitent | |
| 12:36:50 | sean-k-mooney | we have not warned agaisnt the use of the qemu virt type up to this point and the emulation case is no different to that so if we add something it shoudl be consitent | |
| 12:45:15 | kashyap | sean-k-mooney: Yeah; that's a valid point - warning for 'virt_type=qemu' is beneficial for the operator | |
| 12:45:15 | kashyap | sean-k-mooney: Yeah; that's a valid point - warning for 'virt_type=qemu' is beneficial for the operator | |
| 12:45:31 | kashyap | As sometimes they use it unwittingly | |
| 12:45:31 | kashyap | As sometimes they use it unwittingly | |
| 12:53:07 | lyarwood | https://review.opendev.org/c/openstack/nova/+/787712 - stephenfin / bauzas ; would either of you mind hitting this before we get started with PTG stuff today? | |
| 12:53:07 | lyarwood | https://review.opendev.org/c/openstack/nova/+/787712 - stephenfin / bauzas ; would either of you mind hitting this before we get started with PTG stuff today? | |
| 12:53:17 | stephenfin | sure | |
| 12:53:17 | stephenfin | sure | |
| 12:56:59 | stephenfin | lyarwood: left a comment - could you address that one (happy with the rest being done in a follow-up, as with gibi) | |
| 12:56:59 | stephenfin | lyarwood: left a comment - could you address that one (happy with the rest being done in a follow-up, as with gibi) | |
| 12:59:47 | lyarwood | ack looking | |
| 12:59:47 | lyarwood | ack looking | |
| 13:03:17 | openstackgerrit | Lee Yarwood proposed openstack/nova master: guestfs: With libguestfs >= v1.41.1 decode returned bytes to string https://review.opendev.org/c/openstack/nova/+/787712 | |
| 13:03:17 | openstackgerrit | Lee Yarwood proposed openstack/nova master: guestfs: With libguestfs >= v1.41.1 decode returned bytes to string https://review.opendev.org/c/openstack/nova/+/787712 | |
| 13:03:51 | stephenfin | thanks | |