| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-11-21 | |||
| 18:29:41 | sean-k-mooney | melwitt: instead of recheckign it hit the rebase button | |
| 18:30:35 | sean-k-mooney | that will create a new revisison and kick the jobs out of the queue automatiically | |
| 18:48:31 | opendevreview | Merged openstack/placement master: Drop db migration tool https://review.opendev.org/c/openstack/placement/+/932324 | |
| 19:06:06 | yosef | sean-k-mooney: I dont get the by design part, would it create inconsistency if we add a command or an api to re-sync to the changed flavor? | |
| 19:08:10 | sean-k-mooney | yosef: yes, so flavor are ment to be immutable | |
| 19:08:34 | sean-k-mooney | the only reason you can change the extra specs is to allow you to create it adn add them wihtout doing it with a single command | |
| 19:08:51 | sean-k-mooney | but once they are used the expectation is that you will not modify them | |
| 19:08:55 | opendevreview | Merged openstack/nova master: Amend ShareMappingStatus due to asynchronous call https://review.opendev.org/c/openstack/nova/+/908864 | |
| 19:09:05 | opendevreview | Merged openstack/nova master: Amend DB model add a unique constraint. https://review.opendev.org/c/openstack/nova/+/912518 | |
| 19:09:14 | sean-k-mooney | yosef: the intented workflow is you create new flavor and retire the old one when you need to make changes | |
| 19:12:52 | yosef | sean-k-mooney: we have libvirt network and qos quotas as legacy on our production with thosands of VMs, we are migrating to new neutron qos api by changing database by raw sql queries, as we can not resize every one and take down time, I thought if we could add something so anybody else would have a simpler migration | |
| 19:13:50 | sean-k-mooney | its somethign that can be discssed nad could be done, but it would still be considerd bad pratice | |
| 19:14:06 | sean-k-mooney | that does not mean it cant be facilated in a more graceful way | |
| 19:14:37 | sean-k-mooney | unst that its a get our of jail card rather then how you should plan to operate yoru cloud on a day to day basis | |
| 19:18:11 | yosef | Yep that is the end of discussion, I wanted to know if it is a good Idea and an issue I could contribute on, we have almost done on our migration... | |
| 19:27:51 | sean-k-mooney | it can cause issue withthe exisitng instnace. i.e. if you change some parmaters the curent placmenet if the isntance may become inviald based on the other factors consitred by the schduler | |
| 19:28:30 | sean-k-mooney | also if you dont do it correctly and update both the request spec and the copy in the cell db in the instance_extra table to have the same content then that will cause issues | |
| 19:28:50 | sean-k-mooney | yosef: your not the first operator to do this however | |
| 21:55:23 | sean-k-mooney | o/ night folks | |
| 23:02:45 | opendevreview | melanie witt proposed openstack/nova master: WIP Retry _schedule if AllocationUpdatedFailed https://review.opendev.org/c/openstack/nova/+/935988 | |
| 23:50:04 | ildikov | sean-k-mooney: bauzas: here's the bug report for the contributor docs updates: https://bugs.launchpad.net/nova/+bug/2089325 | |
| 23:51:35 | sean-k-mooney | looks valid to me. interesting template i assuem that is used elsewhere | |
| 23:52:18 | ildikov | sean-k-mooney: Thanks for checking! I just used the template LP gave me :) | |
| 23:52:31 | sean-k-mooney | ah ok | |
| 23:53:44 | sean-k-mooney | im not sure where that came from since this is our actul bug template https://paste.opendev.org/show/beOBq5Zm0gwkM9qRH0LW/ | |
| 23:54:55 | ildikov | sean-k-mooney: I opened LP through the little bug icon in the top right corner of the docs. I think it might be specific to doc bugs? | |
| 23:55:20 | sean-k-mooney | ah ok that is coming form the openstack docs theme then | |
| 23:55:33 | sean-k-mooney | rather then form what we have configured on launchpad | |
| 23:55:39 | sean-k-mooney | its fine either way | |
| 23:55:50 | sean-k-mooney | most peopel ignow the bug text anyway :) | |
| 23:56:20 | ildikov | I would assume so, I intentionally did not change the template I got, as I assumed that wherever it's coming from, it's there for a reason | |
| 23:56:32 | ildikov | lol, I bet | |
| 23:57:04 | ildikov | I used to be a core reviewer a long time ago, so I try my best to create decent bug reports :) | |
| 23:57:40 | sean-k-mooney | its more actionable then a lot of the ones we get so you have not lost your touch | |
| 23:58:12 | ildikov | thank you :) | |
| 23:59:46 | sean-k-mooney | https://bugs.launchpad.net/nova/+bug/2085585 is a particallay fine example | |
| #openstack-nova - 2024-11-22 | |||
| 00:01:43 | ildikov | lol, wow | |
| 00:02:37 | ildikov | there's technically no usable information in that one | |
| 00:03:28 | sean-k-mooney | i was hopign it was a duplicate of https://bugs.launchpad.net/nova/+bug/2088341 since it has the same title but that is fileed by someone else | |
| 00:05:50 | ildikov | I mean, with the amount of information in the first one, saying it's a duplicate is just as accurate as saying it's not | |
| 00:06:14 | ildikov | maybe the two people know each other and worked smh together :) | |
| 00:07:34 | sean-k-mooney | i think they just took oru generic api error header too litrally | |
| 00:07:37 | sean-k-mooney | "Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible." | |
| 00:08:20 | sean-k-mooney | some other software project put an identifyer that allows them to track wehre the issue came form in messages like that | |
| 00:08:24 | s3rj1k | reporter fact-proved that "Unexpected API Error" exists | |
| 00:09:13 | sean-k-mooney | hopefully there issue either went away or they cna come back and tell us a littel more | |
| 00:09:29 | sean-k-mooney | anywya im going to drop again for the night o/ | |
| 00:12:53 | ildikov | ah, I see | |
| 00:13:09 | ildikov | I have my fingers crossed they'll come back if the issue persists! | |
| 00:13:20 | ildikov | thanks again for checking my bug report! | |
| 00:13:25 | ildikov | good night! | |
| 02:19:14 | opendevreview | melanie witt proposed openstack/nova master: Add [quota]unified_limits_resource_(strategy|list) https://review.opendev.org/c/openstack/nova/+/924025 | |
| 09:07:30 | tkajinam | bauzas, hi could you check https://review.opendev.org/c/openstack/releases/+/935892 when you have time ? | |
| 09:09:44 | bauzas | tkajinam: just did | |
| 09:21:40 | tkajinam | bauzas, thanks 1 | |
| 09:21:42 | tkajinam | ! | |
| 09:48:33 | opendevreview | renliang proposed openstack/nova master: Update documentation link for openSUSE index. https://review.opendev.org/c/openstack/nova/+/927705 | |
| 12:37:42 | stephenfin | gmann: Thanks for the very thorough review on https://review.opendev.org/c/openstack/nova/+/915743 That must have taken you a while. I appreciate it and will respin quickly 🙏 | |
| 12:38:51 | ratailor | bauzas, sean-k-mooney could you please check https://review.opendev.org/c/openstack/nova/+/934294 https://review.opendev.org/c/openstack/nova/+/873901 | |
| 12:42:24 | ratailor | gibi, could you please check this https://review.opendev.org/c/openstack/nova/+/927732 its clean cherry-pick and required 1 more +2. | |
| 12:47:14 | gibi | ratailor: done | |
| 12:47:58 | ratailor | gibi, Thanks! | |
| 12:50:10 | ratailor | gibi, also is this approach looks good. WDYT https://review.opendev.org/c/openstack/nova/+/933107 | |
| 14:06:57 | s3rj1k | sean-k-mooney: can you please take a look at https://bugs.launchpad.net/nova/+bug/2089386 when you have time, thanks | |
| 14:08:20 | sean-k-mooney | s3rj1k: so we dont really recomemnt usign the periodic in production | |
| 14:08:30 | sean-k-mooney | you can but it does not scale | |
| 14:09:21 | sean-k-mooney | the database constraits should be sufficent to have correct behaivor even without a distributed lock | |
| 14:09:42 | s3rj1k | sean-k-mooney: even without periodics there is an issue with concurrency for running multiple CLI jobs | |
| 14:10:16 | sean-k-mooney | how so. the unique constraits will fail to allow multipel cli jobs to add the same host | |
| 14:10:29 | sean-k-mooney | so one will just fail and the other will succeed | |
| 14:11:07 | sean-k-mooney | s3rj1k: nova would like to remove our use of tooz in general as an fyi | |
| 14:11:24 | sean-k-mooney | its currently only used for the ironic driver and the functionaltiy that uses it is drepcated for removal | |
| 14:12:19 | s3rj1k | hmm, so maybe periodics should be marked as deprecated? | |
| 14:12:32 | sean-k-mooney | s3rj1k: we could impove this behaivor but our current docs say that you may only enable the perodic in one schduler instnace | |
| 14:12:52 | sean-k-mooney | so this is a known limitation in the curent design | |
| 14:13:26 | sean-k-mooney | s3rj1k: the enhancement is not invlaid but its somethin we have decied not to adress in the past | |
| 14:13:39 | s3rj1k | this is for HA setups, where there are multiple schedulers, so there is a need to have at least 3 periodics enabled | |
| 14:14:06 | sean-k-mooney | right so thats not supported today | |
| 14:14:15 | s3rj1k | think Nova in k8s basically | |
| 14:14:36 | sean-k-mooney | yep in our new k8s operator we expiclty dont use this because of this limitation | |
| 14:14:59 | sean-k-mooney | currntly we requre the human ot manualy run it if they scale out comptue nodes | |
| 14:15:14 | sean-k-mooney | given that is an infrequet operation | |
| 14:15:42 | sean-k-mooney | gibi: ^ you might be interested in thsi conversation | |
| 14:15:58 | s3rj1k | it would be nicer to remove a need of manual tasking here | |
| 14:16:11 | sean-k-mooney | s3rj1k: a better appoch might be to make the mappign code more robost | |
| 14:16:36 | sean-k-mooney | i.e. to catch the db conflict/duplicate key error and proceed with the rest of the mappings | |
| 14:18:00 | sean-k-mooney | s3rj1k: for what its worth we did consier automating it in a k8s chron job | |
| 14:18:09 | s3rj1k | what about periodics? I mean we should decide what we should do with it, having this around and saying that it should not be used looks a bit off | |
| 14:18:26 | sean-k-mooney | that not what we say | |
| 14:18:40 | sean-k-mooney | we say it can be used but must only be enabled in one schduler instance | |
| 14:18:55 | sean-k-mooney | and htat for large deployment its avised to not run it frequently | |
| 14:19:13 | s3rj1k | same a basically setting up plain Linux cron with CLI | |
| 14:19:19 | sean-k-mooney | but yes we coudl deprecate it for removal, but i dont think we want to break existing users | |
| 14:19:42 | sean-k-mooney | s3rj1k: yes and no. the delta is that its ha | |
| 14:20:03 | sean-k-mooney | i.e. as long asa you k8s cluster is functional it can schduler to any approate worker | |
| 14:20:25 | s3rj1k | I mean in case of single node setups, cron vs periodic is same thin, no? | |
| 14:20:29 | sean-k-mooney | the reason we didnt do that of our installer is we did not think this was a good default for production | |
| 14:20:52 | sean-k-mooney | sure but then you cant have the conflcit | |
| 14:21:29 | sean-k-mooney | unless your running multipel schduler on a single node cluster? doable but proably not super useful | |
| 14:22:26 | s3rj1k | yea, point is case env setups what are ok to have periodics enabled are not HA at all and there is no point in supporting periodics in case of not also supporting HA with it, since plain cron can replace it on non HA | |