[openstack-dev] [devstack] [all] systemd in devstack by default
hongbin.lu at huawei.com
Wed May 3 20:02:09 UTC 2017
I tried the new systemd devstack and frankly I don't like it. There are several handy operations in screen that seems to be impossible after switching to systemd. For example, freeze a process by "Ctrl + a + [". In addition, navigating though the logs seems difficult (perhaps I am not familiar with journalctl).
From my understanding, the plan is dropping screen entirely in devstack? I would argue that it is better to keep both screen and systemd, and let users choose one of them based on their preference.
> -----Original Message-----
> From: Sean Dague [mailto:sean at dague.net]
> Sent: May-03-17 6:10 AM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [devstack] [all] systemd in devstack by
> On 05/02/2017 08:30 AM, Sean Dague wrote:
> > We started running systemd for devstack in the gate yesterday, so far
> > so good.
> > The following patch (which will hopefully land soon), will convert
> > default local use of devstack to systemd as well -
> > https://review.openstack.org/#/c/461716/. It also includes
> > substantially updated documentation.
> > Once you take this patch, a "./clean.sh" is recommended. Flipping
> > modes can cause some cruft to build up, and ./clean.sh should be
> > pretty good at eliminating them.
> > https://review.openstack.org/#/c/461716/2/doc/source/development.rst
> > is probably specifically interesting / useful for people to read, as
> > it shows how the standard development workflows will change (for the
> > better) with systemd.
> > -Sean
> As a follow up, there are definitely a few edge conditions we've hit
> with some jobs, so the following is provided as information in case you
> have a job that seems to fail in one of these ways.
> Doing process stop / start
> The nova live migration job is special, it was restarting services
> manually, however it was doing so with some copy / pasted devstack code,
> which means it didn't evolve with the rest of devstack. So the stop
> code stopped working (and wasn't robust enough to make it clear that
> was the issue).
> https://review.openstack.org/#/c/461803/ is the fix (merged)
> run_process limitations
> When doing the systemd conversion I looked for a path forward which was
> going to make 90% of everything just work. The key trick here was that
> services start as the "stack" user, and aren't daemonizing away from
> the console. We can take the run_process command and make that the
> ExecStart in a unit file.
> *Except* that only works if the command is specified by an *absolute
> So things like this in kuryr-libnetwork become an issue
> There is also a second issue there, which is calling sudo in the
> run_process line. If you need to run as a user/group different than the
> default, you need to specify that directly.
> The run_process command now supports that -
> And lastly, run_process really always did expect that the thing you
> started remained attached to the console. These are run as "simple"
> services in systemd. If you are running a thing which already
> daemonizes systemd is going to assume (correctly in this simple mode)
> the fact that the process detatched from it means it died, and kill and
> clean it up.
> This is the issue the OpenDaylight plugin ran into.
> https://review.openstack.org/#/c/461889/ is the proposed fix.
> If you run into any other issues please pop into #openstack-qa (or
> respond to this email) and we'll try to work through them.
> Sean Dague
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev