Re: [openstack-dev] [Glance] [all] Liberty summit: Updates in Glance

[John Garbutt]

On 1 June 2015 at 14:11, Flavio Percoco  wrote:
> On 01/06/15 13:30 +0100, John Garbutt wrote:
>> On 1 June 2015 at 13:10, Flavio Percoco  wrote:
>>> On 01/06/15 11:57 +0100, John Garbutt wrote:
>>> I'm happy you brought this up. What are Nova's plans to adopt Glance's
>>> v2 ? I heard there was a discussion and something along the lines of
>>> creating a library that wraps both APIs came up.
>>
>> We don't have anyone who has stepped up to work on it at his point.
>>
>> I think the push you made around this effort in kilo is the latest
>> updated on this:
>>
>> http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/remove-glanceclient-wrapper.html
>>
>> It would be great if we could find a glance/nova CPL to drive this effort.
>
> So, unless the library is proposed and some magic happens, is it safe
> to assume that the above spec is still valid and that folks can work
> on it?

Well it will need re-approving for Liberty, but we can get that done
very quickly.

I am assuming Jay is pushing this now, which is cool.

Let me know how I can help there.

>>> Where can I find more info about this?
>>
>> I suspect it will be included on our liberty priority TODO list, that
>> I am yet to write, but I expect to appear here:
>> http://specs.openstack.org/openstack/nova-specs/
>>
>>> I really think nova should put some more effort on helping this
>>> happen. The work I did[0] - all red now, I swear it wasn't - during
>>> Kilo didn't get enough attention even before we decided to push it
>>> back. Not a complain, really. However, I'd love to see some
>>> cross-project efforts on making this happen.
>>> [0] https://review.openstack.org/#/c/144875/
>>
>>
>> As there is no one to work on the effort, we haven't made it a
>> priority for liberty.
>>
>> If someone is able to step up to help complete the work, I can do my
>> best to help get that effort reviewed, by raising its priority, just
>> as we did in Kilo.
>
> IIRC, the patch wasn't far from being ready.

I think we reviewed this at the mid cycle.
Basically the patch needs splitting up into little chunks, where possible.
Anyways, lets not get distracted here.

>The latest patch-sets
> relied on the gate to run some tests and the biggest issue I had -
> still have - is that this script[0] didn't even use glanceclient but
> direct http calls. The issue, to be precises, is that I didn't have
> ways to test it locally, which made the work painful.

Its possible to test it locally, using opensource software, but its a
painful setup process.

> If there's a way to do it - something that has already being asked -
> it'd be great.
>
> This said, I'm not sure how much time I'll have for this but I'm
> trying to find someone that could help out.
>
> https://review.openstack.org/#/c/144875/30/plugins/xenserver/xenapi/etc/xapi.d/plugins/glance,cm

I offered to help with that at the mid cycle, but I figured it got
fixed already, because no one reached out. Sorry, I mean to reach out
to you to check, but I totally forgot.

I don't have the time now I am afraid. Nikhil or I should be able to
find someone at Rackspace to help out with that. Its important.

>> I suspect looking at how to slowly move towards v2, rather than going
>> for a "big bang" approach, will make this easier to land. That and
>> solving how we implement "changed-since", if thats not available in
>> the newer glance APIs. Honestly, part of me wonders about skipping v2,
>> and going straight to v3.
>
> Regardless, I think we should enable people to run on a v2 only
> deployment. Not a crazy thought, I think. We'll have to think this
> through a bit more.

Agreed its important and needs doing.

Happy to see some signs of progress again.

Thanks,
John

__
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] [Glance] [all] Liberty summit: Updates in Glance

[John Garbutt]

On 4 June 2015 at 09:51, John Garbutt  wrote:
> On 3 June 2015 at 00:47, Fei Long Wang  wrote:
>> On 02/06/15 01:51, Jay Pipes wrote:
>>> Please assign me as the CPL for Glance from Nova.
>> I'm happy  to work with Jay for Nova from Glance :)
>
> I have added you both here:
> https://wiki.openstack.org/wiki/CrossProjectLiaisons#Inter-project_Liaisons
>
> Please do double check I got that correct.

Sorry, I missed out the thank you, which was the main reason I sent email.

Thank you both for stepping up here!

John

__
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] [Glance] [all] Liberty summit: Updates in Glance

[John Garbutt]

On 3 June 2015 at 00:47, Fei Long Wang  wrote:
> On 02/06/15 01:51, Jay Pipes wrote:
>> Please assign me as the CPL for Glance from Nova.
> I'm happy  to work with Jay for Nova from Glance :)

I have added you both here:
https://wiki.openstack.org/wiki/CrossProjectLiaisons#Inter-project_Liaisons

Please do double check I got that correct.

Thanks,
John

__
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] [Glance] [all] Liberty summit: Updates in Glance

[Flavio Percoco]

On 04/06/15 12:19 +0900, Joe Gordon wrote:



On Mon, Jun 1, 2015 at 6:11 AM, Flavio Percoco  wrote:

   On 01/06/15 13:30 +0100, John Garbutt wrote:

   On 1 June 2015 at 13:10, Flavio Percoco  wrote:

   On 01/06/15 11:57 +0100, John Garbutt wrote:


   On 26/05/15 13:54 -0400, Nikhil Komawar wrote:


   On 5/26/15 12:57 PM, Jesse Cook wrote:
      We also had some hallway talk about putting the v1
   and v2 APIs on top
   of
      the v3 API. This forces faster adoption, verifies
   supportability via
   v1
   and
      v2 tests, increases supportability of v1 and v2
   APIs, and pushes out
   the
      need to kill v1 API.

   Let's discuss more as time and development progresses
   on that
   possibility.
   v3
   API should stay EXPERIMENTAL for now as that would help
   us understand
   use-cases
   across programs as it gets adopted by various
   code-bases. Putting v1/v2
   on
   top
   of v3 would be tricky for now as we may have breaking
   changes with code
   being
   relatively-less stable due to narrow review domain.




   I actually think we'd benefit more from having V2 on top of
   V3 than
   not doing it. I'd probably advocate to make this M material
   rather
   than L but I think it'd be good.

   I think regardless of what we do, I'd like to kill v1 as it
   has a
   sharing model that is not secure.



   Given v1 has lots of users, killing it will be hard.

   If you maintained v1 support as v1 on top of v3 (or v2 I
   guess), could
   you not do something like permanently disable the "bad bits" of
   the
   API?


   I agree it'll be hard but, at least for v1, I believe it should
   happen. It has some security issues (mostly related to image
   sharing)
   that are not going to be fixed there.


   OK, I guess you mean this one:
   https://wiki.openstack.org/wiki/OSSN/1226078


   The idea being, users listing their images, and updating image
   metadata via v1, don't get broken during the evolution?


   The feedback we got at the summit (even from OPs) was that we could
   go
   ahead, mark it as deprecated, give a deprecation period and then
   turn
   it off.


   I am surprised by that reply, but OK.


   FWIW, moving Nova from glance v1 to glance v2, without breaking
   Nova's
   public API, will require someone getting a big chunk of glance
   v1 on
   top of glance v2.


   AFAIK, the biggest issue right now is "changed-since" which is
   something Glance doesn't have in v2 but it's exposed throught
   Nova's
   image API.


   Thats the big unanswered question that needs fixing in any spec we
   would approve around this effort.


   I don't have an answer myself right now.




   I'm happy you brought this up. What are Nova's plans to adopt
   Glance's
   v2 ? I heard there was a discussion and something along the lines
   of
   creating a library that wraps both APIs came up.


   We don't have anyone who has stepped up to work on it at his point.

   I think the push you made around this effort in kilo is the latest
   updated on this:
   http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/
   remove-glanceclient-wrapper.html

   It would be great if we could find a glance/nova CPL to drive this
   effort.


   So, unless the library is proposed and some magic happens, is it safe
   to assume that the above spec is still valid and that folks can work
   on it?




   Where can I find more info about this?


   I suspect it will be included on our liberty priority TODO list, that
   I am yet to write, but I expect to appear here:
   http://specs.openstack.org/openstack/nova-specs/


   I really think nova should put some more effort on helping this
   happen. The work I did[0] - all red now, I swear it wasn't - during
   Kilo didn't get enough attention even before we decided to push it
   back. Not a complain, really. However, I'd love to see some
   cross-project effo

