| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-04-22 | |||
| 16:30:08 | openstackgerrit | Merged openstack/nova master: libvirt: Remove dead error handling code https://review.opendev.org/c/openstack/nova/+/779704 | |
| 16:30:08 | openstackgerrit | Merged openstack/nova master: libvirt: Remove dead error handling code https://review.opendev.org/c/openstack/nova/+/779704 | |
| #openstack-nova - 2021-04-23 | |||
| 02:07:01 | openstackgerrit | liuzhuangzhuang proposed openstack/nova master: Fix RBD timeout https://review.opendev.org/c/openstack/nova/+/786588 | |
| 06:37:24 | openstackgerrit | Balazs Gibizer proposed openstack/placement stable/wallaby: Add a reproduction test for bug story/2008831 https://review.opendev.org/c/openstack/placement/+/787525 | |
| 06:37:24 | openstackgerrit | Balazs Gibizer proposed openstack/placement stable/wallaby: Add a reproduction test for bug story/2008831 https://review.opendev.org/c/openstack/placement/+/787525 | |
| 06:37:28 | openstackgerrit | Balazs Gibizer proposed openstack/placement stable/wallaby: Make sure the policy upgrade check get a valid config https://review.opendev.org/c/openstack/placement/+/787526 | |
| 06:37:28 | openstackgerrit | Balazs Gibizer proposed openstack/placement stable/wallaby: Make sure the policy upgrade check get a valid config https://review.opendev.org/c/openstack/placement/+/787526 | |
| 11:31:02 | 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 | |
| 11:36:17 | lyarwood | ^ hopefully an easy one if anyone has time | |
| 11:36:17 | lyarwood | ^ hopefully an easy one if anyone has time | |
| 11:46:34 | gibi | lyarwood: I have a question about the fakeguestfs change in ^^ | |
| 11:46:34 | gibi | lyarwood: I have a question about the fakeguestfs change in ^^ | |
| 11:58:02 | sean-k-mooney | gibi: i think that is what lyarwood was saying changed in the new version | |
| 11:58:02 | sean-k-mooney | gibi: i think that is what lyarwood was saying changed in the new version | |
| 11:58:26 | sean-k-mooney | gibi: i.e. it now returns bytes when you call read_file in libguestfs? | |
| 11:58:26 | sean-k-mooney | gibi: i.e. it now returns bytes when you call read_file in libguestfs? | |
| 11:58:46 | sean-k-mooney | lyarwood: is that right i was not fully following what you said in the commit message | |
| 11:58:46 | sean-k-mooney | lyarwood: is that right i was not fully following what you said in the commit message | |
| 11:59:02 | sean-k-mooney | gibi: so i think lee is emulating the new behavior | |
| 11:59:02 | sean-k-mooney | gibi: so i think lee is emulating the new behavior | |
| 12:01:58 | lyarwood | gibi: gibi thanks replied | |
| 12:01:58 | lyarwood | gibi: gibi thanks replied | |
| 12:02:12 | lyarwood | sean-k-mooney: yeah sorry that's correct | |
| 12:02:20 | lyarwood | sean-k-mooney: yeah sorry that's correct | |
| 12:02:38 | lyarwood | that's the new behaviour, I'm not testing the older behaviour here but I'm not sure if that's worth it tbh | |
| 12:02:38 | lyarwood | that's the new behaviour, I'm not testing the older behaviour here but I'm not sure if that's worth it tbh | |
| 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 | |