Re: [openstack-dev] [glance][nova] how to upgrade from v1 to v2?

[Chris Hoge]

> On Sep 29, 2015, at 1:07 AM, Flavio Percoco  wrote:
> 
> On 28/09/15 16:29 -0400, Doug Hellmann wrote:
>> Excerpts from Mark Voelker's message of 2015-09-28 19:55:18 +:
>>> On Sep 28, 2015, at 9:03 AM, Doug Hellmann  wrote:
>>> >
>>> > Excerpts from John Garbutt's message of 2015-09-28 12:32:53 +0100:
>>> >> On 28 September 2015 at 12:10, Sean Dague  wrote:
>>> >>> On 09/27/2015 08:43 AM, Doug Hellmann wrote:
>>>  Excerpts from Mark Voelker's message of 2015-09-25 20:43:23 +:
>>> > On Sep 25, 2015, at 1:56 PM, Doug Hellmann  
>>> > wrote:
>>> >>
>>> >> Excerpts from Mark Voelker's message of 2015-09-25 17:42:24 +:
>>> >>> 
>>> >
>>> > Ah.  Thanks for bringing that up, because I think this may be an area 
>>> > where there’s some misconception about what DefCore is set up to do 
>>> > today.  In it’s present form, the Board of Directors has structured 
>>> > DefCore to look much more at trailing indicators of market acceptance 
>>> > rather than future technical direction.  More on that over here. [1]
>>> 
>>>  And yet future technical direction does factor in, and I'm trying
>>>  to add a new heuristic to that aspect of consideration of tests:
>>>  Do not add tests that use proxy APIs.
>>> 
>>>  If there is some compelling reason to add a capability for which
>>>  the only tests use a proxy, that's important feedback for the
>>>  contributor community and tells us we need to improve our test
>>>  coverage. If the reason to use the proxy is that no one is deploying
>>>  the proxied API publicly, that is also useful feedback, but I suspect
>>>  we will, in most cases (glance is the exception), say "Yeah, that's
>>>  not how we mean for you to run the services long-term, so don't
>>>  include that capability."
>>> >>>
>>> >>> I think we might also just realize that some of the tests are using the
>>> >>> proxy because... that's how they were originally written.
>>> >>
>>> >> From my memory, thats how we got here.
>>> >>
>>> >> The Nova tests needed to use an image API. (i.e. list images used to
>>> >> check the snapshot Nova, or similar)
>>> >>
>>> >> The Nova proxy was chosen over Glance v1 and Glance v2, mostly due to
>>> >> it being the only widely deployed option.
>>> >
>>> > Right, and I want to make sure it's clear that I am differentiating
>>> > between "these tests are bad" and "these tests are bad *for DefCore*".
>>> > We should definitely continue to test the proxy API, since it's a
>>> > feature we have and that our users rely on.
>>> >
>>> >>
>>> >>> And they could be rewritten to use native APIs.
>>> >>
>>> >> +1
>>> >> Once Glance v2 is available.
>>> >>
>>> >> Adding Glance v2 as advisory seems a good step to help drive more 
>>> >> adoption.
>>> >
>>> > I think we probably don't want to rewrite the existing tests, since
>>> > that effectively changes the contract out from under existing folks
>>> > complying with DefCore.  If we need new, parallel, tests that do
>>> > not use the proxy to make more suitable tests for DefCore to use,
>>> > we should create those.
>>> >
>>> >>
>>> >>> I do agree that "testing proxies" should not be part of Defcore, and I
>>> >>> like Doug's idea of making that a new heuristic in test selection.
>>> >>
>>> >> +1
>>> >> Thats a good thing to add.
>>> >> But I don't think we had another option in this case.
>>> >
>>> > We did have the option of leaving the feature out and highlighting the
>>> > discrepancy to the contributors so tests could be added. That
>>> > communication didn't really happen, as far as I can tell.
>>> >
>>>  Sorry, I wasn't clear. The Nova team would, I expect, view the use of
>>>  those APIs in DefCore as a reason to avoid deprecating them in the code
>>>  even if they wanted to consider them as legacy features that should be
>>>  removed. Maybe that's not true, and the Nova team would be happy to
>>>  deprecate the APIs, but I did think that part of the feedback cycle we
>>>  were establishing here was to have an indication from the outside of 
>>>  the
>>>  contributor base about what APIs are considered important enough to 
>>>  keep
>>>  alive for a long period of time.
>>> >>> I'd also agree with this. Defcore is a wider contract that we're trying
>>> >>> to get even more people to write to because that cross section should be
>>> >>> widely deployed. So deprecating something in Defcore is something I
>>> >>> think most teams, Nova included, would be very reluctant to do. It's
>>> >>> just asking for breaking your users.
>>> >>
>>> >> I can't see us removing the proxy APIs in Nova any time soon,
>>> >> regardless of DefCore, as it would break too many people.
>>> >>
>>> >> But personally, I like dropping them from Defcore, to signal that the
>>> >> best practice is to use the Glance v2 API directly, rather than the
>>> >> Nova proxy.
>>> >>
>>> >> Maybe the are just marked deprecated, but s

Re: [openstack-dev] [glance][nova] how to upgrade from v1 to v2?

[Flavio Percoco]

On 28/09/15 16:29 -0400, Doug Hellmann wrote:

Excerpts from Mark Voelker's message of 2015-09-28 19:55:18 +:

On Sep 28, 2015, at 9:03 AM, Doug Hellmann  wrote:
>
> Excerpts from John Garbutt's message of 2015-09-28 12:32:53 +0100:
>> On 28 September 2015 at 12:10, Sean Dague  wrote:
>>> On 09/27/2015 08:43 AM, Doug Hellmann wrote:
 Excerpts from Mark Voelker's message of 2015-09-25 20:43:23 +:
> On Sep 25, 2015, at 1:56 PM, Doug Hellmann  wrote:
>>
>> Excerpts from Mark Voelker's message of 2015-09-25 17:42:24 +:
>>> 
>
> Ah.  Thanks for bringing that up, because I think this may be an area 
where there’s some misconception about what DefCore is set up to do today.  In it’s present 
form, the Board of Directors has structured DefCore to look much more at trailing indicators 
of market acceptance rather than future technical direction.  More on that over here. [1]

 And yet future technical direction does factor in, and I'm trying
 to add a new heuristic to that aspect of consideration of tests:
 Do not add tests that use proxy APIs.

 If there is some compelling reason to add a capability for which
 the only tests use a proxy, that's important feedback for the
 contributor community and tells us we need to improve our test
 coverage. If the reason to use the proxy is that no one is deploying
 the proxied API publicly, that is also useful feedback, but I suspect
 we will, in most cases (glance is the exception), say "Yeah, that's
 not how we mean for you to run the services long-term, so don't
 include that capability."
>>>
>>> I think we might also just realize that some of the tests are using the
>>> proxy because... that's how they were originally written.
>>
>> From my memory, thats how we got here.
>>
>> The Nova tests needed to use an image API. (i.e. list images used to
>> check the snapshot Nova, or similar)
>>
>> The Nova proxy was chosen over Glance v1 and Glance v2, mostly due to
>> it being the only widely deployed option.
>
> Right, and I want to make sure it's clear that I am differentiating
> between "these tests are bad" and "these tests are bad *for DefCore*".
> We should definitely continue to test the proxy API, since it's a
> feature we have and that our users rely on.
>
>>
>>> And they could be rewritten to use native APIs.
>>
>> +1
>> Once Glance v2 is available.
>>
>> Adding Glance v2 as advisory seems a good step to help drive more adoption.
>
> I think we probably don't want to rewrite the existing tests, since
> that effectively changes the contract out from under existing folks
> complying with DefCore.  If we need new, parallel, tests that do
> not use the proxy to make more suitable tests for DefCore to use,
> we should create those.
>
>>
>>> I do agree that "testing proxies" should not be part of Defcore, and I
>>> like Doug's idea of making that a new heuristic in test selection.
>>
>> +1
>> Thats a good thing to add.
>> But I don't think we had another option in this case.
>
> We did have the option of leaving the feature out and highlighting the
> discrepancy to the contributors so tests could be added. That
> communication didn't really happen, as far as I can tell.
>
 Sorry, I wasn't clear. The Nova team would, I expect, view the use of
 those APIs in DefCore as a reason to avoid deprecating them in the code
 even if they wanted to consider them as legacy features that should be
 removed. Maybe that's not true, and the Nova team would be happy to
 deprecate the APIs, but I did think that part of the feedback cycle we
 were establishing here was to have an indication from the outside of the
 contributor base about what APIs are considered important enough to keep
 alive for a long period of time.
>>> I'd also agree with this. Defcore is a wider contract that we're trying
>>> to get even more people to write to because that cross section should be
>>> widely deployed. So deprecating something in Defcore is something I
>>> think most teams, Nova included, would be very reluctant to do. It's
>>> just asking for breaking your users.
>>
>> I can't see us removing the proxy APIs in Nova any time soon,
>> regardless of DefCore, as it would break too many people.
>>
>> But personally, I like dropping them from Defcore, to signal that the
>> best practice is to use the Glance v2 API directly, rather than the
>> Nova proxy.
>>
>> Maybe the are just marked deprecated, but still required, although
>> that sounds a bit crazy.
>
> Marking them as deprecated, then removing them from DefCore, would let
> the Nova team make a technical decision about what to do with them
> (maybe they get spun out into a separate service, maybe they're so
> popular you just keep them, whatever).

So, here’s that Who’s On First thing again.  Just to clarify: Nova does not 
need Capabilities to be removed from Guidelines in order to make technical 
decisions about what to do with a featur

Re: [openstack-dev] [glance][nova] how to upgrade from v1 to v2?

[Flavio Percoco]

On 28/09/15 09:03 -0400, Doug Hellmann wrote:

Excerpts from John Garbutt's message of 2015-09-28 12:32:53 +0100:

On 28 September 2015 at 12:10, Sean Dague  wrote:
> On 09/27/2015 08:43 AM, Doug Hellmann wrote:
>> Excerpts from Mark Voelker's message of 2015-09-25 20:43:23 +:
>>> On Sep 25, 2015, at 1:56 PM, Doug Hellmann  wrote:

 Excerpts from Mark Voelker's message of 2015-09-25 17:42:24 +:
> 
>>>
>>> Ah.  Thanks for bringing that up, because I think this may be an area where 
there’s some misconception about what DefCore is set up to do today.  In it’s present 
form, the Board of Directors has structured DefCore to look much more at trailing 
indicators of market acceptance rather than future technical direction.  More on that 
over here. [1]
>>
>> And yet future technical direction does factor in, and I'm trying
>> to add a new heuristic to that aspect of consideration of tests:
>> Do not add tests that use proxy APIs.
>>
>> If there is some compelling reason to add a capability for which
>> the only tests use a proxy, that's important feedback for the
>> contributor community and tells us we need to improve our test
>> coverage. If the reason to use the proxy is that no one is deploying
>> the proxied API publicly, that is also useful feedback, but I suspect
>> we will, in most cases (glance is the exception), say "Yeah, that's
>> not how we mean for you to run the services long-term, so don't
>> include that capability."
>
> I think we might also just realize that some of the tests are using the
> proxy because... that's how they were originally written.

From my memory, thats how we got here.

The Nova tests needed to use an image API. (i.e. list images used to
check the snapshot Nova, or similar)

The Nova proxy was chosen over Glance v1 and Glance v2, mostly due to
it being the only widely deployed option.


Right, and I want to make sure it's clear that I am differentiating
between "these tests are bad" and "these tests are bad *for DefCore*".
We should definitely continue to test the proxy API, since it's a
feature we have and that our users rely on.


++





> And they could be rewritten to use native APIs.

+1
Once Glance v2 is available.

Adding Glance v2 as advisory seems a good step to help drive more adoption.


I think we probably don't want to rewrite the existing tests, since
that effectively changes the contract out from under existing folks
complying with DefCore.  If we need new, parallel, tests that do
not use the proxy to make more suitable tests for DefCore to use,
we should create those.


I believe this is the road we'll take. It'll not only be safer but
it'll also respect the current contract.



> I do agree that "testing proxies" should not be part of Defcore, and I
> like Doug's idea of making that a new heuristic in test selection.

+1
Thats a good thing to add.
But I don't think we had another option in this case.


We did have the option of leaving the feature out and highlighting the
discrepancy to the contributors so tests could be added. That
communication didn't really happen, as far as I can tell.


++




