guidelines for upstart in oe?

guidelines for upstart in oe?

[Steffen Sledz]

If i remember right there are some first experiments with using upstart as an sysvinit replacement in some oe based distros.

Do some guidelines or suggestions exist to make an application recipes upstart ready?

Nowadays a recipe for a common service contains INITSCRIPT_NAME & Co and installs an init script for sysvinit.

How should such a recipe be modified to be able to install the application in a native upstart image (without sysvinit compatible runlevels)?

-- 
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sledz@dresearch-fe.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058

Re: guidelines for upstart in oe?

[Steffen Sledz]

On 14.09.2011 17:31, Steffen Sledz wrote:
> If i remember right there are some first experiments with using upstart as an sysvinit replacement in some oe based distros.
> 
> Do some guidelines or suggestions exist to make an application recipes upstart ready?
> 
> Nowadays a recipe for a common service contains INITSCRIPT_NAME & Co and installs an init script for sysvinit.
> 
> How should such a recipe be modified to be able to install the application in a native upstart image (without sysvinit compatible runlevels)?

Let me put it in concrete terms.

Is it possible to write a bb recipe in a way like this?

---------------------->snip<-------------------------
...
IF IMAGE USES UPSTART AS INIT THEN

inherit autotools

do_install_append() {
    install -d ${D}${sysconfdir}/init
    install -m 0644 ${S}/upstartscript ${D}${sysconfdir}/init/foo.conf
}

ELSE

inherit autotools update-rc.d

do_install_append() {
    install -d ${D}${sysconfdir}/init.d
    install -m 0755 ${WORKDIR}/initscript ${D}${sysconfdir}/init.d/foo
}

INITSCRIPT_NAME = "foo"

FI
...
---------------------->snip<-------------------------

Regards
Steffen

-- 
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sledz@dresearch-fe.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058

Re: guidelines for upstart in oe?

[Phil Blundell]

On Fri, 2011-09-16 at 17:29 +0200, Steffen Sledz wrote:
> On 14.09.2011 17:31, Steffen Sledz wrote:
> > If i remember right there are some first experiments with using upstart as an sysvinit replacement in some oe based distros.
> > 
> > Do some guidelines or suggestions exist to make an application recipes upstart ready?
> > 
> > Nowadays a recipe for a common service contains INITSCRIPT_NAME & Co and installs an init script for sysvinit.
> > 
> > How should such a recipe be modified to be able to install the application in a native upstart image (without sysvinit compatible runlevels)?
> 
> Let me put it in concrete terms.
> 
> Is it possible to write a bb recipe in a way like this?
> 
> ---------------------->snip<-------------------------
> ...
> IF IMAGE USES UPSTART AS INIT THEN
> 

Fundamentally no, since there is no way to know at the time the recipe
is evaluated what images it will go into.

It would be possible to ship both sets of scripts and then have a
postprocessing step to remove the ones that you don't need.  Or you
could make upstart vs sysvinit be a DISTRO_FEATURE.  Or, in at least
some cases, we could probably stop shipping the scripts as discrete
files altogether and replace them with some symbolic representation from
which the necessary scripts could be constructed dynamically at install
time.

p.

Re: guidelines for upstart in oe?

[Koen Kooi]

Op 16 sep. 2011, om 17:29 heeft Steffen Sledz het volgende geschreven:

> On 14.09.2011 17:31, Steffen Sledz wrote:
>> If i remember right there are some first experiments with using upstart as an sysvinit replacement in some oe based distros.
>> 
>> Do some guidelines or suggestions exist to make an application recipes upstart ready?
>> 
>> Nowadays a recipe for a common service contains INITSCRIPT_NAME & Co and installs an init script for sysvinit.
>> 
>> How should such a recipe be modified to be able to install the application in a native upstart image (without sysvinit compatible runlevels)?
> 
> Let me put it in concrete terms.
> 
> Is it possible to write a bb recipe in a way like this?
> 
> ---------------------->snip<-------------------------
> ...
> IF IMAGE USES UPSTART AS INIT THEN

images are orthogonal to recipe, so no

And stop being so bloody annoying with CC:, oe.dev is a closed list, so people that post are subscribed

Re: guidelines for upstart in oe?

[Steffen Sledz]

On 16.09.2011 17:32, Phil Blundell wrote:
> On Fri, 2011-09-16 at 17:29 +0200, Steffen Sledz wrote:
>> On 14.09.2011 17:31, Steffen Sledz wrote:
>>> If i remember right there are some first experiments with using upstart as an sysvinit replacement in some oe based distros.
>>>
>>> Do some guidelines or suggestions exist to make an application recipes upstart ready?
>>>
>>> Nowadays a recipe for a common service contains INITSCRIPT_NAME & Co and installs an init script for sysvinit.
>>>
>>> How should such a recipe be modified to be able to install the application in a native upstart image (without sysvinit compatible runlevels)?
>>
>> Let me put it in concrete terms.
>>
>> Is it possible to write a bb recipe in a way like this?
>>
>> ---------------------->snip<-------------------------
>> ...
>> IF IMAGE USES UPSTART AS INIT THEN
>>
> 
> Fundamentally no, since there is no way to know at the time the recipe
> is evaluated what images it will go into.
> 
> It would be possible to ship both sets of scripts and then have a
> postprocessing step to remove the ones that you don't need.  Or you
> could make upstart vs sysvinit be a DISTRO_FEATURE.  Or, in at least
> some cases, we could probably stop shipping the scripts as discrete
> files altogether and replace them with some symbolic representation from
> which the necessary scripts could be constructed dynamically at install
> time.

