Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-09-04
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
17:56:52 melwitt sean-k-mooney: you did fix the `` things. the only remaining fix from the january patch was a it's => its grammar thing so it was technically 1/3 valid still 😛
17:57:11 sean-k-mooney ah ok
17:58:14 melwitt when I looked at it I was like, "this looks really familiar" so I pulled up your patch and linked it in a comment, just for informational purposes
18:00:47 melwitt I've been looking through review dashboards and launchpad bugs seeing what things I could clear out
18:01:58 melwitt which reminds me, I replied to an issue someone opened yesterday about the inability to force live migration destinations that I thought was interesting https://bugs.launchpad.net/nova/+bug/2078932
18:02:51 melwitt I'm not sure if we have an official recommendation on how to do that given the "force" flags removal from the API
18:03:33 melwitt if we do, I'd like to add it to the docs somewhere bc it seems like a common use case
18:46:02 sean-k-mooney melwitt: well you can always use the old microversion but ya that kind of by desing
18:46:17 sean-k-mooney schduler hint are not ment to be changeable for the lifetime of an instance
18:46:21 melwitt right
18:46:50 sean-k-mooney you can specify a host
18:47:01 sean-k-mooney and provide that host passes all filters we will use it
18:47:21 sean-k-mooney the jsonfilter is off by default as its kind of a security problem
18:47:58 sean-k-mooney but obvioulsy if it has been used and used to selct based on host name then that vm is effectivly pinned and needs to be upgraded in place with downtime
18:48:15 melwitt that doesn't work for them because they have a jsonfilter that filters on specific hostnames (I know) but they have some kind of numa pinning requirements and I dunno enough about that to know a better way
18:48:59 sean-k-mooney they have this jsonfilter https://github.com/openstack/nova/blob/master/nova/scheduler/filters/json_filter.py#L24
18:49:06 melwitt I would like to document what is the right way to do this if possible because I think it will come up a lot
18:49:08 sean-k-mooney that allows you to match on anyting in the host state object
18:49:16 melwitt right
18:49:44 sean-k-mooney well the write way is to not live migrate it
18:49:54 melwitt :D
18:49:57 sean-k-mooney what they want to do is intentially not supported
18:50:09 melwitt they said it was a host evacuate situation though
18:50:21 sean-k-mooney the could shelve and unhevle the host but there is no way to move the instance without recreating it
18:50:24 melwitt which seems reasonable to me
18:50:46 sean-k-mooney so how i woudl fix this
18:50:57 melwitt ok. that's what I thought but I wasn't sure if there were more things I didn't know about

Earlier   Later