userdata runcmd overwrites runcmd under cloud.cfg.d

[Jack Chen]

I'm using Juju to deploy machine. Added runcmd section in /etc/cloud.cfg.d/60-my-conf.cfg:

```
merge_how: 'list(append)+dict(recurse_array)+str()'

runcmd:
 - echo "run in 60 my cloudinit cfg"
 - usermod -aG docker ubuntu

merge_how: 'list(append)+dict(recurse_array)+str()'
```

This script works when deploy machine using MAAS. But it didn't work when deploy machine using JUJU, Seems merge_how doesn't works.

I want to use cloud-init single to seem how runcmd executes, but seems it's only displaying the last execution's status?

```
cloud-init single --name cc_runcmd --frequency always
Cloud-init v. 18.4-0ubuntu1~16.04.2 running 'single' at Tue, 04 Dec 2018 00:01:54 +0000. Up 1338.24 seconds
```

Seems I didn't find a good way to debug this problem, appreciate any debug commands or tips for debug this kind of problems here.

[Jack Chen (scsvip)]

Could you guys please help figure out the overwriting rules used in juju user-data?
I tested `write_files` section defined under cloud.cfg.d/ is not override by juju user-data.
Currently I use `write_files` to write my scripts into `/var/lib/cloud/instance/scripts/part-001` to customize juju deployed machine. But it's hack and not straight forward.