I'm not sure if there exist upstart based oe distros/images. But it seems that there are some systemd based ones (recipes/images/angstrom-systemd-image.bb).

Do they have a similar problem? How do these handle the sysvinit config vs. systemd config for the different services?

-- 
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sledz@dresearch-fe.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058

Re: guidelines for upstart in oe?

[Steffen Sledz]

Am 16.09.2011 18:15, schrieb Steffen Sledz:
> On 16.09.2011 17:32, Phil Blundell wrote:
>> On Fri, 2011-09-16 at 17:29 +0200, Steffen Sledz wrote:
>>> On 14.09.2011 17:31, Steffen Sledz wrote:
>>>> If i remember right there are some first experiments with using upstart as an sysvinit replacement in some oe based distros.
>>>>
>>>> Do some guidelines or suggestions exist to make an application recipes upstart ready?
>>>>
>>>> Nowadays a recipe for a common service contains INITSCRIPT_NAME & Co and installs an init script for sysvinit.
>>>>
>>>> How should such a recipe be modified to be able to install the application in a native upstart image (without sysvinit compatible runlevels)?
>>>
>>> Let me put it in concrete terms.
>>>
>>> Is it possible to write a bb recipe in a way like this?
>>>
>>> ---------------------->snip<-------------------------
>>> ...
>>> IF IMAGE USES UPSTART AS INIT THEN
>>>
>>
>> Fundamentally no, since there is no way to know at the time the recipe
>> is evaluated what images it will go into.
>>
>> It would be possible to ship both sets of scripts and then have a
>> postprocessing step to remove the ones that you don't need.  Or you
>> could make upstart vs sysvinit be a DISTRO_FEATURE.  Or, in at least
>> some cases, we could probably stop shipping the scripts as discrete
>> files altogether and replace them with some symbolic representation from
>> which the necessary scripts could be constructed dynamically at install
>> time.
> 
> I'm not sure if there exist upstart based oe distros/images. But it seems that there are some systemd based ones (recipes/images/angstrom-systemd-image.bb).
> 
> Do they have a similar problem? How do these handle the sysvinit config vs. systemd config for the different services?

BTW: What exactly are purpose and effects of IMAGE_INIT_MANAGER?

-- 
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sledz@dresearch-fe.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058

Re: guidelines for upstart in oe?

[Steffen Sledz]

Am 16.09.2011 17:32, schrieb Phil Blundell:
> On Fri, 2011-09-16 at 17:29 +0200, Steffen Sledz wrote:
>> On 14.09.2011 17:31, Steffen Sledz wrote:
>>> If i remember right there are some first experiments with using upstart as an sysvinit replacement in some oe based distros.
>>>
>>> Do some guidelines or suggestions exist to make an application recipes upstart ready?
>>>
>>> Nowadays a recipe for a common service contains INITSCRIPT_NAME & Co and installs an init script for sysvinit.
>>>
>>> How should such a recipe be modified to be able to install the application in a native upstart image (without sysvinit compatible runlevels)?
>>
>> Let me put it in concrete terms.
>>
>> Is it possible to write a bb recipe in a way like this?
>>
>> ---------------------->snip<-------------------------
>> ...
>> IF IMAGE USES UPSTART AS INIT THEN
>>
> 
> Fundamentally no, since there is no way to know at the time the recipe
> is evaluated what images it will go into.
> 
> It would be possible to ship both sets of scripts and then have a
> postprocessing step to remove the ones that you don't need.  Or you
> could make upstart vs sysvinit be a DISTRO_FEATURE.  Or, in at least
> some cases, we could probably stop shipping the scripts as discrete
> files altogether and replace them with some symbolic representation from
> which the necessary scripts could be constructed dynamically at install
> time.

Would it be an accepted solution to have two different packages in two recipes with common parts in an include like this?


foo_x.y.bb:
------------------>snip<-------------------
require foo-x.y.inc

RCONFLICTS = "foo-upstart"

inherit update-rc.d

do_install_append() {
    install -d ${D}${sysconfdir}/init.d
    install -m 0755 ${WORKDIR}/initscript ${D}${sysconfdir}/init.d/foo
}

INITSCRIPT_NAME = "foo"
...
------------------>snip<-------------------


foo-upstart_x.y.bb:
------------------>snip<-------------------
require foo-x.y.inc