>> Sorry, I wasn't clear. The Nova team would, I expect, view the use of
>> those APIs in DefCore as a reason to avoid deprecating them in the code
>> even if they wanted to consider them as legacy features that should be
>> removed. Maybe that's not true, and the Nova team would be happy to
>> deprecate the APIs, but I did think that part of the feedback cycle we
>> were establishing here was to have an indication from the outside of the
>> contributor base about what APIs are considered important enough to keep
>> alive for a long period of time.
> I'd also agree with this. Defcore is a wider contract that we're trying
> to get even more people to write to because that cross section should be
> widely deployed. So deprecating something in Defcore is something I
> think most teams, Nova included, would be very reluctant to do. It's
> just asking for breaking your users.

I can't see us removing the proxy APIs in Nova any time soon,
regardless of DefCore, as it would break too many people.

But personally, I like dropping them from Defcore, to signal that the
best practice is to use the Glance v2 API directly, rather than the
Nova proxy.

Maybe the are just marked deprecated, but still required, although
that sounds a bit crazy.


Marking them as deprecated, then removing them from DefCore, would let
the Nova team make a technical decision about what to do with them
(maybe they get spun out into a separate service, maybe they're so
popular you just keep them, whatever).


++


Flavio

--
@flaper87
Flavio Percoco


pgpsQBrQ_xXDQ.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][nova] how to upgrade from v1 to v2?

[Flavio Percoco]

On 28/09/15 12:32 +0100, John Garbutt wrote:

On 28 September 2015 at 12:10, Sean Dague  wrote:

On 09/27/2015 08:43 AM, Doug Hellmann wrote:

Excerpts from Mark Voelker's message of 2015-09-25 20:43:23 +:

On Sep 25, 2015, at 1:56 PM, Doug Hellmann  wrote:


Excerpts from Mark Voelker's message of 2015-09-25 17:42:24 +:




Ah.  Thanks for bringing that up, because I think this may be an area where 
there’s some misconception about what DefCore is set up to do today.  In it’s 
present form, the Board of Directors has structured DefCore to look much more 
at trailing indicators of market acceptance rather than future technical 
direction.  More on that over here. [1]


And yet future technical direction does factor in, and I'm trying
to add a new heuristic to that aspect of consideration of tests:
Do not add tests that use proxy APIs.

If there is some compelling reason to add a capability for which
the only tests use a proxy, that's important feedback for the
contributor community and tells us we need to improve our test
coverage. If the reason to use the proxy is that no one is deploying
the proxied API publicly, that is also useful feedback, but I suspect
we will, in most cases (glance is the exception), say "Yeah, that's
not how we mean for you to run the services long-term, so don't
include that capability."


I think we might also just realize that some of the tests are using the
proxy because... that's how they were originally written.


From my memory, thats how we got here.

The Nova tests needed to use an image API. (i.e. list images used to
check the snapshot Nova, or similar)

The Nova proxy was chosen over Glance v1 and Glance v2, mostly due to
it being the only widely deployed option.


And they could be rewritten to use native APIs.


+1
Once Glance v2 is available.

Adding Glance v2 as advisory seems a good step to help drive more adoption.


What do you mean here? Glance v2 tests?

I just want to make sure you're talking about the tests and not the
API since the later is available and deployed in several clouds.[0]

[0] 
http://lists.openstack.org/pipermail/openstack-dev/2015-September/074500.html

Flavio




--
@flaper87
Flavio Percoco


pgprPQXkGJYuL.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][nova] how to upgrade from v1 to v2?

[Doug Hellmann]

