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 <mord...@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-requ...@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. mna...@vexxhost.com W. http://vexxhost.com __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev