Open Stack

Sometimes there are features that require different containers to be
deployed, or different config files to be generated. These are things that
cannot be done simply through merging a fixed set of config files.
nova_compute_virt_type
is an example of such a variable - various non-config tasks depend upon it. I
guess the question is, for the supported values of kolla-ansible's
variables, should a minimal working deployment also be supported? Does this
logic inevitably lead to (1), or is it sustainable?

Mark

On 30 January 2018 at 12:54, Simon Leinen <simon.leinen at switch.ch> wrote:

> Paul Bourke writes:
> > So I think everyone is in agreement that it should be option 2. I'm
> > leaning towards this also but I'm wondering how much of this makes
> > things easier for us as developers rather than operators.
>
> > How committed this are we in practice? For example, if we take
> > nova.conf[0], if we follow option 2, theoretically all alternate
> > hypervisor options (vmware/xen/nova-fake) etc. should come out and be
> > left to override files. As should options templating options such as
> > metadata_workers, listen ports, etc. globals.yml could probably be
> > half the size it currently is. But if we go this route how many
> > operators will stick with kolla? [...]
>
> Operator here.  I've been following this discussion.  Background: We
> have been using puppet-openstack combined with our own Puppet
> "integration classes" for several years.  All configuration parameters
> are neatly in Hiera.  So we're used to the "batteries-included" way that
> Paul describes under (1).  For various reasons, we are also looking at
> new ways of provisioning our control plane, including Kolla.
>
> In hindsight, and in my personal opinion, while our previous approach
> (1) has somehow felt like the proper way to do things, it hasn't really
> paid off for us as an operator, and I would happily try approach (2).
>
> The perceived downside of (2) - or a perceived advantage of (1) - is
> that in an ideal world, (1) isolates us from the arcane configuration
> file details that the crazy devs of individual services come up with.
> In practice, it turns out that (a) those files aren't rocket science (b)
> as an operator you need to understand them anyway, at the latest when
> you need to debug stuff, and (c) the deployment tool can easily become a
> bottlenecks for deploying new features.
>
> This is why I'm happy to embrace the current Kolla philosophy (2).
> Sorry if I'm just repeating arguments that led to its adoption in the
> first place - I wasn't there when that happened.
> --
> Simon.
>
> > Maybe it won't be a big deal, the issue currently is the line is
> > blurred on what gets templated and what doesn't.
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180130/e29a1ce4/attachment.html>