Re: [openstack-dev] [glance][tempest][api] community images, tempest tests, and API stability

2017-01-16 Thread Ken'ichi Ohmichi 
2017-01-13 9:25 GMT-08:00 Ian Cordasco <sigmaviru...@gmail.com>:
> -Original Message-
> From: Ian Cordasco <sigmaviru...@gmail.com>
> Reply: Ian Cordasco <sigmaviru...@gmail.com>
> Date: January 13, 2017 at 08:12:12
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> Subject:  Re: [openstack-dev] [glance][tempest][api] community images,
> tempest tests, and API stability
>
>> And besides "No one uses Glance" [ref: 
>> http://lists.openstack.org/pipermail/openstack-dev/2013-February/005758.html]
>
> I was being a bit glib when I wrote this last sentence this morning,
> but in commenting on the Gerrit patch to skip the test in question, I
> realized this is actually far more valid than I realized.
>
> Let's look at the state of Glance v2 and be brutally honest:
>
> Interoperability
>
> Glance v2 is currently incapable of being truly interoperable between
> existing publicly accessible clouds. There are two ways to currently
> upload images to Glance. Work is being done to add a third way that
> suits the needs of all cloud providers. This introduces further
> interoperability incompatibility (say *that* three times fast ;)) and
> honestly, I don't see it being a problem for the next reason.
>
> Further, the tasks API presents a huge number of interoperability
> problems. We've limited that to users with the admin role, but if you
> have an admin on two clouds operated by different people, there is a
> good likelihood the tasks will not be the same.
>
>
> v2 deployment and usage
>
> The best anyone working on Glance can determine, v2 is rarely deployed
> for users and if it is, it isn't chosen. v2 was written to specifically
> excise some problematic "features" that some users still rely on. A
> such, you see conversations even between Glance and *other services*
> about how to migrate to v2. Nova only recently made the migration. Heat
> still has yet to do so and I think has only just relented in their
> desire to avoid it.

Humm, Defcore list contains Glance v2 tests for the interoperability
like https://github.com/openstack/defcore/blob/master/2016.08.json#L1366
# We can see Tempest tests of Glance v2 API by searching "tempest.api.image.v2".
I guess many deployments provide the v2 API today..

> Security Concerns
>
> There are some serious security issues that will be fixed by this
> change. If we were to add the backwards compatibility shim that the QA
> team has suggested repeatedly that we add, we'd be keeping those security
> issues.

Security issues/problems should be solved as the highest priority.
The progress should be nice if having CVE.

> In short, I feel like the constant refrain from the QA team has been two fold:
>
> - "This will cause interoperability problems"
> - "This is backwards incompatible"
>
> The Glance team has come to terms with this over the course of several
> cycles. I don't think anyone is thrilled about the prospect of
> potentially breaking some users' workflows. If we had been that
> enthusiastic about it, then we simply would have acted on this when it
> was first proposed. It would have completely gone unnoticed except by
> some users. There's no acceptable way (without sacrificing security -
> which let's be clear, is entirely unacceptable) that we can maintain a
> backwards compatibility shim and Glance v2 already has loads of
> interoperability problems. We're working on fixing them, but we're
> also working on fixing the user experience, which is a big part of
> this patch.

I think Glance team has spent time and considering for moving to this
direction and I believe the team will take responsibility if facing
issues on the direction.
Then I also am going to take this way.

Thanks
Ken Ohmichi

__
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][tempest][api] community images, tempest tests, and API stability

2017-01-13 Thread Ian Cordasco 
-Original Message-
From: Ian Cordasco <sigmaviru...@gmail.com>
Reply: Ian Cordasco <sigmaviru...@gmail.com>
Date: January 13, 2017 at 08:12:12
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [glance][tempest][api] community images,
tempest tests, and API stability

> And besides "No one uses Glance" [ref: 
> http://lists.openstack.org/pipermail/openstack-dev/2013-February/005758.html]

I was being a bit glib when I wrote this last sentence this morning,
but in commenting on the Gerrit patch to skip the test in question, I
realized this is actually far more valid than I realized.

Let's look at the state of Glance v2 and be brutally honest:

Interoperability

    Glance v2 is currently incapable of being truly interoperable between
    existing publicly accessible clouds. There are two ways to currently
    upload images to Glance. Work is being done to add a third way that
    suits the needs of all cloud providers. This introduces further
    interoperability incompatibility (say *that* three times fast ;)) and
    honestly, I don't see it being a problem for the next reason.

    Further, the tasks API presents a huge number of interoperability
    problems. We've limited that to users with the admin role, but if you
    have an admin on two clouds operated by different people, there is a
    good likelihood the tasks will not be the same.


v2 deployment and usage

    The best anyone working on Glance can determine, v2 is rarely deployed
    for users and if it is, it isn't chosen. v2 was written to specifically
    excise some problematic "features" that some users still rely on. A
    such, you see conversations even between Glance and *other services*
    about how to migrate to v2. Nova only recently made the migration. Heat
    still has yet to do so and I think has only just relented in their
    desire to avoid it.


Security Concerns

    There are some serious security issues that will be fixed by this
    change. If we were to add the backwards compatibility shim that the QA
    team has suggested repeatedly that we add, we'd be keeping those security
    issues.


In short, I feel like the constant refrain from the QA team has been two fold:

- "This will cause interoperability problems"
- "This is backwards incompatible"

The Glance team has come to terms with this over the course of several
cycles. I don't think anyone is thrilled about the prospect of
potentially breaking some users' workflows. If we had been that
enthusiastic about it, then we simply would have acted on this when it
was first proposed. It would have completely gone unnoticed except by
some users. There's no acceptable way (without sacrificing security -
which let's be clear, is entirely unacceptable) that we can maintain a
backwards compatibility shim and Glance v2 already has loads of
interoperability problems. We're working on fixing them, but we're
also working on fixing the user experience, which is a big part of
this patch.

--
Ian Cordasco

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

Re: [openstack-dev] [glance][tempest][api] community images, tempest tests, and API stability

2017-01-13 Thread Ian Cordasco 
-Original Message-
From: Ken'ichi Ohmichi <ken1ohmi...@gmail.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: January 12, 2017 at 13:35:56
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [glance][tempest][api] community images,
tempest tests, and API stability

> 2017-01-12 5:47 GMT-08:00 Brian Rosmaita :
> > The issue is that we are proposing to introduce an incompatible change
> > in order to address an incoherence with image visibility semantics. We
> > have acknowledged that this is a breaking change, but the impact of the
> > change is mitigated by the way that the default visibility value is
> > assigned in Ocata.
> >
> > As I've documented earlier in the thread, we have discussed this change
> > with the wider community and the API Working Group, and they are OK with it.
> >
> > The current tempest test has done its duty and identified an
> > incompatibility in the Ocata code. We acknowledge that and salute you.
> > On balance, however, this change will be better for users (and as I've
> > documented earlier in the thread, we've minimized the impact of the
> > change), and we want to make it anyway.
>
> It is difficult to expect the impact of API change is small by us as 
> developers.

We're not claiming it is small. We have done our best to minimize the
impact though.

> For example, if there could be some APPs which list images of both
> private and shared by depending on
> https://bugs.launchpad.net/glance/+bug/1394299 , the APPs will be
> broken after fixing it.
> Nova team faced such situation we expected the impact of the change
> was small but horizon was broken, then we reverted the change in the
> same dev cycle.