Re: [openstack-dev] [Glance] [all] Liberty summit: Updates in Glance

[Joe Gordon]

On Mon, Jun 1, 2015 at 6:11 AM, Flavio Percoco  wrote:

> On 01/06/15 13:30 +0100, John Garbutt wrote:
>
>> On 1 June 2015 at 13:10, Flavio Percoco  wrote:
>>
>>> On 01/06/15 11:57 +0100, John Garbutt wrote:
>>>

> On 26/05/15 13:54 -0400, Nikhil Komawar wrote:
>
>>
>> On 5/26/15 12:57 PM, Jesse Cook wrote:
>>We also had some hallway talk about putting the v1 and v2 APIs on
>> top
>> of
>>the v3 API. This forces faster adoption, verifies supportability
>> via
>> v1
>> and
>>v2 tests, increases supportability of v1 and v2 APIs, and pushes
>> out
>> the
>>need to kill v1 API.
>>
>> Let's discuss more as time and development progresses on that
>> possibility.
>> v3
>> API should stay EXPERIMENTAL for now as that would help us understand
>> use-cases
>> across programs as it gets adopted by various code-bases. Putting
>> v1/v2
>> on
>> top
>> of v3 would be tricky for now as we may have breaking changes with
>> code
>> being
>> relatively-less stable due to narrow review domain.
>>
>
>
>
> I actually think we'd benefit more from having V2 on top of V3 than
> not doing it. I'd probably advocate to make this M material rather
> than L but I think it'd be good.
>
> I think regardless of what we do, I'd like to kill v1 as it has a
> sharing model that is not secure.
>


 Given v1 has lots of users, killing it will be hard.

 If you maintained v1 support as v1 on top of v3 (or v2 I guess), could
 you not do something like permanently disable the "bad bits" of the
 API?

>>>
>>> I agree it'll be hard but, at least for v1, I believe it should
>>> happen. It has some security issues (mostly related to image sharing)
>>> that are not going to be fixed there.
>>>
>>
>> OK, I guess you mean this one:
>> https://wiki.openstack.org/wiki/OSSN/1226078
>>
>>  The idea being, users listing their images, and updating image
 metadata via v1, don't get broken during the evolution?

>>>
>>> The feedback we got at the summit (even from OPs) was that we could go
>>> ahead, mark it as deprecated, give a deprecation period and then turn
>>> it off.
>>>
>>
>> I am surprised by that reply, but OK.
>>
>>  FWIW, moving Nova from glance v1 to glance v2, without breaking Nova's
 public API, will require someone getting a big chunk of glance v1 on
 top of glance v2.

>>>
>>> AFAIK, the biggest issue right now is "changed-since" which is
>>> something Glance doesn't have in v2 but it's exposed throught Nova's
>>> image API.
>>>
>>
>> Thats the big unanswered question that needs fixing in any spec we
>> would approve around this effort.
>>
>
> I don't have an answer myself right now.
>
>
>>  I'm happy you brought this up. What are Nova's plans to adopt Glance's
>>> v2 ? I heard there was a discussion and something along the lines of
>>> creating a library that wraps both APIs came up.
>>>
>>
>> We don't have anyone who has stepped up to work on it at his point.
>>
>> I think the push you made around this effort in kilo is the latest
>> updated on this:
>>
>> http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/remove-glanceclient-wrapper.html
>>
>> It would be great if we could find a glance/nova CPL to drive this effort.
>>
>
> So, unless the library is proposed and some magic happens, is it safe
> to assume that the above spec is still valid and that folks can work
> on it?
>
>
>>  Where can I find more info about this?
>>>
>>
>> I suspect it will be included on our liberty priority TODO list, that
>> I am yet to write, but I expect to appear here:
>> http://specs.openstack.org/openstack/nova-specs/
>>
>>  I really think nova should put some more effort on helping this
>>> happen. The work I did[0] - all red now, I swear it wasn't - during
>>> Kilo didn't get enough attention even before we decided to push it
>>> back. Not a complain, really. However, I'd love to see some
>>> cross-project efforts on making this happen.
>>> [0] https://review.openstack.org/#/c/144875/
>>>
>>
>> As there is no one to work on the effort, we haven't made it a
>> priority for liberty.
>>
>> If someone is able to step up to help complete the work, I can do my
>> best to help get that effort reviewed, by raising its priority, just
>> as we did in Kilo.
>>
>
> IIRC, the patch wasn't far from being ready. The latest patch-sets
> relied on the gate to run some tests and the biggest issue I had -
> still have - is that this script[0] didn't even use glanceclient but
> direct http calls. The issue, to be precises, is that I didn't have
> ways to test it locally, which made the work painful.
>
> If there's a way to do it - something that has already being asked -
> it'd be great.
>
> This said, I'm not sure how much time I'll have for this but I'm
> trying to find someone that could help out.
>
>
> https://review.openstack.org/

Re: [openstack-dev] [Glance] [all] Liberty summit: Updates in Glance

[Fei Long Wang]

On 02/06/15 01:51, Jay Pipes wrote:
> On 06/01/2015 08:30 AM, John Garbutt wrote:
>> On 1 June 2015 at 13:10, Flavio Percoco  wrote:
>>> On 01/06/15 11:57 +0100, John Garbutt wrote:
> On 26/05/15 13:54 -0400, Nikhil Komawar wrote:
 FWIW, moving Nova from glance v1 to glance v2, without breaking Nova's
 public API, will require someone getting a big chunk of glance v1 on
 top of glance v2.
>>>
>>> AFAIK, the biggest issue right now is "changed-since" which is
>>> something Glance doesn't have in v2 but it's exposed throught Nova's
>>> image API.
>>
I'm working on something in Glance related to this.
>> Thats the big unanswered question that needs fixing in any spec we
>> would approve around this effort.
>>
>>> I'm happy you brought this up. What are Nova's plans to adopt Glance's
>>> v2 ? I heard there was a discussion and something along the lines of
>>> creating a library that wraps both APIs came up.
>>
>> We don't have anyone who has stepped up to work on it at his point.
>>
>> I think the push you made around this effort in kilo is the latest
>> updated on this:
>> http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/remove-glanceclient-wrapper.html
>>
>>
>> It would be great if we could find a glance/nova CPL to drive this
>> effort.
>
> I am happy to take the lead on this from the Nova side. I'm familiar
> with the code in Nova.
>
>>> I really think nova should put some more effort on helping this
>>> happen. The work I did[0] - all red now, I swear it wasn't - during
>>> Kilo didn't get enough attention even before we decided to push it
>>> back. Not a complain, really. However, I'd love to see some
>>> cross-project efforts on making this happen.
>>> [0] https://review.openstack.org/#/c/144875/
>>
>> As there is no one to work on the effort, we haven't made it a
>> priority for liberty.
>
> It's not a huge amount of work. I can do it.
Yes, given the L release is just starting. I think we have enough time
to make it happen.
>
>> If someone is able to step up to help complete the work, I can do my
>> best to help get that effort reviewed, by raising its priority, just
>> as we did in Kilo.
>>
>> I suspect looking at how to slowly move towards v2, rather than going
>> for a "big bang" approach, will make this easier to land. That and
>> solving how we implement "changed-since", if thats not available in
>> the newer glance APIs. Honestly, part of me wonders about skipping v2,
>> and going straight to v3.
>
> We actually already support Glance V2 in some things. It shouldn't be
> too difficult to complete the work to fully support V2.
>
> Please assign me as the CPL for Glance from Nova.
I'm happy  to work with Jay for Nova from Glance :)
>
> Best,
> -jay
>
> __
>
> 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

-- 
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 



__
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] [Glance] [all] Liberty summit: Updates in Glance

[Steve Lewis]

On Monday, June 1, 2015 05:30, John Garbutt   wrote:
On 1 June 2015 at 13:10, Flavio Percoco  wrote:
>> AFAIK, the biggest issue right now is "changed-since" which is
>> something Glance doesn't have in v2 but it's exposed throught Nova's
>> image API.
>
> Thats the big unanswered question that needs fixing in any spec we
> would approve around this effort.
>
We're working on a plan for that, too. 


__
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] [Glance] [all] Liberty summit: Updates in Glance

[Jay Pipes]

On 06/01/2015 08:30 AM, John Garbutt wrote:

On 1 June 2015 at 13:10, Flavio Percoco  wrote:

On 01/06/15 11:57 +0100, John Garbutt wrote:

On 26/05/15 13:54 -0400, Nikhil Komawar wrote:

FWIW, moving Nova from glance v1 to glance v2, without breaking Nova's
public API, will require someone getting a big chunk of glance v1 on
top of glance v2.


AFAIK, the biggest issue right now is "changed-since" which is
something Glance doesn't have in v2 but it's exposed throught Nova's
image API.


Thats the big unanswered question that needs fixing in any spec we
would approve around this effort.


I'm happy you brought this up. What are Nova's plans to adopt Glance's
v2 ? I heard there was a discussion and something along the lines of
creating a library that wraps both APIs came up.


We don't have anyone who has stepped up to work on it at his point.

I think the push you made around this effort in kilo is the latest
updated on this:
http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/remove-glanceclient-wrapper.html

It would be great if we could find a glance/nova CPL to drive this effort.


I am happy to take the lead on this from the Nova side. I'm familiar 
with the code in Nova.



I really think nova should put some more effort on helping this
happen. The work I did[0] - all red now, I swear it wasn't - during
Kilo didn't get enough attention even before we decided to push it
back. Not a complain, really. However, I'd love to see some
cross-project efforts on making this happen.
[0] https://review.openstack.org/#/c/144875/


As there is no one to work on the effort, we haven't made it a
priority for liberty.


It's not a huge amount of work. I can do it.


If someone is able to step up to help complete the work, I can do my
best to help get that effort reviewed, by raising its priority, just
as we did in Kilo.

I suspect looking at how to slowly move towards v2, rather than going
for a "big bang" approach, will make this easier to land. That and
solving how we implement "changed-since", if thats not available in
the newer glance APIs. Honestly, part of me wonders about skipping v2,
and going straight to v3.


We actually already support Glance V2 in some things. It shouldn't be 
too difficult to complete the work to fully support V2.


Please assign me as the CPL for Glance from Nova.

Best,
-jay

__
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] [Glance] [all] Liberty summit: Updates in Glance

[Flavio Percoco]

On 01/06/15 13:30 +0100, John Garbutt wrote:

On 1 June 2015 at 13:10, Flavio Percoco  wrote:

On 01/06/15 11:57 +0100, John Garbutt wrote:


On 26/05/15 13:54 -0400, Nikhil Komawar wrote:


On 5/26/15 12:57 PM, Jesse Cook wrote:
   We also had some hallway talk about putting the v1 and v2 APIs on top
of
   the v3 API. This forces faster adoption, verifies supportability via
v1
and
   v2 tests, increases supportability of v1 and v2 APIs, and pushes out
the
   need to kill v1 API.

Let's discuss more as time and development progresses on that
possibility.
v3
API should stay EXPERIMENTAL for now as that would help us understand
use-cases
across programs as it gets adopted by various code-bases. Putting v1/v2
on
top
of v3 would be tricky for now as we may have breaking changes with code
being
relatively-less stable due to narrow review domain.




I actually think we'd benefit more from having V2 on top of V3 than
not doing it. I'd probably advocate to make this M material rather
than L but I think it'd be good.

I think regardless of what we do, I'd like to kill v1 as it has a
sharing model that is not secure.



Given v1 has lots of users, killing it will be hard.

If you maintained v1 support as v1 on top of v3 (or v2 I guess), could
you not do something like permanently disable the "bad bits" of the
API?


I agree it'll be hard but, at least for v1, I believe it should
happen. It has some security issues (mostly related to image sharing)
that are not going to be fixed there.


OK, I guess you mean this one:
https://wiki.openstack.org/wiki/OSSN/1226078


The idea being, users listing their images, and updating image
metadata via v1, don't get broken during the evolution?


The feedback we got at the summit (even from OPs) was that we could go
ahead, mark it as deprecated, give a deprecation period and then turn
it off.


I am surprised by that reply, but OK.


FWIW, moving Nova from glance v1 to glance v2, without breaking Nova's
public API, will require someone getting a big chunk of glance v1 on
top of glance v2.


AFAIK, the biggest issue right now is "changed-since" which is
something Glance doesn't have in v2 but it's exposed throught Nova's
image API.


Thats the big unanswered question that needs fixing in any spec we
would approve around this effort.


I don't have an answer myself right now.




I'm happy you brought this up. What are Nova's plans to adopt Glance's
v2 ? I heard there was a discussion and something along the lines of
creating a library that wraps both APIs came up.


We don't have anyone who has stepped up to work on it at his point.

I think the push you made around this effort in kilo is the latest
updated on this:
http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/remove-glanceclient-wrapper.html

It would be great if we could find a glance/nova CPL to drive this effort.


So, unless the library is proposed and some magic happens, is it safe
to assume that the above spec is still valid and that folks can work
on it?




