Open Stack

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.

> > 
> > 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.
> 
> > 
> > 10. 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-configuration.html
>