| opendevreview | Stephen Finucane proposed openstack/service-types-authority master: docs: Fix typo https://review.opendev.org/c/openstack/service-types-authority/+/953876 | 10:02 |
|---|---|---|
| opendevreview | Stephen Finucane proposed openstack/service-types-authority master: Apply ruff https://review.opendev.org/c/openstack/service-types-authority/+/953562 | 10:02 |
| opendevreview | Stephen Finucane proposed openstack/service-types-authority master: Remove packaging files https://review.opendev.org/c/openstack/service-types-authority/+/953563 | 10:02 |
| opendevreview | Stephen Finucane proposed openstack/service-types-authority master: Add retired attribute https://review.opendev.org/c/openstack/service-types-authority/+/953584 | 10:02 |
| opendevreview | Stephen Finucane proposed openstack/service-types-authority master: Mark retired APIs as such https://review.opendev.org/c/openstack/service-types-authority/+/930811 | 10:02 |
| opendevreview | Stephen Finucane proposed openstack/service-types-authority master: Post-ruff follow-ups https://review.opendev.org/c/openstack/service-types-authority/+/955175 | 10:02 |
| sean-k-mooney | im kind of disturbed to see that https://opendev.org/openstack/os-service-types exists, from my perspectives SIG dont own any athoritive repos in general. this to me is at best infromational. the athoritive source of what service types are used/supported is the project that implement that service endpoint. espically given the api sig has been defunt for years im srupised we are | 10:10 |
| sean-k-mooney | not retiring this repo configuring it via project.yaml offically os-service-types is actully a deliveralble of the sdk by they way https://github.com/openstack/governance/blob/master/reference/projects.yaml#L1794-L1796 it grew out of shade and has never actully been a repo manged by the api sig https://github.com/openstack/governance/blob/master/reference/sigs-repos.yaml as far | 10:10 |
| sean-k-mooney | as i am aware this has never been a tc devliverable and i dont think new service or renames need to go though the tc. it could but the existing of this repo has never been documened in the project creation guide https://docs.openstack.org/project-team-guide/preface.html that just links to the open dev one https://docs.opendev.org/opendev/infra-manual/latest/creators.html which | 10:10 |
| sean-k-mooney | obvioulsy does not link to any opnestack sepcific requirements. the end result of this is https://opendev.org/openstack/aetos is not in os-service-types becaue no one including the tc even mentioned that new service should be listed there. from https://specs.openstack.org/openstack/watcher-specs/specs/2025.2/approved/prometheus-multitenancy-support.html#proposed-change we have | 10:10 |
| sean-k-mooney | capture the details form teh telemetry team that """It’s expected for Aetos to always have an endpoint registered in keystone with service name ‘aetos’ and service type ‘prometheus’.""" | 10:10 |
| sean-k-mooney | what do i have to tell the telemetry team to do? update os-service-types and have the sdk team review/merge it or do they have to come to the TC? or can we proceed without updating it since the services are the athoritive soruce? | 10:13 |
| opendevreview | Merged openstack/service-types-authority master: docs: Fix typo https://review.opendev.org/c/openstack/service-types-authority/+/953876 | 10:14 |
| sean-k-mooney | ill also point out that since microversion were first intoduced by nova in 2.1 we have supproted registring nova as nova_legacy with service type compute_legacy and that has never been tracked in os-service-types. we dont actully need to fix that as we resolved to deprecate 2.0 this cycle to remove in a future release | 10:22 |
| sean-k-mooney | https://specs.openstack.org/openstack/nova-specs/specs/2025.2/approved/deprecate-v20-api.html | 10:22 |
| fungi | sean-k-mooney: where did sigs come into that? the sigs discussion tangent was about possibly adopting x/gerrit-dash-creator | 11:59 |
| sean-k-mooney | oh ok i tought hte assertion was that it was a deliverbale of the api sig | 11:59 |
| sean-k-mooney | i may have mis read that scrol back. | 11:59 |
| sean-k-mooney | when i clicked into the goverance change form stephen i tought the assertion "was movign it under sdk" impliing it was not already and sdk devlierbale was not a good idea | 12:01 |
| sean-k-mooney | fungi: anyway the main point of my rant is this repos existing and if it need to be udpated is not documemnt and not common knowladge, its obviouly not well maintianed so do we actully need to ask the telemetry team to add aetos to it and the promethus service type? and if so does that need tc involvement | 12:02 |
| fungi | though yes looking through the projects.yaml git history, openstack/os-service-types was added as a deliverable of the OpenStackSDK team in https://review.openstack.org/523520 about eight years ago | 12:02 |
| fungi | (previously the shade team) | 12:02 |
| sean-k-mooney | which realsiticlly ws the same team/people that was just a brandign exersize fo sort and consolidation | 12:03 |
| fungi | it was added to the shade team about half a year before the rename | 12:03 |
| fungi | in https://review.openstack.org/480748 | 12:04 |
| sean-k-mooney | so i think this grow out of monty trying to normalise the way that openstack serivce were deployed in diffent public clouds. | 12:04 |
| sean-k-mooney | i.e. getting away form needing to have shade paper over those diffences | 12:04 |
| sean-k-mooney | by trying to standardise it | 12:04 |
| sean-k-mooney | but the topic of os-service-types has never come up in any installer converstaion i have ever had | 12:05 |
| sean-k-mooney | it might serve as a standard registry of know service type alias | 12:06 |
| fungi | "The API-WG recently defined the publication of data about the official service types and their historical aliases. os-service-types is a library to consume and encapsulate that data properly for anyone using python." (from https://review.opendev.org/c/openstack/project-config/+/475080 ) | 12:06 |
| sean-k-mooney | but i dont think any installer has ever looked at it as a source of truth | 12:06 |
| fungi | so yeah it came out of api sig work, but landed in shade | 12:06 |
| fungi | (though we didn't have sigs back then, it was the api working group at the time) | 12:07 |
| fungi | now all the above is about the consuming library. openstack/service-types-authority was officially added to the tc repos list by https://review.openstack.org/279780 about 1.5 years prior to the existence of the openstack/os-service-types library | 12:10 |
| fungi | and the project-config dependency for that refers to discussion here: https://lists.openstack.org/pipermail/openstack-dev/2016-February/086269.html | 12:11 |
| sean-k-mooney | fungi: isint that the website | 12:12 |
| sean-k-mooney | i.e. https://service-types.openstack.org/ | 12:13 |
| fungi | correct. and yes, the api sig (nee wg) was originally expected to have votes on that content, but it was created as owned by the tc, where it has resided ever since, so it wasn't really inherited so much as the tc was left as the only reviewers after the api sig ceased activity | 12:13 |
| sean-k-mooney | whic is generated form the lib | 12:13 |
| sean-k-mooney | right but the evolution of the service api is governed by the service core teams. the sig/working groups were created to help guide that process but they were never the source of truth of how it evovled | 12:15 |
| sean-k-mooney | so the idea that the service project woudl not have voting right and the sig would seams backwards to me | 12:15 |
| fungi | the lib is the tooling for consuming it, but https://opendev.org/openstack/service-types-authority/src/branch/master/service-types.yaml is the source data that gets transformed into json for publication | 12:16 |
| fungi | os-service-types (lib) != service-types-authority (data) | 12:16 |
| sean-k-mooney | anyway i guess im still not any closer to the answer, does aetos need to be added with the prometheus service type | 12:16 |
| sean-k-mooney | fungi:... so whats the point of https://opendev.org/openstack/os-service-types/src/branch/master/os_service_types/data/service-types.json then | 12:17 |
| sean-k-mooney | sinct that is the data that the lib uses | 12:17 |
| fungi | it look like the proposal bot generates a copy of the public content from service-types-authority for embedding in os-service-types, i guess to eliminate network lookups though the os-service-types maintainers probably know better than i do | 12:20 |
| sean-k-mooney | ok so the json data in os-service-types is generate form the yaml file in service-tyeps-authority | 12:20 |
| fungi | os_service_types/service_types.py has a code comment for class ServiceTypes which explains | 12:21 |
| fungi | "The Service Types Authority data will be either pulled from its remote location or from local files as is appropriate." | 12:21 |
| fungi | so it can use either | 12:21 |
| fungi | (the comment goes into much more detail but that's the tl;dr) | 12:21 |
| sean-k-mooney | this all seams vastly over complictate for soemthign that shoudl be done exlicivly in the servervice repos | 12:22 |
| fungi | so if you're going to add aetos then looks like it should be proposed to service-types-authority which will then propagate to the convenience copy in os-service-types | 12:23 |
| sean-k-mooney | well my orgial question were do we need too, since its not document as part of project creation, does the tc need to vote on it? are they ok with using promethus as the service type which si what the telemetry project inteded to use and how shold i comunicate this to the telementry team | 12:25 |
| fungi | what would be the model fr putting it in the service repos? how do you propagate that to public clouds running ancient versions of those services? | 12:25 |
| sean-k-mooney | for example woudl it be better to have this dicussed at the next tc meeting and leave the tc liason comunciate it | 12:25 |
| fungi | hopefully tc-members can chime in on that when they're around | 12:26 |
| sean-k-mooney | fungi: i was thinkign seupt tools entry points or somethign else discoverable + docs or in the openapi schemea if we could. | 12:27 |
| sean-k-mooney | i belvie we do actully descibe this in the install guide already | 12:27 |
| sean-k-mooney | i.e. how to create the keystone endpoints | 12:27 |
| fungi | yeah, and that works for new/updated deployments | 12:28 |
| fungi | but can't necessarily be added post-facto to clouds that pre-date it without work being done by the operators of those older deployments | 12:28 |
| sean-k-mooney | right but clodu that predate it are also not using the service-type-athoruity stuff | 12:29 |
| sean-k-mooney | no are then non offical client | 12:29 |
| fungi | but clients communicating with those clouds could be | 12:29 |
| sean-k-mooney | stephen was interested in this because gophercloud was not using it | 12:29 |
| sean-k-mooney | and he was trying to impovve how it did endpoint discovery | 12:29 |
| fungi | e.g. we use modern versions of openstackclient with rackspace classic | 12:30 |
| sean-k-mooney | yep but you need the alisas adn the sdk import of shad to make that work properly | 12:30 |
| sean-k-mooney | that why it still has "profiles" for rax and vexhost ectra | 12:30 |
| fungi | which is also the reason for the historical alias data in service-types-authority | 12:30 |
| fungi | but yes more of that could be embedded in the client profiles i suppose | 12:31 |
| sean-k-mooney | i suspect that no client has ever been created that exclivily relies on the service athority | 12:33 |
| sean-k-mooney | like the officaly clinet/sdk has addtional fallback | 12:33 |
| sean-k-mooney | dont get me wrong, i spoke to stephen seperatly about this and i fully agree with there point that the one thing openstack does not need more of is inconsitency | 12:35 |
| sean-k-mooney | but we are missing docs for this in the project creation guide (because that need an actual proper chapter to descibe the opnestack specific parts) i dont think this was ever integrated with interopo requirements | 12:35 |
| sean-k-mooney | and if im being honest i did not kwno this even existied until today | 12:36 |
| sean-k-mooney | so i dont think its well known that https://opendev.org/openstack/service-types-authority is a thing in the comunity | 12:36 |
| sean-k-mooney | like i woudl expect installer tools to use it to validate the endpoitn they are creating ectra | 12:37 |
| fungi | yeah, i mean, openstacksdk/client should also be usable in environments where the client can reach the cloud api endpoint but not the internet at large, so needs a local fallback even if that results in a stale dataset contemporary with the client/lib version they installed | 12:37 |
| sean-k-mooney | ya well there are a few ways to do that such as a dep on the lib. and the fact it can also match on the service name as a fallback | 12:39 |
| sean-k-mooney | or its own logic | 12:39 |
| sean-k-mooney | liek the profiles | 12:39 |
| fungi | right, openstacksdk consumes it in openstack.config.cloud_region.from_conf() but then relies on profiles to supply overrides for nonconforming providers | 12:41 |
| sean-k-mooney | fungi: anywya thanks for the feed back. lets wait for the tc folks to come online, summery for tc, 1 do we need to add aetos to server-types-athority, 2 is it ok to use "prometheus" as the offial service type of Aetos, 3 does it need TC apporval beyond a gerrit review to update the service-types-athority repo, 4 who will comunicate this to the telementry team. i have not brought | 12:43 |
| sean-k-mooney | this up with them yet. | 12:43 |
| fungi | sean-k-mooney: i have a feeling "prometheus" doen't meet the requirements listed in the README.rst under the "Naming" section | 12:45 |
| fungi | the indication there is that you need a descriptive noun, and "prometheus" isn't a generic thing it's the name of an arbitrary open source project | 12:47 |
| sean-k-mooney | the problem is that meter/metics/telemetry i think are all ready taken by ceiometer/gnocci | 12:47 |
| sean-k-mooney | since Aetos is a reverse proxy providing keystone auth over the prometheus api and will never supprot other backend | 12:47 |
| sean-k-mooney | using a generic name may not work | 12:48 |
| sean-k-mooney | monitoring is used by monasca as well | 12:49 |
| fungi | in the telemetry team's view, what does aetos do that distinguishes it from ceiometer/gnocci? i.e. if prometheus ceased to exist what else would aetos use instead, and what's a good general descriptor for that? | 12:49 |
| sean-k-mooney | so moniotring means monasca, metering/telemetry means ceilometers api which is now removed | 12:49 |
| sean-k-mooney | fungi: if prometheus ceased to exist aetos would too | 12:50 |
| fungi | i wonder if aetos reimplements a metering or telemetry api then? could be an argument for restoring the endpoint name even if the api isn't backward-compatible with the one that used to exist, as long as clients can reliably differentiate between them | 12:51 |
| sean-k-mooney | aetos exist bcause prometheus does not have native multi tenacy supprot | 12:51 |
| sean-k-mooney | fungi: no it wont provide ceilometer compatablity apis | 12:51 |
| fungi | oh, so aetos is supplying prometheus-as-a-service to end users? | 12:51 |
| sean-k-mooney | kind of yes | 12:51 |
| sean-k-mooney | it will use there keyston token to limit what they can see | 12:52 |
| fungi | sort of like magnum makes kubernetes multi-tenant capable or trove dbaas or... | 12:52 |
| sean-k-mooney | allowing safe usage in aodh and horizon(grian-ui) but also via the cli by the python-obeserviablity client | 12:52 |
| fungi | mmm, so not general purpose prometheus for users, but prometheus views of openstack resources then? | 12:53 |
| sean-k-mooney | fungi: so the way this is shaping up celiometer now supprot a promethous scrap endpoint and promethous is just acting as a time series database/metrics sotre | 12:53 |
| * fungi has never used prometheus but understands it's similar to snmp or statsd/grafana | 12:53 | |
| sean-k-mooney | fungi: no the idea of providing it as a keystone endpoint is partly to allow access via osc using the python-observablity client plugin | 12:54 |
| fungi | okay, and aetos is giving users limited prometheus api access, not just implementing an api in front of prometheus and using it for a database? | 12:54 |
| sean-k-mooney | so non admin can get tenatn metrics similar to how that work with ceilometer/gnoccii | 12:54 |
| sean-k-mooney | fungi: correct its just a reverse proxy that add the auth part | 12:55 |
| sean-k-mooney | basiclly its enforcign that a keystone token is requried then checking the roles and if it does nto ahve the admin or service role it will enfoce that the project id of the toke is added as a required lable for the metic quieis | 12:56 |
| sean-k-mooney | i.e. ensuring that you can only see metrics related to your openstack resouces | 12:56 |
| fungi | looking at magnum as a similar case, even though it only (afaik) supports kubernetes protocols and resources (or maybe those of kubernetes forks/derivatives), it still calls the service container-infrastructure-management | 12:57 |
| fungi | rather than calling it "kubernetes" | 12:57 |
| sean-k-mooney | well magnum supprot other contaner engines like docker swarm and it use to supprot "nomade"? | 12:58 |
| sean-k-mooney | it snot a k8s as a service proejct or it didnt actully sart that way | 12:58 |
| sean-k-mooney | it was ment to be geneic contaienr plathforms as a serivce . after the split the contaienr as a service part into zun | 12:59 |
| fungi | so back to the what-ifs, say prometheus ends up in a hostile takeover and a fork emerges and people start using aetos with "primetheos" instead, would calling the aetos service type "prometheus" still be appropriate? | 12:59 |
| sean-k-mooney | ya i was wonderign that too. i was orginally surrpised it was not "aetos" | 13:00 |
| fungi | like calling things "docker" even when they're using podman | 13:00 |
| sean-k-mooney | but ya taking the valkey vs redis split as a recent example promethus made me a littel uncormfortabel | 13:00 |
| sean-k-mooney | if there was a redis as a service proejct we woudl call it keystore or similar as the service-type | 13:01 |
| sean-k-mooney | not redis or valkey | 13:02 |
| mnasiadka | sean-k-mooney: Magnum only supports Kubernetes nowadays, other COE drivers have been dropped. | 14:22 |
| sean-k-mooney | sure but the service type was creted when it supproted other COEs | 14:23 |
| sean-k-mooney | and if maintainers were willing to step up its in scope for someone to writhe a new COE driver adn contibute it to mangnum | 14:23 |
| mnasiadka | Yup, I’m all in for project/product agnostic naming | 14:24 |
| sean-k-mooney | any suggetion on what Aetos could use. naming thigs is hard | 14:24 |
| sean-k-mooney | maybe somethign like tenant-metrics? | 14:25 |
| sean-k-mooney | i only really care about this because the telemery team want to add supprot for aetos to watcher and as part fo that we want ot do a startup check to conform ateos is deploy if you enabel the aetos data souce by checkign the keystone endpoint is registred | 14:28 |
| sean-k-mooney | so we need to do that via the service type | 14:28 |
| sean-k-mooney | or name | 14:28 |
| mnasiadka | tenant-metrics sounds good to me | 19:47 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!