yahoo-eng-team team mailing list archive

[Abel Luck <1814289@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

As discussed on IRC with rharper:

There is no way to influence the order that scripts are executed.

The use case is: Build an AMI with a /etc/cloud/cloud.cfg.d/XXXX.cfg
file that contains a `runcmd` directive, and have this script executed
BEFORE the runtime user-data script supplied by EC2.

Currently what happens is that the user-data script is dropped into
`/var/lib/cloud/instance/scripts/part-00` and the runcmd script is
dropped as `/var/lib/cloud/instance/scripts/runcmd`. Lexically `part-00`
is before `runcmd`, so the user-data script is always executed first.

There is no way to influence this with a cloud-init option.

I cannot use bootcmd, as it runs too early.

rharper suggested: "another option is to switch the user-data shell
script into a #cloud-config runcmd: and 'write_files'". I also cannot do
this, as in my organization it is already standard practice to pass the
user-data as a shell script.

As a workaround I am going to bypass cloud-init entirely add use a
systemd unit.

** 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/1814289

Title:
  No control over the order in which scripts are executed

Status in cloud-init:
  New

Bug description:
  As discussed on IRC with rharper:

  There is no way to influence the order that scripts are executed.

  The use case is: Build an AMI with a /etc/cloud/cloud.cfg.d/XXXX.cfg
  file that contains a `runcmd` directive, and have this script executed
  BEFORE the runtime user-data script supplied by EC2.

  Currently what happens is that the user-data script is dropped into
  `/var/lib/cloud/instance/scripts/part-00` and the runcmd script is
  dropped as `/var/lib/cloud/instance/scripts/runcmd`. Lexically
  `part-00` is before `runcmd`, so the user-data script is always
  executed first.

  There is no way to influence this with a cloud-init option.

  I cannot use bootcmd, as it runs too early.

  rharper suggested: "another option is to switch the user-data shell
  script into a #cloud-config runcmd: and 'write_files'". I also cannot
  do this, as in my organization it is already standard practice to pass
  the user-data as a shell script.

  As a workaround I am going to bypass cloud-init entirely add use a
  systemd unit.

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