Open Stack

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