Where can I find more info about this?


I suspect it will be included on our liberty priority TODO list, that
I am yet to write, but I expect to appear here:
http://specs.openstack.org/openstack/nova-specs/


I really think nova should put some more effort on helping this
happen. The work I did[0] - all red now, I swear it wasn't - during
Kilo didn't get enough attention even before we decided to push it
back. Not a complain, really. However, I'd love to see some
cross-project efforts on making this happen.
[0] https://review.openstack.org/#/c/144875/


As there is no one to work on the effort, we haven't made it a
priority for liberty.

If someone is able to step up to help complete the work, I can do my
best to help get that effort reviewed, by raising its priority, just
as we did in Kilo.


IIRC, the patch wasn't far from being ready. The latest patch-sets
relied on the gate to run some tests and the biggest issue I had -
still have - is that this script[0] didn't even use glanceclient but
direct http calls. The issue, to be precises, is that I didn't have
ways to test it locally, which made the work painful.

If there's a way to do it - something that has already being asked -
it'd be great.

This said, I'm not sure how much time I'll have for this but I'm
trying to find someone that could help out.

https://review.openstack.org/#/c/144875/30/plugins/xenserver/xenapi/etc/xapi.d/plugins/glance,cm



I suspect looking at how to slowly move towards v2, rather than going
for a "big bang" approach, will make this easier to land. That and
solving how we implement "changed-since", if thats not available in
the newer glance APIs. Honestly, part of me wonders about skipping v2,
and going straight to v3.


Regardless, I think we should enable people to run on a v2 only
deployment. Not a crazy thought, I think. We'll have to think this
through a bit more.

Cheers,
Flavio

--
@flaper87
Flavio Percoco


pgpskjVyn6vqX.pgp
Description: PGP signature
_

Re: [openstack-dev] [Glance] [all] Liberty summit: Updates in Glance

[John Garbutt]

On 1 June 2015 at 13:10, Flavio Percoco  wrote:
> On 01/06/15 11:57 +0100, John Garbutt wrote:
>>>
>>> On 26/05/15 13:54 -0400, Nikhil Komawar wrote:

 On 5/26/15 12:57 PM, Jesse Cook wrote:
We also had some hallway talk about putting the v1 and v2 APIs on top
 of
the v3 API. This forces faster adoption, verifies supportability via
 v1
 and
v2 tests, increases supportability of v1 and v2 APIs, and pushes out
 the
need to kill v1 API.

 Let's discuss more as time and development progresses on that
 possibility.
 v3
 API should stay EXPERIMENTAL for now as that would help us understand
 use-cases
 across programs as it gets adopted by various code-bases. Putting v1/v2
 on
 top
 of v3 would be tricky for now as we may have breaking changes with code
 being
 relatively-less stable due to narrow review domain.
>>>
>>>
>>>
>>> I actually think we'd benefit more from having V2 on top of V3 than
>>> not doing it. I'd probably advocate to make this M material rather
>>> than L but I think it'd be good.
>>>
>>> I think regardless of what we do, I'd like to kill v1 as it has a
>>> sharing model that is not secure.
>>
>>
>> Given v1 has lots of users, killing it will be hard.
>>
>> If you maintained v1 support as v1 on top of v3 (or v2 I guess), could
>> you not do something like permanently disable the "bad bits" of the
>> API?
>
> I agree it'll be hard but, at least for v1, I believe it should
> happen. It has some security issues (mostly related to image sharing)
> that are not going to be fixed there.

OK, I guess you mean this one:
https://wiki.openstack.org/wiki/OSSN/1226078

>> The idea being, users listing their images, and updating image
>> metadata via v1, don't get broken during the evolution?
>
> The feedback we got at the summit (even from OPs) was that we could go
> ahead, mark it as deprecated, give a deprecation period and then turn
> it off.

I am surprised by that reply, but OK.

>> FWIW, moving Nova from glance v1 to glance v2, without breaking Nova's
>> public API, will require someone getting a big chunk of glance v1 on
>> top of glance v2.
>
> AFAIK, the biggest issue right now is "changed-since" which is
> something Glance doesn't have in v2 but it's exposed throught Nova's
> image API.

Thats the big unanswered question that needs fixing in any spec we
would approve around this effort.

> I'm happy you brought this up. What are Nova's plans to adopt Glance's
> v2 ? I heard there was a discussion and something along the lines of
> creating a library that wraps both APIs came up.

We don't have anyone who has stepped up to work on it at his point.

I think the push you made around this effort in kilo is the latest
updated on this:
http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/remove-glanceclient-wrapper.html

It would be great if we could find a glance/nova CPL to drive this effort.

> Where can I find more info about this?

I suspect it will be included on our liberty priority TODO list, that
I am yet to write, but I expect to appear here:
http://specs.openstack.org/openstack/nova-specs/

> I really think nova should put some more effort on helping this
> happen. The work I did[0] - all red now, I swear it wasn't - during
> Kilo didn't get enough attention even before we decided to push it
> back. Not a complain, really. However, I'd love to see some
> cross-project efforts on making this happen.
> [0] https://review.openstack.org/#/c/144875/

As there is no one to work on the effort, we haven't made it a
priority for liberty.

If someone is able to step up to help complete the work, I can do my
best to help get that effort reviewed, by raising its priority, just
as we did in Kilo.

I suspect looking at how to slowly move towards v2, rather than going
for a "big bang" approach, will make this easier to land. That and
solving how we implement "changed-since", if thats not available in
the newer glance APIs. Honestly, part of me wonders about skipping v2,
and going straight to v3.

Thanks,
John

__
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] [Glance] [all] Liberty summit: Updates in Glance

[Flavio Percoco]

On 01/06/15 11:57 +0100, John Garbutt wrote:

On 26/05/15 13:54 -0400, Nikhil Komawar wrote:

On 5/26/15 12:57 PM, Jesse Cook wrote:
   We also had some hallway talk about putting the v1 and v2 APIs on top
of
   the v3 API. This forces faster adoption, verifies supportability via v1
and
   v2 tests, increases supportability of v1 and v2 APIs, and pushes out
the
   need to kill v1 API.

Let's discuss more as time and development progresses on that possibility.
v3
API should stay EXPERIMENTAL for now as that would help us understand
use-cases
across programs as it gets adopted by various code-bases. Putting v1/v2 on
top
of v3 would be tricky for now as we may have breaking changes with code
being
relatively-less stable due to narrow review domain.



I actually think we'd benefit more from having V2 on top of V3 than
not doing it. I'd probably advocate to make this M material rather
than L but I think it'd be good.

I think regardless of what we do, I'd like to kill v1 as it has a
sharing model that is not secure.


Given v1 has lots of users, killing it will be hard.

If you maintained v1 support as v1 on top of v3 (or v2 I guess), could
you not do something like permanently disable the "bad bits" of the
API?


I agree it'll be hard but, at least for v1, I believe it should
happen. It has some security issues (mostly related to image sharing)
that are not going to be fixed there.



The idea being, users listing their images, and updating image
metadata via v1, don't get broken during the evolution?


