[openstack-dev] [neutron] No QoS meeting today

[Alonso Hernandez, Rodolfo]

Hello:

Due to Denver PTG, today there will be no QoS meeting today. Next one will be 
on September 26.

Regards.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] QoS meeting cancelled, next meeting 29/08/2017

[Alonso Hernandez, Rodolfo]

Hello:

Yesterday by mistake I didn't send an email saying the QoS meeting was 
cancelled. During this weeks, our focus are in the RC and solving possible bugs.

Next meeting (no excuses) will be on 29/08/2017.

Regards.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] no QoS meeting tomorrow

[Alonso Hernandez, Rodolfo]

Hello everyone:

Sorry for the late heads up. Today won't be Neutron QoS meeting because of the 
lack of quorum (4th of July).

Regards.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] [nova] [os-vif] OVS plugin assumes an incorrect datapath_type in os-vif

[Alonso Hernandez, Rodolfo]

Hello fellows:

Currently there is a bug in os-vif 
[1]. When os-vif tries to plug 
an OVS interface, the datapath type is hardcoded:

-  
https://github.com/openstack/os-vif/blob/9fb7fe512902a37432e38d884b8be59ce91582db/vif_plug_ovs/ovs.py#L100-L101

-  
https://github.com/openstack/os-vif/blob/9fb7fe512902a37432e38d884b8be59ce91582db/vif_plug_ovs/ovs.py#L127-L128

-  
https://github.com/openstack/os-vif/blob/9fb7fe512902a37432e38d884b8be59ce91582db/vif_plug_ovs/ovs.py#L135-L136

-  
https://github.com/openstack/os-vif/blob/9fb7fe512902a37432e38d884b8be59ce91582db/vif_plug_ovs/ovs.py#L149-L150

The problem is os-vif doesn’t have this information now. I’m proposing the 
following solution:

-  Nova: https://review.openstack.org/#/c/474892/

-  Neutron: https://review.openstack.org/#/c/474588/

-  Neutron-lib: https://review.openstack.org/#/c/474248/

-  os-vif: https://review.openstack.org/#/c/474914/

Neutron will add to VIF details the datapath type to the vif details dict. If 
this information is not given in the config file, the default parameter written 
will be OVS_DATAPATH_SYSTEM, which is the default value. The change in 
neutron-lib is needed for Neutron to keep the same dict key name (matching the 
name set in nova.network.model)

1)

2)  Nova will receive this information (if given in the dict), getting the 
value stored in vif['details']. If the key is not set, the default datapath 
will be None. Because currently no information is passed and Nova doesn’t know 
about the different datapath types (this information is in Neutron), it makes 
sense not to assign any value. Nova is protected in case the dict doesn't have 
this information.

Finally, os-vif will receive the VIF information given by Nova. If the 
datapath_type is not given in the variable (dict) or the value is None, the 
default value (OVS_DATAPATH_SYSTEM) will be set.

As you can see, it's indeed an API change, but the projects affected are 
protected in case the information expected in the variable passed is not 
present.

What do you think?

Thank you in advance.

[1] https://bugs.launchpad.net/os-vif/+bug/1632372




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Neutron team social event in Barcelona

[Alonso Hernandez, Rodolfo]

+1

From: Doug Wiegley [mailto:doug...@parksidesoftware.com]
Sent: Saturday, October 15, 2016 1:57 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Neutron] Neutron team social event in Barcelona

+1
Doug

On Oct 14, 2016, at 6:24 PM, Kevin Benton 
mailto:ke...@benton.pub>> wrote:

+1

On Oct 14, 2016 1:33 PM, "Miguel Lavalle" 
mailto:mig...@mlavalle.com>> wrote:
Dear Neutrinos,
I am organizing a social event for the team on Thursday 27th at 19:30. After 
doing some Google research, I am proposing Raco de la Vila, which is located in 
Poblenou: http://www.racodelavila.com/en/index.htm. The menu is here: 
http://www.racodelavila.com/en/carta-racodelavila.htm
It is easy to get there by subway from the Summit venue: 
https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people under 
'Neutron' or "Miguel Lavalle". Please confirm your attendance so we can get a 
final count.
Here's some reviews: 
https://www.tripadvisor.com/Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_Vila-Barcelona_Catalonia.html

