Open Stack

Hi, Manuel.

Thank you for your comments.

> since you introduce switches that are currently not reflected in the Neutron entities, am I correct that a switch.port is always unknown to Neutron? Can a switch.port ever be a VM port?

Yes, Neutron doesn't know a switch.port. A switch.port is related to physical and virtual switch's port. Those are not managed by Neutron.

You can know VM is connected to a switch.port, if SDN controller manages switch that is connected to VM(e.g. br-int in the compute-node).
If SDN controller doesn't manage, you can't know that.

In specification of this BP, Server, VM and Switch's Mac address and IP address will be included in the resource metadata on a switch.port, if those are connected to switch.
But, this is recommend, not requirement.

I am making OpenDaylight Implementation, that supports this.

Thanks.
> Yuuichi,
> 
> since you introduce switches that are currently not reflected in the Neutron entities, am I correct that a switch.port is always unknown to Neutron? Can a switch.port ever be a VM port?
> 
> I'd be happy if you could help me understand this better.
> 
> Best, Manuel
> ________________________________________
> From: Yuuichi Fujioka [fujioka-yuuichi at zx.mxh.nes.nec.co.jp]
> Sent: Wednesday, December 11, 2013 8:25 AM
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [Ceilometer] RFC: blueprint monitoring-network
> 
> Hi, Ceilometer team.
> 
> We have posted 2 blueprints.[1][2]
> 
> This feature collects the network information(device, link status, statistics) via NorthBound API from SDN Controller.
> The purpose of this feature is testing network route, resource optimization based on network proximity and etc.
> 
> In particular, the feature collects statistics and information about ports, flows and tables in switches.
> 
> We feel ceilometer shouldn't talk to switches directly.
> If having made pollster that talks to switches directly via SouthBound API, pollsters would be created for each switch vendor.
> It would make large maintenance cost.
> In general, NorthBound API abstracts differences between hardwares. Thus this feature collects via NorthBound API.
> 
> We define some meters in this feature on the blueprints.
> The meters are based on the OpenFlow Switch Specification.
> But, We have no intention of limiting to OpenFlow Switch.
> We guess OpenFlow Switch Specification covers general the network information.
> If you know other necessary meters, please let me know.
> 
> Details are written in wiki.[3]
> 
> We hope feedback of you.
> 
> [1]https://blueprints.launchpad.net/ceilometer/+spec/monitoring-network
> [2]https://blueprints.launchpad.net/ceilometer/+spec/monitoring-network-from-opendaylight
> [3]https://wiki.openstack.org/wiki/Ceilometer/blueprints/monitoring-network
> 
> Thanks.
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>