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] - 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
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 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.
9. 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)