Excerpts from Mark Voelker's message of 2015-09-28 19:55:18 +:
> On Sep 28, 2015, at 9:03 AM, Doug Hellmann  wrote:
> > 
> > Excerpts from John Garbutt's message of 2015-09-28 12:32:53 +0100:
> >> On 28 September 2015 at 12:10, Sean Dague  wrote:
> >>> On 09/27/2015 08:43 AM, Doug Hellmann wrote:
>  Excerpts from Mark Voelker's message of 2015-09-25 20:43:23 +:
> > On Sep 25, 2015, at 1:56 PM, Doug Hellmann  
> > wrote:
> >> 
> >> Excerpts from Mark Voelker's message of 2015-09-25 17:42:24 +:
> >>> 
> > 
> > Ah.  Thanks for bringing that up, because I think this may be an area 
> > where there’s some misconception about what DefCore is set up to do 
> > today.  In it’s present form, the Board of Directors has structured 
> > DefCore to look much more at trailing indicators of market acceptance 
> > rather than future technical direction.  More on that over here. [1]
>  
>  And yet future technical direction does factor in, and I'm trying
>  to add a new heuristic to that aspect of consideration of tests:
>  Do not add tests that use proxy APIs.
>  
>  If there is some compelling reason to add a capability for which
>  the only tests use a proxy, that's important feedback for the
>  contributor community and tells us we need to improve our test
>  coverage. If the reason to use the proxy is that no one is deploying
>  the proxied API publicly, that is also useful feedback, but I suspect
>  we will, in most cases (glance is the exception), say "Yeah, that's
>  not how we mean for you to run the services long-term, so don't
>  include that capability."
> >>> 
> >>> I think we might also just realize that some of the tests are using the
> >>> proxy because... that's how they were originally written.
> >> 
> >> From my memory, thats how we got here.
> >> 
> >> The Nova tests needed to use an image API. (i.e. list images used to
> >> check the snapshot Nova, or similar)
> >> 
> >> The Nova proxy was chosen over Glance v1 and Glance v2, mostly due to
> >> it being the only widely deployed option.
> > 
> > Right, and I want to make sure it's clear that I am differentiating
> > between "these tests are bad" and "these tests are bad *for DefCore*".
> > We should definitely continue to test the proxy API, since it's a
> > feature we have and that our users rely on.
> > 
> >> 
> >>> And they could be rewritten to use native APIs.
> >> 
> >> +1
> >> Once Glance v2 is available.
> >> 
> >> Adding Glance v2 as advisory seems a good step to help drive more adoption.
> > 
> > I think we probably don't want to rewrite the existing tests, since
> > that effectively changes the contract out from under existing folks
> > complying with DefCore.  If we need new, parallel, tests that do
> > not use the proxy to make more suitable tests for DefCore to use,
> > we should create those.
> > 
> >> 
> >>> I do agree that "testing proxies" should not be part of Defcore, and I
> >>> like Doug's idea of making that a new heuristic in test selection.
> >> 
> >> +1
> >> Thats a good thing to add.
> >> But I don't think we had another option in this case.
> > 
> > We did have the option of leaving the feature out and highlighting the
> > discrepancy to the contributors so tests could be added. That
> > communication didn't really happen, as far as I can tell.
> > 
>  Sorry, I wasn't clear. The Nova team would, I expect, view the use of
>  those APIs in DefCore as a reason to avoid deprecating them in the code
>  even if they wanted to consider them as legacy features that should be
>  removed. Maybe that's not true, and the Nova team would be happy to
>  deprecate the APIs, but I did think that part of the feedback cycle we
>  were establishing here was to have an indication from the outside of the
>  contributor base about what APIs are considered important enough to keep
>  alive for a long period of time.
> >>> I'd also agree with this. Defcore is a wider contract that we're trying
> >>> to get even more people to write to because that cross section should be
> >>> widely deployed. So deprecating something in Defcore is something I
> >>> think most teams, Nova included, would be very reluctant to do. It's
> >>> just asking for breaking your users.
> >> 
> >> I can't see us removing the proxy APIs in Nova any time soon,
> >> regardless of DefCore, as it would break too many people.
> >> 
> >> But personally, I like dropping them from Defcore, to signal that the
> >> best practice is to use the Glance v2 API directly, rather than the
> >> Nova proxy.
> >> 
> >> Maybe the are just marked deprecated, but still required, although
> >> that sounds a bit crazy.
> > 
> > Marking them as deprecated, then removing them from DefCore, would let
> > the Nova team make a technical decision about what to do with them
> > (maybe they get spun out into a separate service, maybe they're so
> > popular you just keep th

Re: [openstack-dev] [glance][nova] how to upgrade from v1 to v2?

[Mark Voelker]

On Sep 28, 2015, at 9:03 AM, Doug Hellmann  wrote:
> 
> Excerpts from John Garbutt's message of 2015-09-28 12:32:53 +0100:
>> On 28 September 2015 at 12:10, Sean Dague  wrote:
>>> On 09/27/2015 08:43 AM, Doug Hellmann wrote:
 Excerpts from Mark Voelker's message of 2015-09-25 20:43:23 +:
> On Sep 25, 2015, at 1:56 PM, Doug Hellmann  wrote:
>> 
>> Excerpts from Mark Voelker's message of 2015-09-25 17:42:24 +:
>>> 
> 
> Ah.  Thanks for bringing that up, because I think this may be an area 
> where there’s some misconception about what DefCore is set up to do 
> today.  In it’s present form, the Board of Directors has structured 
> DefCore to look much more at trailing indicators of market acceptance 
> rather than future technical direction.  More on that over here. [1]
 
 And yet future technical direction does factor in, and I'm trying
 to add a new heuristic to that aspect of consideration of tests:
 Do not add tests that use proxy APIs.
 
 If there is some compelling reason to add a capability for which
 the only tests use a proxy, that's important feedback for the
 contributor community and tells us we need to improve our test
 coverage. If the reason to use the proxy is that no one is deploying
 the proxied API publicly, that is also useful feedback, but I suspect
 we will, in most cases (glance is the exception), say "Yeah, that's
 not how we mean for you to run the services long-term, so don't
 include that capability."
>>> 
>>> I think we might also just realize that some of the tests are using the
>>> proxy because... that's how they were originally written.
>> 
>> From my memory, thats how we got here.
>> 
>> The Nova tests needed to use an image API. (i.e. list images used to
>> check the snapshot Nova, or similar)
>> 
>> The Nova proxy was chosen over Glance v1 and Glance v2, mostly due to
>> it being the only widely deployed option.
> 
> Right, and I want to make sure it's clear that I am differentiating
> between "these tests are bad" and "these tests are bad *for DefCore*".
> We should definitely continue to test the proxy API, since it's a
> feature we have and that our users rely on.
> 
>> 
>>> And they could be rewritten to use native APIs.
>> 
>> +1
>> Once Glance v2 is available.
>> 
>> Adding Glance v2 as advisory seems a good step to help drive more adoption.
> 
> I think we probably don't want to rewrite the existing tests, since
> that effectively changes the contract out from under existing folks
> complying with DefCore.  If we need new, parallel, tests that do
> not use the proxy to make more suitable tests for DefCore to use,
> we should create those.
> 
>> 
>>> I do agree that "testing proxies" should not be part of Defcore, and I
>>> like Doug's idea of making that a new heuristic in test selection.
>> 
>> +1
>> Thats a good thing to add.
>> But I don't think we had another option in this case.
> 
> We did have the option of leaving the feature out and highlighting the
> discrepancy to the contributors so tests could be added. That
> communication didn't really happen, as far as I can tell.
> 
 Sorry, I wasn't clear. The Nova team would, I expect, view the use of
 those APIs in DefCore as a reason to avoid deprecating them in the code
 even if they wanted to consider them as legacy features that should be
 removed. Maybe that's not true, and the Nova team would be happy to
 deprecate the APIs, but I did think that part of the feedback cycle we
 were establishing here was to have an indication from the outside of the
 contributor base about what APIs are considered important enough to keep
 alive for a long period of time.
>>> I'd also agree with this. Defcore is a wider contract that we're trying
>>> to get even more people to write to because that cross section should be
>>> widely deployed. So deprecating something in Defcore is something I
>>> think most teams, Nova included, would be very reluctant to do. It's
>>> just asking for breaking your users.
>> 
>> I can't see us removing the proxy APIs in Nova any time soon,
>> regardless of DefCore, as it would break too many people.
>> 
>> But personally, I like dropping them from Defcore, to signal that the
>> best practice is to use the Glance v2 API directly, rather than the
>> Nova proxy.
>> 
>> Maybe the are just marked deprecated, but still required, although
>> that sounds a bit crazy.
> 
> Marking them as deprecated, then removing them from DefCore, would let
> the Nova team make a technical decision about what to do with them
> (maybe they get spun out into a separate service, maybe they're so
> popular you just keep them, whatever).

So, here’s that Who’s On First thing again.  Just to clarify: Nova does not 
need Capabilities to be removed from Guidelines in order to make technical 
decisions about what to do with a feature (though removing a Capability from 
future Guidelines may make No

Re: [openstack-dev] [glance][nova] how to upgrade from v1 to v2?

[Doug Hellmann]

Excerpts from John Garbutt's message of 2015-09-28 12:32:53 +0100:
> On 28 September 2015 at 12:10, Sean Dague  wrote:
> > On 09/27/2015 08:43 AM, Doug Hellmann wrote:
> >> Excerpts from Mark Voelker's message of 2015-09-25 20:43:23 +:
> >>> On Sep 25, 2015, at 1:56 PM, Doug Hellmann  wrote:
> 
>  Excerpts from Mark Voelker's message of 2015-09-25 17:42:24 +:
> > 
> >>>
> >>> Ah.  Thanks for bringing that up, because I think this may be an area 
> >>> where there’s some misconception about what DefCore is set up to do 
> >>> today.  In it’s present form, the Board of Directors has structured 
> >>> DefCore to look much more at trailing indicators of market acceptance 
> >>> rather than future technical direction.  More on that over here. [1]
> >>
> >> And yet future technical direction does factor in, and I'm trying
> >> to add a new heuristic to that aspect of consideration of tests:
> >> Do not add tests that use proxy APIs.
> >>
> >> If there is some compelling reason to add a capability for which
> >> the only tests use a proxy, that's important feedback for the
> >> contributor community and tells us we need to improve our test
> >> coverage. If the reason to use the proxy is that no one is deploying
> >> the proxied API publicly, that is also useful feedback, but I suspect
> >> we will, in most cases (glance is the exception), say "Yeah, that's
> >> not how we mean for you to run the services long-term, so don't
> >> include that capability."
> >
> > I think we might also just realize that some of the tests are using the
> > proxy because... that's how they were originally written.
> 
> From my memory, thats how we got here.
> 
> The Nova tests needed to use an image API. (i.e. list images used to
> check the snapshot Nova, or similar)
> 
> The Nova proxy was chosen over Glance v1 and Glance v2, mostly due to
> it being the only widely deployed option.

Right, and I want to make sure it's clear that I am differentiating
between "these tests are bad" and "these tests are bad *for DefCore*".
We should definitely continue to test the proxy API, since it's a
feature we have and that our users rely on.

> 
> > And they could be rewritten to use native APIs.
> 
> +1
> Once Glance v2 is available.
> 
> Adding Glance v2 as advisory seems a good step to help drive more adoption.

I think we probably don't want to rewrite the existing tests, since
that effectively changes the contract out from under existing folks
complying with DefCore.  If we need new, parallel, tests that do
not use the proxy to make more suitable tests for DefCore to use,
we should create those.

> 
> > I do agree that "testing proxies" should not be part of Defcore, and I
> > like Doug's idea of making that a new heuristic in test selection.
> 
> +1
> Thats a good thing to add.
> But I don't think we had another option in this case.

We did have the option of leaving the feature out and highlighting the
discrepancy to the contributors so tests could be added. That
communication didn't really happen, as far as I can tell.

> >> Sorry, I wasn't clear. The Nova team would, I expect, view the use of
> >> those APIs in DefCore as a reason to avoid deprecating them in the code
> >> even if they wanted to consider them as legacy features that should be
> >> removed. Maybe that's not true, and the Nova team would be happy to
> >> deprecate the APIs, but I did think that part of the feedback cycle we
> >> were establishing here was to have an indication from the outside of the
> >> contributor base about what APIs are considered important enough to keep
> >> alive for a long period of time.
> > I'd also agree with this. Defcore is a wider contract that we're trying
> > to get even more people to write to because that cross section should be
> > widely deployed. So deprecating something in Defcore is something I
> > think most teams, Nova included, would be very reluctant to do. It's
> > just asking for breaking your users.
> 
> I can't see us removing the proxy APIs in Nova any time soon,
> regardless of DefCore, as it would break too many people.
> 
> But personally, I like dropping them from Defcore, to signal that the
> best practice is to use the Glance v2 API directly, rather than the
> Nova proxy.
> 
> Maybe the are just marked deprecated, but still required, although
> that sounds a bit crazy.

Marking them as deprecated, then removing them from DefCore, would let
the Nova team make a technical decision about what to do with them
(maybe they get spun out into a separate service, maybe they're so
popular you just keep them, whatever).

Doug

__
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][nova] how to upgrade from v1 to v2?

[John Garbutt]

On 28 September 2015 at 12:10, Sean Dague  wrote:
> On 09/27/2015 08:43 AM, Doug Hellmann wrote:
>> Excerpts from Mark Voelker's message of 2015-09-25 20:43:23 +:
>>> On Sep 25, 2015, at 1:56 PM, Doug Hellmann  wrote:

 Excerpts from Mark Voelker's message of 2015-09-25 17:42:24 +:
> 
>>>
>>> Ah.  Thanks for bringing that up, because I think this may be an area where 
>>> there’s some misconception about what DefCore is set up to do today.  In 
>>> it’s present form, the Board of Directors has structured DefCore to look 
>>> much more at trailing indicators of market acceptance rather than future 
>>> technical direction.  More on that over here. [1]
>>
>> And yet future technical direction does factor in, and I'm trying
>> to add a new heuristic to that aspect of consideration of tests:
>> Do not add tests that use proxy APIs.
>>
>> If there is some compelling reason to add a capability for which
>> the only tests use a proxy, that's important feedback for the
>> contributor community and tells us we need to improve our test
>> coverage. If the reason to use the proxy is that no one is deploying
>> the proxied API publicly, that is also useful feedback, but I suspect
>> we will, in most cases (glance is the exception), say "Yeah, that's
>> not how we mean for you to run the services long-term, so don't
>> include that capability."
>
> I think we might also just realize that some of the tests are using the
> proxy because... that's how they were originally written.

From my memory, thats how we got here.

The Nova tests needed to use an image API. (i.e. list images used to
check the snapshot Nova, or similar)

The Nova proxy was chosen over Glance v1 and Glance v2, mostly due to
it being the only widely deployed option.

> And they could be rewritten to use native APIs.

+1
Once Glance v2 is available.

Adding Glance v2 as advisory seems a good step to help drive more adoption.

> I do agree that "testing proxies" should not be part of Defcore, and I
> like Doug's idea of making that a new heuristic in test selection.

+1
Thats a good thing to add.
But I don't think we had another option in this case.

>> Sorry, I wasn't clear. The Nova team would, I expect, view the use of
>> those APIs in DefCore as a reason to avoid deprecating them in the code
>> even if they wanted to consider them as legacy features that should be
>> removed. Maybe that's not true, and the Nova team would be happy to
>> deprecate the APIs, but I did think that part of the feedback cycle we
>> were establishing here was to have an indication from the outside of the
>> contributor base about what APIs are considered important enough to keep
>> alive for a long period of time.
> I'd also agree with this. Defcore is a wider contract that we're trying
> to get even more people to write to because that cross section should be
> widely deployed. So deprecating something in Defcore is something I
> think most teams, Nova included, would be very reluctant to do. It's
> just asking for breaking your users.

I can't see us removing the proxy APIs in Nova any time soon,
regardless of DefCore, as it would break too many people.

But personally, I like dropping them from Defcore, to signal that the
best practice is to use the Glance v2 API directly, rather than the
Nova proxy.

Maybe the are just marked deprecated, but still required, although
that sounds a bit crazy.

Thanks,
johnthetubaguy

 situation for us to be relying on any proxy APIs like this. Yes,
 they are widely deployed, but we want to be using glance for image
 features, neutron for networking, etc. Having the nova proxy is
 fine, but while we have DefCore using tests to enforce the presence
 of the proxy we can't deprecate those APIs.
>>>
>>>
>>> Actually that’s not true: DefCore can totally deprecate things too, and can 
>>> do so in response to the technical community deprecating things.  See my 
>>> comments in this review [2].  Maybe I need to write another post about 
>>> that...
>>
>
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> 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

Re: [openstack-dev] [glance][nova] how to upgrade from v1 to v2?

[Sean Dague]

On 09/27/2015 08:43 AM, Doug Hellmann wrote:
> Excerpts from Mark Voelker's message of 2015-09-25 20:43:23 +:
>> On Sep 25, 2015, at 1:56 PM, Doug Hellmann  wrote:
>>>
>>> Excerpts from Mark Voelker's message of 2015-09-25 17:42:24 +:

>>
>> Ah.  Thanks for bringing that up, because I think this may be an area where 
>> there’s some misconception about what DefCore is set up to do today.  In 
>> it’s present form, the Board of Directors has structured DefCore to look 
>> much more at trailing indicators of market acceptance rather than future 
>> technical direction.  More on that over here. [1] 
> 
> And yet future technical direction does factor in, and I'm trying
> to add a new heuristic to that aspect of consideration of tests:
> Do not add tests that use proxy APIs.
> 
> If there is some compelling reason to add a capability for which
> the only tests use a proxy, that's important feedback for the
> contributor community and tells us we need to improve our test
> coverage. If the reason to use the proxy is that no one is deploying
> the proxied API publicly, that is also useful feedback, but I suspect
> we will, in most cases (glance is the exception), say "Yeah, that's
> not how we mean for you to run the services long-term, so don't
> include that capability."

I think we might also just realize that some of the tests are using the
proxy because... that's how they were originally written. And they could
be rewritten to use native APIs. Realistically I think use of the image
proxy in Tempest is mostly because the nova API (with proxy) was easier
to write to... 3 years ago.

Changing these tests is definitely a thing that's on the table when they
do a funny thing.

I do agree that "testing proxies" should not be part of Defcore, and I
like Doug's idea of making that a new heuristic in test selection.

>>> situation for us to be relying on any proxy APIs like this. Yes,
>>> they are widely deployed, but we want to be using glance for image
>>> features, neutron for networking, etc. Having the nova proxy is
>>> fine, but while we have DefCore using tests to enforce the presence
>>> of the proxy we can't deprecate those APIs.
>>
>>
>> Actually that’s not true: DefCore can totally deprecate things too, and can 
>> do so in response to the technical community deprecating things.  See my 
>> comments in this review [2].  Maybe I need to write another post about 
>> that...
> 
> Sorry, I wasn't clear. The Nova team would, I expect, view the use of
> those APIs in DefCore as a reason to avoid deprecating them in the code
> even if they wanted to consider them as legacy features that should be
> removed. Maybe that's not true, and the Nova team would be happy to
> deprecate the APIs, but I did think that part of the feedback cycle we
> were establishing here was to have an indication from the outside of the
> contributor base about what APIs are considered important enough to keep
> alive for a long period of time.

I'd also agree with this. Defcore is a wider contract that we're trying
to get even more people to write to because that cross section should be
widely deployed. So deprecating something in Defcore is something I
think most teams, Nova included, would be very reluctant to do. It's
just asking for breaking your users.

-Sean

-- 
Sean Dague
http://dague.net

__
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][nova] how to upgrade from v1 to v2?

[Sean Dague]

On 09/25/2015 08:16 PM, Monty Taylor wrote:
> On 09/25/2015 06:37 PM, Chris Hoge wrote:
>>
>>> On Sep 25, 2015, at 10:12 AM, Andrew Laski >> > wrote:
>>>
>>> I understand that reasoning, but still am unsure on a few things.
>>>
>>> The direction seems to be moving towards having a requirement that the
>>> same functionality is offered in two places, Nova API and Glance V2
>>> API. That seems like it would fragment adoption rather than unify it.
>>
>> My hope would be that proxies would be deprecated as new capabilities
>> moved in. Some of this will be driven by application developers too,
>> though. We’re looking at an interoperability standard, which has a
>> natural tension between backwards compatibility and new features.
> 
> Yeah. The proxies are also less efficient, because they have to bounce
> through two places.

The social theory on the proxies is also that they are fully frozen. So
assuming there would be new good features that people want / need from
projects, they'll naturally migrate to newer direct APIs. More carrot
than stick.

Just pulling APIs that work for people is a good way to make people mad
at you. But giving a gentle nudge because we're never adding new
goodness here is fine.

-Sean

-- 
Sean Dague
http://dague.net

__
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][nova] how to upgrade from v1 to v2?

[Doug Hellmann]

