[openstack-dev] [publiccloud-wg][sdk][osc][tc] Extracting vendor profiles from openstacksdk

Mohammed Naser mnaser at vexxhost.com
Tue Oct 16 22:50:06 UTC 2018


I'm in support, mainly for quite a few reasons:

- The vendor data should/might need to be be released often.  If a
provider makes a change, it'd be nice that you can pick it up without
changing everything else that sits in your system (and potentially
breaking other things)
- We can add some very sort of basic gating that at least make sure
the endpoints are responding
- If we want to add a new region, we really shouldn't have to go
through many hours of OpenStack SDK jobs to pick them up

I'm all for it!
On Mon, Oct 15, 2018 at 11:04 PM Monty Taylor <mordred at inaugust.com> wrote:
>
> Heya,
>
> 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?
>
> Thanks!
> Monty
>
> [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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Mohammed Naser — vexxhost
-----------------------------------------------------
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mnaser at vexxhost.com
W. http://vexxhost.com



More information about the OpenStack-dev mailing list