Open Stack

Different distro's move the binaries and services too. ubuntu/debian does:
/usr/sbin/apache2, not httpd. The service is also named apache2, not httpd.

So, I think distro specific sets of packages are somewhat unavoidable.

Now, this use case might be a good case for supporting:
https://blueprints.launchpad.net/heat/+spec/intrinsics
https://blueprints.launchpad.net/heat/+spec/aws-novalue

Amazon finally caved in and implemented these. I think heat needs them too.

Is it possible to implement those with the new plugin function framework? If so, I might be willing to take a stab at it if I can find a bit of time.

Thanks,
Kevin


________________________________________
From: Zane Bitter [zbitter at redhat.com]
Sent: Wednesday, April 16, 2014 8:39 AM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [heat] computed package names?

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.

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...

cheers,
Zane.

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev