On Thu, Nov 26, 2015 at 06:01:31PM +0500, Qasim Sarfraz wrote: > +1. That would be really helpful. > What about passing other deployment parameters via answers.yaml ? For > example, compute-flavor, control-flavor etc
So, I think the main reason to avoid this, is that long term it would be best to deprecate/remove all those hard-coded parameter options (like control-flavor etc). The reason for saying this is --control-flavor is mapped inside tripleoclient to a hard-coded parameter name (OvercloudControlFlavor): https://github.com/openstack/python-tripleoclient/blob/master/tripleoclient/v1/overcloud_deploy.py#L111 This is both fragile (coupling between the tripleo-heat-templates and python-tripleoclient), and inflexible (any new options have to be added to tripleoclient if we want a consistent interface). With the benefit of hindsight, IMHO, it was a mistake to expose these explicit parameter options in the CLI, instead we should be defining the parameters directly in environment files. For example: openstack overcloud deploy --templates -e my_flavors.yaml Where my_flavors.yaml looks like: parameters: OvercloudControlFlavor: overcloud-special OvercloudComputeFlavor: overcloud-special This still works with the answer file interface Lennart is proposing, e.g you just add my_flavors to the environments list, but it avoids hard-coded coupling between tripleoclient and tripleo-heat-templates, which should make maintenance easier in the long term, and allow better flexibilty for operators who which to customize the templates with alternative parameters. Does that sound reasonable? Thanks, Steve __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
