> I think its great that we're having this discussion.
+1, excellent discussion in terms of both tone & content.
> In the hope that its informative, I'd like to give some info on
> issues
> we're looking at when moving our Glance deployment to Folsom. A lot
> of
> this is in common with Ryan, but there are a couple of twists due to
> our
> goals of maximization of uptime (ie we are hoping to do a rolling
> rather
> than lock-step upgrade) and decoupling upgrades. Also, I mention the
> case where you may have existing Glance clients which you don't
> control.
>
> In our case the upgrade of the various components (swift/glance/nova
> etc) will be staggered rather than performed simultaneously. (For
> large
> organisations I imagine this may often be the case.) If we are to
> avoid
> downtime for Glance we must simultaneously support ids and uuids.
> These
> must be presented appropriately to Nova nodes which we must assume
> are
> moving targets -- ie will initially be on older code, but will
> upgrade
> to Folsom.
>
> We have some ideas on how this may be possible but haven't worked
> through
> all the details yet (in particular the Nova database entries)... but
> there could be some coding for Nova/Glance and some deploys of the
> interoperable code before eventually switching to standard Folsom.
Its unfortunate that the glance.images.id->uuid migration didn't follow
the nova.instances.{id|uuid} co-existence pattern, where the old IDs
are maintained in the DB and also continue to be supported for
identification purposes in the API.
But in any case, I presume your migration scenario is pre-Essex
to Folsom? (as the glance UUIDs were already in place for Essex)
I wonder though for the more tractable migration of Essex to Folsom,
should we consider building in tolerance for mixed old/new glance
deployments during a rolling upgrade of horizontally scaled glance-api
services?
Given that (a) the api service is now DB-aware, whereas previously this
was limited to the registry service, and (b) the amount of churn in the
glance DB schema was relatively limited between Essex and Folsom (a
new image_tags table, an additional images.protected column and some
munging of any swift images.location URIs).
For an Essex glance-api service to continue to run against the Folsom DB
schema, it might only require that any *new* swift location URIs are quoted
after the fact, and we bake in tolerance for unquoted URIs in the Folsom
code that interacts with the swift backend. (I would need to confirm that ...)
> (Jay -- I don't think scripts are sufficient here?)
>
> If Glance were publically available its not clear how the id/uuid
> change
> could be worked through gracefully where we didn't have control over
> the
> glance client. Ie the upgrade would break existing customers' clients
> which expected an id rather than a uuid.
Other than maintaining *both* the existing numeric id and the new varchar
UUID as described above, while allowing the image to identified by either,
I don't see how support for old clients could work.
Cheers,
Eoghan
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
