Re: [openstack-dev] [OSLO] Comments/Questions on Messaging Wiki
Hi William, I think Doug has done a good job of answering all these, but here's another set of answers to make sure there's no confusion :) On Fri, 2013-07-12 at 17:40 -0400, William Henry wrote: Hi all, I've been reading through the Messaging Wiki and have some comments. The docs generated from the code are now up on: http://docs.openstack.org/developer/oslo.messaging/ There should be some useful clarifying stuff in there too. Indeed some of thinking has moved on a bit since the wiki page was written. Not criticisms, just comments and questions. I have found this to be a very useful document. Thanks. 1. There are multiple backend transport drivers which implement the API semantics using different messaging systems - e.g. RabbitMQ, Qpid, ZeroMQ. While both sides of a connection must use the same transport driver configured in the same way, the API avoids exposing details of transports so that code written using one transport should work with any other transport. The good news for AMQP 1.0 users is that technically boths sides of the connection do not have to use same transport driver. In pre-AMQP 1.0 days this was the case. But today interoperability between AMQP 1.0 implementations has been demonstrated. Yeah, the point was more that like you need to use the zmq driver on both sides. I could imagine us having multiple amqp 1.0 interoperable drivers. I don't know what the use case would be for using one of those drivers on one side and another on the other side, but there's no reason why it should be impossible. 2. I notice under the RPC concepts section that you mention Exchanges as a container in which topics are scoped. Is this exchange a pre AMQP 1.0 artifact or just a general term for oslo.messaging that is loosely based on the pre-AMQP 1.0 artifact called an Exchange? i.e. are you assuming that messaging implementations have something called an exchange? Or do you mean that messaging implementations can scope a topic and in oslo we call that scoping an exchange? Yeah, it really is only loosely related to the AMQP concept. It's purely a namespace thing. You could e.g. have two Nova deployments with exactly the same messaging transport (and e.g. sending messages over the same broker, using the same topic names, etc.) and you could keep them separated from one another by using a different exchange name for each. The reason we've stuck with the name exchange is that we have a control_exchange configuration variable (defaulting to e.g. 'nova') that servers roughly this purpose now and we want to continue using it rather than renaming it to something else. Which raises a point about all of this - we need to be able to interoperate with existing OpenStack deployments using the current RPC code. So, we really don't have the luxury of changing on-the-wire formats, basic messaging semantics, configuration settings, etc. oslo.messaging is mostly about cleaning up the python API which services use to issue/receive RPCs and send notifications. 3. Some messaging nomenclature: The way the wiki describes RPC Invoke Method on One of Multiple Servers is more like a queue than a topic. In messaging a queue is something that multiple consumers can attach to and one of them gets and services a message/request. A topic is where 1+ consumers are connected and each receives a the message and each can service it as it sees fit. In pre-AMQP 1.0 terms what this seems to describe is a direct exchange. And a direct excahnge can have multiple consumers listening to a queue on that exchange. (Remember that fanout is just a generalization of topic in that all consumers get all fanout messages - there are no sub-topics etc.) In AMQP 1.0 the addressing doesn't care or know about exchanges but it can support this queue type behavior on an address or topic type behavior on an address. I know this isn't about AMQP specifically but therefore this is even more important. Topics are pub/sub with multiple consumer/services responding to a single message. Queues are next consumer up gets the next message. (BTW I've seen this kind of confusion also in early versions of MCollective in Puppet.) It might be better to change some of the references to topic to address. This would solve the problem. i.e. a use case where one of many servers listening on an address services a message/request. And later all of servers listening on an address service a message/request. Addressing also solves the one-to-one as the address is specific to the server (and the others don't have to receive and reject the message). It sounds to me like the qpid-proton based transport driver could easily map the semantics we expect from topic/fanout to amqp 1.0 addresses. The 'topic' nomenclature is pretty baked in the various services doing RPC and notifications, especially in the naming of configuration options. The basic semantics is a nova compute service listens on the
Re: [openstack-dev] [OSLO] Comments/Questions on Messaging Wiki
- Original Message - - Original Message - Hi William, I think Doug has done a good job of answering all these, but here's another set of answers to make sure there's no confusion :) On Fri, 2013-07-12 at 17:40 -0400, William Henry wrote: Hi all, I've been reading through the Messaging Wiki and have some comments. The docs generated from the code are now up on: http://docs.openstack.org/developer/oslo.messaging/ There should be some useful clarifying stuff in there too. Indeed some of thinking has moved on a bit since the wiki page was written. Not criticisms, just comments and questions. I have found this to be a very useful document. Thanks. 1. There are multiple backend transport drivers which implement the API semantics using different messaging systems - e.g. RabbitMQ, Qpid, ZeroMQ. While both sides of a connection must use the same transport driver configured in the same way, the API avoids exposing details of transports so that code written using one transport should work with any other transport. The good news for AMQP 1.0 users is that technically boths sides of the connection do not have to use same transport driver. In pre-AMQP 1.0 days this was the case. But today interoperability between AMQP 1.0 implementations has been demonstrated. Yeah, the point was more that like you need to use the zmq driver on both sides. I could imagine us having multiple amqp 1.0 interoperable drivers. I don't know what the use case would be for using one of those drivers on one side and another on the other side, but there's no reason why it should be impossible. 2. I notice under the RPC concepts section that you mention Exchanges as a container in which topics are scoped. Is this exchange a pre AMQP 1.0 artifact or just a general term for oslo.messaging that is loosely based on the pre-AMQP 1.0 artifact called an Exchange? i.e. are you assuming that messaging implementations have something called an exchange? Or do you mean that messaging implementations can scope a topic and in oslo we call that scoping an exchange? Yeah, it really is only loosely related to the AMQP concept. It's purely a namespace thing. You could e.g. have two Nova deployments with exactly the same messaging transport (and e.g. sending messages over the same broker, using the same topic names, etc.) and you could keep them separated from one another by using a different exchange name for each. The reason we've stuck with the name exchange is that we have a control_exchange configuration variable (defaulting to e.g. 'nova') that servers roughly this purpose now and we want to continue using it rather than renaming it to something else. Which raises a point about all of this - we need to be able to interoperate with existing OpenStack deployments using the current RPC code. So, we really don't have the luxury of changing on-the-wire formats, basic messaging semantics, configuration settings, etc. oslo.messaging is mostly about cleaning up the python API which services use to issue/receive RPCs and send notifications. 3. Some messaging nomenclature: The way the wiki describes RPC Invoke Method on One of Multiple Servers is more like a queue than a topic. In messaging a queue is something that multiple consumers can attach to and one of them gets and services a message/request. A topic is where 1+ consumers are connected and each receives a the message and each can service it as it sees fit. In pre-AMQP 1.0 terms what this seems to describe is a direct exchange. And a direct excahnge can have multiple consumers listening to a queue on that exchange. (Remember that fanout is just a generalization of topic in that all consumers get all fanout messages - there are no sub-topics etc.) In AMQP 1.0 the addressing doesn't care or know about exchanges but it can support this queue type behavior on an address or topic type behavior on an address. I know this isn't about AMQP specifically but therefore this is even more important. Topics are pub/sub with multiple consumer/services responding to a single message. Queues are next consumer up gets the next message. (BTW I've seen this kind of confusion also in early versions of MCollective in Puppet.) It might be better to change some of the references to topic to address. This would solve the problem. i.e. a use case where one of many servers listening on an address services a message/request. And later all of servers listening on an address service a message/request. Addressing also solves the one-to-one as the address is specific to the server (and the others don't have to receive and reject the message). It sounds to me like the qpid-proton based transport driver could easily map the semantics we
Re: [openstack-dev] [OSLO] Comments/Questions on Messaging Wiki
- Original Message - On Fri, Jul 12, 2013 at 8:09 PM, William Henry whe...@redhat.com wrote: Sent from my iPhone On Jul 12, 2013, at 5:27 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote: On Fri, Jul 12, 2013 at 5:40 PM, William Henry whe...@redhat.com wrote: Hi all, I've been reading through the Messaging Wiki and have some comments. Not criticisms, just comments and questions. I have found this to be a very useful document. Thanks. 1. There are multiple backend transport drivers which implement the API semantics using different messaging systems - e.g. RabbitMQ, Qpid, ZeroMQ. While both sides of a connection must use the same transport driver configured in the same way, the API avoids exposing details of transports so that code written using one transport should work with any other transport. The good news for AMQP 1.0 users is that technically boths sides of the connection do not have to use same transport driver. In pre-AMQP 1.0 days this was the case. But today interoperability between AMQP 1.0 implementations has been demonstrated. In this case I think we mean the Transport driver from within Oslo. So you could not connect a ZMQ Transport on one end to an AMQP Transport on the other. It will be an implementation detail of the AMQP Transport class to decide whether it supports more than one version of AMQP, or if the different versions are implemented as different Transports. 2. I notice under the RPC concepts section that you mention Exchanges as a container in which topics are scoped. Is this exchange a pre AMQP 1.0 artifact or just a general term for oslo.messaging that is loosely based on the pre-AMQP 1.0 artifact called an Exchange? i.e. are you assuming that messaging implementations have something called an exchange? Or do you mean that messaging implementations can scope a topic and in oslo we call that scoping an exchange? The latter. Ack. Good. Fits very well into AMQP 1.0 then ;-) 3. Some messaging nomenclature: The way the wiki describes RPC Invoke Method on One of Multiple Servers is more like a queue than a topic. In messaging a queue is something that multiple consumers can attach to and one of them gets and services a message/request. A topic is where 1+ consumers are connected and each receives a the message and each can service it as it sees fit. In pre-AMQP 1.0 terms what this seems to describe is a direct exchange. And a direct excahnge can have multiple consumers listening to a queue on that exchange. (Remember that fanout is just a generalization of topic in that all consumers get all fanout messages - there are no sub-topics etc.) In AMQP 1.0 the addressing doesn't care or know about exchanges but it can support this queue type behavior on an address or topic type behavior on an address. I know this isn't about AMQP specifically but therefore this is even more important. Topics are pub/sub with multiple consumer/services responding to a single message. Queues are next consumer up gets the next message. (BTW I've seen this kind of confusion also in early versions of MCollective in Puppet.) It might be better to change some of the references to topic to address. This would solve the problem. i.e. a use case where one of many servers listening on an address services a message/request. And later all of servers listening on an address service a message/request. Addressing also solves the one-to-one as the address is specific to the server (and the others don't have to receive and reject the message). Too many of these terms are overloaded. :-) Yep. But topic pup/sub is certainly different to a queue. ;-) I'm not sure of the details of how topic and address are different in AMQP 1.0. The word address implies to me that the message sender knows where the message receiver is in some concrete sense. We don't want those semantics in a lot of our use cases. If the address is abstract, then it sounds like it works much as a topic does. Maybe you can expand on the differences? Nope the address is essentially a namespace. The send knows not where it ends up. Hence in some applications it doesn't even know of its a topic or a queue an it could go to one or many depending. OK, that sounds like it would be part of the Transport's handling of a Target ( https://github.com/markmc/oslo.messaging/blob/master/oslo/messaging/target.py ). Thanks Doug. This is interesting. What's the difference between an exchange and a namespace? If exchange is a
Re: [openstack-dev] [OSLO] Comments/Questions on Messaging Wiki
On Mon, Jul 15, 2013 at 1:15 PM, William Henry whe...@redhat.com wrote: -- On Fri, Jul 12, 2013 at 8:09 PM, William Henry whe...@redhat.com wrote: Sent from my iPhone On Jul 12, 2013, at 5:27 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote: On Fri, Jul 12, 2013 at 5:40 PM, William Henry whe...@redhat.com wrote: Hi all, I've been reading through the Messaging Wiki and have some comments. Not criticisms, just comments and questions. I have found this to be a very useful document. Thanks. 1. There are multiple backend transport drivers which implement the API semantics using different messaging systems - e.g. RabbitMQ, Qpid, ZeroMQ. While both sides of a connection must use the same transport driver configured in the same way, the API avoids exposing details of transports so that code written using one transport should work with any other transport. The good news for AMQP 1.0 users is that technically boths sides of the connection do not have to use same transport driver. In pre-AMQP 1.0 days this was the case. But today interoperability between AMQP 1.0 implementations has been demonstrated. In this case I think we mean the Transport driver from within Oslo. So you could not connect a ZMQ Transport on one end to an AMQP Transport on the other. It will be an implementation detail of the AMQP Transport class to decide whether it supports more than one version of AMQP, or if the different versions are implemented as different Transports. 2. I notice under the RPC concepts section that you mention Exchanges as a container in which topics are scoped. Is this exchange a pre AMQP 1.0 artifact or just a general term for oslo.messaging that is loosely based on the pre-AMQP 1.0 artifact called an Exchange? i.e. are you assuming that messaging implementations have something called an exchange? Or do you mean that messaging implementations can scope a topic and in oslo we call that scoping an exchange? The latter. Ack. Good. Fits very well into AMQP 1.0 then ;-) 3. Some messaging nomenclature: The way the wiki describes RPC Invoke Method on One of Multiple Servers is more like a queue than a topic. In messaging a queue is something that multiple consumers can attach to and one of them gets and services a message/request. A topic is where 1+ consumers are connected and each receives a the message and each can service it as it sees fit. In pre-AMQP 1.0 terms what this seems to describe is a direct exchange. And a direct excahnge can have multiple consumers listening to a queue on that exchange. (Remember that fanout is just a generalization of topic in that all consumers get all fanout messages - there are no sub-topics etc.) In AMQP 1.0 the addressing doesn't care or know about exchanges but it can support this queue type behavior on an address or topic type behavior on an address. I know this isn't about AMQP specifically but therefore this is even more important. Topics are pub/sub with multiple consumer/services responding to a single message. Queues are next consumer up gets the next message. (BTW I've seen this kind of confusion also in early versions of MCollective in Puppet.) It might be better to change some of the references to topic to address. This would solve the problem. i.e. a use case where one of many servers listening on an address services a message/request. And later all of servers listening on an address service a message/request. Addressing also solves the one-to-one as the address is specific to the server (and the others don't have to receive and reject the message). Too many of these terms are overloaded. :-) Yep. But topic pup/sub is certainly different to a queue. ;-) I'm not sure of the details of how topic and address are different in AMQP 1.0. The word address implies to me that the message sender knows where the message receiver is in some concrete sense. We don't want those semantics in a lot of our use cases. If the address is abstract, then it sounds like it works much as a topic does. Maybe you can expand on the differences? Nope the address is essentially a namespace. The send knows not where it ends up. Hence in some applications it doesn't even know of its a topic or a queue an it could go to one or many depending. OK, that sounds like it would be part of the Transport's handling of a Target ( https://github.com/markmc/oslo.messaging/blob/master/oslo/messaging/target.py ). Thanks Doug. This is interesting. What's the difference between an exchange and a namespace? If exchange is a scope and namespace is essentially a scope, then why have both? The namespace relates to the API implementation inside the receiver. The way it currently works is the receiver subscribes to messages on a topic/exchange pair to have AMQP route messages to it, and then it looks inside the message for further dispatch to an object that knows about
Re: [openstack-dev] [OSLO] Comments/Questions on Messaging Wiki
On Mon, Jul 15, 2013 at 4:28 PM, Russell Bryant rbry...@redhat.com wrote: On 07/15/2013 02:36 PM, Doug Hellmann wrote: The namespace relates to the API implementation inside the receiver. The way it currently works is the receiver subscribes to messages on a topic/exchange pair to have AMQP route messages to it, and then it looks inside the message for further dispatch to an object that knows about that API. That lets the nova API implementation be split up among different objects, for example. I'm not sure why it evolved that way, instead of using separate topics and having the messaging layer do all of the routing. Maybe we should take another look at that part of the new API design. In retrospect, yes, a separate topic would have worked. The namespace was very convenient for the current nova implementation, but that doesn't mean it was the best design. The code that sets up which topics to consume from is very generic and applies to *all* services. So, instead of reworking this to let it be different per-service, I did the namespace thing, which worked without having to change any other nova code. That's a completely understandable pragmatic solution. :-) Doug -- Russell Bryant ___ 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] [OSLO] Comments/Questions on Messaging Wiki
Hi all, I've been reading through the Messaging Wiki and have some comments. Not criticisms, just comments and questions. I have found this to be a very useful document. Thanks. 1. There are multiple backend transport drivers which implement the API semantics using different messaging systems - e.g. RabbitMQ, Qpid, ZeroMQ. While both sides of a connection must use the same transport driver configured in the same way, the API avoids exposing details of transports so that code written using one transport should work with any other transport. The good news for AMQP 1.0 users is that technically boths sides of the connection do not have to use same transport driver. In pre-AMQP 1.0 days this was the case. But today interoperability between AMQP 1.0 implementations has been demonstrated. 2. I notice under the RPC concepts section that you mention Exchanges as a container in which topics are scoped. Is this exchange a pre AMQP 1.0 artifact or just a general term for oslo.messaging that is loosely based on the pre-AMQP 1.0 artifact called an Exchange? i.e. are you assuming that messaging implementations have something called an exchange? Or do you mean that messaging implementations can scope a topic and in oslo we call that scoping an exchange? 3. Some messaging nomenclature: The way the wiki describes RPC Invoke Method on One of Multiple Servers is more like a queue than a topic. In messaging a queue is something that multiple consumers can attach to and one of them gets and services a message/request. A topic is where 1+ consumers are connected and each receives a the message and each can service it as it sees fit. In pre-AMQP 1.0 terms what this seems to describe is a direct exchange. And a direct excahnge can have multiple consumers listening to a queue on that exchange. (Remember that fanout is just a generalization of topic in that all consumers get all fanout messages - there are no sub-topics etc.) In AMQP 1.0 the addressing doesn't care or know about exchanges but it can support this queue type behavior on an address or topic type behavior on an address. I know this isn't about AMQP specifically but therefore this is even more important. Topics are pub/sub with multiple consumer/services responding to a single message. Queues are next consumer up gets the next message. (BTW I've seen this kind of confusion also in early versions of MCollective in Puppet.) It might be better to change some of the references to topic to address. This would solve the problem. i.e. a use case where one of many servers listening on an address services a message/request. And later all of servers listening on an address service a message/request. Addressing also solves the one-to-one as the address is specific to the server (and the others don't have to receive and reject the message). Please feel free to respond and critique my comments/suggestions. Best, William ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OSLO] Comments/Questions on Messaging Wiki
Woops the wiki I am referring to is: https://wiki.openstack.org/wiki/Oslo/Messaging William - Original Message - Hi all, I've been reading through the Messaging Wiki and have some comments. Not criticisms, just comments and questions. I have found this to be a very useful document. Thanks. 1. There are multiple backend transport drivers which implement the API semantics using different messaging systems - e.g. RabbitMQ, Qpid, ZeroMQ. While both sides of a connection must use the same transport driver configured in the same way, the API avoids exposing details of transports so that code written using one transport should work with any other transport. The good news for AMQP 1.0 users is that technically boths sides of the connection do not have to use same transport driver. In pre-AMQP 1.0 days this was the case. But today interoperability between AMQP 1.0 implementations has been demonstrated. 2. I notice under the RPC concepts section that you mention Exchanges as a container in which topics are scoped. Is this exchange a pre AMQP 1.0 artifact or just a general term for oslo.messaging that is loosely based on the pre-AMQP 1.0 artifact called an Exchange? i.e. are you assuming that messaging implementations have something called an exchange? Or do you mean that messaging implementations can scope a topic and in oslo we call that scoping an exchange? 3. Some messaging nomenclature: The way the wiki describes RPC Invoke Method on One of Multiple Servers is more like a queue than a topic. In messaging a queue is something that multiple consumers can attach to and one of them gets and services a message/request. A topic is where 1+ consumers are connected and each receives a the message and each can service it as it sees fit. In pre-AMQP 1.0 terms what this seems to describe is a direct exchange. And a direct excahnge can have multiple consumers listening to a queue on that exchange. (Remember that fanout is just a generalization of topic in that all consumers get all fanout messages - there are no sub-topics etc.) In AMQP 1.0 the addressing doesn't care or know about exchanges but it can support this queue type behavior on an address or topic type behavior on an address. I know this isn't about AMQP specifically but therefore this is even more important. Topics are pub/sub with multiple consumer/services responding to a single message. Queues are next consumer up gets the next message. (BTW I've seen this kind of confusion also in early versions of MCollective in Puppet.) It might be better to change some of the references to topic to address. This would solve the problem. i.e. a use case where one of many servers listening on an address services a message/request. And later all of servers listening on an address service a message/request. Addressing also solves the one-to-one as the address is specific to the server (and the others don't have to receive and reject the message). Please feel free to respond and critique my comments/suggestions. Best, William ___ 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
Re: [openstack-dev] [OSLO] Comments/Questions on Messaging Wiki
Sent from my iPhone On Jul 12, 2013, at 5:27 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote: On Fri, Jul 12, 2013 at 5:40 PM, William Henry whe...@redhat.com wrote: Hi all, I've been reading through the Messaging Wiki and have some comments. Not criticisms, just comments and questions. I have found this to be a very useful document. Thanks. 1. There are multiple backend transport drivers which implement the API semantics using different messaging systems - e.g. RabbitMQ, Qpid, ZeroMQ. While both sides of a connection must use the same transport driver configured in the same way, the API avoids exposing details of transports so that code written using one transport should work with any other transport. The good news for AMQP 1.0 users is that technically boths sides of the connection do not have to use same transport driver. In pre-AMQP 1.0 days this was the case. But today interoperability between AMQP 1.0 implementations has been demonstrated. In this case I think we mean the Transport driver from within Oslo. So you could not connect a ZMQ Transport on one end to an AMQP Transport on the other. It will be an implementation detail of the AMQP Transport class to decide whether it supports more than one version of AMQP, or if the different versions are implemented as different Transports. 2. I notice under the RPC concepts section that you mention Exchanges as a container in which topics are scoped. Is this exchange a pre AMQP 1.0 artifact or just a general term for oslo.messaging that is loosely based on the pre-AMQP 1.0 artifact called an Exchange? i.e. are you assuming that messaging implementations have something called an exchange? Or do you mean that messaging implementations can scope a topic and in oslo we call that scoping an exchange? The latter. Ack. Good. Fits very well into AMQP 1.0 then ;-) 3. Some messaging nomenclature: The way the wiki describes RPC Invoke Method on One of Multiple Servers is more like a queue than a topic. In messaging a queue is something that multiple consumers can attach to and one of them gets and services a message/request. A topic is where 1+ consumers are connected and each receives a the message and each can service it as it sees fit. In pre-AMQP 1.0 terms what this seems to describe is a direct exchange. And a direct excahnge can have multiple consumers listening to a queue on that exchange. (Remember that fanout is just a generalization of topic in that all consumers get all fanout messages - there are no sub-topics etc.) In AMQP 1.0 the addressing doesn't care or know about exchanges but it can support this queue type behavior on an address or topic type behavior on an address. I know this isn't about AMQP specifically but therefore this is even more important. Topics are pub/sub with multiple consumer/services responding to a single message. Queues are next consumer up gets the next message. (BTW I've seen this kind of confusion also in early versions of MCollective in Puppet.) It might be better to change some of the references to topic to address. This would solve the problem. i.e. a use case where one of many servers listening on an address services a message/request. And later all of servers listening on an address service a message/request. Addressing also solves the one-to-one as the address is specific to the server (and the others don't have to receive and reject the message). Too many of these terms are overloaded. :-) Yep. But topic pup/sub is certainly different to a queue. ;-) I'm not sure of the details of how topic and address are different in AMQP 1.0. The word address implies to me that the message sender knows where the message receiver is in some concrete sense. We don't want those semantics in a lot of our use cases. If the address is abstract, then it sounds like it works much as a topic does. Maybe you can expand on the differences? Nope the address is essentially a namespace. The send knows not where it ends up. Hence in some applications it doesn't even know of its a topic or a queue an it could go to one or many depending. William Thanks, Doug Please feel free to respond and critique my comments/suggestions. Best, William ___ 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