The feedback we got at the summit (even from OPs) was that we could go
ahead, mark it as deprecated, give a deprecation period and then turn
it off.


FWIW, moving Nova from glance v1 to glance v2, without breaking Nova's
public API, will require someone getting a big chunk of glance v1 on
top of glance v2.


AFAIK, the biggest issue right now is "changed-since" which is
something Glance doesn't have in v2 but it's exposed throught Nova's
image API.

I'm happy you brought this up. What are Nova's plans to adopt Glance's
v2 ? I heard there was a discussion and something along the lines of
creating a library that wraps both APIs came up.

Where can I find more info about this?

I really think nova should put some more effort on helping this
happen. The work I did[0] - all red now, I swear it wasn't - during
Kilo didn't get enough attention even before we decided to push it
back. Not a complain, really. However, I'd love to see some
cross-project efforts on making this happen.

[0] https://review.openstack.org/#/c/144875/

Happy to help,
Flavio

--
@flaper87
Flavio Percoco


pgp0yOXS5xQjM.pgp
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] [Glance] [all] Liberty summit: Updates in Glance

[John Garbutt]

> On 26/05/15 13:54 -0400, Nikhil Komawar wrote:
>> On 5/26/15 12:57 PM, Jesse Cook wrote:
>>We also had some hallway talk about putting the v1 and v2 APIs on top
>> of
>>the v3 API. This forces faster adoption, verifies supportability via v1
>> and
>>v2 tests, increases supportability of v1 and v2 APIs, and pushes out
>> the
>>need to kill v1 API.
>>
>> Let's discuss more as time and development progresses on that possibility.
>> v3
>> API should stay EXPERIMENTAL for now as that would help us understand
>> use-cases
>> across programs as it gets adopted by various code-bases. Putting v1/v2 on
>> top
>> of v3 would be tricky for now as we may have breaking changes with code
>> being
>> relatively-less stable due to narrow review domain.
>
>
> I actually think we'd benefit more from having V2 on top of V3 than
> not doing it. I'd probably advocate to make this M material rather
> than L but I think it'd be good.
>
> I think regardless of what we do, I'd like to kill v1 as it has a
> sharing model that is not secure.

Given v1 has lots of users, killing it will be hard.

If you maintained v1 support as v1 on top of v3 (or v2 I guess), could
you not do something like permanently disable the "bad bits" of the
API?

The idea being, users listing their images, and updating image
metadata via v1, don't get broken during the evolution?

FWIW, moving Nova from glance v1 to glance v2, without breaking Nova's
public API, will require someone getting a big chunk of glance v1 on
top of glance v2.

Thanks,
John

__
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] [Glance] [all] Liberty summit: Updates in Glance

[Flavio Percoco]

On 27/05/15 11:30 -0400, Nikhil Komawar wrote:
I kinda agree with all 3 of you, possibly because there are Grey areas 
on how best we can actually do this. We are talking about one cycle 
ahead to the very least. While that is a great thing to do, I think we 
should focus on making the current Artifacts implementation stable & 
bring it to a state that it works great with the different data asset 
requirements within OpenStack realm (to support the main motivation 
behind this concept and Glance's mission statement).


That's the fun thing the Artifacts work. We can't just make it work
well without having this migration plan in mind (at least in the
reviewers mind) because I believe there are areas where, depending on
the transition plan, the work on artifacts won't be as straightforward
as we'd like.

Flavio



Cheers
Nikhil

On 5/27/15 8:30 AM, Kuvaja, Erno wrote:

-Original Message-
From: Flavio Percoco [mailto:fla...@redhat.com]
Sent: 27 May 2015 00:58
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glance] [all] Liberty summit: Updates in Glance

Jesse, you beat me on this one :)

On 26/05/15 13:54 -0400, Nikhil Komawar wrote:

Thank you Jesse for your valuable input (here and at the summit) as
well as intent to clarify the discussion.

Just trying to ensure people are aware about the EXPERIMENTAL nature of
the v3 API and reasons behind it. Please find my responses in-line.
However, I do want to ensure you all, that we will strive hard to move
away from the EXPERIMENTAL nature and go with a rock solid
implementation as and when interest grows in the code-base (that helps

stabilize it).

On 5/26/15 12:57 PM, Jesse Cook wrote:


   On 5/22/15, 4:28 PM, "Nikhil Komawar" 

wrote:


   Hi all,

   tl;dr; Artifacts IS staying in Glance.

1. We had a nice discussion at the contributors' meet-up at the
   Vancouver summit this morning. After weighing in many possibilities
   and evolution of the Glance program, we have decided to go ahead
   with the Artifacts implementation within Glance program under the
   EXPERIMENTAL v3 API.

   Want to clarify a bit here. My understanding is: s/Artifacts/v3 API/g. That
   is to say, Artifacts is the technical implementation of the v3 API. This
   also means the v3 API is an objects API vs just an images API.


Generic "data assets'" API would be a nice term along the lines of the
mission statement. Artifacts seemed fitting as that was the focus of
discussion at various sessions.

Regardless of how we call it, I do appreciate the clarity on the fact that
Artifacts - data assests - is just the technical implementation of what will be
Glance's API v3. It's an important distinction to avoid sending the wrong
message on what it's going to be done there.


   We also had some hallway talk about putting the v1 and v2 APIs on top of
   the v3 API. This forces faster adoption, verifies supportability via v1 and
   v2 tests, increases supportability of v1 and v2 APIs, and pushes out the
   need to kill v1 API.

Let's discuss more as time and development progresses on that
possibility. v3 API should stay EXPERIMENTAL for now as that would help
us understand use-cases across programs as it gets adopted by various
code-bases. Putting v1/v2 on top of v3 would be tricky for now as we
may have breaking changes with code being relatively-less stable due to

narrow review domain.

I actually think we'd benefit more from having V2 on top of V3 than not doing
it. I'd probably advocate to make this M material rather than L but I think it'd
be good.

We perhaps would, but that would realistically push v2 adoption across the 
projects to somewhere around O release. Just looking how long it took the v2 
code base to mature enough that we're seriously talking moving to use that in 
production.

I think regardless of what we do, I'd like to kill v1 as it has a sharing model
that is not secure.

The above would postpone this one somewhere around Q-R (which is btw. not so 
far from U anymore).

More I think about this the more convinced I am about focusing to the move to 
v2 on our consumers, deprecating the v1 out and after that we can start talking 
about moving v2 on top of the v3 codebase if possible, not other way around 
hoping that it would speed up the v3 adoption.

- Erno

Flavio


1.
2. The effort would primarily be conducted as a sub-team-like
   structure within the program and the co-coordinators and drivers of
   the necessary Artifacts features would be given core-reviewer
   status temporarily with an informal agreement to merge code that is
   only related to Artifacts.
3. The entire Glance team would give reviews as time and priorities
   permit. The approval (+A/+WorkFlow) of any code within the

program

Re: [openstack-dev] [Glance] [all] Liberty summit: Updates in Glance

[Nikhil Komawar]