Excerpts from Mark Voelker's message of 2015-09-25 20:43:23 +:
> On Sep 25, 2015, at 1:56 PM, Doug Hellmann  wrote:
> > 
> > Excerpts from Mark Voelker's message of 2015-09-25 17:42:24 +:
> >> On Sep 25, 2015, at 1:24 PM, Brian Rosmaita  
> >> wrote:
> >>> 
> >>> I'd like to clarify something.
> >>> 
> >>> On 9/25/15, 12:16 PM, "Mark Voelker"  wrote:
> >>> [big snip]
>  Also worth pointing out here: when we talk about ³doing the same thing²
>  from a DefCore perspective, we¹re essentially talking about what¹s
>  exposed to the end user, not how that¹s implemented in OpenStack¹s source
>  code.  So from an end user¹s perspective:
>  
>  If I call nova image-create, I get an image in my cloud.  If I call the
>  Glance v2 API to create an image, I also get an image in my cloud.  I
>  neither see nor care that Nova is actually talking to Glance in the
>  background, because if I¹m writing code that uses the OpenStack API¹s, I
>  need to pick which one of those two API¹s to make my code call upon to
>  put an image in my cloud.  Or, in the worst case, I have to write a bunch
>  of if/else loops into my code because some clouds I want to use only
>  allow one way and some allow only the other.
> >>> 
> >>> The above is a bit inaccurate.
> >>> 
> >>> The nova image-create command does give you an image in your cloud.  The
> >>> image you get, however, is a snapshot of an instance that has been
> >>> previously created in Nova.  If you don't have an instance, you cannot
> >>> create an image via that command.  There is no provision in the Compute
> >>> (Nova) API to allow you to create an image out of bits that you supply.
> >>> 
> >>> The Image (Glance) APIs (both v1 and v2) allow you to supply the bits and
> >>> register them as an image which you can then use to boot instances from by
> >>> using the Compute API.  But note that if all you have available is the
> >>> Images API, you cannot create an image of one of your instances.
> >>> 
>  So from that end-user perspective, the Nova image-create API indeed does
>  ³do the same thing" as the Glance API.
> >>> 
> >>> They don't "do the same thing".  Even if you have full access to the
> >>> Images v1 or v2 API, you will still have to use the Compute (Nova) API to
> >>> create an image of an instance, which is by far the largest use-case for
> >>> image creation.  You can't do it through Glance, because Glance doesn't
> >>> know anything about instances.  Nova has to know about Glance, because it
> >>> needs to fetch images for instance creation, and store images for
> >>> on-demand images of instances.
> >> 
> >> Yup, that’s fair: this was a bad example to pick (need moar coffee I 
> >> guess).  Let’s use image-list instead. =)
> > 
> > From a "technical direction" perspective, I still think it's a bad
> 
> Ah.  Thanks for bringing that up, because I think this may be an area where 
> there’s some misconception about what DefCore is set up to do today.  In it’s 
> present form, the Board of Directors has structured DefCore to look much more 
> at trailing indicators of market acceptance rather than future technical 
> direction.  More on that over here. [1] 

And yet future technical direction does factor in, and I'm trying
to add a new heuristic to that aspect of consideration of tests:
Do not add tests that use proxy APIs.

If there is some compelling reason to add a capability for which
the only tests use a proxy, that's important feedback for the
contributor community and tells us we need to improve our test
coverage. If the reason to use the proxy is that no one is deploying
the proxied API publicly, that is also useful feedback, but I suspect
we will, in most cases (glance is the exception), say "Yeah, that's
not how we mean for you to run the services long-term, so don't
include that capability."

> 
> > situation for us to be relying on any proxy APIs like this. Yes,
> > they are widely deployed, but we want to be using glance for image
> > features, neutron for networking, etc. Having the nova proxy is
> > fine, but while we have DefCore using tests to enforce the presence
> > of the proxy we can't deprecate those APIs.
> 
> 
> Actually that’s not true: DefCore can totally deprecate things too, and can 
> do so in response to the technical community deprecating things.  See my 
> comments in this review [2].  Maybe I need to write another post about that...

Sorry, I wasn't clear. The Nova team would, I expect, view the use of
those APIs in DefCore as a reason to avoid deprecating them in the code
even if they wanted to consider them as legacy features that should be
removed. Maybe that's not true, and the Nova team would be happy to
deprecate the APIs, but I did think that part of the feedback cycle we
were establishing here was to have an indication from the outside of the
contributor base about what APIs are considered important enough to keep
alive for a long period of time.

> 
> /m

Re: [openstack-dev] [glance][nova] how to upgrade from v1 to v2?

[Monty Taylor]

On 09/25/2015 06:37 PM, Chris Hoge wrote:



On Sep 25, 2015, at 10:12 AM, Andrew Laski mailto:and...@lascii.com>> wrote:

I understand that reasoning, but still am unsure on a few things.

The direction seems to be moving towards having a requirement that the
same functionality is offered in two places, Nova API and Glance V2
API. That seems like it would fragment adoption rather than unify it.


My hope would be that proxies would be deprecated as new capabilities
moved in. Some of this will be driven by application developers too,
though. We’re looking at an interoperability standard, which has a
natural tension between backwards compatibility and new features.


Yeah. The proxies are also less efficient, because they have to bounce 
through two places.




Also after digging in on image-create I feel that there may be a
mixup.  The image-create in Glance and image-create in Nova are two
different things. In Glance you create an image and send the disk
image data in the request, in Nova an image-create takes a snapshot of
the instance provided in the request.  But it seems like DefCore is
treating them as equivalent unless I'm misunderstanding.




__
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

Re: [openstack-dev] [glance][nova] how to upgrade from v1 to v2?

[Chris Hoge]

> On Sep 25, 2015, at 10:12 AM, Andrew Laski  wrote:
> 
> I understand that reasoning, but still am unsure on a few things.
> 
> The direction seems to be moving towards having a requirement that the same 
> functionality is offered in two places, Nova API and Glance V2 API. That 
> seems like it would fragment adoption rather than unify it.

My hope would be that proxies would be deprecated as new capabilities
moved in. Some of this will be driven by application developers too,
though. We’re looking at an interoperability standard, which has a
natural tension between backwards compatibility and new features.

> 
> Also after digging in on image-create I feel that there may be a mixup.  The 
> image-create in Glance and image-create in Nova are two different things. In 
> Glance you create an image and send the disk image data in the request, in 
> Nova an image-create takes a snapshot of the instance provided in the 
> request.  But it seems like DefCore is treating them as equivalent unless I'm 
> misunderstanding.
> 
__
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][nova] how to upgrade from v1 to v2?

[Andrew Laski]

On 09/25/15 at 07:44pm, Rochelle Grober wrote:



Doug Hellmann wrote:
Excerpts from Mark Voelker's message of 2015-09-25 17:42:24 +:

On Sep 25, 2015, at 1:24 PM, Brian Rosmaita  
wrote:
>
> I'd like to clarify something.
>
> On 9/25/15, 12:16 PM, "Mark Voelker"  wrote:
> [big snip]
>> Also worth pointing out here: when we talk about ³doing the same thing²
>> from a DefCore perspective, we¹re essentially talking about what¹s
>> exposed to the end user, not how that¹s implemented in OpenStack¹s source
>> code.  So from an end user¹s perspective:
>>
>> If I call nova image-create, I get an image in my cloud.  If I call the
>> Glance v2 API to create an image, I also get an image in my cloud.  I
>> neither see nor care that Nova is actually talking to Glance in the
>> background, because if I¹m writing code that uses the OpenStack API¹s, I
>> need to pick which one of those two API¹s to make my code call upon to
>> put an image in my cloud.  Or, in the worst case, I have to write a bunch
>> of if/else loops into my code because some clouds I want to use only
>> allow one way and some allow only the other.
>
> The above is a bit inaccurate.
>
> The nova image-create command does give you an image in your cloud.  The
> image you get, however, is a snapshot of an instance that has been
> previously created in Nova.  If you don't have an instance, you cannot
> create an image via that command.  There is no provision in the Compute
> (Nova) API to allow you to create an image out of bits that you supply.
>
> The Image (Glance) APIs (both v1 and v2) allow you to supply the bits and
> register them as an image which you can then use to boot instances from by
> using the Compute API.  But note that if all you have available is the
> Images API, you cannot create an image of one of your instances.
>
>> So from that end-user perspective, the Nova image-create API indeed does
>> ³do the same thing" as the Glance API.
>
> They don't "do the same thing".  Even if you have full access to the
> Images v1 or v2 API, you will still have to use the Compute (Nova) API to
> create an image of an instance, which is by far the largest use-case for
> image creation.  You can't do it through Glance, because Glance doesn't
> know anything about instances.  Nova has to know about Glance, because it
> needs to fetch images for instance creation, and store images for
> on-demand images of instances.

Yup, that’s fair: this was a bad example to pick (need moar coffee I guess).  
Let’s use image-list instead. =)


From a "technical direction" perspective, I still think it's a bad
situation for us to be relying on any proxy APIs like this. Yes,
they are widely deployed, but we want to be using glance for image
features, neutron for networking, etc. Having the nova proxy is
fine, but while we have DefCore using tests to enforce the presence
of the proxy we can't deprecate those APIs.

What do we need to do to make that change happen over the next cycle
or so?

[Rocky]
This is likely the first case DefCore will have pf deprecating a requirement 
;-)  The committee wasn't thrilled with the original requirement, but really, 
can you have OpenStack without some way of creating an instance?  And Glance V1 
had no user facing APIs, so the committee was kind of stuck.

But, going forward, what needs to happen in Dev is for Glance V2 to become *the way* to 
create images, and for Glance V1 to be deprecated *and removed*.  Then we've got two more 
cycles before we can require V2 only.  Yes, DefCore is a trailing requirement.  We have 
to give our user community time to migrate to versions of OpenStack that don't have the 
"old" capability.


I still feel that there's a misunderstanding here.  The Nova API is a 
proxy for listing images and getting details on a particular image but 
otherwise does not expose the capabilities of Glance that the Glance API 
does.  Nova does not allow users to create images in Glance in the 
manner that seems to be under discussion here.  You can boot an instance 
from a preexisting image, modify it, and then have Nova upload a 
snapshot of that image to Glance.  You can not take a user provided 
image and get it into Glance via Nova.  And if there are no images in 
Glance you can not bootstrap one in via Nova.





But now comes the tricky partHow do you allow both V1 and V2 capabilities 
and still be interoperable?  This will definitely be the first test for DefCore 
on migration from obsolete capabilities to current capabilities.  We could use 
some help figuring out how to make that work.

--Rocky

Doug



At Your Service,

Mark T. Voelker

>
>
>> At Your Service,
>>
>> Mark T. Voelker
>
> Glad to be of service, too,
> brian
>
>
> __
> 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-d

Re: [openstack-dev] [glance][nova] how to upgrade from v1 to v2?

[Mark Voelker]

On Sep 25, 2015, at 1:56 PM, Doug Hellmann  wrote:
> 
> Excerpts from Mark Voelker's message of 2015-09-25 17:42:24 +:
>> On Sep 25, 2015, at 1:24 PM, Brian Rosmaita  
>> wrote:
>>> 
>>> I'd like to clarify something.
>>> 
>>> On 9/25/15, 12:16 PM, "Mark Voelker"  wrote:
>>> [big snip]
 Also worth pointing out here: when we talk about ³doing the same thing²
 from a DefCore perspective, we¹re essentially talking about what¹s
 exposed to the end user, not how that¹s implemented in OpenStack¹s source
 code.  So from an end user¹s perspective:
 
 If I call nova image-create, I get an image in my cloud.  If I call the
 Glance v2 API to create an image, I also get an image in my cloud.  I
 neither see nor care that Nova is actually talking to Glance in the
 background, because if I¹m writing code that uses the OpenStack API¹s, I
 need to pick which one of those two API¹s to make my code call upon to
 put an image in my cloud.  Or, in the worst case, I have to write a bunch
 of if/else loops into my code because some clouds I want to use only
 allow one way and some allow only the other.
>>> 
>>> The above is a bit inaccurate.
>>> 
>>> The nova image-create command does give you an image in your cloud.  The
>>> image you get, however, is a snapshot of an instance that has been
>>> previously created in Nova.  If you don't have an instance, you cannot
>>> create an image via that command.  There is no provision in the Compute
>>> (Nova) API to allow you to create an image out of bits that you supply.
>>> 
>>> The Image (Glance) APIs (both v1 and v2) allow you to supply the bits and
>>> register them as an image which you can then use to boot instances from by
>>> using the Compute API.  But note that if all you have available is the
>>> Images API, you cannot create an image of one of your instances.
>>> 
 So from that end-user perspective, the Nova image-create API indeed does
 ³do the same thing" as the Glance API.
>>> 
>>> They don't "do the same thing".  Even if you have full access to the
>>> Images v1 or v2 API, you will still have to use the Compute (Nova) API to
>>> create an image of an instance, which is by far the largest use-case for
>>> image creation.  You can't do it through Glance, because Glance doesn't
>>> know anything about instances.  Nova has to know about Glance, because it
>>> needs to fetch images for instance creation, and store images for
>>> on-demand images of instances.
>> 
>> Yup, that’s fair: this was a bad example to pick (need moar coffee I guess). 
>>  Let’s use image-list instead. =)
> 
> From a "technical direction" perspective, I still think it's a bad

Ah.  Thanks for bringing that up, because I think this may be an area where 
there’s some misconception about what DefCore is set up to do today.  In it’s 
present form, the Board of Directors has structured DefCore to look much more 
at trailing indicators of market acceptance rather than future technical 
direction.  More on that over here. [1] 



