Request: guardrails for OpenStack charms + other support charms.

charmhub requests
1

Hello

I’d like to self-service create tracks for all the OpenStack charms, and our support charms. It would appear that they have no guardrails at the moment, which is preventing creation:

curl https://api.charmhub.io/v1/charm/manila-generic/tracks -X POST -H'Content-type: application/json' -H "$CHARMHUB_MACAROON_HEADER" -d '[{"name": "2023.2"}]'
{"error-list":[{"code":"missing-guardrails","message":"Missing guardrails for requested ('charm', 'PpQygXZ7e5bLaz4u4fVhIXAGqPPYRtHN') package"}]}

For the OpenStack charms (listed below), the past format for a trackname was a “word” (e.g. wallaby, xena, victoria) and the new format is “YYYY.D” where “YYYY” is the year, and “D” is 1 or 2.

For our other support charms, it varies, but is usually a form of semver, or “\d+.\d+”, or the ubuntu distro codename.

Please could you let us have the most relaxed set of guardrails for the charms?

OpenStack charms are:

  • aodh
  • barbican
  • barbican-vault
  • ceilometer
  • ceilometer-agent
  • cinder
  • cinder-backup
  • cinder-backup-swift-proxy
  • cinder-ceph
  • cinder-lvm
  • cinder-netapp
  • cinder-nimblestorage
  • cinder-purestorage
  • cinder-solidfire
  • cinder-three-par
  • designate
  • designate-bind
  • glance
  • glance-simplestreams-sync
  • gnocchi
  • heat
  • ironic-api
  • ironic-conductor
  • ironic-dashboard
  • keystone
  • keystone-kerberos
  • keystone-ldap
  • keystone-openidc
  • keystone-saml-mellon
  • magnum
  • magnum-dashboard
  • manila
  • manila-dashboard
  • manila-ganesha
  • manila-generic
  • manila-netapp
  • masakari
  • masakari-monitors
  • neutron-api
  • neutron-api-plugin-arista
  • neutron-api-plugin-ironic
  • neutron-api-plugin-ovn
  • neutron-gateway
  • neutron-openvswitch
  • nova-cell-controller
  • nova-cloud-controller
  • nova-compute
  • nova-compute-nvidia-vgpu
  • octavia
  • octavia-dashboard
  • octavia-diskimage-retrofit
  • openstack-dashboard
  • placement
  • swift-proxy
  • swift-storage
  • watcher
  • watcher-dashboard

Support charms are:

  • discoveryserver
  • hacluster
  • magpie
  • mysql-innodb-cluster
  • mysql-router
  • openidc-test-fixture
  • openstack-loadbalancer
  • pacemaker-remote
  • percona-cluster
  • rabbitmq-server
  • vault

Thanks very much Cheers Alex.

2

Hi,

Guardrails are usually suggested by the respective team that wants to take advantage of the self-service track creation functionality. We can propose a set of guardrails for the use cases you described but please check and let us know if you agree or something is amiss.

For the OpenStack charms:

the past format for a trackname was a “word” (e.g. wallaby, xena, victoria) and the new format is “YYYY.D” where “YYYY” is the year, and “D” is 1 or 2.

Does this mean that going forward there will only be tracks with the “YYYY.D” format? If so, a guardrail for this case could be \d{4}\.[12]. This would match e.g. 2023.1 and 2023.2 but not 2023.10.

For the support charms:

The semver should be covered by \d+\.\d+\.\d+ which would match e.g. 1.0.1 but not v1.2.3 or 1.0.0-alpha. For the tracks named after the ubuntu distro codenames, a suggestion would be [a-z]+. This would cover focal or jammy but not focal fossa.

All in all, the guardrails for the support charms would be:

  • \d+\.\d+\.\d+
  • \d+.\d+
  • [a-z]+

Thanks,

Odysseus

3

Hi Odysseus

Yes, that would work very for the OpenStack charms.

Yes, that would work too.

Let’s go with those and I’ll have a go at creating the channels.

Thanks very much.

Cheers, Alex.

4

Hi,

All the guardrails have been successfully created. Given that this was done for a lot of charms, please let us know if we’ve missed something.

Thanks,

Odysseus

5

Thanks very much!

Will do; I’ll go and test them now as I need to create the 2023.2 branch for the OpenStack charms.

Cheers Alex.