[openstack-dev] [nova] how to get domain info of all running instances on a compute host

2016-03-24 Thread Kapil
Hi

I am trying to get the virDomainInfo objects of all the currently running
instances on the compute host. There is an api method in
virt/libvirt/driver.py "*get_info(self, instance)*", but it takes an
instance object as the argument. I can get instance names from "
*list_instances(self)*" but how do I get the instance objects ?

Regards,
Kapil Agarwal
ᐧ
__
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] [nova][ceilometer] unable to see compute.node.cpu.* metrics in ceilometer

2016-03-07 Thread Kapil
I am using Kilo 2015.1.1 version

notification_driver=ceilometer.compute.nova_notifier
notification_driver=nova.openstack.common.notifier.rpc_notifier


I tried the following-

1. printed out event_type in
https://github.com/openstack/ceilometer/blob/stable/kilo/ceilometer/agent/plugin_base.py#L151
However, I am not receiving compute.metrics.update events

2. printed out metrics in
https://github.com/openstack/nova/blob/stable/kilo/nova/compute/resource_tracker.py#L364
I can see that metrics are being generated. I am not sure if they're being
pushed to the notification queue.


ᐧ

Regards,
Kapil Agarwal

On Mon, Mar 7, 2016 at 1:15 PM, Kapil <kapil6...@gmail.com> wrote:

> Hi
>
> I enabled ComputeDriverCPUMonitor in nova.conf on one of the compute
> nodes, restarted nova-compute, ceilometer-agent-compute on the compute node
> and ceilometer-collector, ceilometer-api, ceilometer-agent-central,
> ceilometer-agent-notification on the controller node.
> However, I cannot see the cpu meters or samples in ceilometer.
>
> Any suggestions to what may be the issue ?
>
> Thanks
> Kapil
>
__
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][ceilometer] unable to see compute.node.cpu.* metrics in ceilometer

2016-03-07 Thread Kapil
Hi

I enabled ComputeDriverCPUMonitor in nova.conf on one of the compute nodes,
restarted nova-compute, ceilometer-agent-compute on the compute node and
ceilometer-collector, ceilometer-api, ceilometer-agent-central,
ceilometer-agent-notification on the controller node.
However, I cannot see the cpu meters or samples in ceilometer.

Any suggestions to what may be the issue ?

Thanks
Kapil
__
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] customizing nova scheduler using metrics from ceilometer

2016-03-04 Thread Kapil
Hi

I would like to implement my own scheduling algorithm based on the samples
collected in ceilometer for a custom meter.
I see there is a MetricsFilter but I think they are nova internal metrics
and not ceilometer metrics.

Please refer me to some documentation and how can I install this plug in
into the nova scheduler.

Thanks
Kapil Agarwal
__
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] [ceilometer] Unable to get IPMI meter readings

2016-03-04 Thread Kapil
Yes, I had to look through the source code of the ipmi pollster class to
figure out why the error was being raised. Apparently, I don't have Intel
node manager installed, so power plugin was not being loaded.
I had to write my own plugin to get that data using ipmi-dcmi command which
is not specific to Intel I guess.
Is there any plan to add dcmi support to ceilometer ?
On Mar 3, 2016 7:47 PM, "Lu, Lianhao" <lianhao...@intel.com> wrote:

