Re: [openstack-dev] [tc] [all] [glance] Answers to some questions about Glance

[Nikhil Komawar]

Thank you for stating all the right things Brian.


And I want to add that Glance too takes it to heart.


We needed a major version change and that's been communicated in many
ways. If more documentation, etc stuff is required, you are welcome to
provide that feedback. We are more than happy to help where required.


NOTE FOR ALL: We've spent 170,020,783 Calories on this version change
topic. It's done and we will have to live with it.


That's it. Time to pack up here.


On 5/18/16 8:44 AM, Brian Rosmaita wrote:
> On 5/18/16, 2:15 AM, "Clint Byrum"  wrote:
>
>> Excerpts from Robert Collins's message of 2016-05-18 14:57:05 +1200:
>>> On 18 May 2016 at 00:54, Brian Rosmaita 
>>> wrote:
>>>
> Couple of examples:
> 1. switching from "is_public=true" to "visibility=public"

 This was a major version change in the Images API.  The 'is_public'
>>> boolean
 is in the original Images v1 API, 'visibility' was introduced with the
 Images v2 API in the Folsom release.  You just need an awareness of
>>> which
 version of the API you're talking to.
>>> So I realise this is ancient history, but this is really a good
>>> example of why Monty has been pushing on 'never break our APIs': API
>>> breaks hurt users, major versions or not. Keeping the old attribute as
>>> an alias to the new one would have avoided the user pain for a very
>>> small amount of code.
>>>
>>> We are by definition an API - doesn't matter that its HTTP vs Python -
>>> when we break compatibility, there's a very long tail of folk that
>>> will have to spend time updating their code; 'Microversions' are a
>>> good answer to this, as long as we never raise the minimum version we
>>> support. glibc does a very similar thing with versioned symbols - and
>>> they support things approximately indefinitely.
>> +1, realy well said. As Nikhil said, assumptions are bad, and assuming
>> that nobody's using that, or that they'll just adapt, is not really a
>> great way to establish a relationship with the users.
> I agree with the general sentiment, and I sincerely hope that all
> OpenStack projects take it to heart.
>
> I also want to note for the record that the Images API really did need a
> major version change.
>
> cheers,
> 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

-- 

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] [tc] [all] [glance] Answers to some questions about Glance

[Nikhil Komawar]

On 5/18/16 11:55 AM, Clint Byrum wrote:
> Excerpts from Nikhil Komawar's message of 2016-05-18 11:03:45 -0400:
>> On 5/18/16 2:15 AM, Clint Byrum wrote:
>>> Excerpts from Robert Collins's message of 2016-05-18 14:57:05 +1200:
 On 18 May 2016 at 00:54, Brian Rosmaita  
 wrote:

>> Couple of examples:
>> 1. switching from "is_public=true" to "visibility=public"
> This was a major version change in the Images API.  The 'is_public' 
> boolean
> is in the original Images v1 API, 'visibility' was introduced with the
> Images v2 API in the Folsom release.  You just need an awareness of which
> version of the API you're talking to.
 So I realise this is ancient history, but this is really a good
 example of why Monty has been pushing on 'never break our APIs': API
 breaks hurt users, major versions or not. Keeping the old attribute as
 an alias to the new one would have avoided the user pain for a very
 small amount of code.

 We are by definition an API - doesn't matter that its HTTP vs Python -
 when we break compatibility, there's a very long tail of folk that
 will have to spend time updating their code; 'Microversions' are a
 good answer to this, as long as we never raise the minimum version we
 support. glibc does a very similar thing with versioned symbols - and
 they support things approximately indefinitely.
>>> +1, realy well said. As Nikhil said, assumptions are bad, and assuming
>> You have only conveniently picked up one things I've said in my email,
>> why not choose the other parts of resolving those assumptions correctly.
>> Please do not phrase me when the propaganda is orthogonal to what I
>> proposed.
>>
>>> that nobody's using that, or that they'll just adapt, is not really a
>>> great way to establish a relationship with the users.
>> It's not that assumption that users are not using it:
>>
>> The very _assumption_ people who are using it is that glance v1 is ok to
>> be public facing API which was never designed to be one. So, that's the
>> assumption you need to take into account and not the one you like to
>> pick. That's the part where I talk about being engaged missing in your
>> message.
>>
> It doesn't really matter what it was designed for, once something is
> released as a public facing API, and users build on top of it, there
> are consequences for breaking it.
>
> There's nothing personal about this problem. It happens. My message is
> simple, and consistent with the other thread (and I do see how they are
> linked): We don't get to pick how people consume the messages we send.
> Whether in docs, code, mailing list threads, or even a room with humans
> face to face, mistakes will be made.
>
> So lets be frank about that, and put aside our egos, and accept that

Again, like I keep mentioning in various emails, catching intent is hard
on the ML. If you read the full email and not in pieces you will realize
the point I make about being rational in the feedback.

The problem is about speculation and not ego. Something I wanted to
start as a result of my thread to prove a point and that's been achieved.

The fallout is me merely making sure that Glance team stays happy. If a
few glance-cores leave just because one user is unhappy, that's a big
loss, for the entire community.

Again, let's avoid speculation, keep maintaining rationality in our
approach. Stay on topic, read the comments fully before replying. What
someone consumes is not in our will, but whether we as a community
appreciate such approache is. Let's keep that in mind.

Being judicious in our communication is far more important than frank,
wise feedback always improves, frank may not always do so.

> mistakes were made _by all parties_ in this specific case, and nobody is
> "mad" about this, but we'd all like to avoid making them again.

If you have to work on something in openstack for a few years and that
still remains unresolved for not necessarily the most convincing
reasons, a large portion of the community is going to be mad. What you
see is merely a oversight.

>
> __
> 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] [tc] [all] [glance] Answers to some questions about Glance

[Nikhil Komawar]

All great points. But, I just want us to read between the lines.


On 5/17/16 10:57 PM, Robert Collins wrote:
> On 18 May 2016 at 00:54, Brian Rosmaita  wrote:
>
>>> Couple of examples:
>>> 1. switching from "is_public=true" to "visibility=public"
>>
>> This was a major version change in the Images API.  The 'is_public' boolean
>> is in the original Images v1 API, 'visibility' was introduced with the
>> Images v2 API in the Folsom release.  You just need an awareness of which
>> version of the API you're talking to.
> So I realise this is ancient history, but this is really a good

Thank you for realizing that! Whatever keeps us from reopening this
pandora's box again!

> example of why Monty has been pushing on 'never break our APIs': API

Sure, we need to consider when that was proposed and how OpenStack was
operating before, who were the major stakeholders and why certain things
needed to be changed. I am not arguing against your point, rather saying
for sake of supporting an API that will remain maintainable long term.
Have we considered all the things are important like security before
saying that we need backward compatibility or are we willing to
compromise on that?, I guess not.

> breaks hurt users, major versions or not. Keeping the old attribute as
> an alias to the new one would have avoided the user pain for a very
> small amount of code.

Again, we need to be careful about this, keep the compatibility when it
makes sense and is possible. Having to maintain a hacky code is pretty
bad idea I'd say.

>
> We are by definition an API - doesn't matter that its HTTP vs Python -
> when we break compatibility, there's a very long tail of folk that
> will have to spend time updating their code; 'Microversions' are a
> good answer to this, as long as we never raise the minimum version we
> support. glibc does a very similar thing with versioned symbols - and
> they support things approximately indefinitely.

All good points and we are going in that direction. Thanks for stating
them explicitly.

>
> -Rob
>
> __
> 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] [tc] [all] [glance] Answers to some questions about Glance

[Clint Byrum]

