Open Stack

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
>> 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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20160516/21257cd5/attachment.pgp>