> situation for us to be relying on any proxy APIs like this. Yes,
> they are widely deployed, but we want to be using glance for image
> features, neutron for networking, etc. Having the nova proxy is
> fine, but while we have DefCore using tests to enforce the presence
> of the proxy we can't deprecate those APIs.


Actually that’s not true: DefCore can totally deprecate things too, and can do 
so in response to the technical community deprecating things.  See my comments 
in this review [2].  Maybe I need to write another post about that...

/me envisions the title being “Who’s on First?”


> 
> What do we need to do to make that change happen over the next cycle
> or so?

There are several things that can be done:

First, if you don’t like the Criteria or the weights that the various Criteria 
today have, we can suggest changes to them.  The Board of Directors will 
ultimately have to approve that change, but we can certainly ask (I think 
there’s plenty of evidence that our Directors listen to the community’s 
concerns).  There’s actually already some early discussion about that now, 
though most of the energy is going into other things at the moment (because 
deadlines).  See post above for links.

Second, we certainly could consider changes to the Capabilities that are 
currently required.  That happens every six months according to a 
Board-approved schedule. [3]  The window is just about to close for the next 
Guideline, but that might be ok from the perspective of a lot of stuff is 
likely be advisory in the next Guideline anyway, and advisory cycles are 
explicitly meant to generate feedback like this.  Making changes to Guidelines 
is basically submitting a patch. [4]

Third, as a technical community we can make the capabilities we want score 
better.  So for example: we could make nova image use glance v2, or we could 
deprecate those API’s (per above, you do not have to wait on DefCore for that 
to happen

Re: [openstack-dev] [glance][nova] how to upgrade from v1 to v2?

[Rochelle Grober]

Doug Hellmann wrote:
Excerpts from Mark Voelker's message of 2015-09-25 17:42:24 +:
> On Sep 25, 2015, at 1:24 PM, Brian Rosmaita  
> wrote:
> > 
> > I'd like to clarify something.
> > 
> > On 9/25/15, 12:16 PM, "Mark Voelker"  wrote:
> > [big snip]
> >> Also worth pointing out here: when we talk about ³doing the same thing²
> >> from a DefCore perspective, we¹re essentially talking about what¹s
> >> exposed to the end user, not how that¹s implemented in OpenStack¹s source
> >> code.  So from an end user¹s perspective:
> >> 
> >> If I call nova image-create, I get an image in my cloud.  If I call the
> >> Glance v2 API to create an image, I also get an image in my cloud.  I
> >> neither see nor care that Nova is actually talking to Glance in the
> >> background, because if I¹m writing code that uses the OpenStack API¹s, I
> >> need to pick which one of those two API¹s to make my code call upon to
> >> put an image in my cloud.  Or, in the worst case, I have to write a bunch
> >> of if/else loops into my code because some clouds I want to use only
> >> allow one way and some allow only the other.
> > 
> > The above is a bit inaccurate.
> > 
> > The nova image-create command does give you an image in your cloud.  The
> > image you get, however, is a snapshot of an instance that has been
> > previously created in Nova.  If you don't have an instance, you cannot
> > create an image via that command.  There is no provision in the Compute
> > (Nova) API to allow you to create an image out of bits that you supply.
> > 
> > The Image (Glance) APIs (both v1 and v2) allow you to supply the bits and
> > register them as an image which you can then use to boot instances from by
> > using the Compute API.  But note that if all you have available is the
> > Images API, you cannot create an image of one of your instances.
> > 
> >> So from that end-user perspective, the Nova image-create API indeed does
> >> ³do the same thing" as the Glance API.
> > 
> > They don't "do the same thing".  Even if you have full access to the
> > Images v1 or v2 API, you will still have to use the Compute (Nova) API to
> > create an image of an instance, which is by far the largest use-case for
> > image creation.  You can't do it through Glance, because Glance doesn't
> > know anything about instances.  Nova has to know about Glance, because it
> > needs to fetch images for instance creation, and store images for
> > on-demand images of instances.
> 
> Yup, that’s fair: this was a bad example to pick (need moar coffee I guess).  
> Let’s use image-list instead. =)

From a "technical direction" perspective, I still think it's a bad
situation for us to be relying on any proxy APIs like this. Yes,
they are widely deployed, but we want to be using glance for image
features, neutron for networking, etc. Having the nova proxy is
fine, but while we have DefCore using tests to enforce the presence
of the proxy we can't deprecate those APIs.

What do we need to do to make that change happen over the next cycle
or so?

[Rocky]
This is likely the first case DefCore will have pf deprecating a requirement 
;-)  The committee wasn't thrilled with the original requirement, but really, 
can you have OpenStack without some way of creating an instance?  And Glance V1 
had no user facing APIs, so the committee was kind of stuck.

But, going forward, what needs to happen in Dev is for Glance V2 to become *the 
way* to create images, and for Glance V1 to be deprecated *and removed*.  Then 
we've got two more cycles before we can require V2 only.  Yes, DefCore is a 
trailing requirement.  We have to give our user community time to migrate to 
versions of OpenStack that don't have the "old" capability.

But now comes the tricky partHow do you allow both V1 and V2 capabilities 
and still be interoperable?  This will definitely be the first test for DefCore 
on migration from obsolete capabilities to current capabilities.  We could use 
some help figuring out how to make that work.

--Rocky

Doug

> 
> At Your Service,
> 
> Mark T. Voelker
> 
> > 
> > 
> >> At Your Service,
> >> 
> >> Mark T. Voelker
> > 
> > Glad to be of service, too,
> > brian
> > 
> > 
> > __
> > 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
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/c

Re: [openstack-dev] [glance][nova] how to upgrade from v1 to v2?

[Doug Hellmann]

Excerpts from Mark Voelker's message of 2015-09-25 17:42:24 +:
> On Sep 25, 2015, at 1:24 PM, Brian Rosmaita  
> wrote:
> > 
> > I'd like to clarify something.
> > 
> > On 9/25/15, 12:16 PM, "Mark Voelker"  wrote:
> > [big snip]
> >> Also worth pointing out here: when we talk about ³doing the same thing²
> >> from a DefCore perspective, we¹re essentially talking about what¹s
> >> exposed to the end user, not how that¹s implemented in OpenStack¹s source
> >> code.  So from an end user¹s perspective:
> >> 
> >> If I call nova image-create, I get an image in my cloud.  If I call the
> >> Glance v2 API to create an image, I also get an image in my cloud.  I
> >> neither see nor care that Nova is actually talking to Glance in the
> >> background, because if I¹m writing code that uses the OpenStack API¹s, I
> >> need to pick which one of those two API¹s to make my code call upon to
> >> put an image in my cloud.  Or, in the worst case, I have to write a bunch
> >> of if/else loops into my code because some clouds I want to use only
> >> allow one way and some allow only the other.
> > 
> > The above is a bit inaccurate.
> > 
> > The nova image-create command does give you an image in your cloud.  The
> > image you get, however, is a snapshot of an instance that has been
> > previously created in Nova.  If you don't have an instance, you cannot
> > create an image via that command.  There is no provision in the Compute
> > (Nova) API to allow you to create an image out of bits that you supply.
> > 
> > The Image (Glance) APIs (both v1 and v2) allow you to supply the bits and
> > register them as an image which you can then use to boot instances from by
> > using the Compute API.  But note that if all you have available is the
> > Images API, you cannot create an image of one of your instances.
> > 
> >> So from that end-user perspective, the Nova image-create API indeed does
> >> ³do the same thing" as the Glance API.
> > 
> > They don't "do the same thing".  Even if you have full access to the
> > Images v1 or v2 API, you will still have to use the Compute (Nova) API to
> > create an image of an instance, which is by far the largest use-case for
> > image creation.  You can't do it through Glance, because Glance doesn't
> > know anything about instances.  Nova has to know about Glance, because it
> > needs to fetch images for instance creation, and store images for
> > on-demand images of instances.
> 
> Yup, that’s fair: this was a bad example to pick (need moar coffee I guess).  
> Let’s use image-list instead. =)

From a "technical direction" perspective, I still think it's a bad
situation for us to be relying on any proxy APIs like this. Yes,
they are widely deployed, but we want to be using glance for image
features, neutron for networking, etc. Having the nova proxy is
fine, but while we have DefCore using tests to enforce the presence
of the proxy we can't deprecate those APIs.

What do we need to do to make that change happen over the next cycle
or so?

Doug

> 
> At Your Service,
> 
> Mark T. Voelker
> 
> > 
> > 
> >> At Your Service,
> >> 
> >> Mark T. Voelker
> > 
> > Glad to be of service, too,
> > brian
> > 
> > 
> > __
> > 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

Re: [openstack-dev] [glance][nova] how to upgrade from v1 to v2?

[Mark Voelker]

On Sep 25, 2015, at 1:24 PM, Brian Rosmaita  
wrote:
> 
> I'd like to clarify something.
> 
> On 9/25/15, 12:16 PM, "Mark Voelker"  wrote:
> [big snip]
>> Also worth pointing out here: when we talk about ³doing the same thing²
>> from a DefCore perspective, we¹re essentially talking about what¹s
>> exposed to the end user, not how that¹s implemented in OpenStack¹s source
>> code.  So from an end user¹s perspective:
>> 
>> If I call nova image-create, I get an image in my cloud.  If I call the
>> Glance v2 API to create an image, I also get an image in my cloud.  I
>> neither see nor care that Nova is actually talking to Glance in the
>> background, because if I¹m writing code that uses the OpenStack API¹s, I
>> need to pick which one of those two API¹s to make my code call upon to
>> put an image in my cloud.  Or, in the worst case, I have to write a bunch
>> of if/else loops into my code because some clouds I want to use only
>> allow one way and some allow only the other.
> 
> The above is a bit inaccurate.
> 
> The nova image-create command does give you an image in your cloud.  The
> image you get, however, is a snapshot of an instance that has been
> previously created in Nova.  If you don't have an instance, you cannot
> create an image via that command.  There is no provision in the Compute
> (Nova) API to allow you to create an image out of bits that you supply.
> 
> The Image (Glance) APIs (both v1 and v2) allow you to supply the bits and
> register them as an image which you can then use to boot instances from by
> using the Compute API.  But note that if all you have available is the
> Images API, you cannot create an image of one of your instances.
> 
>> So from that end-user perspective, the Nova image-create API indeed does
>> ³do the same thing" as the Glance API.
> 
> They don't "do the same thing".  Even if you have full access to the
> Images v1 or v2 API, you will still have to use the Compute (Nova) API to
> create an image of an instance, which is by far the largest use-case for
> image creation.  You can't do it through Glance, because Glance doesn't
> know anything about instances.  Nova has to know about Glance, because it
> needs to fetch images for instance creation, and store images for
> on-demand images of instances.

Yup, that’s fair: this was a bad example to pick (need moar coffee I guess).  
Let’s use image-list instead. =)

At Your Service,

Mark T. Voelker


> 
> 
>> At Your Service,
>> 
>> Mark T. Voelker
> 
> Glad to be of service, too,
> brian
> 
> 
> __
> 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

Re: [openstack-dev] [glance][nova] how to upgrade from v1 to v2?

[Brian Rosmaita]

I'd like to clarify something.

On 9/25/15, 12:16 PM, "Mark Voelker"  wrote:
[big snip]
>Also worth pointing out here: when we talk about ³doing the same thing²
>from a DefCore perspective, we¹re essentially talking about what¹s
>exposed to the end user, not how that¹s implemented in OpenStack¹s source
>code.  So from an end user¹s perspective:
>
>If I call nova image-create, I get an image in my cloud.  If I call the
>Glance v2 API to create an image, I also get an image in my cloud.  I
>neither see nor care that Nova is actually talking to Glance in the
>background, because if I¹m writing code that uses the OpenStack API¹s, I
>need to pick which one of those two API¹s to make my code call upon to
>put an image in my cloud.  Or, in the worst case, I have to write a bunch
>of if/else loops into my code because some clouds I want to use only
>allow one way and some allow only the other.

The above is a bit inaccurate.

The nova image-create command does give you an image in your cloud.  The
image you get, however, is a snapshot of an instance that has been
previously created in Nova.  If you don't have an instance, you cannot
create an image via that command.  There is no provision in the Compute
(Nova) API to allow you to create an image out of bits that you supply.

The Image (Glance) APIs (both v1 and v2) allow you to supply the bits and
register them as an image which you can then use to boot instances from by
using the Compute API.  But note that if all you have available is the
Images API, you cannot create an image of one of your instances.

>So from that end-user perspective, the Nova image-create API indeed does
>³do the same thing" as the Glance API.

They don't "do the same thing".  Even if you have full access to the
Images v1 or v2 API, you will still have to use the Compute (Nova) API to
create an image of an instance, which is by far the largest use-case for
image creation.  You can't do it through Glance, because Glance doesn't
know anything about instances.  Nova has to know about Glance, because it
needs to fetch images for instance creation, and store images for
on-demand images of instances.


