Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-04-23
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
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)

Earlier   Later