Cron entry /etc/cron.d/codedeploy-agent-update should not be present (chkconfig not honoured)

[et304383]

I tried to figure out why chkconfig wasn't being honoured for starting the code deploy agent at boot. I explicitly need this disabled to prevent clash between code deploy and cfn-init.

I couldn't figure out why code deploy agent was still starting despite chkconfig listing all flags as OFF.

Turns out a cron entry is added to AUTO UPDATE the agent. This is wrong for two reasons:

• it causes code deploy agent to start at boot because the install program automatically starts the agent service, and thus chkconfig is ignored
• it's wrong to auto update software that hasn't been tested by the team managing the server (save urgent security updates done by AWS through cloud-init).

[amoebaOfDoom]

Don't bake the host agent into your AMI. You should always pull the latest version on instance startup.

There is no LTS support for any host agent release. Disabling the updater or otherwise using old agent versions is not supported and you may receive limited or no assistance for such a configuration.

Removing the cron is trivial and you are free to do so at your own risk.

[et304383]

Don't bake the host agent into your AMI? That seems to go against the fact that CodeDeploy executes against your instances when autoscaling creates them and there is a deployment attached to that autoscaling group through CodeDeploy. I don't like the idea of making an incomplete AMI because of an auto update process that also starts a service I've configured to not start at boot.

This entire issue arose from having cfn-init and CodeDeploy step on each others toes during instance spin-up via autoscaling. CodeDeploy was essentially kicking off while our cfn-init execution was still taking place. The solution was to have the agent configured not to boot at startup and have cfn-init start. It sounds like you're suggesting to instead have cfn-init INSTALL the agent. What if I want to create a server without internet connectivity? Not possible since the installer needs to be downloaded from S3 via an https link:

https://github.com/awslabs/aws-codedeploy-samples/blob/master/conf-mgmt/chef/aws-codedeploy-agent/cookbooks/codedeploy-agent/recipes/default.rb#L2

The idea of having one mechanism for baking the AMI and another LaunchConfiguration for installing the agent (requiring internet access) and then having CodeDeploy finish off the deployment of code somehow seems "not so AWS" to me.

In the end, isn't it wrong to have a service that does not honour chkconfig? Why can't the auto update process install without starting the service? Perhaps only restart it if it's already running? But if it's currently stopped and you're upgrading, don't start it again. It's obviously stopped for a reason.

[et304383]

No updates here? If you want to leave the auto-update in place, fine, but the update process should honour chkconfig and not start the service. Restart? Sure, but don't start blindly, ignoring chkconfig settings.

[et304383]

Last effort to convince the powers that be:

At the very least, can we not have this auto update run at boot? Sure, update daily at a specific time or every 6 hours or something, but running at boot seems like the underlying cause of numerous issues.