```
# cat /var/lib/cloud/instance/user-data.txt.i
Content-Type: multipart/mixed; boundary="===============0252242156900375939=="
MIME-Version: 1.0
Number-Attachments: 1

--===============0252242156900375939==
MIME-Version: 1.0
Content-Type: text/cloud-config
Content-Disposition: attachment; filename="part-001"

#cloud-config
apt_mirror: ""
bootcmd:
- |-
  printf '%s\n' 'Acquire::http::Proxy::"127.0.0.1" "DIRECT";
  Acquire::https::Proxy::"127.0.0.1" "DIRECT";
  Acquire::ftp::Proxy::"127.0.0.1" "DIRECT";
  Acquire::http::Proxy::"localhost" "DIRECT";
  Acquire::https::Proxy::"localhost" "DIRECT";
  Acquire::ftp::Proxy::"localhost" "DIRECT";
  Acquire::http::Proxy::"::1" "DIRECT";
  Acquire::https::Proxy::"::1" "DIRECT";
  Acquire::ftp::Proxy::"::1" "DIRECT";' > /etc/apt/apt.conf.d/95-juju-proxy-settings
output:
  all: '| tee -a /var/log/cloud-init-output.log'
package_update: true
package_upgrade: true
packages:
- bridge-utils
- curl
- cpu-checker
- bridge-utils
- cloud-utils
- tmux
- ubuntu-fan
runcmd:
- set -xe
- |-
  mkdir -p '/var/lib/juju'
  cat > '/var/lib/juju/MAASmachine.txt' << 'EOF'
  'hostname: vm6
  '
  EOF
  chmod 0755 '/var/lib/juju/MAASmachine.txt'
- set -xe
- install -D -m 644 /dev/null '/etc/systemd/system/juju-clean-shutdown.service'
- |-
  printf '%s\n' '
  [Unit]
  Description=Stop all network interfaces on shutdown
  DefaultDependencies=false
  After=final.target

  [Service]
  Type=oneshot
  ExecStart=/sbin/ifdown -a -v --force
  StandardOutput=tty
  StandardError=tty

  [Install]
  WantedBy=final.target
  ' > '/etc/systemd/system/juju-clean-shutdown.service'
- /bin/systemctl enable '/etc/systemd/system/juju-clean-shutdown.service'
- install -D -m 644 /dev/null '/var/lib/juju/nonce.txt'
- printf '%s\n' 'machine-0:a095a350-3630-47f3-8c0b-a49f741c7bf9' > '/var/lib/juju/nonce.txt'
- test -n "$JUJU_PROGRESS_FD" || (exec {JUJU_PROGRESS_FD}>&2) 2>/dev/null && exec
  {JUJU_PROGRESS_FD}>&2 || JUJU_PROGRESS_FD=2
- '[ -e /etc/profile.d/juju-proxy.sh ] || printf ''\n# Added by juju\n[ -f "/etc/juju-proxy.conf"
  ] && . "/etc/juju-proxy.conf"\n'' >> /etc/profile.d/juju-proxy.sh'
- mkdir -p /var/lib/juju/locks
- (id ubuntu &> /dev/null) && chown ubuntu:ubuntu /var/lib/juju/locks
- mkdir -p /var/log/juju
- chown syslog:adm /var/log/juju
- bin='/var/lib/juju/tools/2.4.1.1-xenial-amd64'
- mkdir -p $bin
- echo 'Fetching Juju agent version 2.4.1.1 for amd64' >&$JUJU_PROGRESS_FD
- |2-

  n=1
  while true; do

      printf "Attempt $n to download agent binaries from %s...\n" 'https://10.10.25.44:17070/model/a8436d07-e82f-4ef0-878c-d95d05f57a13/tools/2.4.1.1-xenial-amd64'
      curl -sSfw 'agent binaries from %{url_effective} downloaded: HTTP %{http_code}; time %{time_total}s; size %{size_download} bytes; speed %{speed_download} bytes/s ' --connect-timeout 20 --noproxy "*" --insecure -o $bin/tools....

[Dmitrii Shcherbakov (dmitriis)]

Try using cloudinit-userdata model-config:

cat ./modelconfig.yaml
cloudinit-userdata: |
  ca-certs:
    trusted:
    - |
      -----BEGIN CERTIFICATE-----
      MIIFgDCCA2igAwIBAgIJANG/4O762QdKMA0GCSqGSIb3DQEBCwUAMFUxCzAJBgNV
      # ... rest of the cert here
      -----END CERTIFICATE-----
  preruncmd: |
    - echo this will run before
    - echo juju runcmd
  postruncmd: |
    - echo this will run after
    - echo juju runcmd

juju model-config modelconfig.yaml

[Jack Chen (scsvip)]

Thanks for you reply Dmitrii. Is there any chance to solve it in MAAS layer? Wandering how Juju runcmd overwrites runcmd defined under cloud.cfg.d/ ? I believe this is a feature supported by cloudinit instead of Juju?

[Jack Chen (scsvip)]

Thanks for your reply Dmitrii. Is there any chance to solve it in MAAS layer instead of using preruncmd supported by Juju? Wandering how Juju runcmd overwrites runcmd defined under cloud.cfg.d/, this should be a feature supported by cloudinit instead of Juju, right?

[Anastasia (anastasia-macmood)]

Adding cloud-init and MAAS as projects to this report and marking as Invalid for Juju since Juju operates as expected.

[Andres Rodriguez (andreserl)]

Hi all,

I'm marking this as invalid for MAAS, because, as I understand it from the bug description, this works when deploying with MAAS.

What it is not clear to me, however, how is this done when deploying w/ Juju?

@Jack, can you please clarify a few things:

1. How are you using write_files ? Or how are you customizing your deployment exactly? Form the bug description it is not clear to me what is it that you are doing.
2. Have you tried what Dimitri suggested in comment #2?

@Anastasia, does juju allow passing extra user_data? Is this what Dimitri describes in comment #2? How do you know that Juju operates as expected ?

[Anastasia (anastasia-macmood)]

@Andres Rodriguez (andreserl),

Thank you for the prompt reply \o/

I have read comment # 3 (or comment # 4) as in 'could be in MAAS' but 'MAAS layer' (quoting the reporter), from Juju perspective, could be interpreted as a MAAS provider and, indeed, could involve modification to juju maas provider user data.

I'll leave as 'New' in juju for further consideration but am not convinced that it needs to be addressed in Juju if everything works as desired via model-config as per suggestion.

I am fairly certain that there is nothing to do on cloud-init side either, I was mostly interested in the advice around pre-runcmd/post-runcmd...

[Andres Rodriguez (andreserl)]

Thanks for your reply Anastasia! I was just trying to understand your
conclusion provided that it still remains unclear to me how is he trying to
customize the user_data when using Juju.

Thanks again!

On Fri, Dec 7, 2018 at 12:40 AM Anastasia <email address hidden>
wrote:

> @Andres Rodriguez (andreserl),
>
> Thank you for the prompt reply \o/
>
> I have read comment # 3 (or comment # 4) as in 'could be in MAAS' but
> 'MAAS layer' (quoting the reporter), from Juju perspective, could be
> interpreted as a MAAS provider and, indeed, could involve modification
> to juju maas provider user data.
>
> I'll leave as 'New' in juju for further consideration but am not
> convinced that it needs to be addressed in Juju if everything works as
> desired via model-config as per suggestion.
>
> I am fairly certain that there is nothing to do on cloud-init side
> either, I was mostly interested in the advice around pre-runcmd/post-
> runcmd...
>
> ** Changed in: juju
> Status: Invalid => New
>
> --
> You received this bug notification because you are subscribed to MAAS.
> https://bugs.launchpad.net/bugs/1806504
>
> Title:
> userdata runcmd overwrites runcmd under cloud.cfg.d
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/cloud-init/+bug/1806504/+subscriptions
>
> Launchpad-Notification-Type: bug
> Launchpad-Bug: product=cloud-init; status=New; importance=Undecided;
> assignee=None;
> Launchpad-Bug: product=juju; status=New; importance=Undecided;
> assignee=None;
> Launchpad-Bug: product=maas; status=Invalid; importance=Undecided;
> assignee=None;
> Launchpad-Bug-Information-Type: Public
> Launchpad-Bug-Private: no
> Launchpad-Bug-Security-Vulnerability: no
> Launchpad-Bug-Commenters: anastasia-macmood andreserl dmitriis scsvip
> Launchpad-Bug-Reporter: Jack Chen (scsvip)
> Launchpad-Bug-Modifier: Anastasia (anastasia-macmood)
> Launchpad-Message-Rationale: Subscriber (MAAS)
> Launchpad-Message-For: andreserl
>
--
Andres Rodriguez (RoAkSoAx)
Ubuntu Server Developer
MSc. Telecom & Networking
Systems Engineer

[Jack Chen (scsvip)]

Hi Andres:
Sorry for the delayed response. Had some busy days.

> 1. How are you using write_files ? Or how are you customizing your deployment exactly? Form the bug description it is not clear to me what is it that you are doing.
I solved by using MAAS and cloudinit:
1.In curtin_userdata_ubuntu, writes file `/etc/cloud.cfg.d/60-my-conf.cfg` in target machine
2. In 60-my-conf.cfg, use cloud-init's `write_files` module to write script content into
`/var/lib/cloud/instance/scripts/part-001`. This file will be executed by cloud init.

> 2. Have you tried what Dimitri suggested in comment #2?
Yes, it worked, but I want to find a way to solve it by leveraging MAAS.

[Ryan Harper (raharper)]

Hi, you may want to look at some additional documentation on using merge-how here:

https://git.launchpad.net/cloud-init/tree/doc/rtd/topics/merging.rst#n243

[Launchpad Janitor (janitor)]

[Expired for cloud-init because there has been no activity for 60 days.]

[James Falcon (falcojr)]

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