| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-09-05 | |||
| 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 | |
| 18:50:59 | sean-k-mooney | is implemnt the recreat api i wanted to add a few years ago | |
| 18:51:58 | sean-k-mooney | recreate is ment to be like resize and rebuild combined. one api that by defautl moves the isntance to another host alloing the embded flavor and image property to optionaly be udeated or for either to be chanaged | |
| 18:52:17 | sean-k-mooney | as part of a request it woudl be reasonabel to update the schdeuler hits | |
| 18:52:37 | sean-k-mooney | melwitt: in the short term a nova-mange command to update the reqest spec is proably what we should do | |
| 18:53:26 | melwitt | sean-k-mooney: ok, good. cause that's what I told them :) | |
| 18:53:55 | sean-k-mooney | long them an single api call that is "recreate this vm, keepign its data unless i ask for the image, and optionally changing the flavor" would avoid a lot of user/operator pain | |
| 18:54:21 | sean-k-mooney | s/the image/the image to be changed/ | |
| 18:54:27 | melwitt | but yeah, re: the recreate API for the longterm solution, if the nova-manage command isn't good enough, I think it would be helpful | |
| 18:54:58 | sean-k-mooney | i want recreate for like 10 diffent usecase this just beign one of them | |
| 18:55:24 | sean-k-mooney | another short term soltuion woudl be allow schduler hints to be passed to move ops | |
| 18:55:47 | sean-k-mooney | so to migrate (cold/live) resize, unshleve, evacuate | |
| 18:56:07 | melwitt | yeah, I could see that | |
| 18:56:27 | sean-k-mooney | we allow doing thing like chainging the keypair i think for rebuild | |
| 18:56:37 | melwitt | yes, we do | |
| 18:56:55 | sean-k-mooney | so its not entirly strange to say if we are moving it allow the scheduer hits to optionally be updated | |
| 18:57:20 | sean-k-mooney | im less sure if that should be member or admin policy wiese | |
| 18:57:26 | sean-k-mooney | but i could see the argument either way | |
| 18:57:33 | melwitt | yeah, agree | |
| 18:58:46 | sean-k-mooney | the one nice thing about policy is as long as we are secure by default operator can always define there own | |
| 18:59:36 | melwitt | I think regardless we need the nova-manage command. afaik everyone is +1 about it and it could be backported for older versions | |
| 19:00:30 | sean-k-mooney | im slowly coming to the view that nova manage (witin reason) shoudl have more tooling to help operator get out of messes like this | |
| 19:00:46 | melwitt | same | |
| 19:01:18 | sean-k-mooney | i.e. i kind of want a flavor refesh command in nova-manage to check if the host is still valide and update the embded flavor with the latest verion of that flavor | |
| 19:01:38 | sean-k-mooney | or allwo you to also update the embded flavor extra spec liek the image properties | |
| 19:01:57 | sean-k-mooney | that does not change teh advice of never modify flavor once they are in use | |
| 19:02:13 | sean-k-mooney | but it give you an escape hatch if you did without forceing resizes | |
| 19:02:23 | melwitt | why not resize? oh | |
| 19:03:17 | sean-k-mooney | sometimes people pin thing to hosts :) the other reason i have heard is mano integration | |
| 19:03:30 | sean-k-mooney | i.e. there is a system on top that created the worklaod | |
| 19:03:42 | sean-k-mooney | and changing the flavor id is not trivial as a result | |
| 19:04:22 | sean-k-mooney | for example if it was deployed with heat or somethign like that | |
| 19:04:37 | melwitt | hm | |
| 19:04:43 | sean-k-mooney | i soudl argure that you shoudl stop doing it wrong | |
| 19:05:08 | sean-k-mooney | but customer sometimes dont like that | |
| 19:05:12 | sean-k-mooney | not sure why :) | |
| 19:06:05 | sean-k-mooney | anyway if you or they were to propsoe an extention to nova-mange for there usecase | |