| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-04-23 | |||
| 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 | |
| 13:03:59 | lyarwood | np | |
| 13:04:00 | lyarwood | np | |
| 13:04:03 | lyarwood | thanks for review | |
| 13:04:03 | lyarwood | thanks for review | |
| 13:28:50 | bauzas | wow, so Zoom is eating 5GB of my RAM | |
| 13:28:50 | bauzas | wow, so Zoom is eating 5GB of my RAM | |
| 13:28:55 | bauzas | ... | |
| 13:28:55 | bauzas | ... | |
| 13:29:09 | sean-k-mooney | what browser are you using | |
| 13:29:09 | sean-k-mooney | what browser are you using | |
| 13:29:14 | sean-k-mooney | it prefers chrome | |
| 13:29:14 | sean-k-mooney | it prefers chrome | |
| 13:29:30 | sean-k-mooney | or are you using the zoom app | |
| 13:29:30 | sean-k-mooney | or are you using the zoom app | |
| 13:29:42 | sean-k-mooney | browser seams to work better for me at least | |
| 13:29:42 | sean-k-mooney | browser seams to work better for me at least | |
| 13:31:05 | bauzas | I directly use the zoom app | |
| 13:31:05 | bauzas | I directly use the zoom app | |
| 13:31:24 | bauzas | * bauzas tests a few things before the last PTG day | |
| 13:31:27 | sean-k-mooney | ya i had audio issue with that i could hear but people could not hear me | |
| 13:31:27 | sean-k-mooney | ya i had audio issue with that i could hear but people could not hear me | |
| 13:31:47 | bauzas | hopefully this will be our last virtual PTG... | |
| 13:31:47 | bauzas | hopefully this will be our last virtual PTG... | |
| 13:31:49 | sean-k-mooney | so now im using it in google chrome not chromium | |
| 13:31:49 | sean-k-mooney | so now im using it in google chrome not chromium | |
| 13:53:34 | artom | sean-k-mooney, you mean an entirely new nova-manage command? As in `nova-manage sriov-ports add-requester-id`? | |
| 13:53:34 | artom | sean-k-mooney, you mean an entirely new nova-manage command? As in `nova-manage sriov-ports add-requester-id`? | |
| 13:55:32 | sean-k-mooney | almost | |
| 13:55:32 | sean-k-mooney | almost | |
| 13:55:44 | sean-k-mooney | new yes but i was suggesting that it would be automatic | |
| 13:55:44 | sean-k-mooney | new yes but i was suggesting that it would be automatic | |
| 13:56:08 | sean-k-mooney | i.e. you would not have to specify the requester id manually | |
| 13:56:08 | sean-k-mooney | i.e. you would not have to specify the requester id manually | |
| 13:56:23 | sean-k-mooney | it would try and work it out by looking at teh pci claims and the port profile | |
| 13:56:23 | sean-k-mooney | it would try and work it out by looking at teh pci claims and the port profile | |
| 13:56:32 | artom | I guess... | |
| 13:56:32 | sean-k-mooney | and if they agreed then setting the value | |
| 13:56:32 | artom | I guess... | |
| 13:56:32 | sean-k-mooney | and if they agreed then setting the value | |
| 13:56:44 | artom | That would not apply to any instances that are not ACTIVE though | |
| 13:56:45 | artom | That would not apply to any instances that are not ACTIVE though | |
| 13:56:57 | sean-k-mooney | if not it would out put a list of port that were potnetally broken and say hay you might need to fix these | |
| 13:56:57 | sean-k-mooney | if not it would out put a list of port that were potnetally broken and say hay you might need to fix these | |
| 13:57:00 | artom | Which is also my beef with the data migration (currently writing a para of text in the review) | |
| 13:57:00 | artom | Which is also my beef with the data migration (currently writing a para of text in the review) | |
| 13:57:22 | sean-k-mooney | how do you mean | |
| 13:57:22 | sean-k-mooney | how do you mean | |