Monty Taylor <mord...@inaugust.com> writes: > On 10/29/18 10:47 AM, Doug Hellmann wrote: >> Monty Taylor <mord...@inaugust.com> writes: >> >>> 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  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  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  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? >> >> I understand the benefit of separating the data files from the SDK, but >> what is the benefit of separating the data files from the code that >> reads them? > > I'd say primarily so that the same data files can be used from other > languages. (similar to having the service-types-authority data exist > separate from the python library that consumes it.) > > Also - there is a separation of concerns, potentially. The review team > for a vendor-data repo could just be public cloud sig folks - and what > they are reviewing is the accuracy of the data. The python code to > consume that and interpret it is likely a different set of humans.
The argument about languages is more convincing but I'll accept both answers. The plan makes sense to me, now. Doug __________________________________________________________________________ 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