[openstack-dev] [Horizon] [TripleO] [Tuskar] Thoughts on editing node profiles (aka flavors in Tuskar UI)

Jay Dobies jason.dobies at redhat.com
Thu Feb 20 13:50:52 UTC 2014



On 02/20/2014 06:40 AM, Dmitry Tantsur wrote:
> Hi.
>
> While implementing CRUD operations for node profiles in Tuskar (which
> are essentially Nova flavors renamed) I encountered editing of flavors
> and I have some doubts about it.
>
> Editing of nova flavors in Horizon is implemented as
> deleting-then-creating with a _new_ flavor ID.
> For us it essentially means that all links to flavor/profile (e.g. from
> overcloud role) will become broken. We had the following proposals:
> - Update links automatically after editing by e.g. fetching all
> overcloud roles and fixing flavor ID. Poses risk of race conditions with
> concurrent editing of either node profiles or overcloud roles.
>    Even worse, are we sure that user really wants overcloud roles to be
> updated?

This is a big question. Editing has always been a complicated concept in 
Tuskar. How soon do you want the effects of the edit to be made live? 
Should it only apply to future creations or should it be applied to 
anything running off the old configuration? What's the policy on how to 
apply that (canary v. the-other-one-i-cant-remember-the-name-for v. 
something else)?

> - The same as previous but with confirmation from user. Also risk of
> race conditions.
> - Do not update links. User may be confused: operation called "edit"
> should not delete anything, nor is it supposed to invalidate links. One
> of the ideas was to show also deleted flavors/profiles in a separate
> table.
> - Implement clone operation instead of editing. Shows user a creation
> form with data prefilled from original profile. Original profile will
> stay and should be deleted manually. All links also have to be updated
> manually.
> - Do not implement editing, only creating and deleting (that's what I
> did for now in https://review.openstack.org/#/c/73576/ ).

I'm +1 on not implementing editing. It's why we wanted to standardize on 
a single flavor for Icehouse in the first place, the use cases around 
editing or multiple flavors are very complicated.

> Any ideas on what to do?
>
> Thanks in advance,
> Dmitry Tantsur
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



More information about the OpenStack-dev mailing list