Manual Review - charmed-openstack-exporter

store-requests
1

Hi :wave:

As member of the Solutions Engineering Team, we are creating the charmed-openstack-exporter that will be used on openstack-exporter-k8s and openstack-exporter-operator to unblock our workflow with observability of OpenStack services.

The snap needs to access the path /etc/openstack using system-files to be able to access some configurations.

Thanks

2

Hey @gabrielcocenza

Could you please clarify which files are required and why? It could possibly be worth to narrow the scope to the concrete files that are required rather than the whole folder

Thanks

3

hey @gabrielcocenza could you please provide the above information to us, it will help us to process your request faster

4

Hey, sorry for the late reply. I took some days as annual leave :beach_umbrella:

Just to give some more context, this exporter already exists at GitHub - openstack-exporter/openstack-exporter: OpenStack Exporter for Prometheus under the name golang-openstack-exporter, but due to the limitation of time of the upstream maintainer, the necessary changes to unblock our workflow are taking too long.

This snap is just a way of us having a little bit more autonomy of applying more urgent patches and be able to delivery the snap for Canonical products with the necessary changes, trying to be as close as possible from the upstream code.

The upstream code already uses this interface and if we limit we’ll need to be strict with the filename that we accept by the user.

The plugin right now is:

plugs:
  etc-openstack:
    interface: system-files
    read:
    - /etc/openstack

The read access to the /etc/openstack is because the openstack-exporter accepts a custom file with openstack client configuration. E.g:

clouds:
  default:
    region_name: {{ openstack_region_name }}
    identity_api_version: 3
    identity_interface: internal
    auth:
      username: {{ keystone_admin_user }}
      password: {{ keystone_admin_password }}
      project_name: {{ keystone_admin_project }}
      project_domain_name: 'Default'
      project_domain_id: 'Default' // This can replace "project_domain_name"
      user_domain_name: 'Default'
      auth_url: {{ admin_protocol }}://{{ kolla_internal_fqdn }}:{{ keystone_admin_port }}/v3
    cacert: |
      ---- BEGIN CERTIFICATE ---
      ...
    verify: true | false  // disable || enable SSL certificate verification

Then the user can pass a command like:

./openstack-exporter --os-client-config /etc/openstack/clouds.yaml

Note that the user has autonomy to name the file with any name.

Hope this clarify the need.

Thanks

5

Thanks for the explanation @gabrielcocenza

Considering that the upstream snap already uses it, it feels reasonable to assume that it is required. Thus, I think it should be fine to grant it as far as the publisher is vetted.

+1 from me for granting charmed-openstack-exporter read access to /etc/openstack via system-files interface

6

thanks @gabrielcocenza for all the required information. +1 from my end to have read access to /etc/openstack using system-files interface

7

Hey @gabrielcocenza !

Is this access required by a basic workflow? or is it needed only under certain circumstances? I ask to see if auto-connection is required or manual connection is enough.

Thanks!

8

Hey @emitorino

Yes it will have a workflow and the ideal is to work out out of the box, so auto-connections would be requeried.

Thanks for pointing this

1 Like
9

Ok thanks for the context provided.

+3 votes for, 0 votes against, granting auto-connect of system-files with read access to /etc/openstack. I have vetted the publisher. This is now live.