On 13/05/16 17:10 -0400, Nikhil Komawar wrote:
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 aboveI 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.
The oslo.vo code you'd use for glance-registry would be the exact same you would use for glance-api because they both share the same database code. Therefore, once the oslo.vo code will be implemented, it'd work the same way for the registry service as it'd for the api node. Shutting down all registry nodes to upgrade the DB is not rolling upgrades and it'll cause a downtime. Whatever solution we're thinking to use to fix the registry upgrade issues, we should be able to use for the api service. (I know you know this, just stating for the sake of discussion)
* If I upgrade first g-api do a PATCH on an image (that updates the DB'dOA 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?
The older version of that object. A change to the database schema does not translate to a change in the API. It could, sometimes, but not always. Talking specifically about changes to the *API*, the user would get an older response and I don't think that's really an issue. You could also upgrade a set of glance-api nodes and once those are back up redirect the trafic there while the rest of the nodes are upgraded. That should avoid most of the cases like the one you mentioned 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?I think we need to define some usage patterns and the upgrade support for them to be definite in our approach.
Agreed! The point I'm trying to make, however, is that we don't need the registry to have rolling upgrades. Flavio -- @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
