| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-09-04 | |||
| 17:02:37 | lajoskatona | sean-k-mooney: :-) | |
| 17:04:14 | lajoskatona | sean-k-mooney: thanks, I will check with gibi, this patch now works for basic boot, but to tell the truth I am not sure I have the strength to understand the dirty internals of Nova (not to speak about Neutron API :-)) | |
| 17:09:39 | sean-k-mooney | lajoskatona: i see you are not replacing how we are doing auth which i foudn a little odd | |
| 17:10:25 | sean-k-mooney | have you confirmed that user tokens and not admin tokens are used for thinks liek creating a neuton port when we add a network to the vms | |
| 17:11:18 | sean-k-mooney | not intoducing privadge escaltion but using the admin token is one of the more imporant things we need to watch out for | |
| 17:19:41 | lajoskatona | sean-k-mooney: yes, I made some notes for myself, and that is one of the swampy things as I see (the other is filtering i.e.: networks like shared non-shared admin / non-admin etc) but I am sure there should be more | |
| 17:20:25 | sean-k-mooney | lajoskatona: well the problem with neutrons rbac featues is no one updated nova to supprot any of them | |
| 17:21:01 | sean-k-mooney | lajoskatona: i.e. after many release there are now patches to supprot shared secruity groups for example | |
| 17:21:12 | lajoskatona | sean-k-mooney: any feedback is really useful, I will see if I can work on this (and if I have to patience for this ;)) | |
| 17:21:20 | sean-k-mooney | but as neutron was building out it rbac feature there were no sister propossla filed to nova to use them | |
| 17:21:48 | sean-k-mooney | lajoskatona: nueton has several feature that nova does not officaly supprot | |
| 17:21:55 | sean-k-mooney | like multi provider netwroks | |
| 17:23:51 | sean-k-mooney | the unfortunet pattern is often the neuton extentoin lands and then no one does the nova part to enabel ti properly end ot end | |
| 17:23:52 | lajoskatona | sean-k-mooney: well, we can have a list of these things officially written somewhere where possible brave fresh minded geniuses can select future projects :-) I believe these things should be written somewhere otherwise they are just forgotten | |
| 17:25:35 | sean-k-mooney | funny i was having a paralle conversation about how to document unsupptotred feature a few minutes ago | |
| 17:59:11 | opendevreview | melanie witt proposed openstack/nova master: nova-manage: Add --max_rows option to 'db purge' command https://review.opendev.org/c/openstack/nova/+/927339 | |
| 18:11:43 | opendevreview | Merged openstack/nova stable/2023.2: Skip snapshot test when missing qemu-img https://review.opendev.org/c/openstack/nova/+/927897 | |
| 18:36:44 | opendevreview | melanie witt proposed openstack/nova master: Call volume detach rollback API if detach fails https://review.opendev.org/c/openstack/nova/+/880399 | |
| 21:36:26 | melwitt | dansmith: I was looking through New bugs in launchpad and saw this one that may interest you. online data migration for populate_instance_compute_id failing because of the "fake" instance created by the fill_virtual_interface_list online data migration https://bugs.launchpad.net/nova/+bug/2076614 | |
| 21:59:50 | opendevreview | Merged openstack/nova stable/2023.2: libvirt: call get_capabilities() with all CPUs online https://review.opendev.org/c/openstack/nova/+/927557 | |
| 22:00:00 | opendevreview | Merged openstack/nova stable/2023.1: Skip snapshot test when missing qemu-img https://review.opendev.org/c/openstack/nova/+/927898 | |
| 22:19:03 | dansmith | melwitt: "interest" is a strong word :D | |
| 22:19:18 | dansmith | melwitt: surely the virtual interface migration is crazy old right? | |
| 22:20:07 | sean-k-mooney | its pre trian | |
| 22:20:15 | dansmith | trian? | |
| 22:20:18 | dansmith | oh train | |
| 22:20:38 | sean-k-mooney | porbaly older but its pre pandemic | |
| 22:20:56 | dansmith | yeah I'm just wondering if we want to maybe also delete that.. we really don't need those to stay around forever since we don't support upgrading from any release to any other, | |
| 22:20:56 | sean-k-mooney | so the before times | |
| 22:21:09 | dansmith | although I'm not sure if we (bauzas) added a blocker migration for this or not | |
| 22:21:43 | sean-k-mooney | i kind of forgot it exited so we probably could | |
| 22:22:01 | sean-k-mooney | i had assuemd some of this cleanup was done when stephen did the move to alembic | |
| 22:23:08 | dansmith | "This script should be executed while upgrading to Stein release." | |
| 22:23:16 | dansmith | I thought this was bauzas for sure, but I guess not | |
| 22:24:59 | sean-k-mooney | no this was realted to healing the network info cache | |
| 22:25:00 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/614167 | |
| 22:25:13 | melwitt | dansmith: I saw you on the commit for the compute_id migration :) | |
| 22:25:48 | sean-k-mooney | i have unloaded the contex but if i rememebr correctly this was technially optional | |
| 22:26:20 | sean-k-mooney | as in if you didnt run it i just would not populate the table and give you a stabel order | |
| 22:27:17 | sean-k-mooney | so for me this is old enough that we dont even have unmaintianed barnaches that need it | |
| 22:27:30 | sean-k-mooney | so i dont see why we could not drop anything for stine and older | |
| 22:28:24 | sean-k-mooney | honestly https://github.com/openstack/nova/blob/master/nova/cmd/manage.py#L196-L217 everyting in that block could likely be dropped | |
| 22:29:12 | dansmith | yeah | |
| #openstack-nova - 2024-09-05 | |||
| 08:51:22 | opendevreview | zhou zhong proposed openstack/nova master: nova-manage: modify image properties in request_spec https://review.opendev.org/c/openstack/nova/+/924319 | |
| 08:52:23 | opendevreview | zhou zhong proposed openstack/nova master: nova-manage: modify image properties in request_spec https://review.opendev.org/c/openstack/nova/+/924319 | |
| 08:56:53 | opendevreview | zhou zhong proposed openstack/nova master: nova-manage: modify image properties in request_spec https://review.opendev.org/c/openstack/nova/+/924319 | |
| 08:59:17 | opendevreview | zhou zhong proposed openstack/nova master: nova-manage: modify image properties in request_spec https://review.opendev.org/c/openstack/nova/+/924319 | |
| 09:54:54 | stan | sean-k-mooney is there any work being done on using Shared security group during an instance launch? | |
| 09:55:33 | stan | We have a common security rule that allows access to our backup server, so I would really be handy if we can attach this during instance creation. | |
| 09:57:33 | sean-k-mooney | stan: yes, there is a patch for it but its been worked on inconsitently | |
| 09:57:59 | sean-k-mooney | im expecting we will merge in in the next 3-4 weeks shortly after rc1 is released | |
| 09:58:51 | stan | sean-k-mooney Thanks, that is great news. :) | |
| 09:58:54 | sean-k-mooney | stan: the issue is that when that feature was orgianlly added to neutron it was not even discussed with us let alone propsoed as an enhanemnet | |
| 09:59:22 | sean-k-mooney | the gap is not being closed but its a feature not a bug | |
| 09:59:29 | sean-k-mooney | so we wont be backporting it | |
| 10:00:00 | sean-k-mooney | with that said its pretty trivial so you could do that downstream if you really wanted | |
| 10:00:35 | sean-k-mooney | stan: https://review.opendev.org/c/openstack/nova/+/811521 | |
| 10:01:19 | stan | yeah, I think I will merge it at our downstream. I'm trying to move off of VMware in our company, so I will also try to help as much I can, to contribute back. | |
| 10:01:37 | stan | Thanks again for the prompt response :) | |
| 12:07:03 | opendevreview | Merged openstack/nova stable/2023.1: libvirt: call get_capabilities() with all CPUs online https://review.opendev.org/c/openstack/nova/+/927558 | |
| 14:46:30 | opendevreview | Brian Haley proposed openstack/nova master: Support creating servers with RBAC SGs https://review.opendev.org/c/openstack/nova/+/811521 | |
| 15:01:00 | chris218 | Hi guys is there a reason this patch never got merged or it just wasn't ever proposed? https://opendev.org/openstack/openstack-virtual-baremetal/src/branch/stable/2.0/patches/nova/nova-pxe-boot-pike.patch | |
| 15:10:09 | JayF | I don't know the history of that patch specifically, but the repository it's in has been archived for a couple years. Also the pike release of openstack was something in the neighborhood of 8 years ago? So I suspect that patch is old, too | |
| 15:10:28 | JayF | You might have better results asking a question related to what you're trying to do | |
| 15:58:47 | chris218 | Well i'm interested in letting nova boot directly from pxe which is what that patch provided | |
| 16:02:23 | melwitt | I used this gerrit search "project:openstack/nova message:pxe" to find https://review.opendev.org/c/openstack/nova/+/434549 | |
| 16:04:23 | opendevreview | Merged openstack/nova master: doc: Fix markup syntax and typo https://review.opendev.org/c/openstack/nova/+/906379 | |
| 16:05:40 | chris218 | melwitt: awesome thanks, my gerrit-fu is unfortunately very bad and I didn't find it myself. | |
| 16:06:21 | chris218 | So in theory if somebody implemented it as a flavor extra spec it could get accepted? | |
| 16:06:33 | melwitt | from what I can tell, if someone proposed this with a proper flavor extra spec or image property then it could be considered mergeable.. but obvs would need to run it by other people too in case there is some other concern about the idea | |
| 16:18:06 | sean-k-mooney | we discussee this in the past | |
| 16:18:11 | sean-k-mooney | you can actully do it already today | |
| 16:18:30 | sean-k-mooney | its a littel hacky today and it woudl be nice to make it work more seamlessly | |
| 16:18:51 | sean-k-mooney | chris218: to do this today you need to enabel the boot menu using hw:boot_menu=true | |
| 16:19:02 | sean-k-mooney | and from there you can do a pxe boot | |
| 16:19:16 | sean-k-mooney | but it woudl be nice to have a way to do that more cleanly | |
| 16:44:25 | melwitt | ah, so this is the spec that shows why the effort was abandoned https://review.opendev.org/c/openstack/nova-specs/+/435052 | |
| 16:45:37 | melwitt | chris218: ^ | |
| 16:51:53 | chris218 | Oh wow using rescue with ipxe sounds like a great solution thanks a lot! | |
| 17:41:31 | melwitt | elodilles: I was re-reading the most recent release countdown email and wanted to clarify, it says "In Horizon and the various dashboard plugins, you should stop accepting changes that modify user-visible strings." does that mean it's only for UI components or it's for everything including nova docs? | |
| 17:44:33 | sean-k-mooney | melwitt: technially the string freeze applies to nova and others but we dont really follow that or at least have not for many years | |
| 17:45:32 | sean-k-mooney | we dont go out of our way to not follow it either but realsiticlly if a bug is found we are are not going to hold it because it updates some doc text or add a release note | |
| 17:46:12 | sean-k-mooney | we have https://releases.openstack.org/dalmatian/schedule.html#soft-stringfreeze and https://releases.openstack.org/dalmatian/schedule.html#hard-stringfreeze | |
| 17:46:16 | melwitt | thanks. I approved a tiny docs only change earlier and afterward realized about string freeze and wondered if I should make sure I don't do anymore | |
| 17:46:55 | melwitt | yeah, I was looking at that but 1) the email said horizon and friends and 2) over the years the scope of translated things has shrunk so I wasn't 100% what all it applies to these days | |
| 17:46:56 | sean-k-mooney | i think its fine. this was here to help with localisation efforts | |
| 17:48:08 | sean-k-mooney | melwitt: personally i would argure it time to remove the sting freeze milestones form teh schdule | |
| 17:48:45 | sean-k-mooney | with that said the hard string freeze only come into effect at RC1 | |
| 17:49:10 | sean-k-mooney | so it only applies to the stable branch until the actual release and not to master | |
| 17:49:26 | sean-k-mooney | the soft string freeze is for master between FF and rc1 | |
| 17:53:09 | sean-k-mooney | melwitt: for what its worth im not sure why sphinx lint did not bitch about the syntax issues i added it to catch and prevent those | |
| 17:53:40 | melwitt | +1 on removing the milestones ... but at the very least at least I would appreciate some clarity from the i8n team side what is done nowadays regarding freezes. the i8n efforts used to be visible back in the day at design summits and stuff but it hasn't seemed that visible to me in more recent years | |
| 17:53:43 | sean-k-mooney | maybe it does not detec of handel the unblanced case well | |
| 17:53:47 | sean-k-mooney | " The file is read once at `nova-compute`` " | |
| 17:54:41 | melwitt | sean-k-mooney: the patch was proposed before you added that stuff (it was from january) I've been going through some review dashboards and that's why I saw it | |
| 17:54:45 | sean-k-mooney | i belive the currnt process is they do the changfes on a seperate server we dont look at and peropdically we get a gerrit review that we are jsut ment to appove | |
| 17:54:49 | sean-k-mooney | which i kind of hate | |
| 17:55:21 | sean-k-mooney | melwitt: oh what i ment was when i proposed the sphix-lint thing i fixed a bunch of these | |
| 17:55:30 | sean-k-mooney | so im not sure why i didnt have to fix that one | |
| 17:56:04 | melwitt | right.. I remember the bot changes but I'm not sure if they still do that? and if so, what impact does it have. it's like a black box for me | |