[openstack-dev] [publiccloud-wg][sdk][osc][tc] Extracting vendor profiles from openstacksdk
mordred at inaugust.com
Mon Oct 29 18:27:23 UTC 2018
On 10/29/18 10:47 AM, Doug Hellmann wrote:
> Monty Taylor <mordred at inaugust.com> writes:
>> 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
>> 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
>> 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.
More information about the OpenStack-dev