I kinda agree with all 3 of you, possibly because there are Grey areas 
on how best we can actually do this. We are talking about one cycle 
ahead to the very least. While that is a great thing to do, I think we 
should focus on making the current Artifacts implementation stable & 
bring it to a state that it works great with the different data asset 
requirements within OpenStack realm (to support the main motivation 
behind this concept and Glance's mission statement).


Cheers
Nikhil

On 5/27/15 8:30 AM, Kuvaja, Erno wrote:

-Original Message-
From: Flavio Percoco [mailto:fla...@redhat.com]
Sent: 27 May 2015 00:58
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glance] [all] Liberty summit: Updates in Glance

Jesse, you beat me on this one :)

On 26/05/15 13:54 -0400, Nikhil Komawar wrote:

Thank you Jesse for your valuable input (here and at the summit) as
well as intent to clarify the discussion.

Just trying to ensure people are aware about the EXPERIMENTAL nature of
the v3 API and reasons behind it. Please find my responses in-line.
However, I do want to ensure you all, that we will strive hard to move
away from the EXPERIMENTAL nature and go with a rock solid
implementation as and when interest grows in the code-base (that helps

stabilize it).

On 5/26/15 12:57 PM, Jesse Cook wrote:


On 5/22/15, 4:28 PM, "Nikhil Komawar" 

wrote:


Hi all,

tl;dr; Artifacts IS staying in Glance.

 1. We had a nice discussion at the contributors' meet-up at the
Vancouver summit this morning. After weighing in many possibilities
and evolution of the Glance program, we have decided to go ahead
with the Artifacts implementation within Glance program under the
EXPERIMENTAL v3 API.

Want to clarify a bit here. My understanding is: s/Artifacts/v3 API/g. That
is to say, Artifacts is the technical implementation of the v3 API. This
also means the v3 API is an objects API vs just an images API.


Generic "data assets'" API would be a nice term along the lines of the
mission statement. Artifacts seemed fitting as that was the focus of
discussion at various sessions.

Regardless of how we call it, I do appreciate the clarity on the fact that
Artifacts - data assests - is just the technical implementation of what will be
Glance's API v3. It's an important distinction to avoid sending the wrong
message on what it's going to be done there.


We also had some hallway talk about putting the v1 and v2 APIs on top of
the v3 API. This forces faster adoption, verifies supportability via v1 and
v2 tests, increases supportability of v1 and v2 APIs, and pushes out the
need to kill v1 API.

Let's discuss more as time and development progresses on that
possibility. v3 API should stay EXPERIMENTAL for now as that would help
us understand use-cases across programs as it gets adopted by various
code-bases. Putting v1/v2 on top of v3 would be tricky for now as we
may have breaking changes with code being relatively-less stable due to

narrow review domain.

I actually think we'd benefit more from having V2 on top of V3 than not doing
it. I'd probably advocate to make this M material rather than L but I think it'd
be good.

We perhaps would, but that would realistically push v2 adoption across the 
projects to somewhere around O release. Just looking how long it took the v2 
code base to mature enough that we're seriously talking moving to use that in 
production.

I think regardless of what we do, I'd like to kill v1 as it has a sharing model
that is not secure.

The above would postpone this one somewhere around Q-R (which is btw. not so 
far from U anymore).

More I think about this the more convinced I am about focusing to the move to 
v2 on our consumers, deprecating the v1 out and after that we can start talking 
about moving v2 on top of the v3 codebase if possible, not other way around 
hoping that it would speed up the v3 adoption.

- Erno

Flavio


 1.
 2. The effort would primarily be conducted as a sub-team-like
structure within the program and the co-coordinators and drivers of
the necessary Artifacts features would be given core-reviewer
status temporarily with an informal agreement to merge code that is
only related to Artifacts.
 3. The entire Glance team would give reviews as time and priorities
permit. The approval (+A/+WorkFlow) of any code within the

program

would need to come from core-reviewers who are not temporarily
authorized. The list of such individuals and updated time-line
would be documented in phases during the course of Liberty cycle.
 4. We will continue to evaluate & update the governance, maturity of
the code and future pla

Re: [openstack-dev] [Glance] [all] Liberty summit: Updates in Glance

[Kuvaja, Erno]

> -Original Message-
> From: Flavio Percoco [mailto:fla...@redhat.com]
> Sent: 27 May 2015 00:58
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Glance] [all] Liberty summit: Updates in Glance
> 
> Jesse, you beat me on this one :)
> 
> On 26/05/15 13:54 -0400, Nikhil Komawar wrote:
> >Thank you Jesse for your valuable input (here and at the summit) as
> >well as intent to clarify the discussion.
> >
> >Just trying to ensure people are aware about the EXPERIMENTAL nature of
> >the v3 API and reasons behind it. Please find my responses in-line.
> >However, I do want to ensure you all, that we will strive hard to move
> >away from the EXPERIMENTAL nature and go with a rock solid
> >implementation as and when interest grows in the code-base (that helps
> stabilize it).
> >
> >On 5/26/15 12:57 PM, Jesse Cook wrote:
> >
> >
> >On 5/22/15, 4:28 PM, "Nikhil Komawar" 
> wrote:
> >
> >
> >Hi all,
> >
> >tl;dr; Artifacts IS staying in Glance.
> >
> > 1. We had a nice discussion at the contributors' meet-up at the
> >Vancouver summit this morning. After weighing in many 
> > possibilities
> >and evolution of the Glance program, we have decided to go ahead
> >with the Artifacts implementation within Glance program under the
> >EXPERIMENTAL v3 API.
> >
> >Want to clarify a bit here. My understanding is: s/Artifacts/v3 API/g. 
> > That
> >is to say, Artifacts is the technical implementation of the v3 API. This
> >also means the v3 API is an objects API vs just an images API.
> >
> >
> >Generic "data assets'" API would be a nice term along the lines of the
> >mission statement. Artifacts seemed fitting as that was the focus of
> >discussion at various sessions.
> 
> Regardless of how we call it, I do appreciate the clarity on the fact that
> Artifacts - data assests - is just the technical implementation of what will 
> be
> Glance's API v3. It's an important distinction to avoid sending the wrong
> message on what it's going to be done there.
> 
> >
> >We also had some hallway talk about putting the v1 and v2 APIs on top of
> >the v3 API. This forces faster adoption, verifies supportability via v1 
> > and
> >v2 tests, increases supportability of v1 and v2 APIs, and pushes out the
> >need to kill v1 API.
> >
> >Let's discuss more as time and development progresses on that
> >possibility. v3 API should stay EXPERIMENTAL for now as that would help
> >us understand use-cases across programs as it gets adopted by various
> >code-bases. Putting v1/v2 on top of v3 would be tricky for now as we
> >may have breaking changes with code being relatively-less stable due to
> narrow review domain.
> 
> I actually think we'd benefit more from having V2 on top of V3 than not doing
> it. I'd probably advocate to make this M material rather than L but I think 
> it'd
> be good.

We perhaps would, but that would realistically push v2 adoption across the 
projects to somewhere around O release. Just looking how long it took the v2 
code base to mature enough that we're seriously talking moving to use that in 
production.
> 
> I think regardless of what we do, I'd like to kill v1 as it has a sharing 
> model
> that is not secure.

The above would postpone this one somewhere around Q-R (which is btw. not so 
far from U anymore).

