Tobias and I were chatting at OpenStack Days Nordic about the Public Cloud Working Group potentially taking over as custodians of the vendor profile information [0][1] we keep in openstacksdk (and previously in os-client-config)

I think this is a fine idea, but we've got some dancing to do I think.

A few years ago Dean and I talked about splitting the vendor data into its own repo. We decided not to at the time because it seemed like extra unnecessary complication. But I think we may have reached that time.

We should split out a new repo to hold the vendor data json files. We can manage this repo pretty much how we manage the service-types-authority [2] data now. Also similar to that (and similar to tzdata) these are files that contain information that is true currently and is not release specific - so it should be possible to update to the latest vendor files without updating to the latest openstacksdk.

If nobody objects, I'll start working through getting a couple of new repos created. I'm thinking openstack/vendor-profile-data, owned/managed by Public Cloud WG, with the json files, docs, json schema, etc, and a second one, openstack/os-vendor-profiles - owned/managed by the openstacksdk team that's just like os-service-types [3] and is a tiny/thin library that exposes the files to python (so there's something to depend on) and gets proposed patches from zuul when new content is landed in openstack/vendor-profile-data.

How's that sound?


[0] http://git.openstack.org/cgit/openstack/openstacksdk/tree/openstack/config/vendors [1] https://docs.openstack.org/openstacksdk/latest/user/config/vendor-support.html
[2] http://git.openstack.org/cgit/openstack/service-types-authority
[3] http://git.openstack.org/cgit/openstack/os-service-types

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to