[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 ----
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]
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].
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
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
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 Wed, 05 Feb 2020 12:39:17 -0600 Ghanshyam Mann gmann@ghanshyammann.com wrote ----
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]
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].
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
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
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 2020-03-23 13:34:46 -0500 (-0500), Ghanshyam Mann wrote: [...]
Selected goals till now or V cycle:
- Switch legacy Zuul jobs to native
[...]
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... >
On Monday, 23 March 2020 20:11:50 CET Jeremy Stanley wrote:
On 2020-03-23 13:34:46 -0500 (-0500), Ghanshyam Mann wrote: [...]
Selected goals till now or V cycle:
- Switch legacy Zuul jobs to native
[...]
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/2901f4b87b7506c63aefa34 ece47106ff3c8a328/doc/source/zuulv3.rst >
Why was it removed I think it still important. The amount of jobs still to be converted which lead to this goal should say something.
Can it be restored or at least added somewhere else?
On 2020-03-23 21:28:41 +0100 (+0100), Luigi Toscano wrote:
On Monday, 23 March 2020 20:11:50 CET Jeremy Stanley wrote:
On 2020-03-23 13:34:46 -0500 (-0500), Ghanshyam Mann wrote: [...]
Selected goals till now or V cycle:
- Switch legacy Zuul jobs to native
[...]
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/2901f4b87b7506c63aefa34 ece47106ff3c8a328/doc/source/zuulv3.rst >
Why was it removed I think it still important. The amount of jobs still to be converted which lead to this goal should say something.
Can it be restored or at least added somewhere else?
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.
---- On Mon, 23 Mar 2020 15:43:44 -0500 Jeremy Stanley fungi@yuggoth.org wrote ----
On 2020-03-23 21:28:41 +0100 (+0100), Luigi Toscano wrote:
On Monday, 23 March 2020 20:11:50 CET Jeremy Stanley wrote:
On 2020-03-23 13:34:46 -0500 (-0500), Ghanshyam Mann wrote: [...]
Selected goals till now or V cycle:
- Switch legacy Zuul jobs to native
[...]
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/2901f4b87b7506c63aefa34 ece47106ff3c8a328/doc/source/zuulv3.rst >
Why was it removed I think it still important. The amount of jobs still to be converted which lead to this goal should say something.
Can it be restored or at least added somewhere else?
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.
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:
---- On Mon, 23 Mar 2020 15:43:44 -0500 Jeremy Stanley fungi@yuggoth.org wrote ----
On 2020-03-23 21:28:41 +0100 (+0100), Luigi Toscano wrote:
On Monday, 23 March 2020 20:11:50 CET Jeremy Stanley wrote:
On 2020-03-23 13:34:46 -0500 (-0500), Ghanshyam Mann wrote: [...]
Selected goals till now or V cycle:
- Switch legacy Zuul jobs to native
https://governance.openstack.org/tc/goals/selected/victoria/index.html
[...]
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/2901f4b87b7506c63aefa34
ece47106ff3c8a328/doc/source/zuulv3.rst >
Why was it removed I think it still important. The amount of jobs
still to be
converted which lead to this goal should say something.
Can it be restored or at least added somewhere else?
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.
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?
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 ----
On Mon, Mar 23, 2020, at 3:04 PM, Ghanshyam Mann wrote:
---- On Mon, 23 Mar 2020 15:43:44 -0500 Jeremy Stanley fungi@yuggoth.org wrote ----
On 2020-03-23 21:28:41 +0100 (+0100), Luigi Toscano wrote:
On Monday, 23 March 2020 20:11:50 CET Jeremy Stanley wrote:
On 2020-03-23 13:34:46 -0500 (-0500), Ghanshyam Mann wrote: [...]
Selected goals till now or V cycle:
- Switch legacy Zuul jobs to native
https://governance.openstack.org/tc/goals/selected/victoria/index.html
[...]
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/2901f4b87b7506c63aefa34
ece47106ff3c8a328/doc/source/zuulv3.rst >
Why was it removed I think it still important. The amount of jobs
still to be
converted which lead to this goal should say something.
Can it be restored or at least added somewhere else?
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.
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?
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.
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 ----
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:
- 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...
- 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:
- Switch legacy Zuul jobs to native
-gmann & njohnston
---- On Wed, 26 Feb 2020 11:47:10 -0600 Ghanshyam Mann gmann@ghanshyammann.com wrote ----
---- On Wed, 05 Feb 2020 12:39:17 -0600 Ghanshyam Mann gmann@ghanshyammann.com wrote ----
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]
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].
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
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
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 Fri, Apr 24, 2020 at 11:32 AM Ghanshyam Mann gmann@ghanshyammann.com wrote:
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:
- Migrate from oslo.rootwrap to oslo.privsep
Goal proposal: https://review.opendev.org/#/c/718177/ Champion: Rodolfo Alonso Hernandez (ralonsoh)
- add container-images
Goal proposal: https://review.opendev.org/#/c/718177/ Champion: Mohammed Naser (mnaser) and Monty Taylor (mordred)
-1. From Zun's perspective, we don't have any use case for building and maintaining such container images.
- 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:
- 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 ----
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:
- 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...
- 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:
- 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 Wed, 05 Feb 2020 12:39:17 -0600 Ghanshyam Mann <
gmann@ghanshyammann.com> wrote ----
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]
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].
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
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
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 Fri, 2020-04-24 at 10:22 -0500, Ghanshyam Mann wrote:
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:
- Migrate from oslo.rootwrap to oslo.privsep
Goal proposal: https://review.opendev.org/#/c/718177/ Champion: Rodolfo Alonso Hernandez (ralonsoh)
- add container-images
Goal proposal: https://review.opendev.org/#/c/718177/ Champion: Mohammed Naser (mnaser) and Monty Taylor (mordred)
- 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:
- Switch legacy Zuul jobs to native
https://governance.openstack.org/tc/goals/selected/victoria/index.html
- Champion: Luigi Toscano (tosky)
-gmann & njohnston
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:
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]
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
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:
On 2/5/20 7:39 PM, Ghanshyam Mann wrote:
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]
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
I've added 3 major paint points to the etherpad which I think are very important for operators:
Get all services to systemd-notify
Make it possible to reload service configurations dynamically without
restarting daemons
Wasn't that goal in Rocky: [1]
- All API to provide a /healthcheck URL (like the Keystone one...).
I like that idea :)
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)
[1] https://governance.openstack.org/tc/goals/selected/rocky/enable-mutable-conf...
On Thu, 2020-04-30 at 13:51 +0200, Slawek Kaplonski wrote:
Hi,
On Thu, Apr 30, 2020 at 01:20:29PM +0200, Thomas Goirand wrote:
On 2/5/20 7:39 PM, Ghanshyam Mann wrote:
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]
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
I've added 3 major paint points to the etherpad which I think are very important for operators:
- Get all services to systemd-notify
i commented on the ether pad bug jsut to say it again here. we cant have any of the openstack serivce depend on systemd in anyway first we cant assume the host os will use it (e.g. windows) second even if the linux distro use systemd if we are deploying in a container we cant assume the service will have acess to dbus or systemd or systemd tools.
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.
- Make it possible to reload service configurations dynamically without
restarting daemons
Wasn't that goal in Rocky: [1]
yes the mutable config. without significatnt changes to hwo some services are written we can supprot all configs values being mutable but a subset of them likely already are in many services. for example the log level in nova i belive is mutable. but we cant support changeing for example the virt driver without a restat as too much of the code assumes that will not change while the compute agent is running.
- All API to provide a /healthcheck URL (like the Keystone one...).
I like that idea :)
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)
[1] https://governance.openstack.org/tc/goals/selected/rocky/enable-mutable-conf...
On 4/30/20 2:31 PM, Sean Mooney wrote:
On Thu, 2020-04-30 at 13:51 +0200, Slawek Kaplonski wrote:
Hi,
On Thu, Apr 30, 2020 at 01:20:29PM +0200, Thomas Goirand wrote:
On 2/5/20 7:39 PM, Ghanshyam Mann wrote:
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]
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
I've added 3 major paint points to the etherpad which I think are very important for operators:
- Get all services to systemd-notify
i commented on the ether pad bug jsut to say it again here. we cant have any of the openstack serivce depend on systemd in anyway first we cant assume the host os will use it (e.g. windows) second even if the linux distro use systemd if we are deploying in a container we cant assume the service will have acess to dbus or systemd or systemd tools.
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.
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.
- Make it possible to reload service configurations dynamically without
restarting daemons
Wasn't that goal in Rocky: [1]
yes the mutable config. without significatnt changes to hwo some services are written we can supprot all configs values being mutable but a subset of them likely already are in many services. for example the log level in nova i belive is mutable. but we cant support changeing for example the virt driver without a restat as too much of the code assumes that will not change while the compute agent is running.
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:
On 4/30/20 2:31 PM, Sean Mooney wrote:
On Thu, 2020-04-30 at 13:51 +0200, Slawek Kaplonski wrote:
Hi,
On Thu, Apr 30, 2020 at 01:20:29PM +0200, Thomas Goirand wrote:
On 2/5/20 7:39 PM, Ghanshyam Mann wrote:
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]
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
I've added 3 major paint points to the etherpad which I think are very important for operators:
- Get all services to systemd-notify
i commented on the ether pad bug jsut to say it again here. we cant have any of the openstack serivce depend on systemd in anyway first we cant assume the host os will use it (e.g. windows) second even if the linux distro use systemd if we are deploying in a container we cant assume the service will have acess to dbus or systemd or systemd tools.
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.
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.
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.
- Make it possible to reload service configurations dynamically without
restarting daemons
Wasn't that goal in Rocky: [1]
yes the mutable config. without significatnt changes to hwo some services are written we can supprot all configs values being mutable but a subset of them likely already are in many services. for example the log level in nova i belive is mutable. but we cant support changeing for example the virt driver without a restat as too much of the code assumes that will not change while the compute agent is running.
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 ?
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:
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.
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 Thu, 30 Apr 2020 12:59:37 -0500 Thomas Goirand zigo@debian.org wrote ----
Thanks for your helpful reply.
On 4/30/20 5:43 PM, Ben Nemec 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.
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... :/
This is issue, can you file a bug for that and we can track/fix a bug.
-gmann
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:
Thanks for your helpful reply.
On 4/30/20 5:43 PM, Ben Nemec 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.
Oh, so it means downstream packages must set an env var to support it?
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.
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... :(
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:
On 2/5/20 7:39 PM, Ghanshyam Mann wrote:
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]
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
I've added 3 major paint points to the etherpad which I think are very important for operators:
Get all services to systemd-notify
Make it possible to reload service configurations dynamically without
restarting daemons
- All API to provide a /healthcheck URL (like the Keystone one...).
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.
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)
---- On Thu, 30 Apr 2020 06:20:29 -0500 Thomas Goirand zigo@debian.org wrote ----
On 2/5/20 7:39 PM, Ghanshyam Mann wrote:
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]
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
I've added 3 major paint points to the etherpad which I think are very important for operators:
Get all services to systemd-notify
Make it possible to reload service configurations dynamically without
restarting daemons
- 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?
#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 ----
---- On Thu, 30 Apr 2020 06:20:29 -0500 Thomas Goirand zigo@debian.org wrote ----
On 2/5/20 7:39 PM, Ghanshyam Mann wrote:
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]
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
I've added 3 major paint points to the etherpad which I think are very important for operators:
Get all services to systemd-notify
Make it possible to reload service configurations dynamically without
restarting daemons
- 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?
#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)
participants (10)
-
Ben Nemec
-
Clark Boylan
-
Ghanshyam Mann
-
Hongbin Lu
-
Jean-Philippe Evrard
-
Jeremy Stanley
-
Luigi Toscano
-
Sean Mooney
-
Slawek Kaplonski
-
Thomas Goirand