> Hi Kapil,
>
> Currenlyt, the ipmi pollsters can only get the ipmi data from system bus
> due to the security concerns. So you have the make sure the
> ceilometer-agent-ipmi is running on the same machine you want get the
> hardware.ipmi.node.power metric from. Also you should make sure your
> machine have NodeManager features and enabled that  in your bios settings,
> otherwise the the hardware.ipmi.node.power pollster won't be loaded because
> it will checks whether your machine support that during load time.
>
> -Lianhao Lu
>
> > -Original Message-
> > From: Kapil [mailto:kapil6...@gmail.com]
> > Sent: Friday, March 04, 2016 2:34 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [ceilometer] Unable to get IPMI meter
> > readings
> >
> > So, we upgraded our openstack install from Juno to Kilo 2015.1.1
> >
> > Not sure if this fixed some stuff, but I can now get samples for
> > hardware.ipmi.(fan|temperature). However, I want to get
> > hardware.ipmi.node.power samples and I get the following error in
> > the ceilometer log-
> >
> > ERROR ceilometer.agent.base [-] Skip loading extension for
> > hardware.ipmi.node.power
> >
> >
> > I edited pipeline.yaml as follows-
> > sources:
> > - name: meter_ipmi
> >   interval: 10
> >   resources:
> >   - "ipmi://"
> >   meters:
> >   - "hardware.ipmi.node.power"
> >   sinks:
> >   - ipmi_sink
> > sinks:
> >  - name: ipmi_sink
> >   transformers:
> >   publishers:
> >   - notifier://?per_meter_topic=1
> >
> >
> > I also checked "rabbitmqctl list_queues | grep metering" and all the
> > queues are empty.
> >
> >
> > Do I need to change anything in ceilometer.conf or on the controller
> > nodes ? Currently, I am working only with the compute node and only
> > running ceilometer queries from controller node.
> >
> >
> > Thanks
> >
> >
> > Regards,
> > Kapil Agarwal
> >
> > On Thu, Feb 25, 2016 at 12:20 PM, gordon chung <g...@live.ca> wrote:
> >
> >
> >   at quick glance, it seems like data is being generated[1]. if you
> > check
> >   your queues (rabbitmqctl list_queues for rabbit), do you see
> > any items
> >   sitting on notification.sample queue or metering.sample
> > queue? do you
> >   receive other meters fine? maybe you can query db directly to
> > verify
> >   it's not a permission issue.
> >
> >   [1] see: 2016-02-25 13:36:58.909 21226 DEBUG
> > ceilometer.pipeline [-]
> >   Pipeline meter_sink: Transform sample
> >  >   at 0x7f6b3630ae50> from 0 transformer _publish_samples
> >   /usr/lib/python2.7/dist-packages/ceilometer/pipeline.py:296
> >
> >   On 25/02/2016 8:43 AM, Kapil wrote:
> >   > Below is the output of ceilometer-agent-ipmi in debug mode
> >   >
> >   > http://paste.openstack.org/show/488180/
> >   > ᐧ
> >   >
> >   > Regards,
> >   > Kapil Agarwal
> >   >
> >   > On Wed, Feb 24, 2016 at 8:18 PM, Lu, Lianhao
> > <lianhao...@intel.com
> >
> >   > <mailto:lianhao...@intel.com>> wrote:
> >   >
> >   > On Feb 25, 2016 06:18, Kapil wrote:
> >   >  > Hi
> >   >  >
> >   >  >
> >   >  > I discussed this problem with gordc on the telemetry IRC
> > channel
> >   > but I
> >   >  > am still facing issues.
> >   >  >
> >   >  > I am running the ceilometer-agent-ipmi on the compute
> > nodes, I
> >   > changed
> >   >  > pipeline.yaml of the compute node to include the ipmi
> > meters and
> >   >  > resource as "ipmi://localhost".
> >   >  >
> >   >  > - name: meter_ipmi
> >   >   

Re: [openstack-dev] [ceilometer] Unable to get IPMI meter readings

2016-03-03 Thread Kapil
So, we upgraded our openstack install from Juno to Kilo 2015.1.1
Not sure if this fixed some stuff, but I can now get samples for
hardware.ipmi.(fan|temperature). However, I want to get
hardware.ipmi.node.power samples and I get the following error in the
ceilometer log-

ERROR ceilometer.agent.base [-] Skip loading extension for
hardware.ipmi.node.power

