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.lei...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev