Just to make sure you're aware of that - there is this new Curvature Network Topology view since Liberty [1]. Maybe you want to integrate with it as well...
[1] https://www.openstack.org/software/liberty/ -- ----- Andreas (IRC: scheuran) On Mi, 2016-03-16 at 12:30 +0900, Soichi Shigeta 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: > >> [email protected]?subject:unsubscribe > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > > > > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: [email protected]?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
