cc_salt_minion behaves badly if apt-get update fails

Bug #1594576 reported by Ross Vandegrift on 2016-06-20
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
cloud-init
Medium
Unassigned

Bug Description

I'm using cloud-init to setup some salt-minion config like so:

 #cloud-config
 salt_minion:
   conf:
     grains:
       my_grain_1: a
       my_grain_2: b

cc_salt_minion.py triggers apt-get update. If apt-get update fails, then cc_salt_minion does not update /etc/salt/minion, but nonetheless continues. My automation depends on finding these grains, and salt-minion is already built in.

Please consider the attached patch, which will skip the install if a flag is included. Alternatively, cc_salt_minion could write out /etc/salt/minion even if apt-get fails.

Ross

Scott Moser (smoser) wrote :

Hi,
Thanks for the bug report and patch.
Why was package installation failing for you? Ideally that should not fail.

Second, I think i'd like to have the ability for 'install_packages' to take an option to not install package if the package exists already. Then, we could change the minion code to allow user-data to set that flag. I think ultimately, you would still normally want 'apt-get install <package>' to have run, since that would mean you had then gotten any security updates or other package fixes from the sources provided.

Changed in cloud-init:
importance: Undecided → Medium
status: New → Triaged
Ross Vandegrift (ross-kallisti) wrote :

Package installation problems were caused by network issues, not a problem within cloud-init. I believe it's just repo.salt.stack.com occasionally timing out. It hasn't been reliably reproducible.

I've worked around the issue by switching to write_files - that effectively provides the unconditional salt minion config that I was looking for.

Not sure if this behavior is really a bug - perhaps someone would want configuration to fail if package installation failed. If cloud-init folks think the current behavior is correct, feel free to close.

Thanks,
Ross

Ross Vandegrift (ross-kallisti) wrote :

I now think this could be a conflict between cloud-init and systemd-triggered apt actions.

If apt-daily.service is triggered before cloud-init, any apt actions that cloud-init takes will fail. See this discussion for more info and a possible solution:
https://unix.stackexchange.com/questions/315502/how-to-disable-apt-daily-service-on-ubuntu-cloud-vm-image

Jim Browne (jbrowne) wrote :

Regarding the systemd conflict I discussed this in IRC and opened https://bugs.launchpad.net/cloud-init/+bug/1693361

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers