Open Stack

Excerpts from Zane Bitter's message of 2014-04-16 08:39:56 -0700:
> On 16/04/14 05:53, Thomas Spatzier wrote:
> > IMO, it would be desirable to not have things like yum or apt appear in the
> > template explicitly. For many packages it seems like at least the top level
> > package names (not including distro specific versioning strings) are equal
> > across distros so when specified in a template it should be possible for a
> > software deployment hook (which can be distro specific) to figure out how
> > to install the package.
> 
> I think this thread demonstrates the opposite: package names can be 
> different even among closely-related distributions (Fedora vs. RHEL) - 
> or even versions of the same distribution (Fedora 17 vs. 18). And while 
> Ubuntu is derived from Debian (and thus most apt packages are likely to 
> share package names), there's no reason whatsoever to expect e.g. 
> OpenSUSE to have the same package names as Fedora, despite both being 
> based on RPM.
> 
> Brian Aker once suggested to me a scheme based on the path to the thing 
> you want installed: e.g. you request /usr/bin/httpd and the agent uses 
> "yum provides" or the apt equivalent to install the appropriate package. 
> That's an idea that might work better, although paths are by no means 
> standardised across distros either.

Unfortunately that won't work for Ubuntu/Debian because they have
/usr/bin/apache2. :-P

With diskimage-builder, we've just been building a map of package names
for each distro and using a script called 'install-package' to pull
in packages using a single code base. We've also considered using
bindep:

https://github.com/stackforge/bindep

But I'm not sure it will be generally consumable enough for this
purpose.

> 
> In any event, though, my impression is that we are trying to get out of 
> the cfn-init business as much as possible and leave the task to some 
> combination of custom images, software config and configuration 
> management. Hopefully someone will correct me if that impression is 
> inaccurate...
>

Right, I think that is probably the way to go long term. One large hole
that leaves is post-boot updates, because OS::Heat::CloudConfig will
only be actioned on first boot. But perhaps the right answer there is to
move to a more powerful software management tool to support that case.