Excerpts from Nikhil Komawar's message of 2016-05-18 11:03:45 -0400:
> 
> On 5/18/16 2:15 AM, Clint Byrum wrote:
> > Excerpts from Robert Collins's message of 2016-05-18 14:57:05 +1200:
> >> On 18 May 2016 at 00:54, Brian Rosmaita  
> >> wrote:
> >>
>  Couple of examples:
>  1. switching from "is_public=true" to "visibility=public"
> >>>
> >>> This was a major version change in the Images API.  The 'is_public' 
> >>> boolean
> >>> is in the original Images v1 API, 'visibility' was introduced with the
> >>> Images v2 API in the Folsom release.  You just need an awareness of which
> >>> version of the API you're talking to.
> >> So I realise this is ancient history, but this is really a good
> >> example of why Monty has been pushing on 'never break our APIs': API
> >> breaks hurt users, major versions or not. Keeping the old attribute as
> >> an alias to the new one would have avoided the user pain for a very
> >> small amount of code.
> >>
> >> We are by definition an API - doesn't matter that its HTTP vs Python -
> >> when we break compatibility, there's a very long tail of folk that
> >> will have to spend time updating their code; 'Microversions' are a
> >> good answer to this, as long as we never raise the minimum version we
> >> support. glibc does a very similar thing with versioned symbols - and
> >> they support things approximately indefinitely.
> > +1, realy well said. As Nikhil said, assumptions are bad, and assuming
> 
> You have only conveniently picked up one things I've said in my email,
> why not choose the other parts of resolving those assumptions correctly.
> Please do not phrase me when the propaganda is orthogonal to what I
> proposed.
> 
> > that nobody's using that, or that they'll just adapt, is not really a
> > great way to establish a relationship with the users.
> 
> It's not that assumption that users are not using it:
> 
> The very _assumption_ people who are using it is that glance v1 is ok to
> be public facing API which was never designed to be one. So, that's the
> assumption you need to take into account and not the one you like to
> pick. That's the part where I talk about being engaged missing in your
> message.
> 

It doesn't really matter what it was designed for, once something is
released as a public facing API, and users build on top of it, there
are consequences for breaking it.

There's nothing personal about this problem. It happens. My message is
simple, and consistent with the other thread (and I do see how they are
linked): We don't get to pick how people consume the messages we send.
Whether in docs, code, mailing list threads, or even a room with humans
face to face, mistakes will be made.

So lets be frank about that, and put aside our egos, and accept that
mistakes were made _by all parties_ in this specific case, and nobody is
"mad" about this, but we'd all like to avoid making them again.

__
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] [tc] [all] [glance] Answers to some questions about Glance

[Nikhil Komawar]

On 5/18/16 2:15 AM, Clint Byrum wrote:
> Excerpts from Robert Collins's message of 2016-05-18 14:57:05 +1200:
>> On 18 May 2016 at 00:54, Brian Rosmaita  wrote:
>>
 Couple of examples:
 1. switching from "is_public=true" to "visibility=public"
>>>
>>> This was a major version change in the Images API.  The 'is_public' boolean
>>> is in the original Images v1 API, 'visibility' was introduced with the
>>> Images v2 API in the Folsom release.  You just need an awareness of which
>>> version of the API you're talking to.
>> So I realise this is ancient history, but this is really a good
>> example of why Monty has been pushing on 'never break our APIs': API
>> breaks hurt users, major versions or not. Keeping the old attribute as
>> an alias to the new one would have avoided the user pain for a very
>> small amount of code.
>>
>> We are by definition an API - doesn't matter that its HTTP vs Python -
>> when we break compatibility, there's a very long tail of folk that
>> will have to spend time updating their code; 'Microversions' are a
>> good answer to this, as long as we never raise the minimum version we
>> support. glibc does a very similar thing with versioned symbols - and
>> they support things approximately indefinitely.
> +1, realy well said. As Nikhil said, assumptions are bad, and assuming

You have only conveniently picked up one things I've said in my email,
why not choose the other parts of resolving those assumptions correctly.
Please do not phrase me when the propaganda is orthogonal to what I
proposed.

> that nobody's using that, or that they'll just adapt, is not really a
> great way to establish a relationship with the users.

It's not that assumption that users are not using it:

The very _assumption_ people who are using it is that glance v1 is ok to
be public facing API which was never designed to be one. So, that's the
assumption you need to take into account and not the one you like to
pick. That's the part where I talk about being engaged missing in your
message.

>
> __
> 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] [tc] [all] [glance] Answers to some questions about Glance

[Brian Rosmaita]

On 5/18/16, 2:15 AM, "Clint Byrum"  wrote:

