[tc][uc][all] Starting community-wide goals ideas for V series
Hello everyone, We are in R14 week of Ussuri cycle which means It's time to start the discussions about community-wide goals ideas for the V series. Community-wide goals are important in term of solving and improving a technical area across OpenStack as a whole. It has lot more benefits to be considered from users as well from a developers perspective. See [1] for more details about community-wide goals and process. We have the Zuulv3 migration goal already accepted and pre-selected for v cycle. If you are interested in proposing a goal, please write down the idea on this etherpad[2] - https://etherpad.openstack.org/p/YVR-v-series-goals Accordingly, we will start the separate ML discussion over each goal idea. Also, you can refer to the backlogs of community-wide goals from this[3] and ussuri cycle goals[4]. NOTE: TC has defined the goal process schedule[5] to streamlined the process and ready with goals for projects to plan/implement at the start of the cycle. I am hoping to start that schedule for W cycle goals. [1] https://governance.openstack.org/tc/goals/index.html [2] https://etherpad.openstack.org/p/YVR-v-series-goals [3] https://etherpad.openstack.org/p/community-goals [4] https://etherpad.openstack.org/p/PVG-u-series-goals [5] https://governance.openstack.org/tc/goals/#goal-selection-schedule -gmann
---- On Wed, 05 Feb 2020 12:39:17 -0600 Ghanshyam Mann <gmann@ghanshyammann.com> wrote ----
Updates: We have zuulv3 migration goal selected for V cycle[1] and waiting for more goals proposal. For V cycle, we need one more goal to select, please do not wait or hesitate to propose something you think we should solve in OpenStack as a whole community. You can write your idea on this etherpad - https://etherpad.openstack.org/p/YVR-v-series-goals NOTE: As per the new process[2], we can have as many goals proposed and we pick two goals per cycle. Do not limit yourself to propose your goal ideas which can be selected for V or future cyle. [1] https://governance.openstack.org/tc/goals/selected/victoria/index.html [2] https://governance.openstack.org/tc/goals/#process-details -gmann & njohnston
Hello Everyone. Please find the latest updates on V cycle goals: Etherpad: https://etherpad.openstack.org/p/YVR-v-series-goals We have two more candidates for V cycle goals: 1. Migrate from oslo.rootwrap to oslo.privsep Thanks to Rodolfo who agreed to drive this work. He started the ML thread and initial discussions in happening there. ML: http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013409.htm... 2. Finish moving legacy python-*client CLIs to python-openstackclient This had been tried as a goal in the Train cycle also and one of the important requirements from users. One option we are thinking as multi-cycle goal. Artem agreed to drive this and will give another try by propose as mutli-cycle goal. Selected goals till now or V cycle: 1. Switch legacy Zuul jobs to native - https://governance.openstack.org/tc/goals/selected/victoria/index.html - Champion: tosky -gmann & njohnston ---- On Wed, 26 Feb 2020 11:47:10 -0600 Ghanshyam Mann <gmann@ghanshyammann.com> wrote ----
On 2020-03-23 13:34:46 -0500 (-0500), Ghanshyam Mann wrote: [...]
Please be aware that this goal references the old Zuul v3 Migration Guide which no longer exists except in Git history of the opendev/infra-manual repository (it was removed via https://review.opendev.org/711325 just shy of two years after the Zuul 3.0.0 release). You can still find the old source for it here: <URL: https://opendev.org/opendev/infra-manual/src/commit/2901f4b87b7506c63aefa34e... > -- Jeremy Stanley
On 2020-03-23 21:28:41 +0100 (+0100), Luigi Toscano wrote:
The OpenDev Manual maintainers didn't want to continue curating instructions for a migration which should have happened two years ago. The content is CC-BY licensed though, so should be easy to copy into the goal document or similar if the OpenStack project wants to retain it somewhere. -- Jeremy Stanley
---- On Mon, 23 Mar 2020 15:43:44 -0500 Jeremy Stanley <fungi@yuggoth.org> wrote ----
We need that somewhere until all projects finish the migration. I agree it is a long time for zuulv3 exist but still projects are not migrated to it. What is actual harm of keeping that in opendev manual? -gmann
-- Jeremy Stanley
On Mon, Mar 23, 2020, at 3:04 PM, Ghanshyam Mann wrote:
We are trying to restructure the documentation to be less OpenStack specific and are moving content into other locations as necessary (all of the zuulv3 migration content is basically openstack or zuul specific). In this specific case much of the content is covered by Zuul's documentation (how to write jobs, job inheritance, secrets, etc). At the time this documentation was written a lot of this was still coming together on the Zuul side, but now that shouldn't be the case. If there are bits not covered by the Zuul docs that should be we can fix that. We might also need to add some openstack specific bits into the openstack contributor guide. I'd also be worried that the doc itself is quite stale as it has been a couple years. In particular I think the document lacks a lot of info on where the devstack jobs have evolved to.
---- On Mon, 23 Mar 2020 17:42:26 -0500 Clark Boylan <cboylan@sapwetik.org> wrote ----
I agree that Zuul documentation has all the details but the migration guide has few helpful sections especially from a legacy job perspective for example 'Legacy Jobs to Projects' which can be quick help to convert those to zuulv3. I am sure many people while working on this goal will find Zuul documentation a little too detail. I remember shanghai PTG discussion of this goal and people asked if we have clear documentation on migration and examples. OpenStack contributor guide is more for how to contribute part not some specific features/changes details. Maybe we can keep it where other OpenStack related infra docs are/will be? -gmann
Hello Everyone. Please find the latest updates on V cycle goals: Etherpad: https://etherpad.openstack.org/p/YVR-v-series-goals We have one more candidate for V cycle goals from the last updates. Everyone is requested to review those proposals and provide your feedback. Proposed goals for V cycle: --------------------------------- 1. Migrate from oslo.rootwrap to oslo.privsep Goal proposal: https://review.opendev.org/#/c/718177/ Champion: Rodolfo Alonso Hernandez (ralonsoh) 2. add container-images Goal proposal: https://review.opendev.org/#/c/718177/ Champion: Mohammed Naser (mnaser) and Monty Taylor (mordred) 3. Finish moving legacy python-*client CLIs to python-openstackclient This had been tried as a goal in the Train cycle also and one of the important requirements from users. One option we are thinking as multi-cycle goal. Artem agreed to drive this and will give another try by propose as mutli-cycle goal. Selected goals till now or V cycle: ---------------------------------------- 1. Switch legacy Zuul jobs to native - https://governance.openstack.org/tc/goals/selected/victoria/index.html - Champion: Luigi Toscano (tosky) -gmann & njohnston ---- On Mon, 23 Mar 2020 13:34:46 -0500 Ghanshyam Mann <gmann@ghanshyammann.com> wrote ----
On Fri, 2020-04-24 at 10:22 -0500, Ghanshyam Mann wrote:
Thanks for the continued effort gmann and njohnston! I think it could be worth having a look at the brand new https://review.opendev.org/#/c/722924/ too :) Regards, JP
On 2/5/20 7:39 PM, Ghanshyam Mann wrote:
I've added 3 major paint points to the etherpad which I think are very important for operators: 8. Get all services to systemd-notify 9. Make it possible to reload service configurations dynamically without restarting daemons 10. All API to provide a /healthcheck URL (like the Keystone one...). I don't have the time to implement all of this, but that's still super useful things to have. Does anyone have the time to work on this? Cheers, Thomas Goirand (zigo)
Hi, On Thu, Apr 30, 2020 at 01:20:29PM +0200, Thomas Goirand wrote:
Wasn't that goal in Rocky: [1]
10. All API to provide a /healthcheck URL (like the Keystone one...).
I like that idea :)
[1] https://governance.openstack.org/tc/goals/selected/rocky/enable-mutable-conf... -- Slawek Kaplonski Senior software engineer Red Hat
On Thu, 2020-04-30 at 13:51 +0200, Slawek Kaplonski wrote:
so this might be somethign that distro packagers could do and there might eb some kind of integration that could be done in some installer tools but i dont think this can realsitically be a cross project goals as it wont work for everyone.
On 4/30/20 2:31 PM, Sean Mooney wrote:
Cut/pasting what I wrote in the pad: It looks like you don't understand what this is about. This is *not* about forcing everyone to use systemd, this is about *supporting* its use, and taking advantage of its functionalities. One of them is a bus where you can say "hey, I'm ready", which we could use *if* systemd is in the system. In no way, this means we are making the use of systemd mandatory.
Sorry if this looks like newbie questions, but... ... how do we know if something is mutable? Shouldn't this attribute be written in the generated file by oslo-config-generator, so operators know what is mutable or not? Then what's the way to reload? kill -HUP ? Cheers, Thomas Goirand (zigo)
On 4/30/20 8:55 AM, Thomas Goirand wrote:
Note that we already have systemd notification support in oslo.service: https://github.com/openstack/oslo.service/blob/master/oslo_service/systemd.p... It looks like it should behave sanely without systemd as long as you don't set NOTIFY_SOCKET in the service env.
It is. Check out the doc for the debug option in Nova: https://docs.openstack.org/nova/latest/configuration/sample-config.html And yes, it's SIGHUP to reload config: https://docs.openstack.org/oslo.service/latest/user/usage.html#signal-handli... We could use some more operator-facing documentation about that though. The oslo.service doc is more developer-oriented.
Cheers,
Thomas Goirand (zigo)
Thanks for your helpful reply. On 4/30/20 5:43 PM, Ben Nemec wrote:
Oh, so it means downstream packages must set an env var to support it? The other issue I have is that there's zero documentation on who's supporting it... :/
It is. Check out the doc for the debug option in Nova: https://docs.openstack.org/nova/latest/configuration/sample-config.html
Right. There's really not a lot of them... :( Cheers, Thomas Goirand (zigo)
On 4/30/20 12:59 PM, Thomas Goirand wrote:
I've never used this, but according to https://askubuntu.com/questions/1120023/how-to-use-systemd-notify it looks like you just set the service type to notify and then systemd does what needs to be done.
The other issue I have is that there's zero documentation on who's supporting it... :/
Yeah, oslo.service doesn't really have any user docs. We could also probably test this now that devstack is using systemd.
The vast majority of requests for reloadable config were the debug option, which is why that was the focus of the community goal. Others can be added, but each one needs to be verified by the project to ensure that they can be safely reloaded.
Cheers,
Thomas Goirand (zigo)
On 4/30/20 6:20 AM, Thomas Goirand wrote:
This is just the healthcheck middleware, I believe: https://github.com/openstack/oslo.middleware/tree/master/oslo_middleware/hea... In any project that doesn't already have it they just need to enable the middleware. How to do that will depend on how the API for the service is implemented. In some it's user-configurable, in others the middlewares are hard-coded.
---- On Thu, 30 Apr 2020 06:20:29 -0500 Thomas Goirand <zigo@debian.org> wrote ----
#10 looks interacting to me and useful from the user's point of view. I can help with this. Key thing will be do we need more generic backends than file existence one, for example, DB checks or service-based backends. But we can discuss all those details in separate threads, thanks for bringing this. -gmann
Cheers,
Thomas Goirand (zigo)
Hello Everyone, Sending the final updates on Victoria cycle goal selection(on top of email for easy read). community-wide goals for Victoria cycle are finalized: - https://governance.openstack.org/tc/goals/selected/victoria/index.html Selected goals for Victoria cycle: ---------------------------------------- 1. Switch legacy Zuul jobs to native - https://governance.openstack.org/tc/goals/selected/victoria/native-zuulv3-jo... 2. Migrate CI/CD jobs to new Ubuntu LTS Focal - https://governance.openstack.org/tc/goals/selected/victoria/migrate-ci-cd-jo... Please start planning to work on those goals if not yet done. TC will be starting the W cycle goals process soon. -gmann & njohnston ---- On Tue, 05 May 2020 13:03:59 -0500 Ghanshyam Mann <gmann@ghanshyammann.com> wrote ----
participants (10)
-
Ben Nemec
-
Clark Boylan
-
Ghanshyam Mann
-
Hongbin Lu
-
Jean-Philippe Evrard
-
Jeremy Stanley
-
Luigi Toscano
-
Sean Mooney
-
Slawek Kaplonski
-
Thomas Goirand