More I think about this the more convinced I am about focusing to the move to 
v2 on our consumers, deprecating the v1 out and after that we can start talking 
about moving v2 on top of the v3 codebase if possible, not other way around 
hoping that it would speed up the v3 adoption.

- Erno
> 
> Flavio
> 
> > 1.
> > 2. The effort would primarily be conducted as a sub-team-like
> >structure within the program and the co-coordinators and drivers 
> > of
> >the necessary Artifacts features would be given core-reviewer
> >status temporarily with an informal agreement to merge code that 
> > is
> >only related to Artifacts.
> > 3. The entire Glance team would give reviews as time and priorities
> >permit. The approval (+A/+WorkFlow) of any code within the
> program
> >would need to come from core-reviewers who are not temporarily
> >authorized. The list of such individuals and updated time-line
> >would be d

Re: [openstack-dev] [Glance] [all] Liberty summit: Updates in Glance

[Flavio Percoco]

Jesse, you beat me on this one :)

On 26/05/15 13:54 -0400, Nikhil Komawar wrote:

Thank you Jesse for your valuable input (here and at the summit) as well as
intent to clarify the discussion.

Just trying to ensure people are aware about the EXPERIMENTAL nature of the v3
API and reasons behind it. Please find my responses in-line. However, I do want
to ensure you all, that we will strive hard to move away from the EXPERIMENTAL
nature and go with a rock solid implementation as and when interest grows in
the code-base (that helps stabilize it).

On 5/26/15 12:57 PM, Jesse Cook wrote:


   On 5/22/15, 4:28 PM, "Nikhil Komawar"  wrote:


   Hi all,

   tl;dr; Artifacts IS staying in Glance.

1. We had a nice discussion at the contributors' meet-up at the
   Vancouver summit this morning. After weighing in many possibilities
   and evolution of the Glance program, we have decided to go ahead
   with the Artifacts implementation within Glance program under the
   EXPERIMENTAL v3 API.

   Want to clarify a bit here. My understanding is: s/Artifacts/v3 API/g. That
   is to say, Artifacts is the technical implementation of the v3 API. This
   also means the v3 API is an objects API vs just an images API.


Generic "data assets'" API would be a nice term along the lines of the mission
statement. Artifacts seemed fitting as that was the focus of discussion at
various sessions.


Regardless of how we call it, I do appreciate the clarity on the fact
that Artifacts - data assests - is just the technical implementation
of what will be Glance's API v3. It's an important distinction to
avoid sending the wrong message on what it's going to be done there.



   We also had some hallway talk about putting the v1 and v2 APIs on top of
   the v3 API. This forces faster adoption, verifies supportability via v1 and
   v2 tests, increases supportability of v1 and v2 APIs, and pushes out the
   need to kill v1 API.

Let's discuss more as time and development progresses on that possibility. v3
API should stay EXPERIMENTAL for now as that would help us understand use-cases
across programs as it gets adopted by various code-bases. Putting v1/v2 on top
of v3 would be tricky for now as we may have breaking changes with code being
relatively-less stable due to narrow review domain.


I actually think we'd benefit more from having V2 on top of V3 than
not doing it. I'd probably advocate to make this M material rather
than L but I think it'd be good.

I think regardless of what we do, I'd like to kill v1 as it has a
sharing model that is not secure.

Flavio


1.
2. The effort would primarily be conducted as a sub-team-like
   structure within the program and the co-coordinators and drivers of
   the necessary Artifacts features would be given core-reviewer
   status temporarily with an informal agreement to merge code that is
   only related to Artifacts.
3. The entire Glance team would give reviews as time and priorities
   permit. The approval (+A/+WorkFlow) of any code within the program
   would need to come from core-reviewers who are not temporarily
   authorized. The list of such individuals and updated time-line
   would be documented in phases during the course of Liberty cycle.
4. We will continue to evaluate & update the governance, maturity of
   the code and future plans for the v1, v2 and v3 Glance APIs as time
   progresses. However, for now we are aiming to integrate all of
   Glance (specifically Images) as Artifacts in the v3 API.

  
   As I understand it, that is to say that v3 requests in the first

   “micro-version” that specify the object type as image would get a not
   implemented or similar error. The next next “micro-version” would likely
   contain the support for images along with possibly implementing the v1 and
   v2 APIs on top of v3.

As we will have EXPERIMENTAL v3 API, we should try to avoid micro-versions.
However, we should soon consider this as a possibility once things seem to
stabilize.

1.
   Special thanks to Flavio for providing DefCore and TC perspective as
   well as initializing this discussion. Also, thanks to Stuart McLaren
   and Brian Rosmaita for giving us thoughtful veteran feedback. The
   entire team did a great job at putting all their questions and concerns
   amicably on the table and came to a good understanding of the plan and
   level of commitment.

   All the best to the Project SearchLight team who have decided to start
   ElasticSearch based development for search functionality in OpenStack
   as a separate program and would be porting respective code out of
   Glance. Glance team would help co-ordinate this porting effort in order
   to avoid destabilizing Images and MetaDefs code-bases.

   This also means we will re-evaluate some of the existing spec 

Re: [openstack-dev] [Glance] [all] Liberty summit: Updates in Glance

[Nikhil Komawar]

Thank you Jesse for your valuable input (here and at the summit) as well 
as intent to clarify the discussion.


Just trying to ensure people are aware about the EXPERIMENTAL nature of 
the v3 API and reasons behind it. Please find my responses in-line. 
However, I do want to ensure you all, that we will strive hard to move 
away from the EXPERIMENTAL nature and go with a rock solid 
implementation as and when interest grows in the code-base (that helps 
stabilize it).


On 5/26/15 12:57 PM, Jesse Cook wrote:


On 5/22/15, 4:28 PM, "Nikhil Komawar" > wrote:


Hi all,

tl;dr; Artifacts IS staying in Glance.

 1. We had a nice discussion at the contributors' meet-up at the
Vancouver summit this morning. After weighing in many
possibilities and evolution of the Glance program, we have
decided to go ahead with the Artifacts implementation within
Glance program under the EXPERIMENTAL v3 API.

Want to clarify a bit here. My understanding is: s/Artifacts/v3 API/g. 
That is to say, Artifacts is the technical implementation of the v3 
API. This also means the v3 API is an objects API vs just an images API.


Generic "data assets'" API would be a nice term along the lines of the 
mission statement. Artifacts seemed fitting as that was the focus of 
discussion at various sessions.
We also had some hallway talk about putting the v1 and v2 APIs on top 
of the v3 API. This forces faster adoption, verifies supportability 
via v1 and v2 tests, increases supportability of v1 and v2 APIs, and 
pushes out the need to kill v1 API.
Let's discuss more as time and development progresses on that 
possibility. v3 API should stay EXPERIMENTAL for now as that would help 
us understand use-cases across programs as it gets adopted by various 
code-bases. Putting v1/v2 on top of v3 would be tricky for now as we may 
have breaking changes with code being relatively-less stable due to 
narrow review domain.


1.


 2. The effort would primarily be conducted as a sub-team-like
