[openstack-dev] [neutron][taas] Proposal of Dashboard for TaaS

Soichi Shigeta shigeta.soichi at jp.fujitsu.com
Wed Mar 16 03:30:09 UTC 2016


  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
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: DashboardForTaaS_20160316-01.pdf
Type: application/pdf
Size: 251639 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160316/ef7f0e55/attachment-0001.pdf>


More information about the OpenStack-dev mailing list