Open Stack

On 11/10/2017 03:20 AM, Giulio Fidente wrote:
> On 11/26/2015 03:17 PM, Jiří Stránský wrote:
>> On 26.11.2015 14:12, Jiří Stránský wrote:
> 
> [...]
> 
>>> It seems TripleO is hitting similar composability and sanity limits with
>>> the top-down approach, and the number of parameters which can only be
>>> fed via parameter_defaults is increasing. (The disadvantage of
>>> parameter_defaults is that, unlike hiera, we currently have no clear
>>> namespacing rules, which means a higher chance of conflict. Perhaps the
>>> unit tests suggested in another subthread would be a good start, maybe
>>> we could even think about how to do proper namespacing.)
>>>
>>>
>>> Does what i described seem somewhat accurate? Should we maybe buy into
>>> the concept of "composable templates, externally fed
>>> hierarchy-transcending parameters" for the long term?
>>
>> I now realized i might have used too generic or Puppetish terms in the
>> explanation, perhaps drowning the gist of the message a bit :) What i'm
>> suggesting is: let's consider going with parameter_defaults wherever we
>> can, for the sake of composability, and figure out what is the best way
>> to prevent parameter name collisions.
> +1 I like very much the idea of parameter_defaults + strictier
> namespacing rules
> 
> Specifically regarding namespaces, puppet was great but ansible doesn't
> seem to be as good (at least to me), in fact I think we have chances for
> conflicts in both THT and the ansible playbooks
> 

I will point out that we now have a pep8 check that all definitions of a 
parameter have the exact same type, description, and default.  That 
makes it highly unlikely that someone would duplicate a parameter name 
but want to use it for something different from the original.

There are a few exclusions remaining so it's possible those could still 
get duplicated, but they're pretty specific (it only ignores certain 
fields on the listed parameters) so it's not a high likelihood.

It would be good if somebody would clean up the remaining 
inconsistencies in tht so we can validate as many parameters as 
possible.  There are some I'm not sure we can change that this point 
because it would affect users if we did, but there are quite a few that 
I think we can still address: 
https://github.com/openstack/tripleo-heat-templates/blob/master/tools/yaml-validate.py#L62 
  Everything below the TODO still needs to be looked at.  In a lot of 
cases it's just a question of making the descriptions consistent across 
all of the definitions.