Comment 2 for bug 1450092

The current behavior is expected, even if not helpful. For cloudinit (see environs/cloudinit/cloudinit.go) we decide the init system based on the juju version of the to-be-provisioned instance. In the case of vivid, that translates to systemd.

When bootstrapping, cloudinit is used to set up the local host as the state instance. In this case, combined with vivid (or later) running upstart, the selection of systemd is incorrect. Early on we made the decision to handle this case by providing a feature flag: "legacy-upstart". So using that flag should allow bootstrap to succeed.

However, the feature flag will cause all vivid (and later) containers to also try to use upstart, which will thus cause problems when deploying services. This is less of an issue since there aren't any vivid charms in the charm store. However, it could be a problem for personal namespace charms or local charms that support vivid.

I'll look at finding a better solution to the cloudinit situation.