Open Stack

On 29.6.2017 23:28, Ben Nemec wrote:
>
>
> 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 <akrivoka at redhat.com
>> <mailto: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. :)
>
> 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.


I've taken a look into how the plan creation actually works and here are 
the outcomes:

There are 3 ways to create a plan using plan creation mistral workflow:
1. Create plan from default templates in undercloud machine
2. Create plan from Swift container
3. Create plan from git repository

TripleO UI currently only uses second option and it provides user to do 
it 2 ways:
1. Upload via directory (Chrome browser only)
2. Upload tarball

In both cases, the mistral workflow expects the Swift container to be 
created before the workflow is triggered. TripleO UI now does it as a 
single chain of API calls - call Swift API to create container and 
upload files, call Mistral to run the plan creation workflow. So in 
theory we could split this in UI into a wizard, where once the files are 
in place in swift, we could reach for plan-environment.yaml and let the 
user set the description. Once that is done user can continue with 
triggering the mistral workflow in wizard.

Problem with this is that this solution would not support options 1. and 
3. which we'd like to integrate in TripleO UI too. So alternatively, we 
can turn the Plan creation dialog into a wizard which first creates the 
plan (swift uploads if needed, run plan creation workflow) and when 
succeeds, wizards provides user to edit plan description which would 
finalize the plan creation wizard.

The same approach could be used for plan update and plan export.

I think this discussion is a nice start for Queens spec/blueprint which 
introduces additional plan creation options and description editting in 
TripleO UI.

-- Jirka

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