Open Stack

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?

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