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-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

Reply via email to