Re: [openstack-dev] [Openstack-operators] [glance] glance-registry deprecation: Request for feedback

2016-05-16 Thread Flavio Percoco 

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


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [glance] glance-registry deprecation: Request for feedback

2016-05-15 Thread Sam Morrison 

> On 14 May 2016, at 5:36 AM, Flavio Percoco  wrote:
> 
>> 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.

Yeah, if glance supported versioned objects then yes this would be great. 

We only have 3 glance-registries and so upgrading these first is a lot easier 
than upgrading all ~15 of our glance-apis at once.

Sam




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [glance] glance-registry deprecation: Request for feedback

2016-05-13 Thread Nikhil Komawar 


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

Re: [openstack-dev] [Openstack-operators] [glance] glance-registry deprecation: Request for feedback

2016-05-13 Thread Flavio Percoco 

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 
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-operat...@lists.openstack.org

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



__
   OpenStack Development Mailing List (not for usage questions)
   Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--

Thanks,
Nikhil





--

Thanks,
Nikhil



--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [glance] glance-registry deprecation: Request for feedback

2016-05-13 Thread Nikhil Komawar 


On 5/13/16 3:29 PM, Flavio Percoco wrote:
> On 12/05/16 20:06 -0400, Nikhil Komawar wrote:
>> The copy-from case is only in v1.
>>
>>
>> For v2, I am having discussion with Doug, Morgan and Mike (TC) members
>> as well as Chris (interop engineer with foundation) to ensure that we
>> can actually support copy-from in v2 for end users. I will add you to
>> the review and you can chime in.
>
> First time I hear about these discussions. Where is it happening.
> What's the
> thing under discussion at this point?
>

https://review.openstack.org/#/c/270980/

> Flavio
>
>>
>> Thanks.
>>
>>
>> On 5/12/16 7:59 PM, Fox, Kevin M wrote:
>>> Is there a copy-from-url method that's not deprecated yet?
>>>
>>> The app catalog is still pointing users at the command line in v1
>>> mode
>>>
>>> Thanks,
>>> Kevin
>>> 
>>>
>>> *From:* Matt Fischer [m...@mattfischer.com]
>>> *Sent:* Thursday, May 12, 2016 4:43 PM
>>> *To:* Flavio Percoco
>>> *Cc:* openstack-dev@lists.openstack.org;
>>> openstack-operat...@lists.openstack.org
>>> *Subject:* Re: [Openstack-operators] [glance] glance-registry
>>> deprecation: Request for feedback
>>>
>>>
>>> On May 11, 2016 10:03 PM, "Flavio Percoco" >> > 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?
>>>
>>> I've not seen any responses so far so wanted to just say we have no
>>> use case for it. I assume this also explains the silence from the rest
>>> of the ops. +1 to remove.
>>>
>>>
>>>
>>> __
>>>
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> -- 
>>
>> Thanks,
>> Nikhil
>>
>>
>> __
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 

Thanks,
Nikhil


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [glance] glance-registry deprecation: Request for feedback

2016-05-13 Thread Nikhil Komawar 


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

-- 

Thanks,
Nikhil


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [glance] glance-registry deprecation: Request for feedback

2016-05-13 Thread Flavio Percoco 

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.


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  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-operat...@lists.openstack.org
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


   __
   OpenStack Development Mailing List (not for usage questions)
   Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--

Thanks,
Nikhil



--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [glance] glance-registry deprecation: Request for feedback

2016-05-13 Thread Flavio Percoco 

On 12/05/16 20:06 -0400, Nikhil Komawar wrote:

The copy-from case is only in v1.


For v2, I am having discussion with Doug, Morgan and Mike (TC) members
as well as Chris (interop engineer with foundation) to ensure that we
can actually support copy-from in v2 for end users. I will add you to
the review and you can chime in.


First time I hear about these discussions. Where is it happening. What's the
thing under discussion at this point?

Flavio



Thanks.


On 5/12/16 7:59 PM, Fox, Kevin M wrote:

Is there a copy-from-url method that's not deprecated yet?

The app catalog is still pointing users at the command line in v1 mode

Thanks,
Kevin

*From:* Matt Fischer [m...@mattfischer.com]
*Sent:* Thursday, May 12, 2016 4:43 PM
*To:* Flavio Percoco
*Cc:* openstack-dev@lists.openstack.org;
openstack-operat...@lists.openstack.org
*Subject:* Re: [Openstack-operators] [glance] glance-registry
deprecation: Request for feedback


On May 11, 2016 10:03 PM, "Flavio Percoco" > 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?

I've not seen any responses so far so wanted to just say we have no
use case for it. I assume this also explains the silence from the rest
of the ops. +1 to remove.



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--

Thanks,
Nikhil


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [glance] glance-registry deprecation: Request for feedback

2016-05-13 Thread Ian Cordasco 
-Original Message-
From: Fox, Kevin M 
Reply: Fox, Kevin M 
Date: May 12, 2016 at 19:00:12
To: Matt Fischer , Flavio Percoco 
Cc: openstack-dev@lists.openstack.org , 
openstack-operat...@lists.openstack.org 

Subject:  Re: [Openstack-operators] [glance] glance-registry deprecation: 
Request for feedback

> Is there a copy-from-url method that's not deprecated yet?
>  
> The app catalog is still pointing users at the command line in v1 mode

I'm sorry for missing something that must be obvious. What does this have to do 
with deprecating the registry?

--  
Ian Cordasco


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [glance] glance-registry deprecation: Request for feedback

2016-05-12 Thread Nikhil Komawar 
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.

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 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  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-operat...@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 

Thanks,
Nikhil

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [glance] glance-registry deprecation: Request for feedback

2016-05-12 Thread Sam Morrison 
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 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  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-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [glance] glance-registry deprecation: Request for feedback

2016-05-12 Thread Nikhil Komawar 
The copy-from case is only in v1.


For v2, I am having discussion with Doug, Morgan and Mike (TC) members
as well as Chris (interop engineer with foundation) to ensure that we
can actually support copy-from in v2 for end users. I will add you to
the review and you can chime in.


Thanks.


On 5/12/16 7:59 PM, Fox, Kevin M wrote:
> Is there a copy-from-url method that's not deprecated yet?
>
> The app catalog is still pointing users at the command line in v1 mode
>
> Thanks,
> Kevin
> 
> *From:* Matt Fischer [m...@mattfischer.com]
> *Sent:* Thursday, May 12, 2016 4:43 PM
> *To:* Flavio Percoco
> *Cc:* openstack-dev@lists.openstack.org;
> openstack-operat...@lists.openstack.org
> *Subject:* Re: [Openstack-operators] [glance] glance-registry
> deprecation: Request for feedback
>
>
> On May 11, 2016 10:03 PM, "Flavio Percoco"  > 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?
>
> I've not seen any responses so far so wanted to just say we have no
> use case for it. I assume this also explains the silence from the rest
> of the ops. +1 to remove.
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 

Thanks,
Nikhil


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [glance] glance-registry deprecation: Request for feedback

2016-05-12 Thread Fox, Kevin M 
Is there a copy-from-url method that's not deprecated yet?

The app catalog is still pointing users at the command line in v1 mode

Thanks,
Kevin

From: Matt Fischer [m...@mattfischer.com]
Sent: Thursday, May 12, 2016 4:43 PM
To: Flavio Percoco
Cc: openstack-dev@lists.openstack.org; openstack-operat...@lists.openstack.org
Subject: Re: [Openstack-operators] [glance] glance-registry deprecation: 
Request for feedback


On May 11, 2016 10:03 PM, "Flavio Percoco" 
> 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?

I've not seen any responses so far so wanted to just say we have no use case 
for it. I assume this also explains the silence from the rest of the ops. +1 to 
remove.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [glance] glance-registry deprecation: Request for feedback

2016-05-12 Thread Matt Fischer 
On May 11, 2016 10:03 PM, "Flavio Percoco"  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?

I've not seen any responses so far so wanted to just say we have no use
case for it. I assume this also explains the silence from the rest of the
ops. +1 to remove.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev