Hi ![:wave: :wave:](https://forum.snapcraft.io/images/emoji/twitter/wave.png?v=12)
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
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
hey @gabrielcocenza could you please provide the above information to us, it will help us to process your request faster
Hey, sorry for the late reply. I took some days as annual leave ![:beach_umbrella: :beach_umbrella:](https://forum.snapcraft.io/images/emoji/twitter/beach_umbrella.png?v=12)
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
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
thanks @gabrielcocenza for all the required information. +1 from my end to have read access to /etc/openstack
using system-files
interface
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!
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
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.