>At Your Service,
>
>Mark T. Voelker

Glad to be of service, too,
brian


__
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][nova] how to upgrade from v1 to v2?

[Andrew Laski]

On 09/25/15 at 03:09pm, Mark Voelker wrote:

On Sep 25, 2015, at 10:42 AM, Andrew Laski  wrote:


On 09/25/15 at 09:59am, Doug Hellmann wrote:

Excerpts from Mark Voelker's message of 2015-09-25 01:20:04 +:

>
> On Sep 24, 2015, at 5:55 PM, Sabari Murugesan  wrote:
>
> Hi Melanie
>
> In general, images created by glance v1 API should be accessible using v2 and
> vice-versa. We fixed some bugs [1] [2] [3] where metadata associated with an 
image was
> causing incompatibility. These fixes were back-ported to stable/kilo.
>
> Thanks
> Sabari
>
> [1] - https://bugs.launchpad.net/glance/+bug/1447215
> [2] - https://bugs.launchpad.net/bugs/1419823
> [3] - https://bugs.launchpad.net/python-glanceclient/+bug/1447193
>
>
> On Thu, Sep 24, 2015 at 2:17 PM, melanie witt  wrote:
> Hi All,
>
> I have been looking and haven't yet located documentation about how to 
upgrade from glance v1 to glance v2.
>
> From what I understand, images and snapshots created with v1 can't be 
listed/accessed through the v2 api. Are there instructions about how to migrate 
images and snapshots from v1 to v2? Are there other incompatibilities between v1 
and v2?
>
> I'm asking because I have read that glance v1 isn't defcore compliant and so 
we need all projects to move to v2, but the incompatibility from v1 to v2 is 
preventing that in nova. Is there anything else preventing v2 adoption? Could we 
move to glance v2 if there's a migration path from v1 to v2 that operators can run 
through before upgrading to a version that uses v2 as the default?

Just to clarify the DefCore situation a bit here:

The DefCore Committee is considering adding some Glance v2

capabilities [1] as “advisory” (e.g. not required now but might be
in the future unless folks provide feedback as to why it shouldn’t
be) in it’s next Guideline, which is due to go the Board of Directors
in January and will cover Juno, Kilo, and Liberty [2].  The Nova image
API’s are already required [3][4].  As discussion began about which
Glance capabilities to include and whether or not to keep the Nova
image API’s as required, it was pointed out that the many ways images
can currently be created in OpenStack is problematic from an
interoperability point of view in that some clouds use one and some use
others.  To be included in a DefCore Guideline, capabilities are scored
against twelve Criteria [5], and need to achieve a certain total to be
included.  Having a bunch of different ways to deal with images
actually hurts the chances of any one of them meeting the bar because
it makes it less likely that they’ll achieve several criteria.  For
example:


One of the criteria is “widely deployed” [6].  In the case of images, both the 
Nova image-create API and Glance v2 are both pretty widely deployed [7]; Glance 
v1 isn’t, and at least one uses none of those but instead uses the import task 
API.

Another criteria is “atomic” [8] which basically means the capability is unique 
and can’t be built out of other required capabilities.  Since the Nova 
image-create API is already required and effectively does the same thing as 
glance v1 and v2’s image create API’s, the latter lose points.


This seems backwards. The Nova API doesn't "do the same thing" as
the Glance API, it is a *proxy* for the Glance API. We should not
be requiring proxy APIs for interop. DefCore should only be using
tests that talk directly to the service that owns the feature being
tested.


I completely agree with this.  I will admit to having some confusion as to why 
Glance capabilities have been tested through Nova and I know others have raised 
this same thought within the process.


Because it turns out that’s how most of the world is dealing with images.

Generally speaking, the nova image API and glance v2 API’s have roughly equal 
adoption among public and private cloud products, but among the client SDK’s 
people are using to interact with OpenStack the nova image API’s have much 
better adoption (see notes in previous message for details).  So we gave the 
world lots of different ways to do the same thing and the world has strongly 
adopted two of them (with reasonable evidence that the Nova image API is 
actually the most-adopted of the lot).  If you’re looking for the most 
interoperable way to create an image across lots of different OpenStack clouds 
today, it’s actually through Nova.


I understand that reasoning, but still am unsure on a few things.

The direction seems to be moving towards having a requirement that the 
same functionality is offered in two places, Nova API and Glance V2 API.  
That seems like it would fragment adoption rather than unify it.


Also after digging in on image-create I feel that there may be a mixup.  
The image-create in Glance and image-create in Nova are two different 
things.  In Glance you create an image and send the disk image data in 
the request, in Nova an image-create takes a snapshot of the instance 
provided in the request.  But it seems like DefCore is tre

Re: [openstack-dev] [glance][nova] how to upgrade from v1 to v2?

[Mark Voelker]

On Sep 25, 2015, at 12:00 PM, Chris Hoge  wrote:
> 
>> 
>> On Sep 25, 2015, at 6:59 AM, Doug Hellmann  wrote:
>> 
>> Excerpts from Mark Voelker's message of 2015-09-25 01:20:04 +:
 
 On Sep 24, 2015, at 5:55 PM, Sabari Murugesan  
 wrote:
 
 Hi Melanie
 
 In general, images created by glance v1 API should be accessible using v2 
 and
 vice-versa. We fixed some bugs [1] [2] [3] where metadata associated with 
 an image was
 causing incompatibility. These fixes were back-ported to stable/kilo.
 
 Thanks
 Sabari
 
 [1] - https://bugs.launchpad.net/glance/+bug/1447215
 [2] - https://bugs.launchpad.net/bugs/1419823 
 [3] - https://bugs.launchpad.net/python-glanceclient/+bug/1447193 
 
 
 On Thu, Sep 24, 2015 at 2:17 PM, melanie witt  wrote:
 Hi All,
 
 I have been looking and haven't yet located documentation about how to 
 upgrade from glance v1 to glance v2.
 
 From what I understand, images and snapshots created with v1 can't be 
 listed/accessed through the v2 api. Are there instructions about how to 
 migrate images and snapshots from v1 to v2? Are there other 
 incompatibilities between v1 and v2?
 
 I'm asking because I have read that glance v1 isn't defcore compliant and 
 so we need all projects to move to v2, but the incompatibility from v1 to 
 v2 is preventing that in nova. Is there anything else preventing v2 
 adoption? Could we move to glance v2 if there's a migration path from v1 
 to v2 that operators can run through before upgrading to a version that 
 uses v2 as the default?
>>> 
>>> Just to clarify the DefCore situation a bit here: 
>>> 
>>> The DefCore Committee is considering adding some Glance v2
>> capabilities [1] as “advisory” (e.g. not required now but might be
>> in the future unless folks provide feedback as to why it shouldn’t
>> be) in it’s next Guideline, which is due to go the Board of Directors
>> in January and will cover Juno, Kilo, and Liberty [2].   The Nova image
>> API’s are already required [3][4].  As discussion began about which
>> Glance capabilities to include and whether or not to keep the Nova
>> image API’s as required, it was pointed out that the many ways images
>> can currently be created in OpenStack is problematic from an
>> interoperability point of view in that some clouds use one and some use
>> others.  To be included in a DefCore Guideline, capabilities are scored
>> against twelve Criteria [5], and need to achieve a certain total to be
>> included.  Having a bunch of different ways to deal with images
>> actually hurts the chances of any one of them meeting the bar because
>> it makes it less likely that they’ll achieve several criteria.  For
>> example:
>>> 
>>> One of the criteria is “widely deployed” [6].  In the case of images, both 
>>> the Nova image-create API and Glance v2 are both pretty widely deployed 
>>> [7]; Glance v1 isn’t, and at least one uses none of those but instead uses 
>>> the import task API.
>>> 
>>> Another criteria is “atomic” [8] which basically means the capability is 
>>> unique and can’t be built out of other required capabilities.  Since the 
>>> Nova image-create API is already required and effectively does the same 
>>> thing as glance v1 and v2’s image create API’s, the latter lose points.
>> 
>> This seems backwards. The Nova API doesn't "do the same thing" as
>> the Glance API, it is a *proxy* for the Glance API. We should not
>> be requiring proxy APIs for interop. DefCore should only be using
>> tests that talk directly to the service that owns the feature being
>> tested.
> 
> I agree in general, at the time the standard was approved the
> only api we had available to us (because only nova code was
> being considered for inclusion) was the proxy.
> 
> We’re looking at v2 as the required api going forward, but
> as has been mentioned before, the nova proxy requires that
> v1 be present as a non-public api. Not the best situation in
> the world, and I’m personally looking forward to Glance,
> Cinder, and Neutron becoming explicitly required APIs in
> DefCore.
> 

Also worth pointing out here: when we talk about “doing the same thing” from a 
DefCore perspective, we’re essentially talking about what’s exposed to the end 
user, not how that’s implemented in OpenStack’s source code.  So from an end 
user’s perspective:

If I call nova image-create, I get an image in my cloud.  If I call the Glance 
v2 API to create an image, I also get an image in my cloud.  I neither see nor 
care that Nova is actually talking to Glance in the background, because if I’m 
writing code that uses the OpenStack API’s, I need to pick which one of those 
two API’s to make my code call upon to put an image in my cloud.  Or, in the 
worst case, I have to write a bunch of if/else loops into my code because some 
clouds I want to use only allow one way and some allow only the other.

So from

Re: [openstack-dev] [glance][nova] how to upgrade from v1 to v2?

[Chris Hoge]

> On Sep 25, 2015, at 6:59 AM, Doug Hellmann  wrote:
> 
> Excerpts from Mark Voelker's message of 2015-09-25 01:20:04 +:
>>> 
>>> On Sep 24, 2015, at 5:55 PM, Sabari Murugesan  wrote:
>>> 
>>> Hi Melanie
>>> 
>>> In general, images created by glance v1 API should be accessible using v2 
>>> and
>>> vice-versa. We fixed some bugs [1] [2] [3] where metadata associated with 
>>> an image was
>>> causing incompatibility. These fixes were back-ported to stable/kilo.
>>> 
>>> Thanks
>>> Sabari
>>> 
>>> [1] - https://bugs.launchpad.net/glance/+bug/1447215
>>> [2] - https://bugs.launchpad.net/bugs/1419823 
>>> [3] - https://bugs.launchpad.net/python-glanceclient/+bug/1447193 
>>> 
>>> 
>>> On Thu, Sep 24, 2015 at 2:17 PM, melanie witt  wrote:
>>> Hi All,
>>> 
>>> I have been looking and haven't yet located documentation about how to 
>>> upgrade from glance v1 to glance v2.
>>> 
>>> From what I understand, images and snapshots created with v1 can't be 
>>> listed/accessed through the v2 api. Are there instructions about how to 
>>> migrate images and snapshots from v1 to v2? Are there other 
>>> incompatibilities between v1 and v2?
>>> 
>>> I'm asking because I have read that glance v1 isn't defcore compliant and 
>>> so we need all projects to move to v2, but the incompatibility from v1 to 
>>> v2 is preventing that in nova. Is there anything else preventing v2 
>>> adoption? Could we move to glance v2 if there's a migration path from v1 to 
>>> v2 that operators can run through before upgrading to a version that uses 
>>> v2 as the default?
>> 
>> Just to clarify the DefCore situation a bit here: 
>> 
>> The DefCore Committee is considering adding some Glance v2
> capabilities [1] as “advisory” (e.g. not required now but might be
> in the future unless folks provide feedback as to why it shouldn’t
> be) in it’s next Guideline, which is due to go the Board of Directors
> in January and will cover Juno, Kilo, and Liberty [2].The Nova image
> API’s are already required [3][4].  As discussion began about which
> Glance capabilities to include and whether or not to keep the Nova
> image API’s as required, it was pointed out that the many ways images
> can currently be created in OpenStack is problematic from an
> interoperability point of view in that some clouds use one and some use
> others.  To be included in a DefCore Guideline, capabilities are scored
> against twelve Criteria [5], and need to achieve a certain total to be
> included.  Having a bunch of different ways to deal with images
> actually hurts the chances of any one of them meeting the bar because
> it makes it less likely that they’ll achieve several criteria.  For
> example:
>> 
>> One of the criteria is “widely deployed” [6].  In the case of images, both 
>> the Nova image-create API and Glance v2 are both pretty widely deployed [7]; 
>> Glance v1 isn’t, and at least one uses none of those but instead uses the 
>> import task API.
>> 
>> Another criteria is “atomic” [8] which basically means the capability is 
>> unique and can’t be built out of other required capabilities.  Since the 
>> Nova image-create API is already required and effectively does the same 
>> thing as glance v1 and v2’s image create API’s, the latter lose points.
> 
> This seems backwards. The Nova API doesn't "do the same thing" as
> the Glance API, it is a *proxy* for the Glance API. We should not
> be requiring proxy APIs for interop. DefCore should only be using
> tests that talk directly to the service that owns the feature being
> tested.

