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 upgraded 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? Flavio
The feedback from operator sessions also indicated that some ops do use it that way ( http://lists.openstack.org/pipermail/openstack-dev/2016-May/094034.html ). 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 your 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 upgrading the registry nodes is the one you would use to upgrade the glance-api nodes today. Shutting down all registry nodes would live you with unusable glance-api nodes anyway so I'd assume you did a partial upgrade or something similar to that. Thanks a bunch for your feedback, FlavioI 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 state) Sam On 12 May 2016, at 1:51 PM, Flavio Percoco <fla...@redhat.com> wrote: Greetings, 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: https://etherpad.openstack.org/p/newton-glance-registry-deprecation Flavio -- @flaper87 Flavio Percoco _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators __________________________________________________________________________ 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-- Thanks, Nikhil
-- @flaper87 Flavio Percoco
signature.asc
Description: PGP signature
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
