| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-03-03 | |||
| 14:39:12 | gibi | also if somebody could +2 the https://review.opendev.org/c/openstack/nova/+/778177/2 that would be nice to unblock the hyperv rbd series | |
| 14:42:08 | gmann | gibi: done on 778177 | |
| 14:42:15 | gibi | thanks! | |
| 14:42:39 | gmann | removing indirect deps will help in these kind of constraints issue | |
| 14:44:30 | gibi | gmann: we have a PTG topic around that https://etherpad.opendev.org/p/nova-xena-ptg L39 | |
| 14:45:32 | gmann | gibi: +1 and I think by this or next week I will be able to get consensus in TC also and have some reference document too. | |
| 14:45:42 | gibi | cool | |
| 14:46:05 | gmann | stephenfin: do you need help on this? you might have forget this policy change - https://review.opendev.org/c/openstack/nova/+/765798 | |
| 14:46:17 | gmann | last one for that BP as client one is also +A now | |
| 14:46:51 | stephenfin | gmann: Yes, please. I've gotten dragged into UEFI secure boot reviews and haven't been able to round back on that | |
| 14:47:03 | gmann | stephenfin: sure. | |
| 14:57:15 | stephenfin | gibi: +W on https://review.opendev.org/c/openstack/nova/+/757615/ In general I have no issues with you +W your own patches after a rebase and I do it myself all the time. I doubt anyone would disagree :) | |
| 14:57:57 | gibi | ack, thanks | |
| 15:11:53 | openstackgerrit | Stephen Finucane proposed openstack/nova master: apidb: Compact Pike database migrations https://review.opendev.org/c/openstack/nova/+/759403 | |
| 15:16:23 | ralonsoh | hi stephenfin, I have one quick question. When you migrated to privsep, did you have any long lived process to be executed as root? | |
| 15:16:47 | ralonsoh | in other words, do you spawn any daemon/server/etc that requires root permissions? | |
| 15:17:38 | openstackgerrit | Stephen Finucane proposed openstack/nova master: apidb: Compact Queens database migrations https://review.opendev.org/c/openstack/nova/+/759404 | |
| 15:17:53 | stephenfin | ralonsoh: I don't think so. We just escalate when we need to | |
| 15:18:23 | ralonsoh | stephenfin, without rootwrap, of course | |
| 15:18:48 | stephenfin | iirc privsep is run under a rootwrap daemon | |
| 15:18:53 | stephenfin | so rootwrap is still there | |
| 15:19:03 | ralonsoh | yes, but only privsep | |
| 15:19:30 | ralonsoh | I mean, the privsep daemon. In anycase, you still use rootwrap | |
| 15:20:44 | stephenfin | Mostly. I recall there being some rootwrap filters left for some os-brick stuff | |
| 15:21:05 | atmark | hello, is there to another option in the config to move the cold migration target to different interface? I know for live you can set live_migration_inbound_addr but how about for cold migration? | |
| 15:21:13 | ralonsoh | stephenfin, thanks!! | |
| 15:21:37 | stephenfin | atmark: I'm not aware of such a mechanism, no | |
| 15:23:12 | atmark | The cold migration still uses the management interface even if I have live_migration_inbound_addr | |
| 15:24:29 | atmark | in a different interface | |
| 15:33:30 | sean-k-mooney | atmark: yes it will | |
| 15:33:43 | sean-k-mooney | live_migration_inbound_addr is only for live migration | |
| 15:34:17 | sean-k-mooney | you can adres this via kernel routes | |
| 16:02:39 | openstackgerrit | Stephen Finucane proposed openstack/nova master: apidb: Compact Rocky database migrations https://review.opendev.org/c/openstack/nova/+/759405 | |
| 16:03:48 | openstackgerrit | Stephen Finucane proposed openstack/nova master: apidb: Compact Stein database migrations https://review.opendev.org/c/openstack/nova/+/759406 | |
| 16:05:08 | openstackgerrit | Stephen Finucane proposed openstack/nova master: apidb: Compact Train database migrations https://review.opendev.org/c/openstack/nova/+/771420 | |
| 16:18:52 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Bump the Compute RPC API to version 6.0 https://review.opendev.org/c/openstack/nova/+/761452 | |
| 16:19:20 | bauzas | dansmith: gibi: stephenfin: artom: updated based on your feedbacks ^ | |
| 16:19:31 | gibi | bauzas: looking | |
| 16:20:13 | bauzas | tl;dr: removed the unused args from the RPC methods stephenfin told + changed the numa tests to pin to 5.max instead | |
| 16:23:26 | openstackgerrit | Merged openstack/python-novaclient master: Add support for microversion v2.88 https://review.opendev.org/c/openstack/python-novaclient/+/770573 | |
| 16:25:34 | belmoreira | recently found this behaviour in Nova: https://bugs.launchpad.net/nova/+bug/1917645 and I'm not sleeping well since :) not sure if this should be Nova or Oslo. I would appreciate some guidance. | |
| 16:25:35 | openstack | Launchpad bug 1917645 in OpenStack Compute (nova) "Nova can't create instances if RabbitMQ notification cluster is down" [Undecided,New] | |
| 16:29:19 | bauzas | belmoreira: if the rabbit is down, how the conductor and scheduler could help the nova-api service to tell which host ? | |
| 16:29:43 | bauzas | that actually reminds me preemptible instances | |
| 16:29:53 | belmoreira | we have an independent rabbit for everything | |
| 16:29:58 | bauzas | some kind of instance that would be pre-created | |
| 16:30:46 | belmoreira | bauzas each cell has it's own rabbit, including one for the support conductor/scheduler. Then we have a rabbit for the notifications | |
| 16:31:15 | belmoreira | support/super | |
| 16:31:29 | bauzas | oh sorry, I missed the fact you were mentioning the notifications rabbit | |
| 16:31:42 | bauzas | and not the API MQ or the cell MQs | |
| 16:32:02 | bauzas | I guess we hold on emitting notifications | |
| 16:33:13 | belmoreira | I was expecting that behaviour (maybe with an error msg), but in reality instances can't be created | |
| 16:33:40 | belmoreira | was looking into the config options that I think this is not handled at all | |
| 16:33:51 | gibi | belmoreira: I think we need to warp the notification sending with some exception handler and log a WARNING if the notification sending failed but not block the actual work | |
| 16:35:06 | belmoreira | gibi +1 | |
| 16:35:29 | gibi | belmoreira: I think we simply did not have those error handled properly in the current code | |
| 16:36:06 | gibi | one can argue that not delivering a notification could mean some external system become desynced | |
| 16:36:42 | belmoreira | gibi I agree, but in that case should be configurable | |
| 16:37:27 | gibi | belmoreira: hm, that could work. Something like notification_failure_is_fatal config option | |
| 16:38:14 | gibi | so if somebody use the notification interface for charging customers based on usage then that deployer would likely make this config True | |
| 16:38:57 | belmoreira | makes sense to me | |
| 16:41:47 | gibi | me to | |
| 16:41:48 | gibi | o | |
| 16:44:12 | belmoreira | I'm not familiar with the notifications code. Is this something that someone can have a look? | |
| 16:44:44 | gibi | I can take a look but my backlog is pretty long so it will take time to reach that bug | |
| 16:46:44 | belmoreira | thanks gibi, meanwhile I can have a look but definitely I will need some guidance | |
| 16:47:10 | gibi | belmoreira: sure, let me know if you have questions | |
| 16:48:16 | belmoreira | thanks a lot | |
| 16:49:11 | bauzas | gibi: belmoreira: sorry wrapped into a meeting, but the approach looks good to me | |
| 16:57:39 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Remove non-libguestfs file injection for libvirt https://review.opendev.org/c/openstack/nova/+/324720 | |
| 16:58:51 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Remove VFSLocalFS https://review.opendev.org/c/openstack/nova/+/778506 | |
| 16:59:47 | kashyap | gibi: Interesting that you revived it (I agree). Anything in particular that made you revive? | |
| 17:00:35 | gibi | kashyap: the security bug behind it become public a week ago | |
| 17:00:49 | gibi | kashyap: and also we removed Xen support so one less complication | |
| 17:00:50 | kashyap | Argh, rotting security bugs :-( | |
| 17:00:53 | gibi | yepp | |
| 17:01:23 | kashyap | gibi: Right; fair enough. That problem is real ... | |
| 17:03:53 | bauzas | gibi: urgent review needs on them, I guess ? | |
| 17:04:06 | gibi | bauzas: no, it is a really old security bug | |
| 17:04:18 | gibi | so no need to rush | |
| 17:04:51 | gibi | it just become stuck in private state until the secu team did a spring cleaning recently | |
| 17:04:55 | bauzas | gibi: okay, focusing on blueprints reviews, but I can take a look at them later | |
| 17:04:56 | gibi | and made the bug public | |
| 17:05:02 | gibi | bauzas: sure, thanks | |
| 17:10:09 | sean-k-mooney | thats the one we talked about 2 weeks ago in teh meeting right | |
| 17:10:30 | sean-k-mooney | i assume you revied the old patches | |
| 17:11:25 | gibi | sean-k-mooney: yes, I revived, rebased, and realized the we deleted Xen since so I put a cleanup top of it | |
| 17:11:32 | gibi | sean-k-mooney: but the basic idea is the same | |
| 17:11:49 | gibi | sean-k-mooney: fail to boot if file injection is requested but libguestfs is not available on the compute | |
| 17:11:51 | sean-k-mooney | cool ill try and review this this week | |
| 17:11:56 | gibi | sean-k-mooney: thanks | |
| 17:12:48 | sean-k-mooney | by the way i saw your question on the port numa patches. ill hopefully get time to rebase that tomorrow to address it i just need to fix that env i was using it for something else but ill do that in the morning | |
| 17:12:59 | sean-k-mooney | thanks for taking a look | |
| 17:13:03 | gibi | ack | |
| 17:19:49 | bauzas | sean-k-mooney: just a quick q, why do we need to pass the list of ARQs when shelving an instance ? I guess this is for the cyborg-agent to free up the resources ? | |
| 17:19:55 | bauzas | context : https://review.opendev.org/c/openstack/nova/+/778440/1/nova/compute/manager.py | |
| 17:25:25 | sean-k-mooney | bauzas: we need to free them yes | |
| 17:25:31 | sean-k-mooney | so its for unbinding them | |
| 17:25:46 | sean-k-mooney | technially its only needed for the shelve_offload part | |
| 17:26:30 | bauzas | yup, that's what I guessed | |