On 06/29/2017 07:25 AM, Ana Krivokapic wrote:
Resending with the [tripleo] tag, sorry...

On Thu, Jun 29, 2017 at 2:22 PM, Ana Krivokapic <akriv...@redhat.com
<mailto: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. :)

So the user can update the description after the initial upload, right? I wouldn't have a huge problem with just saying that you don't get the description box pre-populated if you upload a binary format like tar. It's not quite as ideal, but as long as there is some way to set the description at some point in the process it should be fine until/unless we decide to pursue a more complicated solution.


    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
    <https://bugs.launchpad.net/tripleo/+bug/1698818>
    [2] 
https://github.com/openstack/tripleo-heat-templates/blob/master/plan-environment.yaml#L4-L5
    
<https://github.com/openstack/tripleo-heat-templates/blob/master/plan-environment.yaml#L4-L5>
    [3] https://review.openstack.org/#/c/477536/
    <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


__________________________________________________________________________
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

Reply via email to