Re: [openstack-dev] [publiccloud-wg][sdk][osc][tc] Extracting vendor profiles from openstacksdk
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. 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
Re: [openstack-dev] [publiccloud-wg][sdk][osc][tc] Extracting vendor profiles from openstacksdk
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. __ 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
Re: [openstack-dev] [publiccloud-wg][sdk][osc][tc] Extracting vendor profiles from openstacksdk
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? Doug > > Thanks! > Monty > > [0] > http://git.openstack.org/cgit/openstack/openstacksdk/tree/openstack/config/vendors > [1] > https://docs.openstack.org/openstacksdk/latest/user/config/vendor-support.html > [2] http://git.openstack.org/cgit/openstack/service-types-authority > [3] http://git.openstack.org/cgit/openstack/os-service-types > > __ > 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 __ 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
Re: [openstack-dev] [publiccloud-wg][sdk][osc][tc] Extracting vendor profiles from openstacksdk
I'm in support, mainly for quite a few reasons: - The vendor data should/might need to be be released often. If a provider makes a change, it'd be nice that you can pick it up without changing everything else that sits in your system (and potentially breaking other things) - We can add some very sort of basic gating that at least make sure the endpoints are responding - If we want to add a new region, we really shouldn't have to go through many hours of OpenStack SDK jobs to pick them up I'm all for it! On Mon, Oct 15, 2018 at 11:04 PM Monty Taylor wrote: > > 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? > > Thanks! > Monty > > [0] > http://git.openstack.org/cgit/openstack/openstacksdk/tree/openstack/config/vendors > [1] > https://docs.openstack.org/openstacksdk/latest/user/config/vendor-support.html > [2] http://git.openstack.org/cgit/openstack/service-types-authority > [3] http://git.openstack.org/cgit/openstack/os-service-types > > __ > 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 -- Mohammed Naser — vexxhost - D. 514-316-8872 D. 800-910-1726 ext. 200 E. mna...@vexxhost.com W. http://vexxhost.com __ 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
[openstack-dev] [publiccloud-wg][sdk][osc][tc] Extracting vendor profiles from openstacksdk
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? Thanks! Monty [0] http://git.openstack.org/cgit/openstack/openstacksdk/tree/openstack/config/vendors [1] https://docs.openstack.org/openstacksdk/latest/user/config/vendor-support.html [2] http://git.openstack.org/cgit/openstack/service-types-authority [3] http://git.openstack.org/cgit/openstack/os-service-types __ 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
