[openstack-dev] [Openstack-operators] [glance] glance-registry deprecation: Request for feedback
flavio at redhat.com
Fri May 13 20:29:20 UTC 2016
On 13/05/16 15:52 -0400, Nikhil Komawar wrote:
>On 5/13/16 3:36 PM, Flavio Percoco wrote:
>> On 12/05/16 21:41 -0400, Nikhil Komawar wrote:
>>> I have been of the same opinion as far as upgrades go.
>>> I think we are stepping ahead of ourselves here a bit. We need to
>>> figure out
>>> the rolling upgrade story first and see if registry is actually
>>> useful or not
>>> there as well.
>> I kinda disagree, tbh. We can have a glance-api service that can be
>> with no downtimes without the need of a registry service.
>With a oslo.vo implementation to work with different models of Glance
>tables (image/members/etc.) schema you _need_ a service that can talk to
>both the type of the models without having to upgrade the DB. From my
>initial perspective, the API nodes up-gradation process will not help
>when we use oslo.vo.
>Because the API will need to be capable of using the new schema where as
>the DB still has a old one. What is the current thought process for
>supporting a rolling upgrade for DB?
Why? I'm failing to see the need of a separate service to do this. The above
suggests there's a service that exposes a single API and that is also capable of
talking to both database schemas. Why can't that service be glance-api itself?
Whatever transformation happens in this separate service could as well happen in
the main service. What am I missing?
>>> The feedback from operator sessions also indicated that some ops do
>>> use it that
>>> way (
>>> Overall, I do think registry is a bit of overhead and it would be
>>> nice to
>>> actually deprecate it but we do need facts/technical research first.
>>> On 5/12/16 9:20 PM, Sam Morrison wrote:
>>> We find glance registry quite useful. Have a central
>>> glance-registry api is useful when you have multiple datacenters all
>>> with glance-apis and talking back to a central registry service. I
>>> guess they could all talk back to the central DB server but currently
>>> that would be over the public Internet for us. Not really an issue,
>>> we can work around it.
>>> The major thing that the registry has given us has been rolling
>>> upgrades. We have been able to upgrade our registry first then one by
>>> one upgrade our API servers (we have about 15 glance-apis)
>> I'm curious to know how you did this upgrade, though. Did you shutdown
>> registry nodes, upgraded the database and then re-started them? Did
>> you upgraded
>> one registry node at a time?
>> I'm asking because, as far as I can tell, the strategy you used for
>> the registry nodes is the one you would use to upgrade the glance-api
>> today. Shutting down all registry nodes would live you with unusable
>> nodes anyway so I'd assume you did a partial upgrade or something
>> similar to
>> Thanks a bunch for your feedback,
>>> I don’t think we would’ve been able to do that if all the
>>> glance-apis were talking to the DB, (At least not in glance’s current
>>> On 12 May 2016, at 1:51 PM, Flavio Percoco <flavio at redhat.com>
>>> The Glance team is evaluating the needs and usefulness of the
>>> Glance Registry
>>> service and this email is a request for feedback from the
>>> overall community
>>> before the team moves forward with anything.
>>> Historically, there have been reasons to create this service.
>>> Some deployments
>>> use it to hide database credentials from Glance public
>>> endpoints, others use it
>>> for scaling purposes and others because v1 depends on it. This
>>> is a good time
>>> for the team to re-evaluate the need of these services since
>>> v2 doesn't depend
>>> on it.
>>> So, here's the big question:
>>> Why do you think this service should be kept around?
>>> Summit etherpad:
>>> Flavio Percoco
>>> OpenStack-operators mailing list
>>> OpenStack-operators at lists.openstack.org
>>> OpenStack Development Mailing List (not for usage questions)
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: not available
More information about the OpenStack-dev