<div dir="ltr"><div class="gmail_extra">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. <span style="color:rgb(36,41,46);font-family:arial,helvetica,sans-serif;font-size:12px;white-space:pre">nova_compute_virt_type is an example of such a variable - various non-config tasks depend upon it. </span>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?</div><div class="gmail_extra"><br></div><div class="gmail_extra">Mark</div><div><br><div class="gmail_quote">On 30 January 2018 at 12:54, Simon Leinen <span dir="ltr"><<a href="mailto:simon.leinen@switch.ch" target="_blank">simon.leinen@switch.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">Paul Bourke writes:<br>
> So I think everyone is in agreement that it should be option 2. I'm<br>
> leaning towards this also but I'm wondering how much of this makes<br>
> things easier for us as developers rather than operators.<br>
<br>
> How committed this are we in practice? For example, if we take<br>
> nova.conf[0], if we follow option 2, theoretically all alternate<br>
> hypervisor options (vmware/xen/nova-fake) etc. should come out and be<br>
> left to override files. As should options templating options such as<br>
> metadata_workers, listen ports, etc. globals.yml could probably be<br>
> half the size it currently is. But if we go this route how many<br>
</span>> operators will stick with kolla? [...]<br>
<br>
Operator here.  I've been following this discussion.  Background: We<br>
have been using puppet-openstack combined with our own Puppet<br>
"integration classes" for several years.  All configuration parameters<br>
are neatly in Hiera.  So we're used to the "batteries-included" way that<br>
Paul describes under (1).  For various reasons, we are also looking at<br>
new ways of provisioning our control plane, including Kolla.<br>
<br>
In hindsight, and in my personal opinion, while our previous approach<br>
(1) has somehow felt like the proper way to do things, it hasn't really<br>
paid off for us as an operator, and I would happily try approach (2).<br>
<br>
The perceived downside of (2) - or a perceived advantage of (1) - is<br>
that in an ideal world, (1) isolates us from the arcane configuration<br>
file details that the crazy devs of individual services come up with.<br>
In practice, it turns out that (a) those files aren't rocket science (b)<br>
as an operator you need to understand them anyway, at the latest when<br>
you need to debug stuff, and (c) the deployment tool can easily become a<br>
bottlenecks for deploying new features.<br>
<br>
This is why I'm happy to embrace the current Kolla philosophy (2).<br>
Sorry if I'm just repeating arguments that led to its adoption in the<br>
first place - I wasn't there when that happened.<br>
<span class="gmail-HOEnZb"><font color="#888888">--<br>
Simon.<br>
</font></span><span class="gmail-im gmail-HOEnZb"><br>
> Maybe it won't be a big deal, the issue currently is the line is<br>
> blurred on what gets templated and what doesn't.<br>
<br>
</span><div class="gmail-HOEnZb"><div class="gmail-h5">______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>