Cheers

Miguel

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] [scheduler] New filter: AggregateInstanceTypeFilter

[Alonso Hernandez, Rodolfo]

Hello:

We have developed a new filter for Nova scheduler 
(SPEC). We have a POC in 
https://review.openstack.org/#/c/346662/.

My question is how to procced with this code:

1)  Merge into nova code. This solution seems not to be accepted (see spec 
comments; also previous versions were merged and reverted in previous releases).

2)  Merge into networking-ovs-dpdk 
(https://github.com/openstack/networking-ovs-dpdk) repo.

3)  Create a new repo to support this new filter.

Which option should we take?

Thank you in advance.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][qos] Egress minimum bandwidth assurance

[Alonso Hernandez, Rodolfo]

Hello Ihar:

Please, take a look to https://review.openstack.org/#/c/318531/.

>> does it mean you want to set some queues on ports that have no qos policy 
>> attached?
That’s exactly what I'm doing, because the unique way to shape traffic in OvS 
is at the end of the datapath. In other words, shaping is only possible for 
egress (OvS point of view) traffic. Because what I need is to limit VM-egress 
(OvS-ingress) traffic, what I'm doing is defined in 
https://review.openstack.org/#/c/318531/9/doc/source/devref/quality_of_service.rst@342.

Regards.


-Original Message-
From: Ihar Hrachyshka [mailto:ihrac...@redhat.com] 
Sent: Monday, July 18, 2016 11:53 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [neutron][qos] Egress minimum bandwidth assurance

Rodolfo  wrote:

> Hello:
>
> I’m working in the egress minimum bandwidth assurance qos policy rule.
>
> I made a POC using the following architecture:
> -  Every time a new rule is created and assigned to a port:
> o   A new queue is created in OVS.
> o   Create/update the qos policy (OVS database) in all other ports in  
> br-int (assigned to the same vlan), br-tun and br-phy, updating the 
> queue value.
> o   Set the queue id to the incoming traffic to the OVS.
> -  Every time rule is updated:
> o   The values are updated in the ovs database.
> -  Every time a rule is unassigned to a port:
> o   The queue is removed from the qos policies. (OVS database)
> o   The OVS rule to set the queue id is removed.
>
> The problem is, based on the neutron extensions API, I can’t make any 
> updates in other ports affected by this rule. That means, for example: 
> if I create a new port, this port must have also a qos assigned (OVS
> database) using the existing queue. But because the Neutron qos rule 
> doesn’t apply to this port, no qos agent function is called and this 
> port is not correctly configured.

I am sorry if the question is trivial, but just for my understanding, does it 
mean you want to set some queues on ports that have no qos policy attached? Why 
is it the case?

Because if the policy IS attached to a port, then qos l2 agent driver will be 
triggered for all supported rules, including your new rule, on every relevant 
policy/rule change.

I am sure I miss something, so please enlighten me.

Ihar

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][qos] Egress minimum bandwidth assurance

[Alonso Hernandez, Rodolfo]

Hello:

I’m working in the egress minimum bandwidth assurance qos policy rule.

I made a POC using the following architecture:

-  Every time a new rule is created and assigned to a port:

o   A new queue is created in OVS.

o   Create/update the qos policy (OVS database) in all other ports in br-int 
(assigned to the same vlan), br-tun and br-phy, updating the queue value.

o   Set the queue id to the incoming traffic to the OVS.

-  Every time rule is updated:

o   The values are updated in the ovs database.

-  Every time a rule is unassigned to a port:

o   The queue is removed from the qos policies. (OVS database)

o   The OVS rule to set the queue id is removed.

The problem is, based on the neutron extensions API, I can’t make any updates 
in other ports affected by this rule. That means, for example: if I create a 
new port, this port must have also a qos assigned (OVS database) using the 
existing queue. But because the Neutron qos rule doesn’t apply to this port, no 
qos agent function is called and this port is not correctly configured.

