[openstack-dev] TripleO client answers file.

Qasim Sarfraz qasims at plumgrid.com
Thu Nov 26 14:08:13 UTC 2015


Thanks Steve. Makes sense to avoid passing deployment parameters with
answer file interface Lennart proposed.

On Thu, Nov 26, 2015 at 6:42 PM, Steven Hardy <shardy at redhat.com> wrote:

> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards,
Qasim Sarfraz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151126/fd9314a9/attachment.html>


More information about the OpenStack-dev mailing list