← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1804809] Re: salt-minion not started after installation

 

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/3282

** Bug watch added: github.com/canonical/cloud-init/issues #3282
   https://github.com/canonical/cloud-init/issues/3282

** Changed in: cloud-init
       Status: Triaged => Expired

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1804809

Title:
  salt-minion not started after installation

Status in cloud-init:
  Expired

Bug description:
  the cc_salt_minion.py module uses the service command to start salt-
  minion after installation. However this command is not guaranteed to
  exist on all distributions.

  In Gentoo, openrc stopped providing this binary not so long ago [1]
  but using systemd on Gentoo does not provide this either. In debian 9
  the bin is provided by init-system-helpers [2] which is an essential
  package meaning removing it most likely breaks your system.

  I wanted to suggest to use distro class init_cmd but even this feels a
  bit limited as it requires duplication for distributions that support
  more than one init system. Would it make sense to create a class
  hierarchy to support the classical init systems out there (openrc,
  debian-style init, systemd) and allow automatic detection of the
  actual init being used ?

  [1] https://www.gentoo.org/support/news-items/2017-10-13-openrc-service-binary-removal.html
  [2] https://packages.debian.org/unstable/main/init-system-helpers

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1804809/+subscriptions



References