Monty Taylor <> writes:

> On 10/29/18 10:47 AM, Doug Hellmann wrote:
>> Monty Taylor <> 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 [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?
>> 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.


OpenStack Development Mailing List (not for usage questions)

Reply via email to