Open Stack

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.

>>> 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 ?

Cheers,

Thomas Goirand (zigo)