I edited pipeline.yaml as follows-
sources:
- name: meter_ipmi
  interval: 10
  resources:
  - "ipmi://"
  meters:
  - "hardware.ipmi.node.power"
  sinks:
  - ipmi_sink
sinks:
 - name: ipmi_sink
  transformers:
  publishers:
  - notifier://?per_meter_topic=1

I also checked "rabbitmqctl list_queues | grep metering" and all the queues
are empty.

Do I need to change anything in ceilometer.conf or on the controller nodes
? Currently, I am working only with the compute node and only running
ceilometer queries from controller node.

Thanks

Regards,
Kapil Agarwal

On Thu, Feb 25, 2016 at 12:20 PM, gordon chung <g...@live.ca> wrote:

> at quick glance, it seems like data is being generated[1]. if you check
> your queues (rabbitmqctl list_queues for rabbit), do you see any items
> sitting on notification.sample queue or metering.sample queue? do you
> receive other meters fine? maybe you can query db directly to verify
> it's not a permission issue.
>
> [1] see: 2016-02-25 13:36:58.909 21226 DEBUG ceilometer.pipeline [-]
> Pipeline meter_sink: Transform sample  at 0x7f6b3630ae50> from 0 transformer _publish_samples
> /usr/lib/python2.7/dist-packages/ceilometer/pipeline.py:296
>
> On 25/02/2016 8:43 AM, Kapil wrote:
> > Below is the output of ceilometer-agent-ipmi in debug mode
> >
> > http://paste.openstack.org/show/488180/
> > ᐧ
> >
> > Regards,
> > Kapil Agarwal
> >
> > On Wed, Feb 24, 2016 at 8:18 PM, Lu, Lianhao <lianhao...@intel.com
> > <mailto:lianhao...@intel.com>> wrote:
> >
> > On Feb 25, 2016 06:18, Kapil wrote:
> >  > Hi
> >  >
> >  >
> >  > I discussed this problem with gordc on the telemetry IRC channel
> > but I
> >  > am still facing issues.
> >  >
> >  > I am running the ceilometer-agent-ipmi on the compute nodes, I
> > changed
> >  > pipeline.yaml of the compute node to include the ipmi meters and
> >  > resource as "ipmi://localhost".
> >  >
> >  > - name: meter_ipmi
> >  >   interval: 60
> >  >   resources:
> >  >   - ipmi://localhost meters: - "hardware.ipmi.node*" -
> >  >   "hardware.ipmi*" - "hardware.degree*" sinks: -
> meter_sink I
> >  > have ipmitool installed on the compute nodes and restarted the
> >  > ceilometer services on compute and controller nodes. Yet, I am not
> >  > receiving any ipmi meters when I run "ceilometer meter-list". I
> also
> >  > tried passing the hypervisor IP address and the ipmi address I get
> >  > when I run "ipmitool lan print" to resources but to no avail.
> >  >
> >  >
> >  > Please help in this regard.
> >  >
> >  >
> >  > Thanks
> >  > Kapil Agarwal
> >
> > Hi Kapil,
> >
> > Would you please turn on debug/verbose configurations and paste the
> > log of ceilometer-agent-ipmi on http://paste.openstack.org ?
> >
> > -Lianhao Lu
> >
>  __
> > 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
> >
>
> --
> gord
> __
> 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] [ceilometer] Unable to get IPMI meter readings

2016-02-25 Thread Kapil
Below is the output of ceilometer-agent-ipmi in debug mode

http://paste.openstack.org/show/488180/
ᐧ

Regards,
Kapil Agarwal

On Wed, Feb 24, 2016 at 8:18 PM, Lu, Lianhao <lianhao...@intel.com> wrote:

