On 26/08/15 12:22 -0400, Nikhil Komawar wrote:
We considered that option and have finally agreed on what Alex suggests at the rel-mgrs office as this is the least painful path for most.
It would have been nice to know it had already been discussed across some glance members and other folks. I'm sure you all considered other options too so I'm good. It'd be nice to have a link to the discussion too. Thanks, Flavio
On 8/26/15 12:04 PM, Flavio Percoco wrote:On 24/08/15 18:37 +0300, Alexander Tivelkov wrote:Hi folks, In the upcoming L release Murano is going to use the "Glance Artifact Repository" feature implemented as part of EXPERIMENTAL Glance V3 API. The server-side support of this feature is already merged in glance's master branch, while the client code is not: it was agreed that the v3's client will stay in a dedicated feature branch (feature/artifacts) and will not be released until the API is stable and final (a major API refactoring based on the feedback from API WG is on the way and is likely to happen in M). So, there will be no v3-aware releases of python-glanceclient on pypi until then. The early adopters of V3 API are encouraged to build the tarballs out of the feature branch on their own and use them, keeping in mind that the API is EXPERIMENTAL so everything may be (and will be) changed. However, Murano needs some way to consume Glance V3 right now, and - as it has a voting requirements job at the gate - it cannot just put a git branch reference in its requirements.txt. It needs some kind of a release which would be part of global requirements etc. So, it was decided to temporary copy-paste the experimental part of glance client into the murano client (i.e. to copy python-glanceclient/feature/ artifacts/v3 to python-muranoclient/master/artifacts) and release it as part of several next releases of python-muranoclient. When the Glance V3 API is stable, we'll put its client to the master branch of python-glanceclient and release it normally, then dropping the temporary copy from python-muranoclient. Until then, all the changes to the experimental client should be done in the feature/artifacts branch of glance client and copied (synced) to murano client. Similar to oslo.incubator sync procedure, just without a shell script :) I hope that the need to do this copy-pasting will not last for long and the v3 API becomes stable soon enough.I was going to sugest having a separate library just for this code. You'd work on this library until the API is stable and then you'd merge it back into glanceclient as soon as the feature is stable server side. We could also have a way to load the library code as a plugin for glanceclient - similar to the way openstack client works - but that requires a spec for mitaka. Anyway, the library could be called `python-glanceclient-artifacts` or something along those lines. Flavio __________________________________________________________________________ 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-- Thanks, Nikhil __________________________________________________________________________ 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
-- @flaper87 Flavio Percoco
pgpd4IbvyuGxn.pgp
Description: PGP signature
__________________________________________________________________________ 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