>Excerpts from Robert Collins's message of 2016-05-18 14:57:05 +1200:
>> On 18 May 2016 at 00:54, Brian Rosmaita 
>>wrote:
>> 
>> >> Couple of examples:
>> >> 1. switching from "is_public=true" to "visibility=public"
>> >
>> >
>> > This was a major version change in the Images API.  The 'is_public'
>>boolean
>> > is in the original Images v1 API, 'visibility' was introduced with the
>> > Images v2 API in the Folsom release.  You just need an awareness of
>>which
>> > version of the API you're talking to.
>> 
>> So I realise this is ancient history, but this is really a good
>> example of why Monty has been pushing on 'never break our APIs': API
>> breaks hurt users, major versions or not. Keeping the old attribute as
>> an alias to the new one would have avoided the user pain for a very
>> small amount of code.
>> 
>> We are by definition an API - doesn't matter that its HTTP vs Python -
>> when we break compatibility, there's a very long tail of folk that
>> will have to spend time updating their code; 'Microversions' are a
>> good answer to this, as long as we never raise the minimum version we
>> support. glibc does a very similar thing with versioned symbols - and
>> they support things approximately indefinitely.
>
>+1, realy well said. As Nikhil said, assumptions are bad, and assuming
>that nobody's using that, or that they'll just adapt, is not really a
>great way to establish a relationship with the users.

I agree with the general sentiment, and I sincerely hope that all
OpenStack projects take it to heart.

I also want to note for the record that the Images API really did need a
major version change.

cheers,
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] [tc] [all] [glance] Answers to some questions about Glance

[Clint Byrum]

Excerpts from Robert Collins's message of 2016-05-18 14:57:05 +1200:
> On 18 May 2016 at 00:54, Brian Rosmaita  wrote:
> 
> >> Couple of examples:
> >> 1. switching from "is_public=true" to "visibility=public"
> >
> >
> > This was a major version change in the Images API.  The 'is_public' boolean
> > is in the original Images v1 API, 'visibility' was introduced with the
> > Images v2 API in the Folsom release.  You just need an awareness of which
> > version of the API you're talking to.
> 
> So I realise this is ancient history, but this is really a good
> example of why Monty has been pushing on 'never break our APIs': API
> breaks hurt users, major versions or not. Keeping the old attribute as
> an alias to the new one would have avoided the user pain for a very
> small amount of code.
> 
> We are by definition an API - doesn't matter that its HTTP vs Python -
> when we break compatibility, there's a very long tail of folk that
> will have to spend time updating their code; 'Microversions' are a
> good answer to this, as long as we never raise the minimum version we
> support. glibc does a very similar thing with versioned symbols - and
> they support things approximately indefinitely.

+1, realy well said. As Nikhil said, assumptions are bad, and assuming
that nobody's using that, or that they'll just adapt, is not really a
great way to establish a relationship with the users.

__
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] [tc] [all] [glance] Answers to some questions about Glance

[Robert Collins]

On 18 May 2016 at 00:54, Brian Rosmaita  wrote:

>> Couple of examples:
>> 1. switching from "is_public=true" to "visibility=public"
>
>
> This was a major version change in the Images API.  The 'is_public' boolean
> is in the original Images v1 API, 'visibility' was introduced with the
> Images v2 API in the Folsom release.  You just need an awareness of which
> version of the API you're talking to.

So I realise this is ancient history, but this is really a good
example of why Monty has been pushing on 'never break our APIs': API
breaks hurt users, major versions or not. Keeping the old attribute as
an alias to the new one would have avoided the user pain for a very
small amount of code.

We are by definition an API - doesn't matter that its HTTP vs Python -
when we break compatibility, there's a very long tail of folk that
will have to spend time updating their code; 'Microversions' are a
good answer to this, as long as we never raise the minimum version we
support. glibc does a very similar thing with versioned symbols - and
they support things approximately indefinitely.

-Rob

__
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] [tc] [all] [glance] Answers to some questions about Glance

[John Griffith]

Thanks Brian

On Tue, May 17, 2016 at 6:54 AM, Brian Rosmaita <
brian.rosma...@rackspace.com> wrote:

