[PKG-Openstack-devel] Bug#770706: Bug#770706: Bug#770706: keystone.service does not start, /var/run/keystone not created

Tue Dec 2 17:58:29 UTC 2014

Hi Mikael

Thanks for still working on this. I think we are getting closer to a
workable solution.

Mikaël Cluseau <mcluseau at isi.nc> writes:

> Hi,
>
> On 12/02/2014 01:52 AM, Gaudenz Steinlin wrote:
>> So only new changes which fix (RC) bugs are allowed and the changes 
>> should be as minimal as possible to fix the bug.
>
> Since I already posted patches for a minimal set of code changes with a 
> minimal set of feature changes, I can now move on more radical changes. 
> My policy is now to follow your comments as long as Thomas doesn't 
> disagree (including this policy itself ;-)). That's why I've gone 
> farther in my last reply.

Did you test the patches with the "minimal set of changes". I think we
need strong arguments that they are working if we want to propose them
to the Release Team for jessie. I currently don't have a good setup to
test such patches.

>> I wanted to comment on this already in my first reply but forgot. 
>> What's the advantage of comparing with "x" prepended here?
>
> I didn't change what existed here. AFAIK, it's a pratice to help have 
> portable shell scripts.

After thinking about this a bit more, it's only usefull in case the
variable content starts with a "-" to avoid it being interpreted as a
test flag. Eg. USE_SYSLOG="-f" would cause an error without this
construct. The empty variable case is already dealt with the quoting.
So it's probably usefull to keep it. 

>
>>> I don't agree at all here. It's *not* a duplicate. With a 
>>> configuration file, you can choose, globally, for a given service, 
>>> where to log. You cannot select which daemon. [...] So we really need 
>>> this as a feature to make it easy to configure for each service, and 
>>> the configuration files just wont do it. 
>> I don't care very much about this. I can see Thomas point [...]
>>
>> The variables are designed in a way which is a bit hard to support with
>> systemd. It would be easier if the values in the /etc/default/ files
>> already contained the command line arguments.
>
> If we want to use these environment files, I can't see a way to keep the 
> current logic without using a shell. As you say and as is suggested in 
> https://wiki.debian.org/systemd/Packaging#overriding_options_and_.2Fetc.2Fdefault_handling, 
> we could switch to an OPTIONS environment variable used in ExecStart. 
> Supporting USE_SYSLOG and USE_LOGFILE seems hard to do while the OPTIONS 
> solution improves the feature by allowing to specify globally any 
> globally recognized daemon parameters. Thus, I think it's a reasonable 
> choice that is easy to support in both init systems. As there's a 
> consensus on keeping the same interface for the sysv-rc and systemd, we 
> should change the init script accordingly.

Yes supporting the yes/no variables is probably not possible directly in
systemd. If we really want to keep them, then we need a small script to
compile the needed command line arguments from them.

>
> My proposal is the following:
>
> EnvironmentFile=-/etc/default/openstack
> EnvironmentFile=-/etc/default/${NAME}
> ExecStart=${DAEMON}--config-file=/etc/${PROJECT_NAME}/${PROJECT_NAME}.conf  \${OPTIONS}
>
>
> We could even use the following environment files when $PROJECT_NAME != 
> $NAME:
>
> EnvironmentFile=-/etc/default/openstack
> EnvironmentFile=-/etc/default/${PROJECT_NAME}
> EnvironmentFile=-/etc/default/${NAME}

I like this proposal. It would also simplify the sysv init script and
it's more flexible than the current approach at the same time. I prefer
this to the current set of yes/no variables. I'm not sure if an
automatic migration is necessary or if a NEWS.Debian entry is enough. I
would probably go for the latter as an automatic migration might be hard
to get right.

This change is certainly post jessie IMO. I don't think we should change
/etc/default settings for jessie at this stage. I don't think anyone
disputes that, just to be clear.

Thomas what do you think about it?

>
>
>> I don't yet fully understand how the templates in openstack-pkg-tools
>> work. How are service specific values filled in?
>
> Every package has a debian/${DAEMON}.init.in with the variables defined. 
> For instance for keystone:
>
> [...]
> DESC="OpenStack Identity service"
> PROJECT_NAME=keystone
> NAME=keystone
> DAEMON=/usr/bin/keystone-all

OK, so PROJECT_NAME, NAME and DAEMON are all set on a per service basis
in the individual packages. 
>
>
>> I agree that we should let the operator choose how he want's to do 
>> logging. I don't think anyone want's to dispute that. But we need a 
>> default configuration. Certainly we don't want debug logging by 
>> default at all. Anyway the discussion was about creating /var/log and 
>> /var/lib from the sysv init script. This is wrong in all cases 
>> independently how logging is done. This just belongs to the package. 
>
> I agree that someone switching where the log file are should create the 
> log directories accordingly. As a consequence, if we default to 
> /var/log/${PROJECT_NAME}, and if every other package is creating these 
> at install time, we probably should do the same and create 
> /var/log/${PROJECT_NAME} at install time (that whould even fix this bug 
> without having to change a line in the unit and the sysv-rc script).
>
>>> I do believe that the /var/lock/${PROJECT_NAME} is needed in some cases
>>> for the internals of OpenStack. I would find it dangerous to remove
>>> it.
>> Then we have to find out which ones use it and create it for those
>> services. At least IMO.
>
> I prefer to avoid dangerous choices; its not expensive to have these 
> created. But then, should they be created by systemd or at install time? 
> (Thomas?)

What do you mean by dangerous choices? If we really need them they have
to be created by systemd and sysv init scripts as /var/lock is a symlink
into /run which is typically a tmpfs.

>
>> So we all agree on this. From here at least for me it follows that the
>> non working unit files should be removed as soon as possible. If we can
>> come up with a solution without relying on the sysv init script and that
>> is acceptable for the Release team, then good. Otherwise the second best
>> option IMO is to use the sysv support in systemd and not ship any unit
>> files.
>
> I think my previous work (keeping the init-script) can be accepted by 
> the release team and is a significant step toward the systemd's way as 
> it avoids start-stop-daemon. I will add the missing auto-created folders 
> to keep closer to the original script.

Do you have a complete patch (including the recent discussion) which can
be applied to openstack-pkg-tools and used to rebuild test packages? I
think this needs thorough testing if it's to be proposed for jessie.

Gaudenz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/openstack-devel/attachments/20141202/2a0a38f7/attachment-0001.sig>