We really wanted to include this in our last beta release but the
Tempest test we're talking about right now prevented exactly that. We
might have been able to garner more information from users that way
but alas, we likely won't have time for users to adopt the changes,
provide us feedback, *and* give us time to revert if it does end up
being as disruptive as some are claiming it will be. (Honestly, I
think it'll probably end up being somewhere between where Brian and
others think it will be and where the QA team is claiming it will be.)

> Then Nova has now API microversions mechanism to avoid impacting to
> the existing APPs.

Right. Microversions do sometimes make changes like this better. That
said, microversioning would probably cause yet *more* confusion around
this change than a hard break would and would likely further introduce
security issues. A microversioned API here would (probably) map
"shared" and "private" in what we're proposing to "private" in what
already exists. That means someone continuing with the old version
could add members to a private image and there would *need* to be an
implicit conversion on the new side. This means someone could create
an image as "private" in our new version, switch to the old and
*force* it to be shared. That's all kinds of awful.

Microversions are great. But they're not a panacea. They would not
have helped us had we already had them. I would like Glance to add
them, but there's a vocal minority among our team that's opposed.

Moving past the microversioning conversation (that we've had far too
many times to date), it sounds like the tempest project still sees
itself as a sort of wiser and older sibling to other projects. Other
projects breaking their APIs (intentionally, to improve the user
experience) are then treated as if they're children and talked down
to, in each email on a topic. That's probably not at all the team's
intention, but that is absolutely how it feels on this side of the
conversation. (And as a reminder, intentions don't magically fix
things.) I'm surprised by this behaviour. It's not at all what I
expected from another project in OpenStack. I understand the QA team
feels as if it is defending some idealized user, but the reality is
that as of the last User Survey, *at least* 40% of users are *still*
using Kilo. If and when they upgrade, they'll be encountering far more
disruptive changes than tempest can prevent. Most are internal
implementation details that will require a whole lot more work to fix
for large clouds than fixing some API interactions.

In short, the Glance team is ready, willing, and able to own the
responsibility for any breakage this causes users and any
interoperability problems this will pose. We'd really appreciate
cooperation on this.

And besides "No one uses Glance" [ref:
http://lists.openstack.org/pipermail/openstack-dev/2013-February/005758.html]
;)

--
Ian Cordasco

___

Re: [openstack-dev] [glance][tempest][api] community images, tempest tests, and API stability