> Subject was: Re: [openstack-dev] [tc] [all] [glance] On operating a high
> throughput or otherwise team
>
> Un-hijacking the thread.  Here are some answers to John's questions, hope
> they are helpful.
>
> On 5/16/16, 9:06 PM, "John Griffith"  wrote:
>
> Hey,
>
> Maybe not related, but maybe it is.  After spending the past couple of
> hours trying to help a customer with a Glance issue I'm a bit... well
> annoyed with Glance.  I'd like to chime in on this thread.  I'm honesty not
> entirely sure what the goal of the thread is, but honestly there's
> something rather important to me that I don't really seem to see being
> called out.
>
> Is there any way we could stop breaking the API and it's behaviors?  Is
> there any way we can fix some of the issues with respect to how things work
> when folks configure multiple Glance repos?
>
> Couple of examples:
> 1. switching from "is_public=true" to "visibility=public"
>
>
> This was a major version change in the Images API.  The 'is_public'
> boolean is in the original Images v1 API, 'visibility' was introduced with
> the Images v2 API in the Folsom release.  You just need an awareness of
> which version of the API you're talking to.
>
>
>
> Ok, cool, I'm sure there's great reasons, but it really sucks when folks
> update their client and now none of their automation works any longer
>
>
> The Images v1 API went from CURRENT to SUPPORTED in the Kilo release
> (April 30, 2015).  The python-glanceclient began using v2 as the default
> with Change-Id: I09c9e409d149e2d797785591183e06c13229b7f7 on June 21, 2015
> (and hence would have been in release 0.17.2 on July 16, 2015).  So these
> changes have been in the works for a while.
>
> 2. making virtual_size R/O
>
>
> So for some time this was a property that folks could use to set the size
> of an image needed for things like volume creation, cloning etc.  At some
> point though it was decided "this should be read only", ok... well again
> all sorts of code is now broken, including code in Cinder.​  It also seems
> there's no way to set it, so it's always there and just Null.  It looked
> like I would be able to set it during image-create maybe... but then I hit
> number 3.
>
>
> The virtual_size was added to the Images v2 API with Change-Id:
> Ie4f58ee2e4da3a6c1229840295c7f62023a95b70 on February 11, 2014.  The commit
> message indicates: "This patch adds the knowledge of a virtual_size field
> to Glance's API v2. The virtual_size field should respect the same rules
> applied to the size field in terms of readability, access control and
> propagation."  The 'size' field has never been end-user modifiable, hence
> the virtual_size is read-only as well.
>
> 3. broken parsing for size and virtual_size
>
> I just started looking at this one and I'm not sure what happened here
> yet, but it seems that these inputs aren't being parsed any more and are
> now raising an exception due to trying to stuff a string into an int field
> in the json schema.
>
>
> Please file a bug with some details when you know more about this one.  It
> sounds like a client issue, but you can put details in the bug report.
>
> So I think if the project wants to move faster that's great, but please is
> theres any chance to value backwards compatibility just a bit more?​  I'm
> sure I'm going to get flamed for this email, and the likely response will
> be "you're doing it wrong".  I guess if I'm the only one that has these
> sorts of issues then alright, I deserve the flames, and maybe somebody will
> enlighten me on the proper ways of using Glance so I can be happier and
> more in tune with my Universe.
>
>
> Well, since you asked for enlightenment ... it *is* helpful to make sure
> that you know which version of the Images API you're using.  The Glance
> community values backwards compatibility, but not across major releases.
>
> As I imagine you're aware, Glance is tagged "release:
> cycle-with-milestones", so you can read about any changes in the release
> notes.  Or if you want a quick overview of what major features were added
> to Glance for each release, there was an excellent presentation at the
> Tokyo summit about the evolution of the Glance APIs:
>
> https://www.openstack.org/summit/tokyo-2015/videos/presentation/the-evolution-of-glance-api-on-the-way-from-v1-to-v3
> slides only:
> http://www.slideshare.net/racker_br/the-evolution-of-glance-api-on-the-way-from-v1-to-v3
>
> Before people begin freaking out at the mention of the Images v3 API,
> please note that the presentation above described the state of Glance as of
> October 2015.  The Glance documentation has a statement about the two
> Images APIs and the current plans for The Future that was updated shortly
> after the Austin summit:
>
> http://docs.openstack.org/developer/glance/glanceapi.html#glance-and-the-images-apis-past-present-and-future
> 

[openstack-dev] [tc] [all] [glance] Answers to some questions about Glance

[Brian Rosmaita]

Subject was: Re: [openstack-dev] [tc] [all] [glance] On operating a high 
throughput or otherwise team

