Merge lp://staging/~ted/libindicator/upstart-no-dbus into lp://staging/libindicator/13.10

FAILED: Continuous integration, rev:491
http://jenkins.qa.ubuntu.com/job/libindicator-ci/21/
Executed test runs:
    FAILURE: http://jenkins.qa.ubuntu.com/job/libindicator-saucy-amd64-ci/8/console
    FAILURE: http://jenkins.qa.ubuntu.com/job/libindicator-saucy-armhf-ci/7/console

Click here to trigger a rebuild:
http://s-jenkins:8080/job/libindicator-ci/21/rebuild

I think having the panel (or anything in the session) being aware of the init daemon is inside-out architecture.

Will every service now have to ship with an upstart script in addition to the dbus service file it already has? That adds an unnecessary dependency, and makes it harder to write services.

Why don't we make upstart aware of dbus activation? (I believe I heard it already is, or will be in the near future?) This will bring us all the benefits of upstart managing the services without any extra work.

Are there any advantages to using upstart explicitly?

On Wed, 2013-05-29 at 15:51 +0000, Lars Uebernickel wrote:

> I think having the panel (or anything in the session) being aware of
> the init daemon is inside-out architecture.

It's not the init daemon in this case. It's the session manager. It's
like being aware that there is a gnome-session.

> Will every service now have to ship with an upstart script in addition
> to the dbus service file it already has? That adds an unnecessary
> dependency, and makes it harder to write services.

No, there'll be no reason to ship a dbus service file.

> Why don't we make upstart aware of dbus activation? (I believe I heard
> it already is, or will be in the near future?) This will bring us all
> the benefits of upstart managing the services without any extra work.
>
> Are there any advantages to using upstart explicitly?

There was a patch for that, it was rejected upstream, we may put it back
in Ubuntu. But, even with that using Upstart jobs is better for
indicators. It keeps the log files in a single file that is
automatically picked up by apport and attached to bugs. Upstart can
restart the service including retry intervals. And for developers they
can manage when the service stops and starts with external tools that
already exist.

> On Wed, 2013-05-29 at 15:51 +0000, Lars Uebernickel wrote:
>
> > I think having the panel (or anything in the session) being aware of
> > the init daemon is inside-out architecture.
>
> It's not the init daemon in this case. It's the session manager. It's
> like being aware that there is a gnome-session.

Right. But I don't see why it should be aware of the session service, either.

> > Will every service now have to ship with an upstart script in addition
> > to the dbus service file it already has? That adds an unnecessary
> > dependency, and makes it harder to write services.
>
> No, there'll be no reason to ship a dbus service file.
>
> > Why don't we make upstart aware of dbus activation? (I believe I heard
> > it already is, or will be in the near future?) This will bring us all
> > the benefits of upstart managing the services without any extra work.
> >
> > Are there any advantages to using upstart explicitly?
>
> There was a patch for that, it was rejected upstream, we may put it back
> in Ubuntu. But, even with that using Upstart jobs is better for
> indicators. It keeps the log files in a single file that is
> automatically picked up by apport and attached to bugs. Upstart can
> restart the service including retry intervals. And for developers they
> can manage when the service stops and starts with external tools that
> already exist.

All of these things will be true anyway, because upstart *is* managing the services.

On Wed, 2013-05-29 at 16:18 +0000, Lars Uebernickel wrote:

> All of these things will be true anyway, because upstart *is* managing
> the services.

I guess, but I'm not sure why you're concerned over the job
configuration having:

  start on dbus-activation com.canonical.indicator.network

versus

  start on indicators-loaded

It seems like the second one is clearer and can be managed more easily
as we'll be able to introspect the startup with things like initctl2dot.

PASSED: Continuous integration, rev:491
http://jenkins.qa.ubuntu.com/job/libindicator-ci/23/
Executed test runs:
    SUCCESS: http://jenkins.qa.ubuntu.com/job/libindicator-saucy-amd64-ci/10
    SUCCESS: http://jenkins.qa.ubuntu.com/job/libindicator-saucy-armhf-ci/9

Click here to trigger a rebuild:
http://s-jenkins:8080/job/libindicator-ci/23/rebuild

PASSED: Continuous integration, rev:493
http://jenkins.qa.ubuntu.com/job/libindicator-ci/24/
Executed test runs:
    SUCCESS: http://jenkins.qa.ubuntu.com/job/libindicator-saucy-amd64-ci/11
    SUCCESS: http://jenkins.qa.ubuntu.com/job/libindicator-saucy-armhf-ci/10

Click here to trigger a rebuild:
http://s-jenkins:8080/job/libindicator-ci/24/rebuild

> On Wed, 2013-05-29 at 16:18 +0000, Lars Uebernickel wrote:
>
> > All of these things will be true anyway, because upstart *is* managing
> > the services.
>
>
> I guess, but I'm not sure why you're concerned over the job
> configuration having:
>
> start on dbus-activation com.canonical.indicator.network
>
> versus
>
> start on indicators-loaded
>
> It seems like the second one is clearer and can be managed more easily
> as we'll be able to introspect the startup with things like initctl2dot.

My point is that the first one won't be needed. Upstart should just take control over all dbus-activated things in the session.

On Thu, 2013-05-30 at 12:17 +0000, Lars Uebernickel wrote:

> My point is that the first one won't be needed. Upstart should just
> take control over all dbus-activated things in the session.

I don't think that it'll "take over" all of them because my
understanding is that for Upstart, dbus activation is an event type not
a job.

At the end of the day, it comes down to upstart being a process manager. Sure, we could use dbus activation, but then the panel service becomes the process manager. Let's leave process management to a tool that is designed to do that job (and does it well).

PASSED: Continuous integration, rev:494
http://jenkins.qa.ubuntu.com/job/libindicator-ci/26/
Executed test runs:
    SUCCESS: http://jenkins.qa.ubuntu.com/job/libindicator-saucy-amd64-ci/13
    SUCCESS: http://jenkins.qa.ubuntu.com/job/libindicator-saucy-armhf-ci/12

Click here to trigger a rebuild:
http://s-jenkins:8080/job/libindicator-ci/26/rebuild

PASSED: Continuous integration, rev:500
http://jenkins.qa.ubuntu.com/job/libindicator-ci/38/
Executed test runs:
    SUCCESS: http://jenkins.qa.ubuntu.com/job/libindicator-saucy-amd64-ci/25
    SUCCESS: http://jenkins.qa.ubuntu.com/job/libindicator-saucy-armhf-ci/24

Click here to trigger a rebuild:
http://s-jenkins:8080/job/libindicator-ci/38/rebuild

I object to this. upstart is not mandatory to manage desktop session on ubuntu. And indicators are used on the desktop sessions which are not managed by upstart. At the moment upstart as a user session manager, is opt-in, not opt-out on per session type as defined in /etc/upstart-xsessions. Thus one should preserve dbus activation files.

I understand the desire to have dbus services be managed/respawned by upstart the session manager, but forcing that to happen is not the right solution.