Open Stack

may be we could move those specific options / templates to sample 
overrides? Operators would move necessary pieces back to 
/etc/kolla/config . Just thinking of config plug-ins / third-party 
supported things.

Thanks,
Vlad

On 01/30/2018 01:46 PM, Paul Bourke wrote:
> 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? Maybe it won't be a big deal, the 
> issue currently is the line is blurred on what gets templated and what 
> doesn't.
>
> On 30/01/18 01:04, Michał Jastrzębski wrote:
>> Hey,
>>
>> So I'm also for option 2. There was big discussion in Atlanta about
>> "how hard it is to keep configs up to date and remove deprecated
>> options". merge_config makes it easier for us to handle this. With
>> amount of services we support I don't think we have enough time to
>> keep tabs on every config change across OpenStack.
>>
>> On 29 January 2018 at 08:03, Steven Dake (stdake) <stdake at cisco.com> 
>> wrote:
>>> Agree, the “why” of this policy is stated here:
>>>
>>> https://docs.openstack.org/developer/kolla-ansible/deployment-philosophy.html 
>>>
>>>
>>>
>>>
>>> Paul, I think your corrective actions sound good.  Perhaps we should 
>>> also
>>> reword “essential” to some other word that is more lenient.
>>>
>>>
>>>
>>> Cheers
>>>
>>> -steve
>>>
>>>
>>>
>>> From: Jeffrey Zhang <zhang.lei.fly at gmail.com>
>>> Reply-To: "OpenStack Development Mailing List (not for usage 
>>> questions)"
>>> <openstack-dev at lists.openstack.org>
>>> Date: Monday, January 29, 2018 at 7:14 AM
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>> <openstack-dev at lists.openstack.org>
>>> Subject: Re: [openstack-dev] [kolla] Policy regarding template 
>>> customisation
>>>
>>>
>>>
>>> Thank Paul for pointing this out.
>>>
>>>
>>>
>>> for me, I prefer to consist with 2)
>>>
>>>
>>>
>>> There are thousands of configuration in OpenStack, it is hard for 
>>> Kolla to
>>>
>>> add every key/value pair in playbooks. Currently, the merge_config 
>>> is a more
>>>
>>> better solutions.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Jan 29, 2018 at 7:13 PM, Paul Bourke 
>>> <paul.bourke at oracle.com> wrote:
>>>
>>> Hi all,
>>>
>>> I'd like to revisit our policy of not templating everything in
>>> kolla-ansible's template files. This is a policy that was set in 
>>> place very
>>> early on in kolla-ansible's development, but I'm concerned we 
>>> haven't been
>>> very consistent with it. This leads to confusion for contributors and
>>> operators - "should I template this and submit a patch, or do I need to
>>> start using my own config files?".
>>>
>>> The docs[0] are currently clear:
>>>
>>> "The Kolla upstream community does not want to place key/value pairs 
>>> in the
>>> Ansible playbook configuration options that are not essential to 
>>> obtaining a
>>> functional deployment."
>>>
>>> In practice though our templates contain many options that are not
>>> necessary, and plenty of patches have merged that while very useful to
>>> operators, are not necessary to an 'out of the box' deployment.
>>>
>>> So I'd like us to revisit the questions:
>>>
>>> 1) Is kolla-ansible attempting to be a 'batteries included' tool, which
>>> caters to operators via key/value config options?
>>>
>>> 2) Or, is it to be a solid reference implementation, where any 
>>> degree of
>>> customisation implies a clear 'bring your own configs' type policy.
>>>
>>> If 1), then we should potentially:
>>>
>>> * Update ours docs to remove the referenced paragraph
>>> * Look at reorganising files like globals.yml into something more
>>> maintainable.
>>>
>>> If 2),
>>>
>>> * We should make it clear to reviewers that patches templating 
>>> options that
>>> are non essential should not be accepted.
>>> * Encourage patches to strip down existing config files to an absolute
>>> minimum.
>>> * Make this policy more clear in docs / templates to avoid 
>>> frustration on
>>> the part of operators.
>>>
>>> Thoughts?
>>>
>>> Thanks,
>>> -Paul
>>>
>>> [0]
>>> https://docs.openstack.org/kolla-ansible/latest/admin/deployment-philosophy.html#why-not-template-customization 
>>>
>>>
>>> __________________________________________________________________________ 
>>>
>>> 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
>>>
>>>
>>>
>>>
>>>
>>> -- 
>>>
>>> Regards,
>>>
>>> Jeffrey Zhang
>>>
>>> Blog: http://xcodest.me
>>>
>>>
>>> __________________________________________________________________________ 
>>>
>>> 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
>>>
>>
>> __________________________________________________________________________ 
>>
>> 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
>>
>
> __________________________________________________________________________ 
>
> 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