Open Stack

I like where this is going. I've been asked a number of times where to 
put things and we never had a solid convention. I like the idea of 
having that docced somewhere.

I like either of the proposed solutions. My biggest concern is that they 
don't capture how you actually use them. I know that was the point of 
your e-mail; we don't yet have the Heat constructs in place for the 
templates to convey that information.

What about if we adopt the directory structure model and strongly 
request a README.md file in there? It's similar to the image elements 
model. We could offer a template to fill out or leave it open ended, but 
the purpose would be to specify:

- Installation instructions (e.g. "set the resource registry namespace 
for Blah to point to this file" or "use the corresponding environment 
file foo.yaml")
- Parameters that can/should be specified via parameter_defaults. I'm 
not saying we add a ton of documentation in there that would be 
duplicate of the actual parameter definitions, but perhaps just a list 
of the parameter names. That way, a user can have an idea of what 
specifically to look for in the template parameter list itself.

That should be all of the info that we'd like Heat to eventually provide 
and hold us over until those discussions are finished.

On 09/08/2015 08:20 AM, Jiří Stránský wrote:
> On 8.9.2015 13:47, Jiří Stránský wrote:
>> Apart from "cinder" and "neutron-ml2" directories, we could also have a
>> "combined" (or sth similar) directory for env files which combine
>> multiple other env files. The use case which i see is for extra
>> pre-deployment configs which would be commonly used together. E.g.
>> combining Neutron and Horizon extensions of a single vendor [4].
>
> Ah i mixed up two things in this paragraph -- env files vs. extraconfig
> nested stacks. Not sure if we want to start namespacing the extraconfig
> bits in a parallel manner. E.g.
> "puppet/extraconfig/pre_deploy/controller/cinder",
> "puppet/extraconfig/pre_deploy/controller/neutron-ml2". It would be
> nice, especially if we're sort of able to map the extraconfig categories
> to env file categories most of the time. OTOH the directory nesting is
> getting quite deep there :)

That was my thought too, that the nesting is getting a bit deep. I also 
don't think we should enforce the role in the directory structure as 
we've already seen instances of things that have to happen on both 
controller and compute.


> J.
>
>> [4]
>> https://review.openstack.org/#/c/213142/1/puppet/extraconfig/pre_deploy/controller/all-bigswitch.yaml
>>
>
>
> __________________________________________________________________________
> 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