Open Stack

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

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
>

-- 
@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/20160513/699a45a7/attachment.pgp>