I agree in general, at the time the standard was approved the
only api we had available to us (because only nova code was
being considered for inclusion) was the proxy.

We’re looking at v2 as the required api going forward, but
as has been mentioned before, the nova proxy requires that
v1 be present as a non-public api. Not the best situation in
the world, and I’m personally looking forward to Glance,
Cinder, and Neutron becoming explicitly required APIs in
DefCore.


> Doug
> 
>> 
>> Another criteria is “future direction” [9].  Glance v1 gets no points here 
>> since v2 is the current API, has been for a while, and there’s even been 
>> some work on v3 already.
>> 
>> There are also criteria for  “used by clients” [11].  Unfortunately both 
>> Glance v1 and v2 fall down pretty hard here as it turns out that of all the 
>> client libraries users reported in the last user survey, it appears the only 
>> one other than the OpenStack clients supports Glance v2 and one supports 
>> Glance v1 while the rest all rely on the Nova API's.  Even within OpenStack 
>> we don’t necessarily have good adoption since Nova still uses the v1 API to 
>> talk to Glance and OpenStackClient didn’t support image creation with v2 
>> until this week’s 1.7.0 release. [13]
>> 
>> So, it’s a bit problematic that v1 is still being used even within the 
>> project (though it did get slightly better this week).  It’s highly unlikely 
>> at this point t

Re: [openstack-dev] [glance][nova] how to upgrade from v1 to v2?

[Mark Voelker]

On Sep 25, 2015, at 10:42 AM, Andrew Laski  wrote:
> 
> On 09/25/15 at 09:59am, Doug Hellmann wrote:
>> Excerpts from Mark Voelker's message of 2015-09-25 01:20:04 +:
>>> >
>>> > On Sep 24, 2015, at 5:55 PM, Sabari Murugesan  
>>> > wrote:
>>> >
>>> > Hi Melanie
>>> >
>>> > In general, images created by glance v1 API should be accessible using v2 
>>> > and
>>> > vice-versa. We fixed some bugs [1] [2] [3] where metadata associated with 
>>> > an image was
>>> > causing incompatibility. These fixes were back-ported to stable/kilo.
>>> >
>>> > Thanks
>>> > Sabari
>>> >
>>> > [1] - https://bugs.launchpad.net/glance/+bug/1447215
>>> > [2] - https://bugs.launchpad.net/bugs/1419823
>>> > [3] - https://bugs.launchpad.net/python-glanceclient/+bug/1447193
>>> >
>>> >
>>> > On Thu, Sep 24, 2015 at 2:17 PM, melanie witt  wrote:
>>> > Hi All,
>>> >
>>> > I have been looking and haven't yet located documentation about how to 
>>> > upgrade from glance v1 to glance v2.
>>> >
>>> > From what I understand, images and snapshots created with v1 can't be 
>>> > listed/accessed through the v2 api. Are there instructions about how to 
>>> > migrate images and snapshots from v1 to v2? Are there other 
>>> > incompatibilities between v1 and v2?
>>> >
>>> > I'm asking because I have read that glance v1 isn't defcore compliant and 
>>> > so we need all projects to move to v2, but the incompatibility from v1 to 
>>> > v2 is preventing that in nova. Is there anything else preventing v2 
>>> > adoption? Could we move to glance v2 if there's a migration path from v1 
>>> > to v2 that operators can run through before upgrading to a version that 
>>> > uses v2 as the default?
>>> 
>>> Just to clarify the DefCore situation a bit here:
>>> 
>>> The DefCore Committee is considering adding some Glance v2
>> capabilities [1] as “advisory” (e.g. not required now but might be
>> in the future unless folks provide feedback as to why it shouldn’t
>> be) in it’s next Guideline, which is due to go the Board of Directors
>> in January and will cover Juno, Kilo, and Liberty [2].   The Nova image
>> API’s are already required [3][4].  As discussion began about which
>> Glance capabilities to include and whether or not to keep the Nova
>> image API’s as required, it was pointed out that the many ways images
>> can currently be created in OpenStack is problematic from an
>> interoperability point of view in that some clouds use one and some use
>> others.  To be included in a DefCore Guideline, capabilities are scored
>> against twelve Criteria [5], and need to achieve a certain total to be
>> included.  Having a bunch of different ways to deal with images
>> actually hurts the chances of any one of them meeting the bar because
>> it makes it less likely that they’ll achieve several criteria.  For
>> example:
>>> 
>>> One of the criteria is “widely deployed” [6].  In the case of images, both 
>>> the Nova image-create API and Glance v2 are both pretty widely deployed 
>>> [7]; Glance v1 isn’t, and at least one uses none of those but instead uses 
>>> the import task API.
>>> 
>>> Another criteria is “atomic” [8] which basically means the capability is 
>>> unique and can’t be built out of other required capabilities.  Since the 
>>> Nova image-create API is already required and effectively does the same 
>>> thing as glance v1 and v2’s image create API’s, the latter lose points.
>> 
>> This seems backwards. The Nova API doesn't "do the same thing" as
>> the Glance API, it is a *proxy* for the Glance API. We should not
>> be requiring proxy APIs for interop. DefCore should only be using
>> tests that talk directly to the service that owns the feature being
>> tested.
> 
> I completely agree with this.  I will admit to having some confusion as to 
> why Glance capabilities have been tested through Nova and I know others have 
> raised this same thought within the process.

Because it turns out that’s how most of the world is dealing with images.

Generally speaking, the nova image API and glance v2 API’s have roughly equal 
adoption among public and private cloud products, but among the client SDK’s 
people are using to interact with OpenStack the nova image API’s have much 
better adoption (see notes in previous message for details).  So we gave the 
world lots of different ways to do the same thing and the world has strongly 
adopted two of them (with reasonable evidence that the Nova image API is 
actually the most-adopted of the lot).  If you’re looking for the most 
interoperable way to create an image across lots of different OpenStack clouds 
today, it’s actually through Nova.

At Your Service,

Mark T. Voelker

> 
>> 
>> Doug
>> 
>>> 
>>> Another criteria is “future direction” [9].  Glance v1 gets no points here 
>>> since v2 is the current API, has been for a while, and there’s even been 
>>> some work on v3 already.
>>> 
>>> There are also criteria for  “used by clients” [11].  Unfortunately both 
>>> Glance v1 and v2 fall down pretty h

Re: [openstack-dev] [glance][nova] how to upgrade from v1 to v2?

[Andrew Laski]

On 09/25/15 at 09:59am, Doug Hellmann wrote:

Excerpts from Mark Voelker's message of 2015-09-25 01:20:04 +:

>
> On Sep 24, 2015, at 5:55 PM, Sabari Murugesan  wrote:
>
> Hi Melanie
>
> In general, images created by glance v1 API should be accessible using v2 and
> vice-versa. We fixed some bugs [1] [2] [3] where metadata associated with an 
image was
> causing incompatibility. These fixes were back-ported to stable/kilo.
>
> Thanks
> Sabari
>
> [1] - https://bugs.launchpad.net/glance/+bug/1447215
> [2] - https://bugs.launchpad.net/bugs/1419823
> [3] - https://bugs.launchpad.net/python-glanceclient/+bug/1447193
>
>
> On Thu, Sep 24, 2015 at 2:17 PM, melanie witt  wrote:
> Hi All,
>
> I have been looking and haven't yet located documentation about how to 
upgrade from glance v1 to glance v2.
>
> From what I understand, images and snapshots created with v1 can't be 
listed/accessed through the v2 api. Are there instructions about how to migrate 
images and snapshots from v1 to v2? Are there other incompatibilities between v1 
and v2?
>
> I'm asking because I have read that glance v1 isn't defcore compliant and so 
we need all projects to move to v2, but the incompatibility from v1 to v2 is 
preventing that in nova. Is there anything else preventing v2 adoption? Could we 
move to glance v2 if there's a migration path from v1 to v2 that operators can run 
through before upgrading to a version that uses v2 as the default?

Just to clarify the DefCore situation a bit here:

The DefCore Committee is considering adding some Glance v2

capabilities [1] as “advisory” (e.g. not required now but might be
in the future unless folks provide feedback as to why it shouldn’t
be) in it’s next Guideline, which is due to go the Board of Directors
in January and will cover Juno, Kilo, and Liberty [2].  The Nova image
API’s are already required [3][4].  As discussion began about which
Glance capabilities to include and whether or not to keep the Nova
image API’s as required, it was pointed out that the many ways images
can currently be created in OpenStack is problematic from an
interoperability point of view in that some clouds use one and some use
others.  To be included in a DefCore Guideline, capabilities are scored
against twelve Criteria [5], and need to achieve a certain total to be
included.  Having a bunch of different ways to deal with images
actually hurts the chances of any one of them meeting the bar because
it makes it less likely that they’ll achieve several criteria.  For
example:


One of the criteria is “widely deployed” [6].  In the case of images, both the 
Nova image-create API and Glance v2 are both pretty widely deployed [7]; Glance 
v1 isn’t, and at least one uses none of those but instead uses the import task 
API.

Another criteria is “atomic” [8] which basically means the capability is unique 
and can’t be built out of other required capabilities.  Since the Nova 
image-create API is already required and effectively does the same thing as 
glance v1 and v2’s image create API’s, the latter lose points.


This seems backwards. The Nova API doesn't "do the same thing" as
the Glance API, it is a *proxy* for the Glance API. We should not
be requiring proxy APIs for interop. DefCore should only be using
tests that talk directly to the service that owns the feature being
tested.


I completely agree with this.  I will admit to having some confusion as 
to why Glance capabilities have been tested through Nova and I know 
others have raised this same thought within the process.




Doug



Another criteria is “future direction” [9].  Glance v1 gets no points here 
since v2 is the current API, has been for a while, and there’s even been some 
work on v3 already.

There are also criteria for  “used by clients” [11].  Unfortunately both Glance 
v1 and v2 fall down pretty hard here as it turns out that of all the client 
libraries users reported in the last user survey, it appears the only one other 
than the OpenStack clients supports Glance v2 and one supports Glance v1 while 
the rest all rely on the Nova API's.  Even within OpenStack we don’t 
necessarily have good adoption since Nova still uses the v1 API to talk to 
Glance and OpenStackClient didn’t support image creation with v2 until this 
week’s 1.7.0 release. [13]

So, it’s a bit problematic that v1 is still being used even within the project 
(though it did get slightly better this week).  It’s highly unlikely at this 
point that it makes any sense for DefCore to require OpenStack Powered products 
to expose v1 to end users.  Even if DefCore does end up requiring Glance v2 to 
be exposed to end users, that doesn’t necessarily mean Nova couldn’t continue 
to use v1: OpenStack Powered products wouldn’t be required to expose v1 to end 
users, but if the nova image-create API remains required then they’d have to 
expose it at least internally to the cloud.  But….really?  That’s still sort of 
an ugly position to be in, because at the end of the day th

Re: [openstack-dev] [glance][nova] how to upgrade from v1 to v2?

[Doug Hellmann]

Excerpts from Mark Voelker's message of 2015-09-25 01:20:04 +:
> > 
> > On Sep 24, 2015, at 5:55 PM, Sabari Murugesan  wrote:
> > 
> > Hi Melanie
> > 
> > In general, images created by glance v1 API should be accessible using v2 
> > and
> > vice-versa. We fixed some bugs [1] [2] [3] where metadata associated with 
> > an image was
> > causing incompatibility. These fixes were back-ported to stable/kilo.
> > 
> > Thanks
> > Sabari
> > 
> > [1] - https://bugs.launchpad.net/glance/+bug/1447215
> > [2] - https://bugs.launchpad.net/bugs/1419823 
> > [3] - https://bugs.launchpad.net/python-glanceclient/+bug/1447193 
> > 
> > 
> > On Thu, Sep 24, 2015 at 2:17 PM, melanie witt  wrote:
> > Hi All,
> > 
> > I have been looking and haven't yet located documentation about how to 
> > upgrade from glance v1 to glance v2.
> > 
> > From what I understand, images and snapshots created with v1 can't be 
> > listed/accessed through the v2 api. Are there instructions about how to 
> > migrate images and snapshots from v1 to v2? Are there other 
> > incompatibilities between v1 and v2?
> > 
> > I'm asking because I have read that glance v1 isn't defcore compliant and 
> > so we need all projects to move to v2, but the incompatibility from v1 to 
> > v2 is preventing that in nova. Is there anything else preventing v2 
> > adoption? Could we move to glance v2 if there's a migration path from v1 to 
> > v2 that operators can run through before upgrading to a version that uses 
> > v2 as the default?
> 
> Just to clarify the DefCore situation a bit here: 
> 
> The DefCore Committee is considering adding some Glance v2
capabilities [1] as “advisory” (e.g. not required now but might be
in the future unless folks provide feedback as to why it shouldn’t
be) in it’s next Guideline, which is due to go the Board of Directors
in January and will cover Juno, Kilo, and Liberty [2].  The Nova image
API’s are already required [3][4].  As discussion began about which
Glance capabilities to include and whether or not to keep the Nova
image API’s as required, it was pointed out that the many ways images
can currently be created in OpenStack is problematic from an
interoperability point of view in that some clouds use one and some use
others.  To be included in a DefCore Guideline, capabilities are scored
against twelve Criteria [5], and need to achieve a certain total to be
included.  Having a bunch of different ways to deal with images
actually hurts the chances of any one of them meeting the bar because
it makes it less likely that they’ll achieve several criteria.  For
example:
> 
> One of the criteria is “widely deployed” [6].  In the case of images, both 
> the Nova image-create API and Glance v2 are both pretty widely deployed [7]; 
> Glance v1 isn’t, and at least one uses none of those but instead uses the 
> import task API.
> 
> Another criteria is “atomic” [8] which basically means the capability is 
> unique and can’t be built out of other required capabilities.  Since the Nova 
> image-create API is already required and effectively does the same thing as 
> glance v1 and v2’s image create API’s, the latter lose points.

This seems backwards. The Nova API doesn't "do the same thing" as
the Glance API, it is a *proxy* for the Glance API. We should not
be requiring proxy APIs for interop. DefCore should only be using
tests that talk directly to the service that owns the feature being
tested.

Doug

> 
> Another criteria is “future direction” [9].  Glance v1 gets no points here 
> since v2 is the current API, has been for a while, and there’s even been some 
> work on v3 already.
> 
> There are also criteria for  “used by clients” [11].  Unfortunately both 
> Glance v1 and v2 fall down pretty hard here as it turns out that of all the 
> client libraries users reported in the last user survey, it appears the only 
> one other than the OpenStack clients supports Glance v2 and one supports 
> Glance v1 while the rest all rely on the Nova API's.  Even within OpenStack 
> we don’t necessarily have good adoption since Nova still uses the v1 API to 
> talk to Glance and OpenStackClient didn’t support image creation with v2 
> until this week’s 1.7.0 release. [13]
> 
> So, it’s a bit problematic that v1 is still being used even within the 
> project (though it did get slightly better this week).  It’s highly unlikely 
> at this point that it makes any sense for DefCore to require OpenStack 
> Powered products to expose v1 to end users.  Even if DefCore does end up 
> requiring Glance v2 to be exposed to end users, that doesn’t necessarily mean 
> Nova couldn’t continue to use v1: OpenStack Powered products wouldn’t be 
> required to expose v1 to end users, but if the nova image-create API remains 
> required then they’d have to expose it at least internally to the cloud.  
> But….really?  That’s still sort of an ugly position to be in, because at the 
> end of the day that’s still a lot more moving parts than are really necessary 
> and th

Re: [openstack-dev] [glance][nova] how to upgrade from v1 to v2?

[Nikhil Komawar]

Hi Melanie,

In short, you can work on images using Glance's v1 and v2 at the same
time and your images should be created, listed etc.

When you operate Glance with Nova and likely use Nova's Images API, you
will need to have Glance's v1 operated currently. There is a upgrade
plan (v1->v2) we are working on and is being planned for Mitaka. So,
currently you need Glance v1 to work with Nova.

On 9/24/15 5:17 PM, melanie witt wrote:
> Hi All,
>
> I have been looking and haven't yet located documentation about how to 
> upgrade from glance v1 to glance v2.
>
> From what I understand, images and snapshots created with v1 can't be 
> listed/accessed through the v2 api. Are there instructions about how to 
> migrate images and snapshots from v1 to v2? Are there other incompatibilities 
> between v1 and v2?
>
> I'm asking because I have read that glance v1 isn't defcore compliant and so 
> we need all projects to move to v2, but the incompatibility from v1 to v2 is 
> preventing that in nova. Is there anything else preventing v2 adoption? Could 
> we move to glance v2 if there's a migration path from v1 to v2 that operators 
> can run through before upgrading to a version that uses v2 as the default?
>
> Thanks,
> -melanie (irc: melwitt)
>
>
>
>
>
>
>
> __
> 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] [glance][nova] how to upgrade from v1 to v2?

[Mark Voelker]

> 
> On Sep 24, 2015, at 5:55 PM, Sabari Murugesan  wrote:
> 
> Hi Melanie
> 
> In general, images created by glance v1 API should be accessible using v2 and
> vice-versa. We fixed some bugs [1] [2] [3] where metadata associated with an 
> image was
> causing incompatibility. These fixes were back-ported to stable/kilo.
> 
> Thanks
> Sabari
> 
> [1] - https://bugs.launchpad.net/glance/+bug/1447215
> [2] - https://bugs.launchpad.net/bugs/1419823 
> [3] - https://bugs.launchpad.net/python-glanceclient/+bug/1447193 
> 
> 
> On Thu, Sep 24, 2015 at 2:17 PM, melanie witt  wrote:
> Hi All,
> 
> I have been looking and haven't yet located documentation about how to 
> upgrade from glance v1 to glance v2.
> 
> From what I understand, images and snapshots created with v1 can't be 
> listed/accessed through the v2 api. Are there instructions about how to 
> migrate images and snapshots from v1 to v2? Are there other incompatibilities 
> between v1 and v2?
> 
> I'm asking because I have read that glance v1 isn't defcore compliant and so 
> we need all projects to move to v2, but the incompatibility from v1 to v2 is 
> preventing that in nova. Is there anything else preventing v2 adoption? Could 
> we move to glance v2 if there's a migration path from v1 to v2 that operators 
> can run through before upgrading to a version that uses v2 as the default?

Just to clarify the DefCore situation a bit here: 

The DefCore Committee is considering adding some Glance v2 capabilities [1] as 
“advisory” (e.g. not required now but might be in the future unless folks 
provide feedback as to why it shouldn’t be) in it’s next Guideline, which is 
due to go the Board of Directors in January and will cover Juno, Kilo, and 
Liberty [2].  The Nova image API’s are already required [3][4].  As discussion 
began about which Glance capabilities to include and whether or not to keep the 
Nova image API’s as required, it was pointed out that the many ways images can 
currently be created in OpenStack is problematic from an interoperability point 
of view in that some clouds use one and some use others.  To be included in a 
DefCore Guideline, capabilities are scored against twelve Criteria [5], and 
need to achieve a certain total to be included.  Having a bunch of different 
ways to deal with images actually hurts the chances of any one of them meeting 
the bar because it makes it less likely that they’ll achieve several criteria.  
For example:

One of the criteria is “widely deployed” [6].  In the case of images, both the 
Nova image-create API and Glance v2 are both pretty widely deployed [7]; Glance 
v1 isn’t, and at least one uses none of those but instead uses the import task 
API.

Another criteria is “atomic” [8] which basically means the capability is unique 
and can’t be built out of other required capabilities.  Since the Nova 
image-create API is already required and effectively does the same thing as 
glance v1 and v2’s image create API’s, the latter lose points.

Another criteria is “future direction” [9].  Glance v1 gets no points here 
since v2 is the current API, has been for a while, and there’s even been some 
work on v3 already.

There are also criteria for  “used by clients” [11].  Unfortunately both Glance 
v1 and v2 fall down pretty hard here as it turns out that of all the client 
libraries users reported in the last user survey, it appears the only one other 
than the OpenStack clients supports Glance v2 and one supports Glance v1 while 
the rest all rely on the Nova API's.  Even within OpenStack we don’t 
necessarily have good adoption since Nova still uses the v1 API to talk to 
Glance and OpenStackClient didn’t support image creation with v2 until this 
week’s 1.7.0 release. [13]

So, it’s a bit problematic that v1 is still being used even within the project 
(though it did get slightly better this week).  It’s highly unlikely at this 
point that it makes any sense for DefCore to require OpenStack Powered products 
to expose v1 to end users.  Even if DefCore does end up requiring Glance v2 to 
be exposed to end users, that doesn’t necessarily mean Nova couldn’t continue 
to use v1: OpenStack Powered products wouldn’t be required to expose v1 to end 
users, but if the nova image-create API remains required then they’d have to 
expose it at least internally to the cloud.  But….really?  That’s still sort of 
an ugly position to be in, because at the end of the day that’s still a lot 
more moving parts than are really necessary and that’s not particularly good 
for operators, end users, developers who want interoperable ways of doing 
things, or pretty much anybody else.  

So basically: yes, it would be *lovely* if we could all get behind fewer ways 
of dealing with images. [10]  

[1] https://review.openstack.org/#/c/213353/
[2] http://git.openstack.org/cgit/openstack/defcore/tree/2016.next.json#n8
[3] http://git.openstack.org/cgit/openstack/defcore/tree/2015.07.json#n23
[4] http://git.openstack.org/cgit/openstack/d

Re: [openstack-dev] [glance][nova] how to upgrade from v1 to v2?

[Fei Long Wang]

Thanks for raising this topic. I don't know why you think the 
images/snapshots created by v1 can't be accessed by v2. But I would say 
it's not true, see http://paste.openstack.org/show/473956/


Personally, I don't think there is any big blocker for this. What we 
need to do is working out a plan on the summit(Glance team have planned 
a design session for this). And meanwhile I'm going to split this 
https://review.openstack.org/#/c/144875/ to make it easier to review.



On 25/09/15 09:17, melanie witt wrote:

Hi All,

I have been looking and haven't yet located documentation about how to upgrade 
from glance v1 to glance v2.

 From what I understand, images and snapshots created with v1 can't be 
listed/accessed through the v2 api. Are there instructions about how to migrate 
images and snapshots from v1 to v2? Are there other incompatibilities between 
v1 and v2?

I'm asking because I have read that glance v1 isn't defcore compliant and so we 
need all projects to move to v2, but the incompatibility from v1 to v2 is 
preventing that in nova. Is there anything else preventing v2 adoption? Could 
we move to glance v2 if there's a migration path from v1 to v2 that operators 
can run through before upgrading to a version that uses v2 as the default?

Thanks,
-melanie (irc: melwitt)







__
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][nova] how to upgrade from v1 to v2?

[Sabari Murugesan]

Hi Melanie

In general, images created by glance v1 API should be accessible using v2
and
vice-versa. We fixed some bugs [1] [2] [3] where metadata associated with
an image was
causing incompatibility. These fixes were back-ported to stable/kilo.

Thanks
Sabari

[1] - https://bugs.launchpad.net/glance/+bug/1447215
[2] - https://bugs.launchpad.net/bugs/1419823
[3] - https://bugs.launchpad.net/python-glanceclient/+bug/1447193


On Thu, Sep 24, 2015 at 2:17 PM, melanie witt  wrote:

> Hi All,
>
> I have been looking and haven't yet located documentation about how to
> upgrade from glance v1 to glance v2.
>
> From what I understand, images and snapshots created with v1 can't be
> listed/accessed through the v2 api. Are there instructions about how to
> migrate images and snapshots from v1 to v2? Are there other
> incompatibilities between v1 and v2?
>
> I'm asking because I have read that glance v1 isn't defcore compliant and
> so we need all projects to move to v2, but the incompatibility from v1 to
> v2 is preventing that in nova. Is there anything else preventing v2
> adoption? Could we move to glance v2 if there's a migration path from v1 to
> v2 that operators can run through before upgrading to a version that uses
> v2 as the default?
>
> Thanks,
> -melanie (irc: melwitt)
>
>
>
>
>
>
> __
> 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

[openstack-dev] [glance][nova] how to upgrade from v1 to v2?

[melanie witt]

Hi All,

I have been looking and haven't yet located documentation about how to upgrade 
from glance v1 to glance v2.

From what I understand, images and snapshots created with v1 can't be 
listed/accessed through the v2 api. Are there instructions about how to migrate 
images and snapshots from v1 to v2? Are there other incompatibilities between 
v1 and v2?

I'm asking because I have read that glance v1 isn't defcore compliant and so we 
need all projects to move to v2, but the incompatibility from v1 to v2 is 
preventing that in nova. Is there anything else preventing v2 adoption? Could 
we move to glance v2 if there's a migration path from v1 to v2 that operators 
can run through before upgrading to a version that uses v2 as the default?

Thanks,
-melanie (irc: melwitt)







signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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