Any good idea to solve this problem?

Maybe the idea of creating veth ports could be easy (although the performance 
could be reduced).

Now I’m in a deadpoint.

Regards.


From: Alonso Hernandez, Rodolfo [mailto:rodolfo.alonso.hernan...@intel.com]
Sent: Friday, June 24, 2016 10:10 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [neutron][qos] Egress minimum bandwidth assurance

Hello:

Ichihara, thank you for your answer. It was just a test to find out how to 
setup correctly the egress traffic shaping. I was facing this situation and I 
found the problem: I was using bridges with datapath_type = netdev, instead of 
system. That was the main problem. Now I can correctly apply a QoS and a queue, 
and assign a traffic to this queue.

To avoid using veth between bridges, I’m implementing the following solution:

-  Create a new queue for each min-qos rule applied to a port (the same 
min-qos rule could be applied to several ports, of course).

-  Because ovs only shapes traffic in the egress direction (ovs point 
of view):

o   Create a qos policy for each port in br-int in the same network of the port 
to apply the qos; then assign the created queue to this qos policy.

o   Create a qos policy for the external port in br-tun, and then assign the 
queue

o   Create a qos policy for the external port for the br-phy in the same 
network, and assign the queue

-  In br-int, table 0, enqueue all traffic going into ovs from the port 
with qos policy assigned to the queue created.

With this implementation, you don’t need to use veth and all traffic going from 
the port with the qos policy assigned to other VM or external port (physical 
bridge, tunnel) will be shaped. Of course, this implementation is a bit 
tangled, so please be gentle in the code-review.

Regards.


From: Hirofumi Ichihara [mailto:ichihara.hirof...@lab.ntt.co.jp]
Sent: Tuesday, June 21, 2016 10:27 AM
To: OpenStack Development Mailing List (not for usage questions) 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron][qos] Egress minimum bandwidth assurance


On 2016/06/15 18:54, Alonso Hernandez, Rodolfo wrote:
Hello:

Context: try to develop a driver for this feature in OVS.

During the last week I’ve been testing several scenarios to make a POC of this 
feature.

Scenario 1:
3 VM connected to br-int, sending traffic through br-physical to other host (an 
external physical machine).
The first VM will have a min BW of 15 Mb. The physical port will be limited to 
20 Mb, so for VM2 and VM3 should be only 5 Mb of available BW.
Those three VM are using iperf to inject traffic against the external host.

A) One qos policy and queue is created at VM1 port (with 
other_config:{min-rate=1500}). The traffic is not shapped.
B) Another qos policy and queue with this minimum BW is created at 
int-phy-patchport. The traffic is not shapped.
C) Another qos policy and queue with this minimum BW is created at 
phy-int-phy-patchport. The traffic is not shapped.
D) Another qos policy and queue with this minimum BW is created at physical 
port. The traffic is still not shapped.
In OVS all traffic from VM1 is filtered to match the correct qos and queues at 
the ports.
It seems that this scenario doesn't expect some scenarios like DVR and multiple 
NIC. I thought that the queue should be set in br-int with veth(instead of 
patch port) between br-int and bt-tun. However, I guess that this may occur a 
issue that traffic cannot turn back in br-int. That may happen in Scenario2 
case.

Therefore, I think that we should set the queue to physical port but we have a 
problem how do we specify the NIC in some cases(vlan, vxlan, DVR mode router 
and DVR FloatingIP).



Scenario 2:
Similar to scenario 1, but using a fourth VM to act as server. In this case, 
traffic only goes through br-

Re: [openstack-dev] [neutron][qos] Egress minimum bandwidth assurance

[Alonso Hernandez, Rodolfo]

Hello:

Ichihara, thank you for your answer. It was just a test to find out how to 
setup correctly the egress traffic shaping. I was facing this situation and I 
found the problem: I was using bridges with datapath_type = netdev, instead of 
system. That was the main problem. Now I can correctly apply a QoS and a queue, 
and assign a traffic to this queue.

