Updated and New Promulgation for BootStack maintained Charms

framework
1

BootStack is updating its Charm release model to align with the OpenStack release process, by having our charms under unified namespaces. For now, we’ve decided to use two namespaces, depending on the functionality of the given charm.

We’d like to get promulgation updated or added for all of our charms currently in a stable release. I’ve created the list here: https://docs.google.com/spreadsheets/d/109SXFr5EZHmH18IjqPcDPRzyscCfKHWlqSZQXl4cddo/edit?usp=sharing

Please let me know if you’d like these split out in anyway - or if a specific person would like write access to this document for tracking.

Thank you

2

For anyone curious, “BootStack” is a team from Canonical that provides managed private cloud infrastructure for customers worldwide.

3

I’d like to talk about the juju-controller charm and what it does. The team has thought about having a charm that we can deploy on controller nodes that could have endpoints for things like prometheus.

Is that what this charm is doing?

4

Ideally we’d reserve that space for our own purposes. Especially if the team means to have this charm for their use but aren’t going to want to support feedback from the community. Ideally it would just be in the namespace for the team vs promulgated.

5

@jldev Promulgation updates is underway - with the exception of the “juju-controller” charm.

I’ve also taken a look through the charms and believe that they would benefit from some clean up.

~llama-chamers

  • canonical livepatch | Juju
    – The contact information page indicated in the README (Canonical Livepatch Charm in Launchpad) doesn’t send users to anywhere that they can contact anyone from
  • advanced routing | Juju
    – Usage section: “Add to an existing application using juju-info relation.” is technically correct, but isn’t easy to understand for new users to Juju. Recommend changing this to “advanced-routing is a subordinate application that can be added to any principal.”. We don’t discuss the juju-info relation in entry-level documentation.
    – Configuration section: there are some parsing issues with the Markdown that are causing the rendering to fail
    – Contact Section: Add the mailing list URL rather than the naked email address
  • hw health | Juju
    – Contact section: You refer to “Nagios charmers”, but shouldn’t we talk about llama-charmers here?
  • juju controller | Juju
    – see below
  • logrotated | Juju
    – Build section: please move to below Testing. This will allow the usage section to appear first (which is more important for those deploying the charm)
    – Configuration section: there are errors with the formatting in this section. Please check that this is valid Markdown.
  • openstack service checks | Juju
    – Usage section: update the deploy line from cs:~canonical-bootstack/openstack-service-checks to cs:openstack-service-checks
    – Usage section: please use juju relate rather than juju add-relation
  • prometheus libvirt exporter | Juju
    – Please add Usage and Contact sections

juju-controller charm

I’m concerned about the idea of adding a charm to the charm store with the name “juju-controller”. Representing the controller as an application in the controller model is actually on the roadmap.

Using “juju” in the title might be interpreted as official. And “controller” sounds a lot like the controller is being deployed as a charm.

~bootstack-chamers

  • etckeeper | Juju
    – Overview: there are some line breaks that are causing rendering issues on the charm’s webpage
  • glance sync | Juju
    – Line breaks that are causing rendering issues on the charm’s webpage
  • sudo-pair (~llama-charmers/sudo-pair?)
    – could you please confirm which charm to promote? it looks like there are 3 options
  • sysconfig | Juju
    – “Governor” section: there are syntax(s) error preventing this paragraph to render properly
  • userdir ldap | Juju
    – Would this charm benefit from promulgation? Its description makes it look very specific: “Install the Canonical userdir-ldap package and configure it for use with Canonical infra.”
6

These charms, bar juju-controller, have been promulgated.

7

@timClicks - Thank you. I have taken an action item to go through the listed projects and clean-up the READMEs. I’ll also update our standards document to exclude README.md from our normal 80-character line limit, since it breaks rendering.

sudo pair | Juju is now in the correct namespace and ready for promulgation.

8

Hey, the new promulgated charms Nagios and NRPE from llama-charmers don’t have a bug URL set anymore on the charm store. I haven’t checked the other charms, but they might have the same issue.

9

I created the bugs for Nagios and NRPE here.

10

A missing bug url on the Charm Store isn’t a bug with the project, so I’ve closed those as invalid. I am still waiting on the Juju team to restore my write permissions to the charm store, so I can fix the bug urls. At the moment, only the core Juju team has access to update my projects.

11

@jldev, sorry for the noise. Feel free to share where you want such issues filed (if at all) if not on the project bug pages.

So, where did this land? Is this promulgation for the community or for the Bootstack team?

12

Sorry that this has languished a few weeks @jldev. I do really appreciate that you took the time to address those nits.

Actions taken this morning:

  • cs:~bootstack-charmers/sudo-pair-0 promulgated to cs:sudo-pair-0
  • permissions fixed, you should be able to update the charms by yourself (as a member of ~bootstack-charmers or ~llama-chamers)from here

Let me know if you have any trouble pushing the new revisions up.

13

@timClicks I have a couple of backports I need to release, and ran into a couple charms I still do not have write access to. I did a full test and found permissions still missing on the following charms:

llama-charmers does not have access to: grafana, graylog, prometheus2, mongodb, memcached, nagios, nrpe, prometheus-alertmanager, prometheus-blackbox-exporter, charm-prometheus-ceph-exporter, prometheus-openstack-exporter, rsyslog, rsyslog-forwarder-ha, telegraf

bootstack-charmers does not have access to: thruk-agent, thruk-external-agent

I also found one charm from the original list which did not get promulgated: thruk-master

14

@szeestraten - The BootStack juju-controller charm will continue to be supported and we are open to community input/contributions. However, we need to have an internal conversation to determine if it is appropriate for promulgation at this time.