> On Feb 25, 2016 06:18, Kapil wrote:
> > Hi
> >
> >
> > I discussed this problem with gordc on the telemetry IRC channel but I
> > am still facing issues.
> >
> > I am running the ceilometer-agent-ipmi on the compute nodes, I changed
> > pipeline.yaml of the compute node to include the ipmi meters and
> > resource as "ipmi://localhost".
> >
> > - name: meter_ipmi
> >   interval: 60
> >   resources:
> >   - ipmi://localhost meters: - "hardware.ipmi.node*" -
> >   "hardware.ipmi*" - "hardware.degree*" sinks: - meter_sink I
> > have ipmitool installed on the compute nodes and restarted the
> > ceilometer services on compute and controller nodes. Yet, I am not
> > receiving any ipmi meters when I run "ceilometer meter-list". I also
> > tried passing the hypervisor IP address and the ipmi address I get
> > when I run "ipmitool lan print" to resources but to no avail.
> >
> >
> > Please help in this regard.
> >
> >
> > Thanks
> > Kapil Agarwal
>
> Hi Kapil,
>
> Would you please turn on debug/verbose configurations and paste the log of
> ceilometer-agent-ipmi on http://paste.openstack.org ?
>
> -Lianhao Lu
> __
> 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] [ceilometer] Unable to get IPMI meter readings

2016-02-24 Thread Kapil
Hi

I discussed this problem with gordc on the telemetry IRC channel but I am
still facing issues.

I am running the ceilometer-agent-ipmi on the compute nodes, I changed
pipeline.yaml of the compute node to include the ipmi meters and resource
as "ipmi://localhost".

- name: meter_ipmi
  interval: 60
  resources:
  - ipmi://localhost
  meters:
  - "hardware.ipmi.node*"
  - "hardware.ipmi*"
  - "hardware.degree*"
  sinks:
  - meter_sink

I have ipmitool installed on the compute nodes and restarted the ceilometer
services on compute and controller nodes. Yet, I am not receiving any ipmi
meters when I run "ceilometer meter-list". I also tried passing the
hypervisor IP address and the ipmi address I get when I run "ipmitool lan
print" to resources but to no avail.

Please help in this regard.

Thanks
Kapil Agarwal
__
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] [oslo] zeromq work for kilo

2014-09-18 Thread Kapil Thangavelu
On Thu, Sep 18, 2014 at 4:18 AM, Flavio Percoco fla...@redhat.com wrote:

 On 09/17/2014 04:34 PM, Doug Hellmann wrote:
  This thread [1] has turned more “future focused, so I’m moving the
 conversation to the -dev list where we usually have those sorts of
 discussions.
 
  [1]
 http://lists.openstack.org/pipermail/openstack/2014-September/009253.html
 


 I saw this mentioned in the `openstack` thread but I'd like us to
 reconsider it.

 Since we've gone through the hey please don't deprecate it, I'll help
 process a couple of times with the zmq driver, I'm thinking we should
 pull it out of the code base anyway.


I think the primary issue has been two fold, one is the lack of
reviews/merges on extant patches that fix critical items that have been
outstanding for months. I think that is compounded by the other issue which
was the lack of tests. We've sprinted last week on adding in both unit
tests, the extant patches and functionally verifying them by automating
cloud deployments with zmq for the messaging driver. We're also committing
as a company to supporting it on an ongoing basis. If we get the gates
going for kilo, i don't see any reason for the churn below, if the gates
don't get going we can yank to external in kilo anyway.

cheers,

Kapil


 Here's a rough plan of what I think we should do until the zmq is
 updated and has a proper gate working:

 1. Pull it out the code base into its own repo (stackforge?)
 2. Setup the basic `oslo.messaging` gates for it
 3. Release the driver on pypi as: `oslo.messaging.zmq`
 4. Make lots of noise and make sure people using zmq knows that they
 have to install a separate package now. (I know this means creating a
 new package for many distros).

 If there are folks interested in maintaining this driver, they can still
 do it with the driver outside the code base. If it ever gets enough
 attention and maturity, it could be re-proposed for inclusion into the
 code base.

 I know there are folks interested in a broker-less solution and we now
 have the not-tested-in-production-yet amqp1.0 driver which I think is a
 very good solution and also shares most of the semantics we rely on
 protocol-wise.

 I didn't go through the whole thread so, I'm sorry if I'm repeating
 something that has already been said/proposed/discussed.

 Flavio

  On Sep 17, 2014, at 7:54 AM, James Page james.p...@ubuntu.com wrote:
 
  Signed PGP part
  Hi Li
 
  On 17/09/14 11:58, Li Ma wrote:
  The scale potential is very appealing and is something I want to
  test - - hopefully in the next month or so.
 
  Canonical are interested in helping to maintain this driver and
  hopefully we help any critical issues prior to Juno release.
 
 
  That sounds good. I just went through all the bugs reported in the
  community.
 
  The only critical bug which makes ZeroMQ malfunction is
  https://bugs.launchpad.net/oslo.messaging/+bug/1301723 and the
  corresponding review is under way:
  https://review.openstack.org/#/c/84938/
 
  Agreed
 
  Others are tagged to 'zmq' in
  https://bugs.launchpad.net/oslo.messaging
 
  Looking through Doug's suggested list of information and collating
  what I know of from our work last week:
 
  1) documentation for how to configure and use zeromq with
  oslo.messaging (note, not the version in oslo-incubator, the version
  in the messaging library repository)
 
  As part of our sprint, I worked on automating deployment of OpenStack
  + 0MQ using Ubuntu + Juju (service orchestration tool). I can re-jig
  that work into some general documentation on how best to configure
  ZeroMQ with OpenStack - the current documentation is a bit raw and
  does not talk about how to configure the oslo-messaging-zmq-receiver
  at all.
 
  I also plan some packaging updates for Debian/Ubuntu in our next dev
  cycle to make this a little easier to configure and digest - for
  example, right now no systemd unit/upstart configuration/sysv init
  script is provided to manage the zmq-receiver.
 
  I'd also like to document the current design of the ZMQ driver - Doug
  - where is the best place todo this? I thought in the source tree
  somewhere.
 
  The documentation in the oslo.messaging repository [2] would be a good
 place to start for that. If we decide deployers/operators need the
 information we can either refer to it from the guides managed by the
 documentation team or we can move/copy the information. How about if you
 start a new drivers subdirectory there, and add information about zmq. We
 can have other driver authors provide similar detail about their drivers in
 the same directory.
 
  [2]
 http://git.openstack.org/cgit/openstack/oslo.messaging/tree/doc/source
 
 
  2) a list of the critical bugs that need to be fixed + any existing
  patches associated with those bugs, so they can be reviewed early in
 kilo
 
  This blocks operation of nova+neutron environements:
 
  https://bugs.launchpad.net/oslo.messaging/+bug/1301723
   Summary: Message was sent to wrong node

Re: [openstack-dev] [oslo] zeromq work for kilo

2014-09-18 Thread Kapil Thangavelu
Hi Davanum

The two primary fixes to oslo.messaging outstanding to get things running
are

https://review.openstack.org/#/c/84938/
https://review.openstack.org/#/c/120745/

cheers,

Kapil


On Thu, Sep 18, 2014 at 11:32 AM, Davanum Srinivas dava...@gmail.com
wrote:

 Kapil,

 I see just 2 relevant reviews for zmq in the oslo.messaging queue:

 https://review.openstack.org/#/q/project:openstack/oslo.messaging+status:open+file:%255E.*zmq.*,n,z

 Are there others i am missing? (fix critical items, tests from your
 email)

 thanks,
 dims

 On Thu, Sep 18, 2014 at 10:16 AM, Kapil Thangavelu
 kapil.thangav...@canonical.com wrote:
 
 
  On Thu, Sep 18, 2014 at 4:18 AM, Flavio Percoco fla...@redhat.com
 wrote:
 
  On 09/17/2014 04:34 PM, Doug Hellmann wrote:
   This thread [1] has turned more “future focused, so I’m moving the
   conversation to the -dev list where we usually have those sorts of
   discussions.
  
   [1]
  
 http://lists.openstack.org/pipermail/openstack/2014-September/009253.html
  
 
 
  I saw this mentioned in the `openstack` thread but I'd like us to
  reconsider it.
 
  Since we've gone through the hey please don't deprecate it, I'll help
  process a couple of times with the zmq driver, I'm thinking we should
  pull it out of the code base anyway.
 
 
  I think the primary issue has been two fold, one is the lack of
  reviews/merges on extant patches that fix critical items that have been
  outstanding for months. I think that is compounded by the other issue
 which
  was the lack of tests. We've sprinted last week on adding in both unit
  tests, the extant patches and functionally verifying them by automating
  cloud deployments with zmq for the messaging driver. We're also
 committing
  as a company to supporting it on an ongoing basis. If we get the gates
 going
  for kilo, i don't see any reason for the churn below, if the gates don't
 get
  going we can yank to external in kilo anyway.
 
  cheers,
 
  Kapil
 
 
  Here's a rough plan of what I think we should do until the zmq is
  updated and has a proper gate working:
 
  1. Pull it out the code base into its own repo (stackforge?)
  2. Setup the basic `oslo.messaging` gates for it
  3. Release the driver on pypi as: `oslo.messaging.zmq`
  4. Make lots of noise and make sure people using zmq knows that they
  have to install a separate package now. (I know this means creating a
  new package for many distros).
 
  If there are folks interested in maintaining this driver, they can still
  do it with the driver outside the code base. If it ever gets enough
  attention and maturity, it could be re-proposed for inclusion into the
  code base.
 
  I know there are folks interested in a broker-less solution and we now
  have the not-tested-in-production-yet amqp1.0 driver which I think is a
  very good solution and also shares most of the semantics we rely on
  protocol-wise.
 
  I didn't go through the whole thread so, I'm sorry if I'm repeating
  something that has already been said/proposed/discussed.
 
  Flavio
 
   On Sep 17, 2014, at 7:54 AM, James Page james.p...@ubuntu.com
 wrote:
  
   Signed PGP part
   Hi Li
  
   On 17/09/14 11:58, Li Ma wrote:
   The scale potential is very appealing and is something I want to
   test - - hopefully in the next month or so.
  
   Canonical are interested in helping to maintain this driver and
   hopefully we help any critical issues prior to Juno release.
  
  
   That sounds good. I just went through all the bugs reported in the
   community.
  
   The only critical bug which makes ZeroMQ malfunction is
   https://bugs.launchpad.net/oslo.messaging/+bug/1301723 and the
   corresponding review is under way:
   https://review.openstack.org/#/c/84938/
  
   Agreed
  
   Others are tagged to 'zmq' in
   https://bugs.launchpad.net/oslo.messaging
  
   Looking through Doug's suggested list of information and collating
   what I know of from our work last week:
  
   1) documentation for how to configure and use zeromq with
   oslo.messaging (note, not the version in oslo-incubator, the version
   in the messaging library repository)
  
   As part of our sprint, I worked on automating deployment of OpenStack
   + 0MQ using Ubuntu + Juju (service orchestration tool). I can re-jig
   that work into some general documentation on how best to configure
   ZeroMQ with OpenStack - the current documentation is a bit raw and
   does not talk about how to configure the oslo-messaging-zmq-receiver
   at all.
  
   I also plan some packaging updates for Debian/Ubuntu in our next dev
   cycle to make this a little easier to configure and digest - for
   example, right now no systemd unit/upstart configuration/sysv init
   script is provided to manage the zmq-receiver.
  
   I'd also like to document the current design of the ZMQ driver - Doug
   - where is the best place todo this? I thought in the source tree
   somewhere.
  
   The documentation in the oslo.messaging repository [2] would be a good
   place to start