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-yuui...@zx.mxh.nes.nec.co.jp] > Sent: Wednesday, December 11, 2013 8:25 AM > To: openstack-dev@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
