Open Stack

Hello Everybody,

The #openstack-ux project specifically has been setup to help with user experience designs.

We use a tool called invision [0] 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. [1]

[0] https://openstack.invisionapp.com/d/main#/projects
[1]

From Piet:
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
company.

Phabricator Pholio
http://phacility.com/phabricator/pholio/

Review board
https://www.reviewboard.org/



Thanks,
Travis




On 3/15/16, 9:30 PM, "Soichi Shigeta" <shigeta.soichi at jp.fujitsu.com> wrote:

>
>  Hi,
>
>      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.
>
>    Regards,
>    Soichi
>
>>
>>   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
>>     list.
>>
>>
>>> 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
>>       here.
>>
>>     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
>>     shown.
>>
>>
>>> 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.
>>
>>
>>     Regards,
>>     Soichi
>>
>>
>>> Regards,
>>> Anil
>>>
>>>
>>>
>>> __________________________________________________________________________
>>>
>>> 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
>>>
>>
>>
>>
>> __________________________________________________________________________
>> 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
>>
>