[openstack-dev] [TripleO] config options, defaults, oh my!

Duncan Thomas duncan.thomas at gmail.com
Wed Apr 9 18:11:06 UTC 2014


On 8 April 2014 18:25, Clint Byrum <clint at fewbar.com> wrote:
> Excerpts from Jay Dobies's message of 2014-04-08 06:40:07 -0700:

>> I've always assumed TripleO is very low-level. Put another way,
>> non-prescriptive. It's not going to push an agenda that says you should
>> be doing things a certain way, but rather gives you more than enough
>> rope to hang yourself (just makes it easier).
>>
>
> And I've always looked at TripleO as the opposite. It is a default
> deployment of OpenStack. That is why we look at having to set a
> non-default option as a bug. That is why we only currently offer one
> set of Heat templates.
>
> Of course I want to see it more widely configurable, as I understand that
> there will be whole sections of the OpenStack interested user base that
> won't want an ovs overlay network. There will be shops that simply refuse
> to use MySQL, or want to put swift proxies on their own nodes, etc. etc.
>
> But if we can't all agree on a widely usable set of defaults, and deploy
> that, then I think OpenStack, not just TripleO, is forever going to be a
> framework on which proprietary solutions are built, rather than a whole
> open source platform.

I think this is dangerous thinking - the config you want depends so
hugely on your intended workload and available hardware that trying
any strong view of what an Openstack deployment should look like into
the deployment tool forever forces that deployment tool to be a minor,
niche product that *has* to be replaced by something more expressive
in order to be widely usable. The config you want for a primary hadoop
shop is totally different to what you'd want for primary web-host shop
is somewhat different to what you'd want for a public/generic cloud,
etc. Things like AZ support, neutron model, cinder back-end choice,
H/A model etc are dictated by scale and use-cases. If you only want
your config tool to deal with one deployment type, that tool becomes
pretty much irrelevant to the totality of the Openstack effort, and
should be replaced by something more layered/openminded.

This isn't to say we must boil the ocean right now and make everything
available, but rather that decisions should take the long view into
account.



More information about the OpenStack-dev mailing list