<div dir="ltr">Thanks Steve. Makes sense to avoid passing deployment parameters with answer file interface Lennart proposed. </div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 26, 2015 at 6:42 PM, Steven Hardy <span dir="ltr"><<a href="mailto:shardy@redhat.com" target="_blank">shardy@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Nov 26, 2015 at 06:01:31PM +0500, Qasim Sarfraz wrote:<br>
>    +1. That would be really helpful. <br>
>    What about passing other deployment parameters via answers.yaml ?  For<br>
>    example, compute-flavor, control-flavor etc<br>
<br>
So, I think the main reason to avoid this, is that long term it would be<br>
best to deprecate/remove all those hard-coded parameter options (like<br>
control-flavor etc).<br>
<br>
The reason for saying this is --control-flavor is mapped inside<br>
tripleoclient to a hard-coded parameter name (OvercloudControlFlavor):<br>
<br>
<a href="https://github.com/openstack/python-tripleoclient/blob/master/tripleoclient/v1/overcloud_deploy.py#L111" rel="noreferrer" target="_blank">https://github.com/openstack/python-tripleoclient/blob/master/tripleoclient/v1/overcloud_deploy.py#L111</a><br>
<br>
This is both fragile (coupling between the tripleo-heat-templates and<br>
python-tripleoclient), and inflexible (any new options have to be added to<br>
tripleoclient if we want a consistent interface).<br>
<br>
With the benefit of hindsight, IMHO, it was a mistake to expose these<br>
explicit parameter options in the CLI, instead we should be defining the<br>
parameters directly in environment files.<br>
<br>
For example:<br>
<br>
openstack overcloud deploy --templates -e my_flavors.yaml<br>
<br>
Where my_flavors.yaml looks like:<br>
<br>
parameters:<br>
  OvercloudControlFlavor: overcloud-special<br>
  OvercloudComputeFlavor: overcloud-special<br>
<br>
This still works with the answer file interface Lennart is proposing, e.g<br>
you just add my_flavors to the environments list, but it avoids hard-coded<br>
coupling between tripleoclient and tripleo-heat-templates, which should<br>
make maintenance easier in the long term, and allow better flexibilty for<br>
operators who which to customize the templates with alternative parameters.<br>
<br>
Does that sound reasonable?<br>
<br>
Thanks,<br>
<br>
Steve<br>
<div class="HOEnZb"><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Regards,<div>Qasim Sarfraz</div></div></div>
</div>