To avoid using veth between bridges, I’m implementing the following solution:

-  Create a new queue for each min-qos rule applied to a port (the same 
min-qos rule could be applied to several ports, of course).

-  Because ovs only shapes traffic in the egress direction (ovs point 
of view):

o   Create a qos policy for each port in br-int in the same network of the port 
to apply the qos; then assign the created queue to this qos policy.

o   Create a qos policy for the external port in br-tun, and then assign the 
queue

o   Create a qos policy for the external port for the br-phy in the same 
network, and assign the queue

-  In br-int, table 0, enqueue all traffic going into ovs from the port 
with qos policy assigned to the queue created.

With this implementation, you don’t need to use veth and all traffic going from 
the port with the qos policy assigned to other VM or external port (physical 
bridge, tunnel) will be shaped. Of course, this implementation is a bit 
tangled, so please be gentle in the code-review.

Regards.


From: Hirofumi Ichihara [mailto:ichihara.hirof...@lab.ntt.co.jp]
Sent: Tuesday, June 21, 2016 10:27 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [neutron][qos] Egress minimum bandwidth assurance


On 2016/06/15 18:54, Alonso Hernandez, Rodolfo wrote:
Hello:

Context: try to develop a driver for this feature in OVS.

During the last week I’ve been testing several scenarios to make a POC of this 
feature.

Scenario 1:
3 VM connected to br-int, sending traffic through br-physical to other host (an 
external physical machine).
The first VM will have a min BW of 15 Mb. The physical port will be limited to 
20 Mb, so for VM2 and VM3 should be only 5 Mb of available BW.
Those three VM are using iperf to inject traffic against the external host.

A) One qos policy and queue is created at VM1 port (with 
other_config:{min-rate=1500}). The traffic is not shapped.
B) Another qos policy and queue with this minimum BW is created at 
int-phy-patchport. The traffic is not shapped.
C) Another qos policy and queue with this minimum BW is created at 
phy-int-phy-patchport. The traffic is not shapped.
D) Another qos policy and queue with this minimum BW is created at physical 
port. The traffic is still not shapped.
In OVS all traffic from VM1 is filtered to match the correct qos and queues at 
the ports.
It seems that this scenario doesn't expect some scenarios like DVR and multiple 
NIC. I thought that the queue should be set in br-int with veth(instead of 
patch port) between br-int and bt-tun. However, I guess that this may occur a 
issue that traffic cannot turn back in br-int. That may happen in Scenario2 
case.

Therefore, I think that we should set the queue to physical port but we have a 
problem how do we specify the NIC in some cases(vlan, vxlan, DVR mode router 
and DVR FloatingIP).




Scenario 2:
Similar to scenario 1, but using a fourth VM to act as server. In this case, 
traffic only goes through br-int.
A) One qos policy and queue is created at VM1 port (with 
other_config:{min-rate=1500}). The traffic is not shapped.
B) Another qos policy and queue with this minimum BW is created at output port 
(VM4 server port). The traffic is still not shapped.


I think we cannot manage this case because we doesn't know MAX bandwidth of 
traffic in br-int and the bandwidth is usually enough.
We should focus our attention on a case that the traffic goes out to other 
nodes.

Thanks,
Hirofumi


I need some help with this implementation, because I’m running out of time an 
ideas!

Thank you in advance.




__

OpenStack Development Mailing List (not for usage questions)

Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<mailto:openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][qos] Egress minimum bandwidth assurance

[Alonso Hernandez, Rodolfo]

Hello:

Context: try to develop a driver for this feature in OVS.

During the last week I’ve been testing several scenarios to make a POC of this 
feature.

Scenario 1:
3 VM connected to br-int, sending traffic through br-physical to other host (an 
external physical machine).
The first VM will have a min BW of 15 Mb. The physical port will be limited to 
20 Mb, so for VM2 and VM3 should be only 5 Mb of available BW.
Those three VM are using iperf to inject traffic against the external host.

