[openstack-dev] [Glance][All] Pecan migration strategies

Roman Prykhodchenko rprikhodchenko at mirantis.com
Tue Jan 14 23:09:42 UTC 2014

Hi folks,

I would vote for implementing the existing version, i.e, 2.0 instead of creating a new one.

The reasons I consider are the following:

1. Introducing a new version of the API means making some changes to the specification.
In the case of changing the major version those changes should be major. In our case we
are going to change not specification but implementation. So for users there will be two
absolutely identical interfaces for a single black box.

2. Creating a new version means that the old one will be kept for some time. That also means
that getting rid of the old code which just duplicates some functions will be harder or even not

3. There are some users of the Glance API. It will take significant time until they all switch to the
new version. That means we will have to support the old one until the last user switched from it.

To make it possible to switch to the new Pecan-based API we need to guarantee that the old version
and the new one are identical. While it's not possible to guarantee 100% match, it would be sufficient
to check whether everything that uses the old version works with the new one. Then switching to the
new version should be as painless as possible.

Roman Prykhodchenko

On Jan 10, 2014, at 14:51 , Flavio Percoco <flavio at redhat.com> wrote:

> Greetings,
> More discussions around the adoption of Pecan.
> I'd like to know what is the feeling of other folks about migrating
> existing APIs to Pecan as opposed to waiting for a new API version as
> an excuse to migrate the API implementation to Pecan?
> We discussed this in one of the sessions at the summit, I'd like to
> get a final consensus on what the desired migration path is for the
> overall community.
> IIRC, Cinder has a working version of the API with Pecan but there's
> not a real motivation to release a new version of it that will use
> the new implementation. Am I right?
> Nova, instead, will start migrating some parts but not all of them and
> it'll happen as part of the API v3. AFAIU.
> Recently a new patch was proposed in glance[0] and it contains a base
> implementation for the existing API v2. I love that patch and the fact
> that Oleh Anufriiev is working on it. What worries me, is that the
> patch re-implements an existing API and I don't think we should just
> swap them.
> Yes, we have tests (unit and functional) and that should be enough to
> make sure the new implementation works as the old one - Should it?
> Should it? - but...
> This most likely has to be evaluated in a per-project basis. But:
>   - What are the thoughts of other folks on this matter?
> Cheers,
> FF
> [0] https://review.openstack.org/#/c/62911/
> -- 
> @flaper87
> Flavio Percoco
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140115/6c0897d6/attachment.pgp>

More information about the OpenStack-dev mailing list