Open Stack

On 16/04/14 21:53, Thomas Spatzier wrote:
>> From: Zane Bitter <zbitter at redhat.com>
>> To: openstack-dev at lists.openstack.org
>> Date: 16/04/2014 00:46
>> Subject: Re: [openstack-dev] [heat] computed package names?
>>
>> On 15/04/14 17:59, Mike Spreitzer wrote:
>>> Clint Byrum <clint at fewbar.com> wrote on 04/15/2014 05:17:21 PM:
>>>  > Excerpts from Zane Bitter's message of 2014-04-15 13:32:30 -0700:
>>>  >
>>>  > > FWIW, in the short term I'm not aware of any issue with installing
>>>  > > mariadb in Fedora 17/18, provided that mysql is not installed
>>> first. And
>>>  > > in fact they're both EOL anyway, so we should probably migrate all
> the
>>>  > > templates to Fedora 20 and mariadb.
>>>  >
>>>  > +1 for that.
>>>
>>> I count 22 templates in heat-templates that are written to support
>>> Fedora, Ubuntu, and RHEL; is MariaDB available in those?  I do not see
>>> it in Ubuntu 12.10, for example.
>> I imagine it's a problem for RHEL (can RHEL 7 just get released
>> already?). Ubuntu is not an issue though, unless they have adopted yum
>> while I was not looking.
>>
>> Checking a random sample, they only includes "yum" and "systemd"
>> sections (no "apt" or "sysvinit") in the metadata, so the purported
>> support for Ubuntu 10.04 is just due to copy-paste and isn't actually
>> implemented.
> 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.
>
Using software-config plus provider templates plus environments it is
possible to write templates which are completely distro (and config
method) agnostic. A separate environment file can be provided for every
desired distro+config which defines resource types for the boot config
and deployment config resources. The result is very tidy and maintainable.