On 04/16/2014 09:24 AM, Fox, Kevin M wrote:
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
Kevin,
There is a review in progress:
https://review.openstack.org/#/c/84468/
butter up some popcorn and enjoy :)
Regards
-steve
________________________________________
From: Zane Bitter [zbit...@redhat.com]
Sent: Wednesday, April 16, 2014 8:39 AM
To: openstack-dev@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
