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. _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
