yahoo-eng-team team mailing list archive

[Gilles Dartiguelongue <gilles.dartiguelongue@xxxxxxxxx>]

Public bug reported:

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

** Affects: cloud-init
     Importance: Undecided
         Status: New

-- 
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:
  New

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