Un-hijacking the thread.  Here are some answers to John's questions, hope they 
are helpful.

On 5/16/16, 9:06 PM, "John Griffith" 
> wrote:
Hey,

Maybe not related, but maybe it is.  After spending the past couple of hours 
trying to help a customer with a Glance issue I'm a bit... well annoyed with 
Glance.  I'd like to chime in on this thread.  I'm honesty not entirely sure 
what the goal of the thread is, but honestly there's something rather important 
to me that I don't really seem to see being called out.

Is there any way we could stop breaking the API and it's behaviors?  Is there 
any way we can fix some of the issues with respect to how things work when 
folks configure multiple Glance repos?

Couple of examples:
1. switching from "is_public=true" to "visibility=public"

This was a major version change in the Images API.  The 'is_public' boolean is 
in the original Images v1 API, 'visibility' was introduced with the Images v2 
API in the Folsom release.  You just need an awareness of which version of the 
API you're talking to.


Ok, cool, I'm sure there's great reasons, but it really sucks when folks update 
their client and now none of their automation works any longer

The Images v1 API went from CURRENT to SUPPORTED in the Kilo release (April 30, 
2015).  The python-glanceclient began using v2 as the default with Change-Id: 
I09c9e409d149e2d797785591183e06c13229b7f7 on June 21, 2015 (and hence would 
have been in release 0.17.2 on July 16, 2015).  So these changes have been in 
the works for a while.

2. making virtual_size R/O

So for some time this was a property that folks could use to set the size of an 
image needed for things like volume creation, cloning etc.  At some point 
though it was decided "this should be read only", ok... well again all sorts of 
code is now broken, including code in Cinder.​  It also seems there's no way to 
set it, so it's always there and just Null.  It looked like I would be able to 
set it during image-create maybe... but then I hit number 3.

The virtual_size was added to the Images v2 API with Change-Id: 
Ie4f58ee2e4da3a6c1229840295c7f62023a95b70 on February 11, 2014.  The commit 
message indicates: "This patch adds the knowledge of a virtual_size field to 
Glance's API v2. The virtual_size field should respect the same rules applied 
to the size field in terms of readability, access control and propagation."  
The 'size' field has never been end-user modifiable, hence the virtual_size is 
read-only as well.

3. broken parsing for size and virtual_size

I just started looking at this one and I'm not sure what happened here yet, but 
it seems that these inputs aren't being parsed any more and are now raising an 
exception due to trying to stuff a string into an int field in the json schema.

Please file a bug with some details when you know more about this one.  It 
sounds like a client issue, but you can put details in the bug report.

So I think if the project wants to move faster that's great, but please is 
theres any chance to value backwards compatibility just a bit more?​  I'm sure 
I'm going to get flamed for this email, and the likely response will be "you're 
doing it wrong".  I guess if I'm the only one that has these sorts of issues 
then alright, I deserve the flames, and maybe somebody will enlighten me on the 
proper ways of using Glance so I can be happier and more in tune with my 
Universe.

Well, since you asked for enlightenment ... it *is* helpful to make sure that 
you know which version of the Images API you're using.  The Glance community 
values backwards compatibility, but not across major releases.

As I imagine you're aware, Glance is tagged "release: cycle-with-milestones", 
so you can read about any changes in the release notes.  Or if you want a quick 
overview of what major features were added to Glance for each release, there 
was an excellent presentation at the Tokyo summit about the evolution of the 
Glance APIs:
https://www.openstack.org/summit/tokyo-2015/videos/presentation/the-evolution-of-glance-api-on-the-way-from-v1-to-v3
slides only: 
http://www.slideshare.net/racker_br/the-evolution-of-glance-api-on-the-way-from-v1-to-v3

Before people begin freaking out at the mention of the Images v3 API, please 
note that the presentation above described the state of Glance as of October 
2015.  The Glance documentation has a statement about the two Images APIs and 
the current plans for The Future that was updated shortly after the Austin 
summit:
http://docs.openstack.org/developer/glance/glanceapi.html#glance-and-the-images-apis-past-present-and-future
(Spoiler alert: no plans for Images v3 API at this point.)

Thanks,
John

Hope that was helpful,
brian

__
OpenStack Development Mailing List