Open Stack

  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
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: DashboardForTaaS_20160315-01.pdf
Type: application/pdf
Size: 286091 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160315/5f7d282c/attachment-0001.pdf>