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 [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.
__________________________________________________________________________
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