structure within the program and the co-coordinators and
drivers of the necessary Artifacts features would be given
core-reviewer status temporarily with an informal agreement to
merge code that is only related to Artifacts.
 3. The entire Glance team would give reviews as time and
priorities permit. The approval (+A/+WorkFlow) of any code
within the program would need to come from core-reviewers who
are not temporarily authorized. The list of such individuals
and updated time-line would be documented in phases during the
course of Liberty cycle.
 4. We will continue to evaluate & update the governance, maturity
of the code and future plans for the v1, v2 and v3 Glance APIs
as time progresses. However, for now we are aiming to
integrate all of Glance (specifically Images) as Artifacts in
the v3 API.


As I understand it, that is to say that v3 requests in the first 
“micro-version” that specify the object type as image would get a not 
implemented or similar error. The next next “micro-version” would 
likely contain the support for images along with possibly implementing 
the v1 and v2 APIs on top of v3.
As we will have EXPERIMENTAL v3 API, we should try to avoid 
micro-versions. However, we should soon consider this as a possibility 
once things seem to stabilize.


1.


Special thanks to Flavio for providing DefCore and TC perspective
as well as initializing this discussion. Also, thanks to Stuart
McLaren and Brian Rosmaita for giving us thoughtful veteran
feedback. The entire team did a great job at putting all their
questions and concerns amicably on the table and came to a good
understanding of the plan and level of commitment.

All the best to the Project SearchLight team who have decided to
start ElasticSearch based development for search functionality in
OpenStack as a separate program and would be porting respective
code out of Glance. Glance team would help co-ordinate this
porting effort in order to avoid destabilizing Images and MetaDefs
code-bases.

This also means we will re-evaluate some of the existing spec
proposals and most likely not ask people for radical changes in
their approach. This first phase of the Liberty cycle would focus
on seeing the Experimental Artifacts API through. We will also
focus on stability aspects of the Images (v1 & v2) related
features. The second phase priorities would be decided at the
mid-cycle meet-up (details to come out soon).

Feel free to ask me questions on IRC or via email.

Cheers,
Nikhil



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

Re: [openstack-dev] [Glance] [all] Liberty summit: Updates in Glance

[Jesse Cook]

On 5/22/15, 4:28 PM, "Nikhil Komawar" 
mailto:nik.koma...@gmail.com>> wrote:

Hi all,

tl;dr; Artifacts IS staying in Glance.


  1.  We had a nice discussion at the contributors' meet-up at the Vancouver 
summit this morning. After weighing in many possibilities and evolution of the 
Glance program, we have decided to go ahead with the Artifacts implementation 
within Glance program under the EXPERIMENTAL v3 API.

Want to clarify a bit here. My understanding is: s/Artifacts/v3 API/g. That is 
to say, Artifacts is the technical implementation of the v3 API. This also 
means the v3 API is an objects API vs just an images API.

We also had some hallway talk about putting the v1 and v2 APIs on top of the v3 
API. This forces faster adoption, verifies supportability via v1 and v2 tests, 
increases supportability of v1 and v2 APIs, and pushes out the need to kill v1 
API.

  1.
  2.  The effort would primarily be conducted as a sub-team-like structure 
within the program and the co-coordinators and drivers of the necessary 
Artifacts features would be given core-reviewer status temporarily with an 
informal agreement to merge code that is only related to Artifacts.
  3.  The entire Glance team would give reviews as time and priorities permit. 
The approval (+A/+WorkFlow) of any code within the program would need to come 
from core-reviewers who are not temporarily authorized. The list of such 
individuals and updated time-line would be documented in phases during the 
course of Liberty cycle.
  4.  We will continue to evaluate & update the governance, maturity of the 
code and future plans for the v1, v2 and v3 Glance APIs as time progresses. 
However, for now we are aiming to integrate all of Glance (specifically Images) 
as Artifacts in the v3 API.

As I understand it, that is to say that v3 requests in the first 
"micro-version" that specify the object type as image would get a not 
implemented or similar error. The next next "micro-version" would likely 
contain the support for images along with possibly implementing the v1 and v2 
APIs on top of v3.

  1.

Special thanks to Flavio for providing DefCore and TC perspective as well as 
initializing this discussion. Also, thanks to Stuart McLaren and Brian Rosmaita 
for giving us thoughtful veteran feedback. The entire team did a great job at 
putting all their questions and concerns amicably on the table and came to a 
good understanding of the plan and level of commitment.

All the best to the Project SearchLight team who have decided to start 
ElasticSearch based development for search functionality in OpenStack as a 
separate program and would be porting respective code out of Glance. Glance 
team would help co-ordinate this porting effort in order to avoid destabilizing 
Images and MetaDefs code-bases.

This also means we will re-evaluate some of the existing spec proposals and 
most likely not ask people for radical changes in their approach. This first 
phase of the Liberty cycle would focus on seeing the Experimental Artifacts API 
through. We will also focus on stability aspects of the Images (v1 & v2) 
related features. The second phase priorities would be decided at the mid-cycle 
meet-up (details to come out soon).

Feel free to ask me questions on IRC or via email.

Cheers,
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-dev] [Glance] [all] Liberty summit: Updates in Glance

[Nikhil Komawar]

Hi all,

tl;dr; Artifacts IS staying in Glance.

1. We had a nice discussion at the contributors' meet-up at the
   Vancouver summit this morning. After weighing in many possibilities
   and evolution of the Glance program, we have decided to go ahead
   with the Artifacts implementation within Glance program under the
   EXPERIMENTAL v3 API.
2. The effort would primarily be conducted as a sub-team-like structure
   within the program and the co-coordinators and drivers of the
   necessary Artifacts features would be given core-reviewer status
   temporarily with an informal agreement to merge code that is only
   related to Artifacts.
3. The entire Glance team would give reviews as time and priorities
   permit. The approval (+A/+WorkFlow) of any code within the program
   would need to come from core-reviewers who are not temporarily
   authorized. The list of such individuals and updated time-line would
   be documented in phases during the course of Liberty cycle.
4. We will continue to evaluate & update the governance, maturity of
   the code and future plans for the v1, v2 and v3 Glance APIs as time
   progresses. However, for now we are aiming to integrate all of
   Glance (specifically Images) as Artifacts in the v3 API.

Special thanks to Flavio for providing DefCore and TC perspective as 
well as initializing this discussion. Also, thanks to Stuart McLaren and 
Brian Rosmaita for giving us thoughtful veteran feedback. The entire 
team did a great job at putting all their questions and concerns 
amicably on the table and came to a good understanding of the plan and 
level of commitment.


All the best to the Project SearchLight team who have decided to start 
ElasticSearch based development for search functionality in OpenStack as 
a separate program and would be porting respective code out of Glance. 
Glance team would help co-ordinate this porting effort in order to avoid 
destabilizing Images and MetaDefs code-bases.


This also means we will re-evaluate some of the existing spec proposals 
and most likely not ask people for radical changes in their approach. 
This first phase of the Liberty cycle would focus on seeing the 
Experimental Artifacts API through. We will also focus on stability 
aspects of the Images (v1 & v2) related features. The second phase 
priorities would be decided at the mid-cycle meet-up (details to come 
out soon).


Feel free to ask me questions on IRC or via email.

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