[openstack-dev] [Ceilometer] RFC: blueprint monitoring-network

Stein, Manuel (Manuel) manuel.stein at alcatel-lucent.com
Thu Jan 9 17:10:01 UTC 2014


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.



OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org

More information about the OpenStack-dev mailing list