Open Stack

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 <flavio at 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 at lists.openstack.org
>>>>
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>>
>>>>
>>>>
>>>>
>>>> __________________________________________________________________________
>>>>
>>>>    OpenStack Development Mailing List (not for usage questions)
>>>>    Unsubscribe:
>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>>    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>> -- 
>>>>
>>>> Thanks,
>>>> Nikhil
>>>>
>>>
>>
>> -- 
>>
>> Thanks,
>> Nikhil
>>
>

-- 

Thanks,
Nikhil