| amoralej | Hi, i'm seeing an issue in our devstack jobs with prometheus datastores. While the controllers are configuring notifications.notification_format = both in nova.conf, for compute1 node it is setting notifications.notification_format = unversioned | 08:56 |
|---|---|---|
| amoralej | that's making to miss some messages for instance.create.end i.e. | 08:57 |
| amoralej | in gnocchi jobs, it's configured correctly, but i don't see where that difference comes from | 08:57 |
| amoralej | for example logs https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_452/openstack/4523166e9ebf4b2da307666d68ef216d/ | 09:00 |
| *** jgilaber_ is now known as jgilaber | 09:09 | |
| jgilaber | amoralej, I think the difference is that the gnocchi job deploys a decision engine in the compute | 09:09 |
| amoralej | no, i found similar behavior in previous jobs | 09:09 |
| jgilaber | and triggers https://github.com/openstack/watcher/blob/master/devstack/override-defaults to be used which configures both versions | 09:09 |
| amoralej | sorry, i missuderstood your message, lemme check | 09:10 |
| jgilaber | see https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_a88/openstack/a88231bb6d3f4dd3af2e9096447e4754/compute1/logs/devstacklog.txt the logs for devstack deploy on the compute of the gnocchi job | 09:10 |
| jgilaber | look for 'NOVA_NOTIFICATION_FORMAT' | 09:10 |
| jgilaber | in the prometheus job it has different https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_452/openstack/4523166e9ebf4b2da307666d68ef216d/compute1/logs/devstacklog.txt | 09:11 |
| amoralej | you are correct | 09:12 |
| amoralej | actually https://review.opendev.org/c/openstack/watcher/+/964546/ is fixing it in prometheus jobs | 09:12 |
| jgilaber | that is surprising though, I didn't know we were deploying a decision engine in the compute https://github.com/openstack/watcher/blob/74efcbf9992b0ffee1fcd5bc72b8b4f7963a4166/.zuul.yaml#L42 | 09:12 |
| amoralej | tbh i was not aware that gnocchi was deploying decision-engine in the compute before | 09:12 |
| amoralej | I may make https://review.opendev.org/c/openstack/watcher/+/964546 the first one in the series | 09:13 |
| jgilaber | we can either do that or set 'NOVA_NOTIFICATION_FORMAT=both' in the subnode devstack config in the prometheus job | 09:15 |
| jgilaber | but since we want to enable it anyway your patch seems like a cleaner solution | 09:15 |
| amoralej | thanks jgilaber++ ! | 09:42 |
| amoralej | that should fix some flakiness in the prometheus jobs | 09:44 |
| opendevreview | Alfredo Moralejo proposed openstack/watcher master: Add second instance of watcher-decision-engine in the compute node https://review.opendev.org/c/openstack/watcher/+/964546 | 09:55 |
| opendevreview | Alfredo Moralejo proposed openstack/watcher master: APISchedulingService migrate audits also on first discovery of services https://review.opendev.org/c/openstack/watcher/+/963981 | 09:55 |
| opendevreview | Alfredo Moralejo proposed openstack/watcher master: Move decision-engine monitoring service to the decision-engine https://review.opendev.org/c/openstack/watcher/+/963252 | 09:55 |
| jgilaber | Hi! Can someone tell me if my understanding of SLURP releases is correct? I'm working on the spec to rename strategy parameters and thinking how many releases we should keep both parameters | 10:22 |
| jgilaber | Gazpacho is a slurp release, so we need to support upgrades from both epoxy and flamingo, but the next H relase we only need to support upgrades from Gazpacho, is that correct? | 10:23 |
| amoralej | https://releases.openstack.org/#releases-with-skip-level-upgrade-release-process-slurp | 10:23 |
| amoralej | yes, that's correct | 10:24 |
| jgilaber | I had not seen that image, that's really clear, thanks! | 10:25 |
| amoralej | actually, upgrade from non-slurp to slurp is marked as optional | 10:25 |
| jgilaber | so technically we need to support any new parameters and deprecate the old versions in gazpacho and could remove them in the next 2026.2 release, right? | 10:26 |
| amoralej | https://docs.openstack.org/project-team-guide/deprecation.html#guidelines | 10:28 |
| amoralej | i think we can not deprecate in G and remove in H | 10:31 |
| jgilaber | I see we need to wait until I to remove | 10:31 |
| amoralej | At the very minimum the feature (or API, or configuration option) should be marked deprecated (and still be supported) in at least one “tick” release branch, and for at least 12 months of releases. | 10:32 |
| amoralej | i understand 12 months of releases means two releases ? | 10:32 |
| jgilaber | I understood the same | 10:32 |
| amoralej | anyway, for me the main discussion is how to manage the old parameters? if we want to maintain some form of backwards compatibility in strategies parameters | 10:33 |
| amoralej | after old-name is not accepted for new audits | 10:34 |
| jgilaber | I'm working under the assumption that we will support both forms internally, mainly for audits existing before the upgrade | 10:36 |
| amoralej | yep, that's the main case | 10:36 |
| amoralej | so, if the strategy keeps accepting the old name as parameter, i'm not sure if that's technically considered parameter removal | 10:37 |
| opendevreview | OpenStack Release Bot proposed openstack/watcher-dashboard master: reno: Update master for unmaintained/2024.1 https://review.opendev.org/c/openstack/watcher-dashboard/+/965677 | 12:03 |
| opendevreview | OpenStack Release Bot proposed openstack/watcher master: reno: Update master for unmaintained/2024.1 https://review.opendev.org/c/openstack/watcher/+/965692 | 12:04 |
| chandankumar | Hello jgilaber sean-k-mooney , I checked with openstack-release team regarding unmaintained branches removal. Based on this https://governance.openstack.org/tc/resolutions/20230724-unmaintained-branches.html, we need to keep multiple unmaintained branches in the repo. But it is not the responsability of team to maintain it. If other interested people want to maintain it and they can maintain it. | 12:23 |
| sean-k-mooney | chandankumar: no | 12:26 |
| sean-k-mooney | we a can keep multipe but we are not required too | 12:26 |
| sean-k-mooney | for the branch to be kept after each new upstream release a unmainteind branch liason has to explcity request it to be kept, and at that poin tin time the ci need to be passing | 12:27 |
| sean-k-mooney | so we shoudl propose the removal of the unmaintained 2024.1 branch and move it to eol. and if someone want to maintain it they can request to keep it and continue to do that each release | 12:28 |
| sean-k-mooney | if there is no one who is requesting to maintain it now there is no reason to keep the brnach as the default is ot retire it and an explcit opt in is requried to keep it | 12:29 |
| sean-k-mooney | chandankumar: jgilaber https://github.com/openstack/governance/blob/master/resolutions/20230724-unmaintained-branches.rst?plain=1#L83-L92 are the relevnet sections | 12:30 |
| sean-k-mooney | jgilaber: in terms of upgrade testing yes for .1 release we are required to test upgrade form the previous .1 adn the previous .2 | 12:31 |
| sean-k-mooney | for .2 release testing upgrades form the previous .2 is not required and optionally done by some teams | 12:31 |
| jgilaber | ack thanks, that was what I understood, but wanted to make I got it right | 12:33 |
| jgilaber | for the unmantained branch pov iiuc we can choose to keep unmantained 2024.1 until the next slurp release or remove it now, is that right? | 12:37 |
| jgilaber | hmm I see we still have unmaintained/2023.1 https://opendev.org/openstack/watcher/src/branch/unmaintained/2023.1/ that one we can remove for sure | 12:38 |
| chandankumar | The PTL or Unmaintained branch liaison are allowed to delete an Unmaintained | 12:40 |
| chandankumar | branch early. Since we follow DPL model, not sure who has the power to delete the branch. | 12:40 |
| chandankumar | checking the same with release team. | 12:40 |
| sean-k-mooney | jgilaber: i think we should remove it | 12:52 |
| sean-k-mooney | chandankumar: the release liasons do | 12:52 |
| sean-k-mooney | the way the tooling is set up release liasons are delegate the ptl approval power | 12:53 |
| sean-k-mooney | so we delete the branch by tagging it as eol | 12:53 |
| sean-k-mooney | it can be recreeated from the tag at a later date if really needed for some reason | 12:53 |
| chandankumar | sean-k-mooney: yes correct, I got the similar reply from release team. | 12:54 |
| sean-k-mooney | i did it before :) | 12:54 |
| sean-k-mooney | so i i know that a release liason can do it | 12:54 |
| sean-k-mooney | i.e. i removed everythin pre 2023.1 | 12:55 |
| jgilaber | sean-k-mooney, so we need to create a git tag eol/2023.1 and push it? | 12:59 |
| sean-k-mooney | no you do it via the release repo | 12:59 |
| sean-k-mooney | let me get an example | 13:00 |
| sean-k-mooney | https://review.opendev.org/c/openstack/releases/+/948118 | 13:00 |
| sean-k-mooney | https://review.opendev.org/c/openstack/releases/+/935983 | 13:00 |
| sean-k-mooney | the second is where i moved all the older brnaches to eol | 13:01 |
| jgilaber | ack thanks, I can do that later today, or do we want to raise it in the next IRC meeting? | 13:02 |
| sean-k-mooney | sure we can you could also send a mail to the list saying that since no one has requested it be maintained and there for no one has opted in to it we plan to remove unmaintied/2023.1 next week | 13:03 |
| sean-k-mooney | then we can review it in the irc meeting and proceed with the release team if no objects | 13:03 |
| jgilaber | sure, I can do that | 13:03 |
| sean-k-mooney | *objections | 13:03 |
| sean-k-mooney | there has been no chang to unmaintained/2023.1 in 11 months since it was created | 13:04 |
| sean-k-mooney | so that to me say no one cares | 13:04 |
| sean-k-mooney | stable/2024.2 shoudl go eol too by the way | 13:05 |
| sean-k-mooney | it is no more then 18 month old and its not eligable to become unmainted/2024.2 | 13:05 |
| sean-k-mooney | actully no im off by one | 13:05 |
| sean-k-mooney | 2025.2 2025.1 and 2024.2 | 13:06 |
| sean-k-mooney | are stil supproted until 2026.1 is release | 13:06 |
| sean-k-mooney | then 2024.2 will go eol after the 2026.1 release | 13:06 |
| sean-k-mooney | what confused me is the stable/2024.1 branch has not been removed yet | 13:06 |
| sean-k-mooney | althoguh unmaintained/2024.1 now exists | 13:07 |
| sean-k-mooney | so that should get fix soon i guess | 13:07 |
| jgilaber | the patch https://review.opendev.org/c/openstack/releases/+/963601 was supposed to be merged last week so it only got in today | 13:08 |
| jgilaber | I guess that is why | 13:08 |
| chandankumar | elodilles is unmaintainer branch core and his employer is interested in maintaining unmaintained branches. keeping it open in upstream help to do less work downstream. | 13:14 |
| chandankumar | *help them | 13:14 |
| opendevreview | David proposed openstack/watcher-tempest-plugin master: Unify wait_for_instance_in_model order execution on real data tests https://review.opendev.org/c/openstack/watcher-tempest-plugin/+/965779 | 13:14 |
| chandankumar | But when eol review will go if any one interested they can object it. | 13:14 |
| jgilaber | I'll write an email today and a second one with the patch next week after the IRC meeting, that should give people plenty of type to object | 13:15 |
| chandankumar | +1 | 13:16 |
| opendevreview | David proposed openstack/watcher-tempest-plugin master: Unify wait_for_instance_in_model order execution on real data tests https://review.opendev.org/c/openstack/watcher-tempest-plugin/+/965779 | 13:16 |
| dviroel | jgilaber: tks, i just added a topic to next meeting agenda | 13:40 |
| jgilaber | thanks dviroel! | 14:00 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!