Open Stack

Monty Taylor <mordred at inaugust.com> writes:

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

Doug