salt-cloud error: No dependencies installation function found

[Steve Kirkpatrick]

Now that I have my salt master squared away, I decided to try salt-cloud.

I have a base AMI that I built using the official CentOS 6 AMI and packer.

Here's what I see when I try to deploy an instance using salt-cloud:

[root@mymaster ~]# salt-cloud -p base_ec2_oregon_private salttest

[INFO    ] salt-cloud starting

[INFO    ] Creating Cloud VM salttest in us-west-2

[INFO    ] Created node salttest

[INFO    ] Salt node data. Private_ip: 10.31.2.114

[INFO    ] Rendering deploy script: /usr/lib/python2.6/site-packages/salt/cloud/deploy/bootstrap-salt.sh

 *  INFO:  /tmp/.saltcloud/deploy.sh -- Version 2014.02.19

 *  INFO: System Information:

 *  INFO:   CPU:          GenuineIntel

 *  INFO:   CPU Arch:     x86_64

 *  INFO:   OS Name:      Linux

 *  INFO:   OS Version:   2.6.32-431.5.1.el6.x86_64

 *  INFO:   Distribution: system 6

 *  INFO: Installing minion

 *  INFO: Found function config_salt

 *  INFO: Found function daemons_running

 * ERROR: No dependencies installation function found. Exiting...

Error: There was a profile error: Executing the command '/tmp/.saltcloud/deploy.sh -c /tmp/.saltcloud' failed

Based on another post concerning this same error, I used yum to install redhat-lsb in the newly created AWS instance.  I then reran the deploy.sh command above and it worked fine.

Before I go and bake redhat-lsb into my base AMI, I wanted to ask if that is the only way to get around this error.

redhat-lsb installs 58 dependencies which I would rather not install in my base AMI if  I can avoid it.

Any advice?

FWIW, here is my version info:

[root@mymaster ~]# salt --versions-report

           Salt: 2014.1.0

         Python: 2.6.6 (r266:84292, Nov 22 2013, 12:16:22)

         Jinja2: 2.2.1

       M2Crypto: 0.20.2

 msgpack-python: 0.1.13

   msgpack-pure: Not Installed

       pycrypto: 2.0.1

         PyYAML: 3.10

          PyZMQ: 2.2.0.1

            ZMQ: 3.2.4

Thanks,

Steve.

[Joseph Hall]

From one point of view, this is a salt-bootstrap issue. Its job is to:

a) Detect the OS
b) Set up the necessary repos for Salt
c) Configure Salt
d) Install Salt

If you already know the OS, and you already have the necessary repos
set up, you can technically skip salt-bootstrap. In ye olde days
before that script, we had a series of OS-specific scripts that would
set up everything. They are no longer actively maintained, and may
need a little patching, but they are still available:

https://github.com/saltstack/salt/tree/develop/salt/cloud/deploy

To use one of them (or any others that you add to that directory) add
a script argument to the cloud profile:

script: RHEL6

If you don't want to muddy up your Red Hat with a bunch of unnecessary
packages (and I can't say I blame you), then this is probably more
appropriate for you.

> --
> You received this message because you are subscribed to the Google Groups
> "Salt-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to salt-users+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
"In order to create, you have to have the willingness, the desire to
be challenged, to be learning." -- Ferran Adria (speaking at Harvard,
2011)

[Steve Kirkpatrick]

Thanks for the quick reply.  You got me thinking.

I reran the deploy.sh after enabling -x so I could see what it was doing.

I noticed it was looking for some seemingly generic function names:

+ POST_FUNC_NAMES=install_system_6_stable_post

+ POST_FUNC_NAMES='install_system_6_stable_post install_system_6_stable_post'

So I looked a little higher and noticed that it found my /etc/system-release file and seemed to lock onto it rather than the /etc/centos-release file:

[root@ip-10-31-2-114 ~]# cat /etc/system-release

GHX AMI release CentOS6_Base.2014.03.14

[root@ip-10-31-2-114 ~]# cat /etc/centos-release

CentOS release 6.5 (Final)

When I removed /etc/system-release, deploy.sh ran just fine, locking in on the /etc/centos-release file.

Is there a way I should format my /etc/system-release file so as not to confuse salt-bootstrap.sh?

Thanks,

Steve.

[Pedro Algarvio]

On 15/03/14 00:18, Steve Kirkpatrick wrote:

Thanks for the quick reply.  You got me thinking.

I reran the deploy.sh after enabling -x so I could see what it was doing.

I noticed it was looking for some seemingly generic function names:

+ POST_FUNC_NAMES=install_system_6_stable_post

+ POST_FUNC_NAMES='install_system_6_stable_post install_system_6_stable_post'

So I looked a little higher and noticed that it found my /etc/system-release file and seemed to lock onto it rather than the /etc/centos-release file:

[root@ip-10-31-2-114 ~]# cat /etc/system-release

GHX AMI release CentOS6_Base.2014.03.14

[root@ip-10-31-2-114 ~]# cat /etc/centos-release

CentOS release 6.5 (Final)

When I removed /etc/system-release, deploy.sh ran just fine, locking in on the /etc/centos-release file.

Is there a way I should format my /etc/system-release file so as not to confuse salt-bootstrap.sh?

Thanks,

Steve.

Heh!

I was going to ask you for such information.

So, from what I've read, `/etc/system-release` is your doin?

Best Regards,

--

Pedro Algarvio  //  //  //  //  //  // Like my work?

[Steve Kirkpatrick]

Yep, I created the /etc/system-release for versioning purposes.  Similar to what Amazon does in their Amazon Linux AMIs.

I have control over the format so I can change to keep it from tripping up salt-bootstrap.

I was going to do more investigation on Monday to see exactly why it uses /etc/system-release rather than /etc/centos-release. 

Maybe you know?

Thanks,

Steve.

[Pedro Algarvio]

On 15/03/14 01:37, Steve Kirkpatrick wrote:

Yep, I created the /etc/system-release for versioning purposes.  Similar to what Amazon does in their Amazon Linux AMIs.

I have control over the format so I can change to keep it from tripping up salt-bootstrap.

I was going to do more investigation on Monday to see exactly why it uses /etc/system-release rather than /etc/centos-release. 

Maybe you know?

Thanks,

Steve.

We do some sorting on known release files and for some know cases, Amazon's Linux as you mentioned, we treat it as a special case, hence why we make it go first when sorting.

There's really nothing you can do besides not using "system-release" to fix your issue with salt-bootstrap. "custom-release", "distro-release", "my-release" :-)   ?