RCONFLICTS = "foo"

do_install_append() {
    install -d ${D}${sysconfdir}/init
    install -m 0644 ${S}/upstartscript ${D}${sysconfdir}/init/foo.conf
}
...
------------------>snip<-------------------


foo-x.y.inc:
------------------>snip<-------------------
inherit autotools
...
------------------>snip<-------------------

Steffen

-- 
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sledz@DResearch.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058

Re: guidelines for upstart in oe?

[Anders Darander]

* Steffen Sledz <sledz@dresearch-fe.de> [110916 18:15]:
> I'm not sure if there exist upstart based oe distros/images. But it
> seems that there are some systemd based ones
> (recipes/images/angstrom-systemd-image.bb).
 
> Do they have a similar problem? How do these handle the sysvinit
> config vs. systemd config for the different services?

It varies slightly. 

Some packages, e.g. dropbear, has an extra package dropbear-systemd in
meta-oe, that packages the systemd unit files for dropbear. The same is
true for dbus in oe-core.

Other packages, like ofono in oe-core, pacakages the systemd unit files
directly in the ofono-package.

In all these cases, sysvinit files are supplied directly in the main
package.

Cheers,
Anders

-- 
Anders Darander
ChargeStorm AB / eStorm AB

Re: guidelines for upstart in oe?

[Phil Blundell]

On Sat, 2011-09-17 at 08:24 +0200, Steffen Sledz wrote:
> Would it be an accepted solution to have two different packages in two recipes with common parts in an include like this?
> 
> 
> foo_x.y.bb:
> ------------------>snip<-------------------
> require foo-x.y.inc
> 
> RCONFLICTS = "foo-upstart"

I think that would be a poor solution.  I guess you could do some sort
of BBCLASSEXTEND = "upstart" thing if you really wanted separate
packaging, though you'd then still have the issuette that a distro using
upstart (only) would end up with everything named "foo-upstart".

p.

Re: guidelines for upstart in oe?

[Steffen Sledz]

On 19.09.2011 10:06, Anders Darander wrote:
> * Steffen Sledz <sledz@dresearch-fe.de> [110916 18:15]:
>> I'm not sure if there exist upstart based oe distros/images. But it
>> seems that there are some systemd based ones
>> (recipes/images/angstrom-systemd-image.bb).
>  
>> Do they have a similar problem? How do these handle the sysvinit
>> config vs. systemd config for the different services?
> 
> It varies slightly. 
> 
> Some packages, e.g. dropbear, has an extra package dropbear-systemd in
> meta-oe, that packages the systemd unit files for dropbear. The same is
> true for dbus in oe-core.
> 
> Other packages, like ofono in oe-core, pacakages the systemd unit files
> directly in the ofono-package.
> 
> In all these cases, sysvinit files are supplied directly in the main
> package.

Hmmmm? This seems to be suitable for systemd images but not for upstart. :(

If a package installs sysvinit files *and* upstart jobs both will be used (at least as long as upstart supports the sysvinit runlevels for a better migration). So there's a need to install one of them only.

Steffen

-- 
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sledz@dresearch-fe.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058

Systemd sysv compat mode, was: Re: guidelines for upstart in oe?

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Op 19-09-11 10:06, Anders Darander schreef:
> * Steffen Sledz <sledz@dresearch-fe.de> [110916 18:15]:
>> I'm not sure if there exist upstart based oe distros/images. But it 
>> seems that there are some systemd based ones 
>> (recipes/images/angstrom-systemd-image.bb).
> 
>> Do they have a similar problem? How do these handle the sysvinit config
>> vs. systemd config for the different services?
> 
> It varies slightly.
> 
> Some packages, e.g. dropbear, has an extra package dropbear-systemd in 
> meta-oe, that packages the systemd unit files for dropbear. The same is 
> true for dbus in oe-core.
> 
> Other packages, like ofono in oe-core, pacakages the systemd unit files 
> directly in the ofono-package.
> 
> In all these cases, sysvinit files are supplied directly in the main 
> package.

This works for systemd since it has a working sysv compat mode and override
mechanism. Consider the following scenarios:

a) native mode
/lib/systemd/system/foo.service

native systemd unit will get used

b) dual mode
/etc/init.d/foo
/lib/systemd/system/foo.service

native systemd unit will get used, sysv script gets ignored.

c) sysv mode
/lib/systemd/system/foo.service

sysv script will run

d) masking
/etc/init.d/foo
/lib/systemd/system/foo.service is a symlink to /dev/null

sysv script will not run

So in the systemd world we can control which system gets used quite well.
And coming from an OE world writing systemd units is easy since they are
conceptually the same as recipes (e.g. DEPENDS -> Requires:) and don't
require a ton of boilerplate.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFOdweBMkyGM64RGpERAuuAAKCzWKuX6zVciC6VGoFv/udJlAgEmQCfRwx9
JDOJJKugRiyamOx+S9RJthg=
=bEGV
-----END PGP SIGNATURE-----