A) One qos policy and queue is created at VM1 port (with 
other_config:{min-rate=1500}). The traffic is not shapped.
B) Another qos policy and queue with this minimum BW is created at 
int-phy-patchport. The traffic is not shapped.
C) Another qos policy and queue with this minimum BW is created at 
phy-int-phy-patchport. The traffic is not shapped.
D) Another qos policy and queue with this minimum BW is created at physical 
port. The traffic is still not shapped.
In OVS all traffic from VM1 is filtered to match the correct qos and queues at 
the ports.

Scenario 2:
Similar to scenario 1, but using a fourth VM to act as server. In this case, 
traffic only goes through br-int.
A) One qos policy and queue is created at VM1 port (with 
other_config:{min-rate=1500}). The traffic is not shapped.
B) Another qos policy and queue with this minimum BW is created at output port 
(VM4 server port). The traffic is still not shapped.

I need some help with this implementation, because I’m running out of time an 
ideas!

Thank you in advance.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] [scheduler] New filter: AggregateInstanceAffinityFilter

[Alonso Hernandez, Rodolfo]

Hello:

For the last two cycles we have tried to introduce a new filter to be able to 
interact better with the aggregates, using the metadata to accept or reject an 
instance depending on the flavor:
https://review.openstack.org/#/c/189279/

This filter was reverted and we agreed to present a new one, being backwards 
compatible with AggregateInstanceExtraSpecsFilter and adding more flexibility 
to the original filter. We have this proposal and we ask you to review it:
https://review.openstack.org/#/c/314097/

Regards.

PD: I know the non-priority feature spec freeze is today and that's why I'm 
asking you to take a look at it.

--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Monasca] collectd-Monasca Python plugin

[Alonso Hernandez, Rodolfo]

Hello Roland:

>> How would you map the metric names and fields in collectd to a monasa name 
>> and dimensions?
I'm on it. I'm reading the API from collectd and monasca, to figure out how to 
connect them. Next week I'll upload a spec and I'll wait for your comments.

Thank you for your interest!

Regards.


-Original Message-
From: Hochmuth, Roland M [mailto:roland.hochm...@hpe.com] 
Sent: Thursday, January 21, 2016 11:53 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Monasca] collectd-Monasca Python plugin

Hi Rodolfo, I think this would be useful work. Collectd has a lot of metrics 
that aren't supported in Monasca yet.

How would you map the metric names and fields in collectd to a monasa name and 
dimensions?

Regards --Roland

From: Jaesuk Ahn mailto:bluejay@gmail.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, January 21, 2016 at 4:49 AM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Monasca] collectd-Monasca Python plugin

We are looking into similar plan to have collectd-plugin for Monasca.

There are some env. we cannot deploy monasca agent, but want to put data into 
Monasca. In addition, we wanted to use easily accepted collectd for gathering 
data from legacy env.

It will be interesting to see more detail about your plan.

Cheers,


---
Jaesuk Ahn
SDI Tech. Lab, SKT


2016년 1월 21일 (목) 19:11, Alonso Hernandez, Rodolfo 
mailto:rodolfo.alonso.hernan...@intel.com>>님이
 작성:
Hello:

We are doing (or at least planning) a collectd-Monasca Python plugin. This 
plugin will receive the data from RPC calls form collectd and will write this 
data in Monasca, using statsd API.

My question is: do you think this development could be useful? Does it worth? 
Any comment?

Thank you in advance. Regards.

Rodolfo Alonso.
--
Intel Research and Development Ireland Limited Registered in Ireland Registered 
Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 
308263


This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). Any review or distribution by others is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Monasca] collectd-Monasca Python plugin

[Alonso Hernandez, Rodolfo]

Hello:

We are doing (or at least planning) a collectd-Monasca Python plugin. This 
plugin will receive the data from RPC calls form collectd and will write this 
data in Monasca, using statsd API.

My question is: do you think this development could be useful? Does it worth? 
Any comment?

Thank you in advance. Regards.

Rodolfo Alonso.
--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev