cinder and ceilometer metrics architecture question
Hello all, I recently came across the need to add cinder's volume telemetry data into a client's ceilometer environment. I've found that there was a patch for charm-cinder that enables the cron-tick for cinder-volume-usage-audit and implemented it in a cherry-picked fashion into my current charm (as I await timing to upgrade this charm to the released version with the patch.) Many thanks to Jorge for that config feature, and this is working properly. Referenced patch here: https://git.openstack.org/cgit/openstack/charm-cinder/commit/?id=07ae3acbb49368c58b0ad3d119ff21db39fb31c2 Unfortunately, nothing in ceilometer is picking up the oslo_message_notifications on the unit where cinder is running. I went to add the ceilometer-agent-charm to the unit, but found it's only written to pick up OS and Compute telemetry data and does not include the ceilometer-agent-notification package. I found documentation here regarding the need to start the ceilometer-agent-notifications service: https://docs.openstack.org/developer/ceilometer/install/manual.html#installing-the-notification-agent My ultimate question for the juju-charmers is whether a new ceilometer-notifications-agent-charm should be written, or if we can extend the ceilometer-agent charm that is specifically written for Compute nodes currently to auto-detect it's parent charm from the subordinate:container relationship and configure appropriately whether that is cinder or nova-compute or some "other" parent? Or, am I missing something else entirely that should be picking up these oslo_messaging_notifications from cinder-volume-usage-audit? Thank you for your time and guidance, -Drew signature.asc Description: PGP signature -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Inherited Constraints Causing LXD to Fail
On Fri, Apr 21, 2017 at 02:30:39PM -0700, James Beedy wrote: It looks like any LXD I deploy to an instance on AWS is now inheriting the constraints from the host, this is causing my LXD to fail across the board. This is slightly difficult to reproduce, as you must have spaces and subnets defined on AWS. This bug does not show do not add any 'spaces' constraints. The following will succeed: $ juju deploy ubuntu # gets machine id 0 $ juju deploy ubuntu ubuntu-lxd --to lxd:0 The following will cause the lxd deploy to fail: $ juju deploy ubuntu --constraints "spaces=myspace" # gets machine id 0 $ juju deploy ubuntu ubuntu-lxd --to lxd:0 Would --bindings "myspace" potentially help with this? Are you trying to constrain to a machine based on space, or are you trying to link your interface to a space? If it's interface linkage, I'd think that using bindings may be more ppropriate. Reading the bug, I'm sure there's still other issues with the process, but I'm wondering if --bindings might help as a workaround in the interrim. signature.asc Description: PGP signature -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Major Roadblocks - real life use cases
On Mon, May 28, 2018 at 10:23:21PM -0700, James Beedy wrote: I want to shed some light on a few blockers for me right now. 2) Maas needs better support for 3rd party drivers. * Getting my Mellanox drivers hooked up at commissioning so maas recognizes the 40Gb interfaces is taking me a few weeks now. Supporting user defined 3rd party driver should be a primary supported capability of MAAS. * how are people doing Hadoop,and Ceph and Openstack without this, possibly someone knows something I don’t know here? Hello James, I believe that MAAS 2.x's nodes-scripts (Hardware Testing and Commissioning scripts) might be helpful for any custom code or drivers you might want to inject in the commissioning process. Here is a link to the guide for these scripts. I might suggest the cript example for "Configure HPA" might provide a good template for how you might want to inject a Mellanox driver/config into your build. https://docs.maas.io/2.3/en/nodes-scripts The MAAS server has a web server serving out a docroot from /var/www/htdocs where you can drop any files you might want to curl/wget from your scripts. I believe there are environment variables for the preseeds for the IP of the MAAS server for your URL. You might also notice that you can have the script automatically install packages from any of apt, snap, or URL. You can even tag the script to automatically run on hardware with a specific PCI ID. with the for_hardware metadata field. Documentation on managing these scripts via the CLI is here: https://docs.maas.io/2.3/en/nodes-scripts-cli In MAAS 1 environments, one would have to update the curtin preseeds manually in /etc/maas/preseeds to inject scripts of this type. I do not know if the commissioning scripts also happen at deployment time (doubtful), but hopefully the install of your chosen OS will include the drivers needed, or you've found that you can add an Ubuntu package repository or PPA that contains your packages to be installed per https://docs.maas.io/2.3/en/manage-repos. I hope this information helps. Sincerely, -Drew Any feedback would be greatly appreciated. Thanks -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju signature.asc Description: PGP signature -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
