cc_salt_minion behaves badly if apt-get update fails

Bug #1594576 reported by Ross Vandegrift
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
cloud-init
Expired
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

Revision history for this message
Ross Vandegrift (ross-kallisti) wrote :
Revision history for this message
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
Revision history for this message
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

Revision history for this message
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

Revision history for this message
Jim Browne (jbrowne) wrote :

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

Revision history for this message
James Falcon (falcojr) wrote :
Changed in cloud-init:
status: Triaged → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.