Open Stack

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:
> >> 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
> >
> 
> __________________________________________________________________________
> 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