Open Stack

Resending with the [tripleo] tag, sorry...

On Thu, Jun 29, 2017 at 2:22 PM, Ana Krivokapic <akrivoka at redhat.com> wrote:

> Hi TripleO devs,
>
> I am working on adding a description field to the "Crate Plan" form in the
> TripleO UI [1]. The goal is to make it possible for the user to specify a
> plan description using a form field when creating a plan. As the plan
> description lives in the plan-environment.yaml file[2], the idea is to
> retrieve this value from plan-environment.yaml when the user uploads the
> plan, populate the form field with it, let the user change it, and then
> save it back to the file.
>
> I have a WIP patch up [3] which solves the issue in the case of uploading
> the plan as a folder. However, I am having a hard time solving the case of
> uploading the plan as a tarball. The issue is obviously with accessing the
> contents of the tarball. Here are some possible approaches that come to
> mind:
>
> 1) Use one of the existing third-party JS libraries that can extract a
> tarball in the browser. Pros: front-end only solution, no need for
> additional API calls, no need for back-end changes. Cons: adding a new
> dependency, these libraries don't seem much maintained.
>
> 2) Use swift to upload and extract the tarball. Pros: no need for back-end
> changes, we can just call the swift API. Cons: splitting the tarball upload
> from plan creation, which should really be one atomic operation.
>
> 3) Modify the plan create workflow to accept a plan description as a
> parameter. Pros: keeps plan creation atomic. Cons: changes to the plan
> create workflow interface needed. Also this way there is no way to send
> back the information about the description to the UI, we would have to just
> accept the value of the form field, and overwrite whatever was in the
> plan-environment.yaml file.
>
> Of course there is also a fourth option:
>
> 4) This is not worth the effort to implement and we should just drop it. :)
>
> My personal opinion is that the cons of 1) and 2) make these approaches
> unacceptable. The cons of 3) make it kind of not worth it - seems like a
> lot of work for a partial solution. So I'm leaning towards 4) at the moment.
>
> I'd like to hear your opinions on this, is there a another/better approach
> that I'm missing? Jirka, you mentioned we could postpone this work to the
> next cycle and there are improvements that we can work on in the meantime
> which would make implementation of this feature easier?
>
> Any and all thoughts, comments, opinions are welcome.
>
> [1] https://bugs.launchpad.net/tripleo/+bug/1698818
> [2] https://github.com/openstack/tripleo-heat-templates/blob/master/plan-
> environment.yaml#L4-L5
> [3] https://review.openstack.org/#/c/477536/
>
> --
> Regards,
> Ana Krivokapic
> Senior Software Engineer
> OpenStack team
> Red Hat Inc.
>



-- 
Regards,
Ana Krivokapic
Senior Software Engineer
OpenStack team
Red Hat Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170629/bcb9f6b5/attachment.html>