[openstack-dev] [neutron][taas] [ux] Proposal of Dashboard for TaaS
Tripp, Travis S
travis.tripp at hpe.com
Wed Mar 16 03:56:50 UTC 2016
The #openstack-ux project specifically has been setup to help with user experience designs.
We use a tool called invision  for visual design commenting and interactions. In addition,
The UX repo has been setup to help facilitate this process and Piet (the PTL) is looking
Into OpenSource opportunities. 
MOCK REVIEW TOOLS
There has been some discussion around replacing Invision because of the
speed, not being open source, etc. I was hoping you could take a look at
a couple of alternatives.
To set expectations, it will need to be an open source project and be
hosted by either the OpenStack Infrastructure project or a specific
On 3/15/16, 9:30 PM, "Soichi Shigeta" <shigeta.soichi at jp.fujitsu.com> wrote:
> Please find attached file.
> Yet another design of the Network Topology Tab.
> # I couldn't upload pdf files to the Wiki.
> When I tried, a message ".pdf file is not permitted"
> was shown.
>> Hi Anil, and folks,
>> Thank you for your comments.
>>> Thanks Soichi and Kaz for your work on implementing Horizon
>>> (dashboard) support for TaaS. The proposal (with screen shots)
>>> discussed in our recent IRC meeting look very nice. Here are some
>>> additional suggestions for improvement.
>>> 1. General
>>> a. When a port is being selected (for a tap-service instance or
>>> a tap-flow) it would be nice to also provide some extra information
>>> associated with that port, such as the VM it belongs to and the IP
>>> address. This will look very similar to what is being done today when
>>> associating a floating IP with a VM vNIC. The extra context will allow
>>> users to identify their source and destination end-points with more
>>> ease. If a VM is not currently associated with a port then the extra
>>> information is not necessary.
>> I agree with you.
>> It is difficult for users to select an appropriate port
>> by seeing only uuid.
>> I didn't explain in the submitted document, in the current
>> implementation, not only uuid but also name is also shown
>> if a port is given a name.
>> I agree to show IP address.
>> i.e., name, uuid, and IP address are shown for each port.
>> Please refer p.1 of the attached file.
>> On the other hand, in terms of modification cost, I'd like
>> to disagree to show associated VM.
>> Because Neutron doesn't know association between a port and
>> a VM, we need to send a query to Nova.
>> Of course, I agree to implement this if requested from field.
>>> b. When selecting the traffic monitoring direction, it would be
>>> nice to provide two check boxes, one for 'ingress' and the other for
>>> 'egress'. A user wishing to monitor a port in both directions can
>>> select both check boxes. I feel this looks better than having an
>>> option called 'both'.
>> In terms of consistency with the option in CLI, I prefer to
>> chose one of the both/ingress/egress from pull down menu.
>> To avoid confusions, it had better to say something like
>> "ingress (to instance)" and "egress (from instance)".
>>> 2. Using the Tap Services Tab
>>> a. Allow tap-flow-create and tap-flow-delete operations to also
>>> be carried out from here. This will let users who prefer working in
>>> this fashion get everything done from the same place.
>> I will plan to add "tap-flow-create" and "tap-flow-delete" button
>> on the tap-service tab.
>> But, I'm afraid that a lot of ports will be listed as candidates
>> when a user starts tap-flow-create from here.
>> Because no instance (VM) is selected here, we can not filter to
>>> b. Provide a way to list tap flows currently associated with a
>>> tap service.
>> Excuse me, I didn't mention about it on the submitted document.
>> This is done on the overview of a tap-service.
>> Please refer p.2 of the attached file.
>>> c. Allow multiple tap-flows to be created at the same time. Let
>>> the user pick multiple source ports (and traffic monitoring
>>> directions) and have all of them attached to a designated tap-service.
>> I'd like to consider this in the future.
>> Because it seems taking larger man-hour cost to realize.
>> (consideration with man-hour we have)
>> Additionally, I think we need to take care of error cases
>> such as a part of tap-flow creation failed.
>>> 3. Using the Network Topology Tab
>>> a. Allow tap-create and tap-delete operations to be also carried
>>> out from here. This will allow users who prefer working in this
>>> fashion get everything done from the same place. The user can pick the
>>> destination port (from one of the existing VMs) in the same way that a
>>> source port is picked when creating a tap-flow.
>> Yes, I think this is a good idea.
>> I will plan to add "tap-flow-create" and "tap-flow-delete" buttons
>> on the Network Topology tab.
>> # As mentioned in 2-a., I'm afraid that a lot of ports will be
>> listed as candidates when a user starts tap-flow-create from
>> Actually, I want to add "tap-flow-create" and "tap-flow-delete"
>> button on the pop up window that is shown when mouse cursor on
>> an instance.
>> Please refer p.3 of the attached file.
>> But, currently very limited buttons are existing on the window.
>> I think we need to discuss with Horizon and Nova team if we want
>> to add buttons for tap-flow operations.
>> I'm afraid that other operations (such as "create snapshot",
>> "associate floating IP", and so on) have higher priority to be
>>> b. Color code the VM whose vNIC is attached to the destination
>>> port of a tap-service.
>> I agree.
>> I made such an instance is colored light-blue.
>> Please refer p.4 of the attached file.
>>> c. BONUS: Allow the user to click on a VM that is serving as the
>>> destination side of a tap-service and highlight all the VMs that are
>>> attached to tap-flows associated with that tap-service.
>> I think this is very nice to have, too.
>> But it seems hard to implement.
>> So, I'd like to try to this in the future.
>>> OpenStack Development Mailing List (not for usage questions)
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev