[tc][uc][all] Starting community-wide goals ideas for V series
openstack at nemebean.com
Thu Apr 30 15:43:45 UTC 2020
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:
>>> 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  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
>>>>> - 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 and ussuri
>>>>> cycle goals.
>>>>> NOTE: TC has defined the goal process schedule 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.
>>>>>  https://governance.openstack.org/tc/goals/index.html
>>>>>  https://etherpad.openstack.org/p/YVR-v-series-goals
>>>>>  https://etherpad.openstack.org/p/community-goals
>>>>>  https://etherpad.openstack.org/p/PVG-u-series-goals
>>>>>  https://governance.openstack.org/tc/goals/#goal-selection-schedule
>>>> 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
> 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:
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: 
>> 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:
And yes, it's SIGHUP to reload config:
We could use some more operator-facing documentation about that though.
The oslo.service doc is more developer-oriented.
> Thomas Goirand (zigo)
More information about the openstack-discuss