Resending with the [tripleo] tag, sorry... On Thu, Jun 29, 2017 at 2:22 PM, Ana Krivokapic <akriv...@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.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
