LBaaS. Adding member(s) to a pool. All members have the same weight.

Bug #1234688 reported by Avishay Balderman
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Neutron LBaaS Dashboard
In Progress
Low
Unassigned

Bug Description

When the user wants to add 1 or more members to a Pool he needs to specify a 'weight'.
As far as I understand each Member should get its own weight.
But with the current UI implementation it is not possible.
Example:
The user checks 3 servers to be used as members. Servsers A,BC
Now he needs to add the weight. At this point he must insert a weight value that will affect all servers.
The user should be able to set the following: (Example)
Server A -- weight = 3
Server B -- weight = 5
Server C -- weight = 1

The same is relevant for 'Protocol Port'

Tags: lbaas neutron
Revision history for this message
Akihiro Motoki (amotoki) wrote :

AFAIK, we can't add members with different weight or protocol port in a single form.
To add member(s) with different weight, we need to visit multiple times per weight.

It is better to be improved from the UX perspective, but it is not a blocking issue.

Changed in horizon:
milestone: none → icehouse-1
importance: Undecided → Low
status: New → Confirmed
David Lyle (david-lyle)
Changed in horizon:
milestone: icehouse-1 → icehouse-2
Changed in horizon:
assignee: nobody → Andres Buraschi (andres-buraschi)
Revision history for this message
Andres Buraschi (andres-buraschi) wrote :

Hi, after struggling with MultiWidgets unsuccessfully trying to implement a decent widget to achieve this behavior, I thought of adding at least some convenient information in the UI.
Specifically:
1) Adding a tool tip to indicate that the weight provided in the 'Add Member' dialog will be used for all selected members and further edition is possible to correctly set the the load balance.
2) Adding the 'Weight' column in the summary tab to easily identify the weights to be updated in a 'second pass'.

I'll be providing a 'partial fix' with these improvements for review.

Regards.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to horizon (master)

Fix proposed to branch: master
Review: https://review.openstack.org/65407

Changed in horizon:
status: Confirmed → In Progress
David Lyle (david-lyle)
Changed in horizon:
milestone: icehouse-2 → icehouse-3
Thierry Carrez (ttx)
Changed in horizon:
milestone: icehouse-3 → icehouse-rc1
David Lyle (david-lyle)
Changed in horizon:
milestone: icehouse-rc1 → next
Revision history for this message
Andres Buraschi (andres-buraschi) wrote :

Adding i18n tag (as suggested) as the proposed patch includes several tool tip (help text) messages:
https://review.openstack.org/#/c/65407/

tags: added: i18n
Revision history for this message
Akihiro Motoki (amotoki) wrote :

Do we need to add I18N tag for all patches including string change?
If so, all blueprints and a big bug fixes will be tagged as I18N. What is the criteria?

Revision history for this message
Andres Buraschi (andres-buraschi) wrote :

That is a good question. I would say no. But on the other hand, I've been encouraged to include a translation review on the mentioned patch because of the length of the proposed change. Any thoughts? I would like to hear opinions on the procedure too.

Regards.

Akihiro Motoki (amotoki)
tags: removed: lbaas
Revision history for this message
Akihiro Motoki (amotoki) wrote :

Good point. I agree that we need a way to track patches which contain string changes in the last moment of a release. IMO it is better to introduce a new official tag to indicate string changes: string-change, translation-affected, i18n-affected?
This tag would be useful for limited period, so I would like to use another tag.

Note that "I18N" tag is usually used to track I18N related issue: cannot translate, hard to translated, not marked as translatable.

Revision history for this message
Akihiro Motoki (amotoki) wrote :

It seems that the proposed patch itself fits Juno-1 and it can be backported if useful.

We don't have explicit criteria with backport string changes so far. I believe it can be accepted if it is useful from UX perspective.

Revision history for this message
Andres Buraschi (andres-buraschi) wrote :

+1 to the string change indicator tag. Thanks for the time to analyze this, Akihiro. I agree to remove the i18n tag, given the above explanation.

tags: added: lbaas
removed: i18n
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to horizon (master)

Reviewed: https://review.openstack.org/65407
Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=d22e81efdc99f7bb8ebd9e99e0eebfe1bf5a9a43
Submitter: Jenkins
Branch: master

commit d22e81efdc99f7bb8ebd9e99e0eebfe1bf5a9a43
Author: Andres Buraschi <email address hidden>
Date: Tue Jan 7 23:44:16 2014 -0300

    Friendlier information for lbaas members creation

    In order to improve the user experience when adding new members to a
    lbass pool, the help information shown in the 'Add Member' dialog has
    been completed. Now, it explains that all selected members get the same
    weight and port, and that later update is possible to achieve the
    expected configuration.
    In addition, the 'Weight' column has been added to the Member summary
    tab, in order to easily identify the results of the performed 'Add
    Member' action.
    The complete fix would implement a more efficient way (through custom
    widgets, perhaps) to select weight and port per instance.

    Change-Id: If9a3ea6d36741fb1ca1ae06fb2dd307a78f537de
    Partial-Bug: #1234688

Revision history for this message
Akihiro Motoki (amotoki) wrote :

I am not sure what is remaining, but anyway LBaaS dashboard has been moved to neutron-lbaas-dashboard, so let's forward it.

affects: horizon → neutron-lbaas-dashboard
Changed in neutron-lbaas-dashboard:
milestone: next → none
assignee: Andres Buraschi (andres-buraschi) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.