2017-01-12 Thread Brian Rosmaita 
(Top-posting, don't bother digging through for more.)

We're following the tempest HACKING.rst procedure.  The patch for step
#2 is: https://review.openstack.org/#/c/419658/

Please review at your earliest convenience.

thanks,
brian


On 1/12/17 3:34 PM, Brian Rosmaita wrote:
> Ken,
> 
> Thanks for the quick response ... we'll follow the procedure outlined in
> the tempest HACKING.rst that you pointed out.
> 
> cheers,
> brian
> 
> On 1/12/17 2:32 PM, Ken'ichi Ohmichi wrote:
>> 2017-01-12 5:47 GMT-08:00 Brian Rosmaita :
>>> On 1/11/17 10:35 PM, GHANSHYAM MANN wrote:
>>>
 But from meeting logs, it looks like impression was(if am not wrong) that
 Tempest test[1] is not doing the right thing and should be ok to change.
 I do not think this is the case, Tempest test is doing what API
 tells/behave. Below is what test does:
  1. Tenant A creates image with explicitly visibility as private.
  2. Tenant A add Tenant B as member of created image to allow Tenant B to
 use that.

 API [2] or Image sharing workflow [3] does not say/recommend anywhere that
 Image should not be created with private visibility as explicitly.

 For me this change breaks people "Creating Image with private visibility as
 *explicitly* and adding member to that" which will be 409 after glance
 proposal.


 Also changing tempest tests does not solve the problem, backward
 incompatible is still will be introduced in API.
>>>
>>> The issue is that we are proposing to introduce an incompatible change
>>> in order to address an incoherence with image visibility semantics.  We
>>> have acknowledged that this is a breaking change, but the impact of the
>>> change is mitigated by the way that the default visibility value is
>>> assigned in Ocata.
>>>
>>> As I've documented earlier in the thread, we have discussed this change
>>> with the wider community and the API Working Group, and they are OK with it.
>>>
>>> The current tempest test has done its duty and identified an
>>> incompatibility in the Ocata code.  We acknowledge that and salute you.
>>> On balance, however, this change will be better for users (and as I've
>>> documented earlier in the thread, we've minimized the impact of the
>>> change), and we want to make it anyway.
>>
>> It is difficult to expect the impact of API change is small by us as 
>> developers.
>> For example, if there could be some APPs which list images of both
>> private and shared by depending on
>> https://bugs.launchpad.net/glance/+bug/1394299 , the APPs will be
>> broken after fixing it.
>> Nova team faced such situation we expected the impact of the change
>> was small but horizon was broken, then we reverted the change in the
>> same dev cycle.
>> Then Nova has now API microversions mechanism to avoid impacting to
>> the existing APPs.
>>
>> This is on very difficult balance, and we don't want to block the
>> glance team development.
>> We have some procedure for this situation like
>> https://github.com/openstack/tempest/blob/master/HACKING.rst#2-bug-fix-on-core-project-needing-tempest-changes
>> I did put some comments on https://review.openstack.org/#/c/414261 .
>> Could you check that?
>>
>> Thanks
>> Ken Ohmichi
>>
>> ---
>>
>>> So the situation isn't that we are claiming that your current code is
>>> flawed.  Rather, it is that we are asking the QA team to approve a
>>> change to that test in order to address a change we are making in Ocata,
>>> a change that has the support of the OpenStack community.
>>>
>>> thanks,
>>> brian
>>>

 .. 1
 http://git.openstack.org/cgit/openstack/tempest/tree/tempest/api/image/v2/test_images.py#n338

 .. 2 http://developer.openstack.org/api-ref/image/v2/#create-an-image
 .. 3
 http://specs.openstack.org/openstack/glance-specs/specs/api/v2/sharing-image-api-v2.html


 Regards
 Ghanshyam Mann
 +818011120698


 On Mon, Jan 9, 2017 at 10:30 PM, Brian Rosmaita 
 
 wrote:

> On 1/5/17 10:19 AM, Brian Rosmaita wrote:
>> To anyone interested in this discussion: I put it on the agenda for
>> today's API-WG meeting (16:00 UTC):
>>
>> https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
>
> As you probably noticed in the API-WG newsletter [A], this issue was
> discussed at last week's API-WG meeting.  The complete discussion is in
> the meeting log [B], but the tldr; is that the proposed change is
> acceptable.  I'll address specific points inline for those who are
> interested, but the key request from the Glance team right now is that
> the QA team approve this patch:
>
> https://review.openstack.org/#/c/414261/
>
>
> [A]
> http://lists.openstack.org/pipermail/openstack-dev/2017-
> January/109698.html
> [B]
> http://eavesdrop.openstack.org/meetings/api_wg/2017/api_
> wg.2017-01-05-16.00.log.html

Re: [openstack-dev] [glance][tempest][api] community images, tempest tests, and API stability

2017-01-12 Thread GHANSHYAM MANN 
On Fri, Jan 13, 2017 at 4:32 AM, Ken'ichi Ohmichi 
wrote:

> 2017-01-12 5:47 GMT-08:00 Brian Rosmaita :
> > On 1/11/17 10:35 PM, GHANSHYAM MANN wrote:
> >
> >> But from meeting logs, it looks like impression was(if am not wrong)
> that
> >> Tempest test[1] is not doing the right thing and should be ok to change.
> >> I do not think this is the case, Tempest test is doing what API
> >> tells/behave. Below is what test does:
> >>  1. Tenant A creates image with explicitly visibility as private.
> >>  2. Tenant A add Tenant B as member of created image to allow Tenant B
> to
> >> use that.
> >>
> >> API [2] or Image sharing workflow [3] does not say/recommend anywhere
> that
> >> Image should not be created with private visibility as explicitly.
> >>
> >> For me this change breaks people "Creating Image with private
> visibility as
> >> *explicitly* and adding member to that" which will be 409 after glance
> >> proposal.
> >>
> >>
> >> Also changing tempest tests does not solve the problem, backward
> >> incompatible is still will be introduced in API.
> >
> > The issue is that we are proposing to introduce an incompatible change
> > in order to address an incoherence with image visibility semantics.  We
> > have acknowledged that this is a breaking change, but the impact of the
> > change is mitigated by the way that the default visibility value is
> > assigned in Ocata.
>

​I am totally agree that the proposed way is really nice improvement but we
should not compensate
the​ breaking change in that. What ever API we provided we have to live
with those until unless it is bug fix.
Improvement in software and mainly APIs are always welcome but they should
not break the users and should be done in versioned way.

The problem here I see is that Glance does not provide any way for users to
discover or pin cloud on what version they want or what they do not. Glance
v2 always default to latest version so all users automatically gets into
the latest changes irrespective of it breaks them and they do not want.

We really do not want to block that visibility improvement proposal but it
should not break users.



> >
> > As I've documented earlier in the thread, we have discussed this change
> > with the wider community and the API Working Group, and they are OK with
> it.
>
​But API-wg guidelines clearly states that below is not acceptable [1]

   - A change such that a request which was successful before now results
   in an error response (unless the success reported previously was hiding an
   existing error condition).

.. 1
https://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html
 ​



> >
> > The current tempest test has done its duty and identified an
> > incompatibility in the Ocata code.  We acknowledge that and salute you.
> > On balance, however, this change will be better for users (and as I've
> > documented earlier in the thread, we've minimized the impact of the
> > change), and we want to make it anyway.
>
> It is difficult to expect the impact of API change is small by us as
> developers.
> For example, if there could be some APPs which list images of both
> private and shared by depending on
> https://bugs.launchpad.net/glance/+bug/1394299 , the APPs will be
> broken after fixing it.
> Nova team faced such situation we expected the impact of the change
> was small but horizon was broken, then we reverted the change in the
> same dev cycle.
> Then Nova has now API microversions mechanism to avoid impacting to
> the existing APPs.
>
> ​+1, microversion is a nice solution for that problem. ​



> This is on very difficult balance, and we don't want to block the
> glance team development.
> We have some procedure for this situation like
> https://github.com/openstack/tempest/blob/master/HACKING.
> rst#2-bug-fix-on-core-project-needing-tempest-changes
> I did put some comments on https://review.openstack.org/#/c/414261 .
> Could you check that?
>
> Thanks
> Ken Ohmichi
>
> ---
>
> > So the situation isn't that we are claiming that your current code is
> > flawed.  Rather, it is that we are asking the QA team to approve a
> > change to that test in order to address a change we are making in Ocata,
> > a change that has the support of the OpenStack community.
> >
> > thanks,
> > brian
> >
> >>
> >> .. 1
> >> http://git.openstack.org/cgit/openstack/tempest/tree/
> tempest/api/image/v2/test_images.py#n338
> >>
> >> .. 2 http://developer.openstack.org/api-ref/image/v2/#create-an-image
> >> .. 3
> >> http://specs.openstack.org/openstack/glance-specs/specs/
> api/v2/sharing-image-api-v2.html
> >>
> >>
> >> Regards
> >> Ghanshyam Mann
> >> +818011120698
> >>
> >>
> >> On Mon, Jan 9, 2017 at 10:30 PM, Brian Rosmaita <
> rosmaita.foss...@gmail.com>
> >> wrote:
> >>
> >>> On 1/5/17 10:19 AM, Brian Rosmaita wrote:
>  To anyone interested in this discussion: I put it on the agenda for
>  today's API-WG meeting (16:00 UTC):
> 
>

Re: [openstack-dev] [glance][tempest][api] community images, tempest tests, and API stability

2017-01-12 Thread Brian Rosmaita 
Ken,

Thanks for the quick response ... we'll follow the procedure outlined in
the tempest HACKING.rst that you pointed out.

cheers,
brian

On 1/12/17 2:32 PM, Ken'ichi Ohmichi wrote:
> 2017-01-12 5:47 GMT-08:00 Brian Rosmaita :
>> On 1/11/17 10:35 PM, GHANSHYAM MANN wrote:
>>
>>> But from meeting logs, it looks like impression was(if am not wrong) that
>>> Tempest test[1] is not doing the right thing and should be ok to change.
>>> I do not think this is the case, Tempest test is doing what API
>>> tells/behave. Below is what test does:
>>>  1. Tenant A creates image with explicitly visibility as private.
>>>  2. Tenant A add Tenant B as member of created image to allow Tenant B to
>>> use that.
>>>
>>> API [2] or Image sharing workflow [3] does not say/recommend anywhere that
>>> Image should not be created with private visibility as explicitly.
>>>
>>> For me this change breaks people "Creating Image with private visibility as
>>> *explicitly* and adding member to that" which will be 409 after glance
>>> proposal.
>>>
>>>
>>> Also changing tempest tests does not solve the problem, backward
>>> incompatible is still will be introduced in API.
>>
>> The issue is that we are proposing to introduce an incompatible change
>> in order to address an incoherence with image visibility semantics.  We
>> have acknowledged that this is a breaking change, but the impact of the
>> change is mitigated by the way that the default visibility value is
>> assigned in Ocata.
>>
>> As I've documented earlier in the thread, we have discussed this change
>> with the wider community and the API Working Group, and they are OK with it.
>>
>> The current tempest test has done its duty and identified an
>> incompatibility in the Ocata code.  We acknowledge that and salute you.
>> On balance, however, this change will be better for users (and as I've
>> documented earlier in the thread, we've minimized the impact of the
>> change), and we want to make it anyway.
> 
> It is difficult to expect the impact of API change is small by us as 
> developers.
> For example, if there could be some APPs which list images of both
> private and shared by depending on
> https://bugs.launchpad.net/glance/+bug/1394299 , the APPs will be
> broken after fixing it.
> Nova team faced such situation we expected the impact of the change
> was small but horizon was broken, then we reverted the change in the
> same dev cycle.
> Then Nova has now API microversions mechanism to avoid impacting to
> the existing APPs.
> 
> This is on very difficult balance, and we don't want to block the
> glance team development.
> We have some procedure for this situation like
> https://github.com/openstack/tempest/blob/master/HACKING.rst#2-bug-fix-on-core-project-needing-tempest-changes
> I did put some comments on https://review.openstack.org/#/c/414261 .
> Could you check that?
> 
> Thanks
> Ken Ohmichi
> 
> ---
> 
>> So the situation isn't that we are claiming that your current code is
>> flawed.  Rather, it is that we are asking the QA team to approve a
>> change to that test in order to address a change we are making in Ocata,
>> a change that has the support of the OpenStack community.
>>
>> thanks,
>> brian
>>
>>>
>>> .. 1
>>> http://git.openstack.org/cgit/openstack/tempest/tree/tempest/api/image/v2/test_images.py#n338
>>>
>>> .. 2 http://developer.openstack.org/api-ref/image/v2/#create-an-image
>>> .. 3
>>> http://specs.openstack.org/openstack/glance-specs/specs/api/v2/sharing-image-api-v2.html
>>>
>>>
>>> Regards
>>> Ghanshyam Mann
>>> +818011120698
>>>
>>>
>>> On Mon, Jan 9, 2017 at 10:30 PM, Brian Rosmaita 
>>> wrote:
>>>
 On 1/5/17 10:19 AM, Brian Rosmaita wrote:
> To anyone interested in this discussion: I put it on the agenda for
> today's API-WG meeting (16:00 UTC):
>
> https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda

 As you probably noticed in the API-WG newsletter [A], this issue was
 discussed at last week's API-WG meeting.  The complete discussion is in
 the meeting log [B], but the tldr; is that the proposed change is
 acceptable.  I'll address specific points inline for those who are
 interested, but the key request from the Glance team right now is that
 the QA team approve this patch:

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


 [A]
 http://lists.openstack.org/pipermail/openstack-dev/2017-
 January/109698.html
 [B]
 http://eavesdrop.openstack.org/meetings/api_wg/2017/api_
 wg.2017-01-05-16.00.log.html

> On 12/25/16 12:04 PM, GHANSHYAM MANN wrote:
>> Thanks Brian for bringing this up, same we been discussing last week on
 QA
>> channel and this patch[1] but I completely agree with Matthew opinion
 here.
>> There is no doubt that this change(4-valued) are much better and clear
 than
>> old one. This makes much defined and clear way of defining the image
>>

Re: [openstack-dev] [glance][tempest][api] community images, tempest tests, and API stability

2017-01-12 Thread Ken'ichi Ohmichi 
2017-01-12 5:47 GMT-08:00 Brian Rosmaita :
> On 1/11/17 10:35 PM, GHANSHYAM MANN wrote:
>
>> But from meeting logs, it looks like impression was(if am not wrong) that
>> Tempest test[1] is not doing the right thing and should be ok to change.
>> I do not think this is the case, Tempest test is doing what API
>> tells/behave. Below is what test does:
>>  1. Tenant A creates image with explicitly visibility as private.
>>  2. Tenant A add Tenant B as member of created image to allow Tenant B to
>> use that.
>>
>> API [2] or Image sharing workflow [3] does not say/recommend anywhere that
>> Image should not be created with private visibility as explicitly.
>>
>> For me this change breaks people "Creating Image with private visibility as
>> *explicitly* and adding member to that" which will be 409 after glance
>> proposal.
>>
>>
>> Also changing tempest tests does not solve the problem, backward
>> incompatible is still will be introduced in API.
>
> The issue is that we are proposing to introduce an incompatible change
> in order to address an incoherence with image visibility semantics.  We
> have acknowledged that this is a breaking change, but the impact of the
> change is mitigated by the way that the default visibility value is
> assigned in Ocata.
>
> As I've documented earlier in the thread, we have discussed this change
> with the wider community and the API Working Group, and they are OK with it.
>
> The current tempest test has done its duty and identified an
> incompatibility in the Ocata code.  We acknowledge that and salute you.
> On balance, however, this change will be better for users (and as I've
> documented earlier in the thread, we've minimized the impact of the
> change), and we want to make it anyway.

It is difficult to expect the impact of API change is small by us as developers.
For example, if there could be some APPs which list images of both
private and shared by depending on
https://bugs.launchpad.net/glance/+bug/1394299 , the APPs will be
broken after fixing it.
Nova team faced such situation we expected the impact of the change
was small but horizon was broken, then we reverted the change in the
same dev cycle.
Then Nova has now API microversions mechanism to avoid impacting to
the existing APPs.

This is on very difficult balance, and we don't want to block the
glance team development.
We have some procedure for this situation like
https://github.com/openstack/tempest/blob/master/HACKING.rst#2-bug-fix-on-core-project-needing-tempest-changes
I did put some comments on https://review.openstack.org/#/c/414261 .
Could you check that?

Thanks
Ken Ohmichi

---

> So the situation isn't that we are claiming that your current code is
> flawed.  Rather, it is that we are asking the QA team to approve a
> change to that test in order to address a change we are making in Ocata,
> a change that has the support of the OpenStack community.
>
> thanks,
> brian
>
>>
>> .. 1
>> http://git.openstack.org/cgit/openstack/tempest/tree/tempest/api/image/v2/test_images.py#n338
>>
>> .. 2 http://developer.openstack.org/api-ref/image/v2/#create-an-image
>> .. 3
>> http://specs.openstack.org/openstack/glance-specs/specs/api/v2/sharing-image-api-v2.html
>>
>>
>> Regards
>> Ghanshyam Mann
>> +818011120698
>>
>>
>> On Mon, Jan 9, 2017 at 10:30 PM, Brian Rosmaita 
>> wrote:
>>
>>> On 1/5/17 10:19 AM, Brian Rosmaita wrote:
 To anyone interested in this discussion: I put it on the agenda for
 today's API-WG meeting (16:00 UTC):

 https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
>>>
>>> As you probably noticed in the API-WG newsletter [A], this issue was
>>> discussed at last week's API-WG meeting.  The complete discussion is in
>>> the meeting log [B], but the tldr; is that the proposed change is
>>> acceptable.  I'll address specific points inline for those who are
>>> interested, but the key request from the Glance team right now is that
>>> the QA team approve this patch:
>>>
>>> https://review.openstack.org/#/c/414261/
>>>
>>>
>>> [A]
>>> http://lists.openstack.org/pipermail/openstack-dev/2017-
>>> January/109698.html
>>> [B]
>>> http://eavesdrop.openstack.org/meetings/api_wg/2017/api_
>>> wg.2017-01-05-16.00.log.html
>>>
 On 12/25/16 12:04 PM, GHANSHYAM MANN wrote:
> Thanks Brian for bringing this up, same we been discussing last week on
>>> QA
> channel and this patch[1] but I completely agree with Matthew opinion
>>> here.
> There is no doubt that this change(4-valued) are much better and clear
>>> than
> old one. This makes much defined and clear way of defining the image
> visibility by/for operator/user.
>>>
>>> Yes, we think that the change clarifies the visibility semantics of
>>> images and, in particular, fixes the problem of there being "private"
>>> images that aren't actually private.
>>>
>>> The current situation is easily misunderstood by end users, as evidenced
>>> by bugs that have been

Re: [openstack-dev] [glance][tempest][api] community images, tempest tests, and API stability

2017-01-12 Thread Brian Rosmaita 
On 1/11/17 10:35 PM, GHANSHYAM MANN wrote:
> Sorry I could not attend meeting due to TZ.

I wound up missing the meeting, too; I thought it was at 17:00 UTC.

> But from meeting logs, it looks like impression was(if am not wrong) that
> Tempest test[1] is not doing the right thing and should be ok to change.
> I do not think this is the case, Tempest test is doing what API
> tells/behave. Below is what test does:
>  1. Tenant A creates image with explicitly visibility as private.
>  2. Tenant A add Tenant B as member of created image to allow Tenant B to
> use that.
> 
> API [2] or Image sharing workflow [3] does not say/recommend anywhere that
> Image should not be created with private visibility as explicitly.
> 
> For me this change breaks people "Creating Image with private visibility as
> *explicitly* and adding member to that" which will be 409 after glance
> proposal.
>
> 
> Also changing tempest tests does not solve the problem, backward
> incompatible is still will be introduced in API.

The issue is that we are proposing to introduce an incompatible change
in order to address an incoherence with image visibility semantics.  We
have acknowledged that this is a breaking change, but the impact of the
change is mitigated by the way that the default visibility value is
assigned in Ocata.

As I've documented earlier in the thread, we have discussed this change
with the wider community and the API Working Group, and they are OK with it.

The current tempest test has done its duty and identified an
incompatibility in the Ocata code.  We acknowledge that and salute you.
On balance, however, this change will be better for users (and as I've
documented earlier in the thread, we've minimized the impact of the
change), and we want to make it anyway.

So the situation isn't that we are claiming that your current code is
flawed.  Rather, it is that we are asking the QA team to approve a
change to that test in order to address a change we are making in Ocata,
a change that has the support of the OpenStack community.

thanks,
brian

> 
> .. 1
> http://git.openstack.org/cgit/openstack/tempest/tree/tempest/api/image/v2/test_images.py#n338
> 
> .. 2 http://developer.openstack.org/api-ref/image/v2/#create-an-image
> .. 3
> http://specs.openstack.org/openstack/glance-specs/specs/api/v2/sharing-image-api-v2.html
> 
> 
> Regards
> Ghanshyam Mann
> +818011120698
>
> 
> On Mon, Jan 9, 2017 at 10:30 PM, Brian Rosmaita 
> wrote:
> 
>> On 1/5/17 10:19 AM, Brian Rosmaita wrote:
>>> To anyone interested in this discussion: I put it on the agenda for
>>> today's API-WG meeting (16:00 UTC):
>>>
>>> https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
>>
>> As you probably noticed in the API-WG newsletter [A], this issue was
>> discussed at last week's API-WG meeting.  The complete discussion is in
>> the meeting log [B], but the tldr; is that the proposed change is
>> acceptable.  I'll address specific points inline for those who are
>> interested, but the key request from the Glance team right now is that
>> the QA team approve this patch:
>>
>> https://review.openstack.org/#/c/414261/
>>
>>
>> [A]
>> http://lists.openstack.org/pipermail/openstack-dev/2017-
>> January/109698.html
>> [B]
>> http://eavesdrop.openstack.org/meetings/api_wg/2017/api_
>> wg.2017-01-05-16.00.log.html
>>
>>> On 12/25/16 12:04 PM, GHANSHYAM MANN wrote:
 Thanks Brian for bringing this up, same we been discussing last week on
>> QA
 channel and this patch[1] but I completely agree with Matthew opinion
>> here.
 There is no doubt that this change(4-valued) are much better and clear
>> than
 old one. This makes much defined and clear way of defining the image
 visibility by/for operator/user.
>>
>> Yes, we think that the change clarifies the visibility semantics of
>> images and, in particular, fixes the problem of there being "private"
>> images that aren't actually private.
>>
>> The current situation is easily misunderstood by end users, as evidenced
>> by bugs that have been filed, for example,
>> https://bugs.launchpad.net/glance/+bug/1394299
>> https://bugs.launchpad.net/glance/+bug/1452443
>>
 Upgrade procedure defined in all referenced ML/spec looks fine for
 redefining the visibility for images with or without members to
 shared/private. Operator feedback/acceptance for this change makes it
 acceptable.
>>
>> Thanks, we discussed this thoroughly and solicited operator feedback.
>>
 But operator/users creating images with visibility as "private"
 *explicitly*, this changes is going to break them:

 - Images with member already added in that would not
>> works
 as Tempest tests does [2].

 - They cannot add member as they used to do that.
>>
>> Yes, we recognize that this change will introduce an incompatibility in
>> the workflow for users who are setting visibility explicitly to
>> 'private' upon image creation.  The

Re: [openstack-dev] [glance][tempest][api] community images, tempest tests, and API stability

2017-01-11 Thread GHANSHYAM MANN 
Sorry I could not attend meeting due to TZ.

But from meeting logs, it looks like impression was(if am not wrong) that
Tempest test[1] is not doing the right thing and should be ok to change.
I do not think this is the case, Tempest test is doing what API
tells/behave. Below is what test does:
 1. Tenant A creates image with explicitly visibility as private.
 2. Tenant A add Tenant B as member of created image to allow Tenant B to
use that.

API [2] or Image sharing workflow [3] does not say/recommend anywhere that
Image should not be created with private visibility as explicitly.

For me this change breaks people "Creating Image with private visibility as
*explicitly* and adding member to that" which will be 409 after glance
proposal.

Also changing tempest tests does not solve the problem, backward
incompatible is still will be introduced in API.

.. 1
http://git.openstack.org/cgit/openstack/tempest/tree/tempest/api/image/v2/test_images.py#n338

.. 2 http://developer.openstack.org/api-ref/image/v2/#create-an-image
.. 3
http://specs.openstack.org/openstack/glance-specs/specs/api/v2/sharing-image-api-v2.html


Regards
Ghanshyam Mann
+818011120698

On Mon, Jan 9, 2017 at 10:30 PM, Brian Rosmaita 
wrote:

> On 1/5/17 10:19 AM, Brian Rosmaita wrote:
> > To anyone interested in this discussion: I put it on the agenda for
> > today's API-WG meeting (16:00 UTC):
> >
> > https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
>
> As you probably noticed in the API-WG newsletter [A], this issue was
> discussed at last week's API-WG meeting.  The complete discussion is in
> the meeting log [B], but the tldr; is that the proposed change is
> acceptable.  I'll address specific points inline for those who are
> interested, but the key request from the Glance team right now is that
> the QA team approve this patch:
>
> https://review.openstack.org/#/c/414261/
>
>
> [A]
> http://lists.openstack.org/pipermail/openstack-dev/2017-
> January/109698.html
> [B]
> http://eavesdrop.openstack.org/meetings/api_wg/2017/api_
> wg.2017-01-05-16.00.log.html
>
> > On 12/25/16 12:04 PM, GHANSHYAM MANN wrote:
> >> Thanks Brian for bringing this up, same we been discussing last week on
> QA
> >> channel and this patch[1] but I completely agree with Matthew opinion
> here.
> >> There is no doubt that this change(4-valued) are much better and clear
> than
> >> old one. This makes much defined and clear way of defining the image
> >> visibility by/for operator/user.
>
> Yes, we think that the change clarifies the visibility semantics of
> images and, in particular, fixes the problem of there being "private"
> images that aren't actually private.
>
> The current situation is easily misunderstood by end users, as evidenced
> by bugs that have been filed, for example,
> https://bugs.launchpad.net/glance/+bug/1394299
> https://bugs.launchpad.net/glance/+bug/1452443
>
> >> Upgrade procedure defined in all referenced ML/spec looks fine for
> >> redefining the visibility for images with or without members to
> >> shared/private. Operator feedback/acceptance for this change makes it
> >> acceptable.
>
> Thanks, we discussed this thoroughly and solicited operator feedback.
>
> >> But operator/users creating images with visibility as "private"
> >> *explicitly*, this changes is going to break them:
> >>
> >> - Images with member already added in that would not
> works
> >> as Tempest tests does [2].
> >>
> >> - They cannot add member as they used to do that.
>
> Yes, we recognize that this change will introduce an incompatibility in
> the workflow for users who are setting visibility explicitly to
> 'private' upon image creation.  The positive side to this change,
> however, is that when a user requests a private image, that's what
> they'll get.  It's important to note that the default visibility value
> will allow the current create-and-immediately-share workflow to continue
> exactly as it does now.
>
> One way to see how small this change is in context is to look at how it
> will appear in release notes:
>
> https://etherpad.openstack.org/p/glance-ocata-sharing-release-note-draft
>
> The incompatibility you're worried about is explained at line 8.
>
> >> First one is being something tested by Tempest and which is valid tests
> as
> >> per current behaviour of API
> >>
> >> There might be lot of operators will be doing the same and going to be
> >> broken after this. We really need to think about this change as API
> >> backward incompatible pov where upgrade Cloud with new visibility
> >> definition is all ok but it break the way of usage(Image of Private
> >> visibility explicitly with added members).
>
> It's possible that some scripts will break, but it's important to note
> that the default visibility upon image creation will allow the current
> workflow to succeed.  While that's small consolation to those whose
> scripts may break, the plus side is that image visibility changes will

Re: [openstack-dev] [glance][tempest][api] community images, tempest tests, and API stability

2017-01-09 Thread Brian Rosmaita 
On 1/5/17 10:19 AM, Brian Rosmaita wrote:
> To anyone interested in this discussion: I put it on the agenda for
> today's API-WG meeting (16:00 UTC):
> 
> https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda

As you probably noticed in the API-WG newsletter [A], this issue was
discussed at last week's API-WG meeting.  The complete discussion is in
the meeting log [B], but the tldr; is that the proposed change is
acceptable.  I'll address specific points inline for those who are
interested, but the key request from the Glance team right now is that
the QA team approve this patch:

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


[A]
http://lists.openstack.org/pipermail/openstack-dev/2017-January/109698.html
[B]
http://eavesdrop.openstack.org/meetings/api_wg/2017/api_wg.2017-01-05-16.00.log.html

> On 12/25/16 12:04 PM, GHANSHYAM MANN wrote:
>> Thanks Brian for bringing this up, same we been discussing last week on QA
>> channel and this patch[1] but I completely agree with Matthew opinion here.
>> There is no doubt that this change(4-valued) are much better and clear than
>> old one. This makes much defined and clear way of defining the image
>> visibility by/for operator/user.

Yes, we think that the change clarifies the visibility semantics of
images and, in particular, fixes the problem of there being "private"
images that aren't actually private.

The current situation is easily misunderstood by end users, as evidenced
by bugs that have been filed, for example,
https://bugs.launchpad.net/glance/+bug/1394299
https://bugs.launchpad.net/glance/+bug/1452443

>> Upgrade procedure defined in all referenced ML/spec looks fine for
>> redefining the visibility for images with or without members to
>> shared/private. Operator feedback/acceptance for this change makes it
>> acceptable.

Thanks, we discussed this thoroughly and solicited operator feedback.

>> But operator/users creating images with visibility as "private"
>> *explicitly*, this changes is going to break them:
>>
>> - Images with member already added in that would not works
>> as Tempest tests does [2].
>>
>> - They cannot add member as they used to do that.

Yes, we recognize that this change will introduce an incompatibility in
the workflow for users who are setting visibility explicitly to
'private' upon image creation.  The positive side to this change,
however, is that when a user requests a private image, that's what
they'll get.  It's important to note that the default visibility value
will allow the current create-and-immediately-share workflow to continue
exactly as it does now.

One way to see how small this change is in context is to look at how it
will appear in release notes:

https://etherpad.openstack.org/p/glance-ocata-sharing-release-note-draft

The incompatibility you're worried about is explained at line 8.

>> First one is being something tested by Tempest and which is valid tests as
>> per current behaviour of API
>>
>> There might be lot of operators will be doing the same and going to be
>> broken after this. We really need to think about this change as API
>> backward incompatible pov where upgrade Cloud with new visibility
>> definition is all ok but it break the way of usage(Image of Private
>> visibility explicitly with added members).

It's possible that some scripts will break, but it's important to note
that the default visibility upon image creation will allow the current
workflow to succeed.  While that's small consolation to those whose
scripts may break, the plus side is that image visibility changes will
now occur in a uniform way for all visibility values with no "magic"
changes occurring as a side effect of a different API call.

>> After looking into glance API versioning mechanism, it seems /v2 points to
>> latest version irrespective of version includes backward compatible or
>> incompatible changes. I mean users cannot lock API on old version (say they
>> want only v2.2). How glance introduced backward incompatible changes?
>>
>> I am not sure why it is not done like api-wg suggested microversion way
>> (like nova). I know glance API versioning is much older but when there are
>> some better improvement coming like this community image change, I feel it
>> should be done with backward compatible way in microversion.

Not everyone in the Glance community is on board with the microversion
movement.  But also, I'm not convinced that microversions would be an
acceptable solution to this situation.  From Ocata on, we want 'private'
to mean "private"; users have to take an extra step to update the
visibility to 'shared' before an image will accept members.  I don't
think a user who expects that behavior will appreciate a pre-Ocata
client that can bypass this safety mechanism and simply add members to
private images.

>> Tempest testing the old behaviour is something very valid here and we
>> should not change that to introduced backward incompatible changes which
>> going to break

Re: [openstack-dev] [glance][tempest][api] community images, tempest tests, and API stability

2017-01-05 Thread Brian Rosmaita 
To anyone interested in this discussion: I put it on the agenda for
today's API-WG meeting (16:00 UTC):

https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda


On 12/25/16 12:04 PM, GHANSHYAM MANN wrote:
> Thanks Brian for bringing this up, same we been discussing last week on QA
> channel and this patch[1] but I completely agree with Matthew opinion here.
> There is no doubt that this change(4-valued) are much better and clear than
> old one. This makes much defined and clear way of defining the image
> visibility by/for operator/user.
> 
> Upgrade procedure defined in all referenced ML/spec looks fine for
> redefining the visibility for images with or without members to
> shared/private. Operator feedback/acceptance for this change makes it
> acceptable.
> 
> But operator/users creating images with visibility as "private"
> *explicitly*, this changes is going to break them:
> 
> - Images with member already added in that would not works
> as Tempest tests does [2].
> 
> - They cannot add member as they used to do that.
> 
> First one is being something tested by Tempest and which is valid tests as
> per current behaviour of API
> 
> There might be lot of operators will be doing the same and going to be
> broken after this. We really need to think about this change as API
> backward incompatible pov where upgrade Cloud with new visibility
> definition is all ok but it break the way of usage(Image of Private
> visibility explicitly with added members).
> 
> After looking into glance API versioning mechanism, it seems /v2 points to
> latest version irrespective of version includes backward compatible or
> incompatible changes. I mean users cannot lock API on old version (say they
> want only v2.2). How glance introduced backward incompatible changes?
> 
> I am not sure why it is not done like api-wg suggested microversion way
> (like nova). I know glance API versioning is much older but when there are
> some better improvement coming like this community image change, I feel it
> should be done with backward compatible way in microversion.
> 
> Tempest testing the old behaviour is something very valid here and we
> should not change that to introduced backward incompatible changes which
> going to break cloud.
> 
> .. [1] https://review.openstack.org/#/c/412731/
> 
> .. [2]
> https://github.com/openstack/tempest/blob/master/tempest/api/image/v2/test_images.py#L339
> 
> ​-gmann
> 
> On Fri, Dec 23, 2016 at 5:51 AM, Matthew Treinish 
> wrote:
> 
>> On Thu, Dec 22, 2016 at 02:57:20PM -0500, Brian Rosmaita wrote:
>>> Something has come up with a tempest test for Glance and the community
>>> images implementation, and I think it could use some mailing list
>>> discussion, as everyone might not be aware of the patch where the
>>> discussion is happening now [1].
>>>
>>> First, the Glance background, to get everyone on the same page:
>>>
>>> As part of implementing community images [2], the 'visibility' field of
>>> an image is going from being 2-valued to being 4-valued.  Up to now, the
>>> only values have been 'private' and 'public', which meant that shared
>>> images were 'private', which was inaccurate and confusing (and bugs were
>>> filed with Glance about shared images not having visibility 'shared'
>>> [3a,b]).
>>>
>>> With the new visibility enum, the Images API v2 will behave as follows:
>>>
>>> * An image with visibility == 'private' is not shared, and is not
>>> shareable until its visibility is changed to 'shared'.
>>>
>>> * An image must have visibility == 'shared' in order to do member
>>> operations or be accessible to image members.
>>>
>>> * The default visibility of a freshly-created image is 'shared'.  This
>>> may seem weird, but a freshly-created image has no members, so it's
>>> effectively private, behaving exactly as a freshly-created image does,
>>> pre-Ocata.  It's also ready to immediately accept a member-create call,
>>> as freshly-created images are pre-Ocata.  So from a workflow
>>> perspective, this change is backward compatible.
>>>
>>> * After much discussion [4], including discussion with operators and an
>>> operator's survey [5], we decided that the correct migration of
>>> 'visibility' values for existing images when a cloud is updated would
>>> be: public images stay 'public', private images with members become
>>> 'shared', and private images without images stay 'private'.  (Thus, if
>>> you have a 'private' image, you'll have to change it to 'shared' before
>>> you can add members.  On the other hand, now it's *really* private.)
>>>
>>> * You can specify a visibility at the time of image-creation, as you can
>>> now.  But if you specify 'private', what you get is *really* private.
>>> This either introduces a minor backward incompatibility, or it fixes a
>>> bug, depending on how you look at it.  The key thing is, if you *don't*
>>> specify a visibility, an image with the default visibility will behave
>>> exactly as

Re: [openstack-dev] [glance][tempest][api] community images, tempest tests, and API stability

2016-12-25 Thread GHANSHYAM MANN 
Thanks Brian for bringing this up, same we been discussing last week on QA
channel and this patch[1] but I completely agree with Matthew opinion here.
There is no doubt that this change(4-valued) are much better and clear than
old one. This makes much defined and clear way of defining the image
visibility by/for operator/user.

Upgrade procedure defined in all referenced ML/spec looks fine for
redefining the visibility for images with or without members to
shared/private. Operator feedback/acceptance for this change makes it
acceptable.

But operator/users creating images with visibility as "private"
*explicitly*, this changes is going to break them:

- Images with member already added in that would not works
as Tempest tests does [2].

- They cannot add member as they used to do that.

First one is being something tested by Tempest and which is valid tests as
per current behaviour of API

There might be lot of operators will be doing the same and going to be
broken after this. We really need to think about this change as API
backward incompatible pov where upgrade Cloud with new visibility
definition is all ok but it break the way of usage(Image of Private
visibility explicitly with added members).

After looking into glance API versioning mechanism, it seems /v2 points to
latest version irrespective of version includes backward compatible or
incompatible changes. I mean users cannot lock API on old version (say they
want only v2.2). How glance introduced backward incompatible changes?

I am not sure why it is not done like api-wg suggested microversion way
(like nova). I know glance API versioning is much older but when there are
some better improvement coming like this community image change, I feel it
should be done with backward compatible way in microversion.

Tempest testing the old behaviour is something very valid here and we
should not change that to introduced backward incompatible changes which
going to break cloud.

.. [1] https://review.openstack.org/#/c/412731/

.. [2]
https://github.com/openstack/tempest/blob/master/tempest/api/image/v2/test_images.py#L339

​-gmann

On Fri, Dec 23, 2016 at 5:51 AM, Matthew Treinish 
wrote:

> On Thu, Dec 22, 2016 at 02:57:20PM -0500, Brian Rosmaita wrote:
> > Something has come up with a tempest test for Glance and the community
> > images implementation, and I think it could use some mailing list
> > discussion, as everyone might not be aware of the patch where the
> > discussion is happening now [1].
> >
> > First, the Glance background, to get everyone on the same page:
> >
> > As part of implementing community images [2], the 'visibility' field of
> > an image is going from being 2-valued to being 4-valued.  Up to now, the
> > only values have been 'private' and 'public', which meant that shared
> > images were 'private', which was inaccurate and confusing (and bugs were
> > filed with Glance about shared images not having visibility 'shared'
> > [3a,b]).
> >
> > With the new visibility enum, the Images API v2 will behave as follows:
> >
> > * An image with visibility == 'private' is not shared, and is not
> > shareable until its visibility is changed to 'shared'.
> >
> > * An image must have visibility == 'shared' in order to do member
> > operations or be accessible to image members.
> >
> > * The default visibility of a freshly-created image is 'shared'.  This
> > may seem weird, but a freshly-created image has no members, so it's
> > effectively private, behaving exactly as a freshly-created image does,
> > pre-Ocata.  It's also ready to immediately accept a member-create call,
> > as freshly-created images are pre-Ocata.  So from a workflow
> > perspective, this change is backward compatible.
> >
> > * After much discussion [4], including discussion with operators and an
> > operator's survey [5], we decided that the correct migration of
> > 'visibility' values for existing images when a cloud is updated would
> > be: public images stay 'public', private images with members become
> > 'shared', and private images without images stay 'private'.  (Thus, if
> > you have a 'private' image, you'll have to change it to 'shared' before
> > you can add members.  On the other hand, now it's *really* private.)
> >
> > * You can specify a visibility at the time of image-creation, as you can
> > now.  But if you specify 'private', what you get is *really* private.
> > This either introduces a minor backward incompatibility, or it fixes a
> > bug, depending on how you look at it.  The key thing is, if you *don't*
> > specify a visibility, an image with the default visibility will behave
> > exactly as it does now, from the perspective of being able to make API
> > calls on it (e.g., adding members).
> >
> > Thanks for reading this far.  (There's a much more detailed discussion
> > in the spec; see the "Other end user impact" section. [2])  Here's the
> > point of this email:
> >
> > The community images

Re: [openstack-dev] [glance][tempest][api] community images, tempest tests, and API stability

2016-12-22 Thread Matthew Treinish 
On Thu, Dec 22, 2016 at 02:57:20PM -0500, Brian Rosmaita wrote:
> Something has come up with a tempest test for Glance and the community
> images implementation, and I think it could use some mailing list
> discussion, as everyone might not be aware of the patch where the
> discussion is happening now [1].
> 
> First, the Glance background, to get everyone on the same page:
> 
> As part of implementing community images [2], the 'visibility' field of
> an image is going from being 2-valued to being 4-valued.  Up to now, the
> only values have been 'private' and 'public', which meant that shared
> images were 'private', which was inaccurate and confusing (and bugs were
> filed with Glance about shared images not having visibility 'shared'
> [3a,b]).
> 
> With the new visibility enum, the Images API v2 will behave as follows:
> 
> * An image with visibility == 'private' is not shared, and is not
> shareable until its visibility is changed to 'shared'.
> 
> * An image must have visibility == 'shared' in order to do member
> operations or be accessible to image members.
> 
> * The default visibility of a freshly-created image is 'shared'.  This
> may seem weird, but a freshly-created image has no members, so it's
> effectively private, behaving exactly as a freshly-created image does,
> pre-Ocata.  It's also ready to immediately accept a member-create call,
> as freshly-created images are pre-Ocata.  So from a workflow
> perspective, this change is backward compatible.
> 
> * After much discussion [4], including discussion with operators and an
> operator's survey [5], we decided that the correct migration of
> 'visibility' values for existing images when a cloud is updated would
> be: public images stay 'public', private images with members become
> 'shared', and private images without images stay 'private'.  (Thus, if
> you have a 'private' image, you'll have to change it to 'shared' before
> you can add members.  On the other hand, now it's *really* private.)
> 
> * You can specify a visibility at the time of image-creation, as you can
> now.  But if you specify 'private', what you get is *really* private.
> This either introduces a minor backward incompatibility, or it fixes a
> bug, depending on how you look at it.  The key thing is, if you *don't*
> specify a visibility, an image with the default visibility will behave
> exactly as it does now, from the perspective of being able to make API
> calls on it (e.g., adding members).
> 
> Thanks for reading this far.  (There's a much more detailed discussion
> in the spec; see the "Other end user impact" section. [2])  Here's the
> point of this email:
> 
> The community images patch [6] is causing a recently added tempest test
> [7] to fail.  The test in question uses an image that was created by a
> request that explicitly specified visibility == private.  Eventually it
> tries to add a member to this image, and as discussed above, this
> operation will fail once we have merged Community Images (because the
> image visibility is not 'shared').  If the image had been created with
> the default visibility (that is, not explicitly specifying a visibility
> in the image-create call), this problem would not arise.  Keep in mind
> that prior to Ocata, there was no reason for end users to specify an
> image visibility explicitly upon image creation because there were only
> two possible values, one of which required special permissions in order
> to use successfully.

While you say there was no reason for a user to do it was still part of the
glance API and part of your contract with end users. It's something anyone
could be doing today, (which is obvious because tempest is doing it)
regardless of whether you think there is a use case for it or not. The whole
point of a stable api is that you don't break things like this. I'd really
recommend reading Sean Dague's blog post here about Nova's api here:

https://dague.net/2015/06/05/the-nova-api-in-kilo-and-beyond-2/

because it does a very good job explaining typical api use cases and how to
think about api compatibility.

> Thus, we feel that the situation occurring in the
> test is not one that many end users will come across.  We have discussed
> the situation extensively with the broader OpenStack community, and the
> consensus is that this change to the API is acceptable.

The guidelines for API compatiblity [1] are there for a reason, and breaking
existing users is **never** the right answer. You'll never get full coverage of
end users by just asking for feedback on the ML and IRC meetings. Heck, I hadn't
heard of any of these proposed changes until that tempest review, and I'm hardly
a disconnected user. The thing to remember is that all APIs have warts and
aspects which are less than ideal, our first priority when making improvements
should be to not randomly break our users in the process. If the goal of
OpenStack is to provide an interoperable cloud platform, ensuring we don't break
our users is kinda

[openstack-dev] [glance][tempest][api] community images, tempest tests, and API stability

2016-12-22 Thread Brian Rosmaita 
Something has come up with a tempest test for Glance and the community
images implementation, and I think it could use some mailing list
discussion, as everyone might not be aware of the patch where the
discussion is happening now [1].

First, the Glance background, to get everyone on the same page:

As part of implementing community images [2], the 'visibility' field of
an image is going from being 2-valued to being 4-valued.  Up to now, the
only values have been 'private' and 'public', which meant that shared
images were 'private', which was inaccurate and confusing (and bugs were
filed with Glance about shared images not having visibility 'shared'
[3a,b]).

With the new visibility enum, the Images API v2 will behave as follows:

* An image with visibility == 'private' is not shared, and is not
shareable until its visibility is changed to 'shared'.

* An image must have visibility == 'shared' in order to do member
operations or be accessible to image members.

* The default visibility of a freshly-created image is 'shared'.  This
may seem weird, but a freshly-created image has no members, so it's
effectively private, behaving exactly as a freshly-created image does,
pre-Ocata.  It's also ready to immediately accept a member-create call,
as freshly-created images are pre-Ocata.  So from a workflow
perspective, this change is backward compatible.

* After much discussion [4], including discussion with operators and an
operator's survey [5], we decided that the correct migration of
'visibility' values for existing images when a cloud is updated would
be: public images stay 'public', private images with members become
'shared', and private images without images stay 'private'.  (Thus, if
you have a 'private' image, you'll have to change it to 'shared' before
you can add members.  On the other hand, now it's *really* private.)

* You can specify a visibility at the time of image-creation, as you can
now.  But if you specify 'private', what you get is *really* private.
This either introduces a minor backward incompatibility, or it fixes a
bug, depending on how you look at it.  The key thing is, if you *don't*
specify a visibility, an image with the default visibility will behave
exactly as it does now, from the perspective of being able to make API
calls on it (e.g., adding members).

Thanks for reading this far.  (There's a much more detailed discussion
in the spec; see the "Other end user impact" section. [2])  Here's the
point of this email:

The community images patch [6] is causing a recently added tempest test
[7] to fail.  The test in question uses an image that was created by a
request that explicitly specified visibility == private.  Eventually it
tries to add a member to this image, and as discussed above, this
operation will fail once we have merged Community Images (because the
image visibility is not 'shared').  If the image had been created with
the default visibility (that is, not explicitly specifying a visibility
in the image-create call), this problem would not arise.  Keep in mind
that prior to Ocata, there was no reason for end users to specify an
image visibility explicitly upon image creation because there were only
two possible values, one of which required special permissions in order
to use successfully.  Thus, we feel that the situation occurring in the
test is not one that many end users will come across.  We have discussed
the situation extensively with the broader OpenStack community, and the
consensus is that this change to the API is acceptable.

To conclude: before and after this change, the "default" visibility of
an image will allow adding members to the image. We would hope that the
failing tempest test could be revised to not explicitly request
"private" visibility but to allow Glance to use its default visibility
instead [10]. We have wide cross-project support [8, 9] for the
"Community Images" work and the only thing blocking us now is tempest.
Due to the shortened cycle in Ocata, we'd really appreciate finding
common ground with the QA team quickly.

thanks,
brian

[1] https://review.openstack.org/#/c/412731/
[2]
http://specs.openstack.org/openstack/glance-specs/specs/newton/approved/glance/community_visibility.html
[3a] https://bugs.launchpad.net/glance/+bug/1394299
[3b] https://bugs.launchpad.net/glance/+bug/1452443
[4] https://review.openstack.org/#/c/396919/
[5]
http://lists.openstack.org/pipermail/openstack-operators/2016-November/012107.html
[6] https://review.openstack.org/#/c/369110/
[7] https://review.openstack.org/#/c/317088/
[8]
http://lists.openstack.org/pipermail/openstack-dev/2016-November/107349.html
[9]
http://eavesdrop.openstack.org/meetings/api_wg/2016/api_wg.2016-06-09-15.59.log.html#l-84
[10] https://review.openstack.org/#/c/414261

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