On 5/13/16 4:29 PM, Flavio Percoco wrote: > 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
I do not know all the answers hence, the request for research. For instance: * What happens if I have 3 g-api nodes (no-registry) and oslo.vo upgrade support for the DB. * If I upgrade first g-api do a PATCH on an image (that updates the DB scheme), and then go GET via the other 2 g-api (older version of the g-api) on the same image. What should the non-upgraded g-api return? > 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? I think we need to define some usage patterns and the upgrade support for them to be definite in our approach. > > 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, >>> Flavio >>> >>>> 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 >>>> 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-operat...@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 >> > -- 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
