Open Stack

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.py

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-handling 
We could use some more operator-facing documentation about that though. 
The oslo.service doc is more developer-oriented.

> 
> Cheers,
> 
> Thomas Goirand (zigo)
>