[openstack-dev] [TripleO] config options, defaults, oh my!
Alexis Lee
alexisl at hp.com
Fri Apr 11 09:01:37 UTC 2014
Clint Byrum said on Thu, Apr 10, 2014 at 09:45:17AM -0700:
> > Now you've described it, you're right, I'm not interested in TripleO or
> > TripleO milestones. I am interested in using os-*-config, Heat and
> > tripleo-image-elements to produce pure OpenStack deployments from 3 to
> > 3000 nodes, for varying workloads.
>
> That is precisely what TripleO wants as that first milestone too. What
> is the difference between what I said we want (a default OpenStack
> deployment) and what you just said (a "pure" OpenStack deployment)? At
> what point did anybody suggest to you that TripleO doesn't want a highly
> scalable deployment of OpenStack?
>
> I'm not sure why you wouldn't just put the configuration you need
> in the upstream TripleO as the default configuration. Even more, why
> wouldn't you put these configurations in as the defaults for upstream
> Nova/Glance/Cinder/Neutron/etc?
The trouble is there can only be one default configuration, whereas
there are many potential kinds of deployment. If the default deployment
is highly scalable, it will need a minimum number of nodes to start up.
EG a highly scalable Logstash infrastructure requires at least 8 nodes
to itself before you add any compute nodes. This won't be useful to
those who want to start with a trial deployment and scale up from there.
I like your Heat idea very much, where the user can easily supply whole
files or filesets. This allows the user to choose:
1) What software is installed on which nodes, by element composition
2) The contents of configuration files, by Heat passthrough of a fileset
3) Per-instance variables plus a few tweak-prone knobs, via Heat
parameters
Thus we don't have to enshrine a single configuration or add a Heat
parameter for every single config option. And TripleO can publish at
first one but later several "default Openstack deployments", each
suitable for a different scale.
Alexis
--
Nova Engineer, HP Cloud. AKA lealexis, lxsli.
More information about the OpenStack-dev
mailing list