| jwysogla | tkajinam: When working on Aetos, I introduced a new "prometheus" service type (We agreed on it during the PTG). Now we got told we should register it in https://opendev.org/openstack/service-types-authority and we agreed that "prometheus" doesn't follow the naming convention from that repo. So we want to change it before Flamingo releases. We were deciding between "metric-storage" and | 08:27 |
|---|---|---|
| jwysogla | "tenant-metric". There weren't any strong opinions, but people seemed to lean more towards "metric-storage". I wonder if you have any input / opinion on the topic? If not, I want you to at least be aware of this. | 08:27 |
| jwysogla | On a related note, we originally chose "prometheus", to also allow prometheus (not only aetos) to be registered as a keystone endpoint, since the APIs are the same. This is why people lean more towards "metric-storage" now. But we don't want to send keystone tokens to a non-openstack service, so there needs to be a way distinguish between Aetos and Prometheus. The observabilityclient currently | 08:32 |
| jwysogla | checks the service name to do that and so it requires service_type='prometheus' && service_name='aetos' for Aetos. There are opinions, that requiring a particular service name isn't correct. I wonder what do you think as I know you have way more experience in the area than me. | 08:32 |
| opendevreview | Merged openstack/ceilometer master: Deprecate pollster builder https://review.opendev.org/c/openstack/ceilometer/+/953446 | 09:40 |
| opendevreview | Merged openstack/ceilometer master: Fix outdated package/service name in RDO https://review.opendev.org/c/openstack/ceilometer/+/955702 | 09:40 |
| opendevreview | Merged openstack/python-aodhclient master: Drop reference to ceilometerclient https://review.opendev.org/c/openstack/python-aodhclient/+/953470 | 09:40 |
| tkajinam | jwysogla, between these two, metric storage would be better (as tenant is an old terminology and in OpenStack everything should be aware of tenant/project) | 11:25 |
| tkajinam | one concern is that "metric" is what has been used for gnocchi (though it has never been accepted officially due to its governance). metric-storage might be too similar though I think we are ok as long as we use different strings | 11:26 |
| tkajinam | jwysogla, regarding the endpoint discovery I think using service_type is a common approach made in multiple clients (for example aodhclient uses service_type='alarming'), and may be preferred | 11:28 |
| jwysogla | The thing about the endpoint discovery is if we should also require service_name='aetos'. That's something other services aren't doing I think. The alternative would be to not check the service name and check only the service type. With that, we'd always assume it's Aetos, we'd always send the keystone tokens and Prometheus access would need to be configured the same as before (either through a | 12:13 |
| jwysogla | file, env var or by using the PrometheusAPIClient class and including the config into a /etc/service/service.conf, which is what Watcher currently does). | 12:13 |
| jwysogla | hmm, maybe we could just mention users can create a keystone endpoint for prometheus with a warning that keystone tokens are going to be sent to a non-openstack service (prometheus). | 12:15 |
| jwysogla | I think that sounds quite fine, that people should expect an authentication attempt will be made for all endpoints registered in Keystone. | 12:16 |
| tkajinam | jwysogla, +1. I don't think people may attempt to register prometheus endpoint to keystone without actual auth integration. | 14:58 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!