On Wed, Dec 13, 2017 at 10:34:25PM -0000, Andres Rodriguez wrote:
> FWIW, this is currently affecting customers who are running MAAS and
> require livepatch.

It's been affecting users since January, no? Why the sudden urgency?
What difference will a week or two make?

> Comments #11 and #12 above confirm that the patch is enough for the MAAS
> needs. Whichever way MAAS decides to check for systemd is up to MAAS and
> that is not a reason to block an SRU provided that it does not impact
> any other piece of software. That said, this patch does not does not
> introduce  a regression to MAAS nor any other software.

I think that's quite a brave claim to make. I'm sure "does not
introduce a regression" was a claim that might have been made in the
systemd SRU that regressed this too, and yet here we are.

> Lastly, this patch is *only* for 1.9 as this code path is only available
> in Trusty, so upgrades to later Ubuntu releases will yield on using a
> newer version of MAAS that doesn't rely on this code path.

If we did decide to SRU an emergency fix as a stopgap for MAAS' use
case, and it's for Trusty only, then why have a test at all? Can we just
return 'upstart' without a test?

To be clear, I'm not demanding or even requesting anything specific
right now. I don't feel that a case for urgency has yet been made, given
the currently known regression timeline. In the meantime I think it's
worth understanding how we want to fix this properly, because requiring
multiple SRUs while we swing back and forth is bad for everyone, and
equally I don't want to see us locked into a suboptimal solution.

If a case is accepted on the basis of urgency, or another SRU team
member disagrees with my assessment, I wouldn't want to block that. Feel
free to land what you think is appropriate.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1732703

Title:
  MAAS does not detect properly if Ubuntu is using upstart/systemd

Status in MAAS:
  Won't Fix
Status in MAAS 1.9 series:
  In Progress
Status in maas package in Ubuntu:
  New
Status in snapd package in Ubuntu:
  Won't Fix
Status in systemd package in Ubuntu:
  New
Status in maas source package in Trusty:
  New
Status in snapd source package in Trusty:
  New
Status in systemd source package in Trusty:
  New

Bug description:
  [impact]
  Since Trusty uses upstart by default, MAAS manages its services with upstart. 
However, when a user installs systemd (even if it is not used as the init 
system), MAAS detects systemd installed and tries to manage its services via 
systemd. This obviously creates issues and prevents MAAS from working.

  [Test Case]
  1. Install & configure MAAS
  2. Add machines
  3. install systemd
  4. MAAS will fail to manage machines

  [Regression potential]
  Minimal. This just ensures that upstart is detected correctly even if systemd 
is installed (but not used).

  [Original bug report]
  Trusty uses upstart by default, and installing snapd (e.g. for livepatch 
purposes), pulls systemd too. In this setup, upstart is _not_ replaced by 
systemd, but MAAS "detects" systemd as init because of the existence of 
/run/systemd/system:

  @src/provisioningserver/utils/__init__.py:505

  SYSTEMD_RUN_PATH = '/run/systemd/system'

  def get_init_system():
      """Returns 'upstart' or 'systemd'."""
      if os.path.exists(SYSTEMD_RUN_PATH):
          return 'systemd'
      else:
          return 'upstart'

  One possible solution would be to check if /sbin/init is a symlink
  pointing to /lib/systemd/systemd:

  def get_init_system():
      """Returns 'upstart' or 'systemd'."""
      initpath = os.readlink("/sbin/init")
      if (initpath == "/lib/systemd/systemd"):
          return 'systemd'
      else:
      return 'upstart'

  Other affected parts of the code are the postinst files for maas-proxy
  and maas-dhcp (debian/maas-proxy.postinst debian/maas-dhcp.postinst),
  throwing an error if maas is installed after systemd in Trusty

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1732703/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to