[openstack-dev] [python-keystoneclient] Return request-id to caller

[koshiya maho]

Hi Keystone devs,

Blueprint [1] related to request-ids is approved for Mitaka and 
its implementation [2] is up for review for quite a long time. 
And, I have submitted a blueprint about logging [3].
I would like to include these patch in Ocata.
Could you review it?

[1]
https://blueprints.launchpad.net/python-keystoneclient/+spec/return-request-id-to-caller

[2]
https://review.openstack.org/#/c/261188/
https://review.openstack.org/#/c/267449/
https://review.openstack.org/#/c/267456/
https://review.openstack.org/#/c/268003/

[3]
https://blueprints.launchpad.net/python-keystoneclient/+spec/log-request-id

Thank you,
--
Maho Koshiya
E-Mail : koshiya.m...@po.ntts.co.jp



__
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] [python-keystoneclient] Return request-id to caller

[koshiya maho]

Hi, keystone devs,

Thank you for your many comments about my patch [1].

I modified this patch in reference to your comments.
I want to get many opinions about this new Patch Set.

Could you review it?
[1]: https://review.openstack.org/#/c/261188/

Thank you,

On Tue, 31 May 2016 20:46:36 +0900
koshiya maho  wrote:

> Hi, keystone devs,
> 
> Thank you for your many opinions about request id mapping.
> I fixed this patch [1] by the way that Brant and Cao gave me suggestions [2].
> Could you review it?
> 
> [1] https://review.openstack.org/#/c/261188/
> [2] http://paste.openstack.org/show/495040/
> 
> Thank you,
> 
> On Wed, 20 Apr 2016 16:37:31 -0700
> Morgan Fainberg  wrote:
> 
> > On Wed, Apr 13, 2016 at 6:07 AM, David Stanek  wrote:
> > 
> > > On Wed, Apr 13, 2016 at 3:26 AM koshiya maho 
> > > wrote:
> > >
> > >>
> > >> My request to all keystone cores to give their suggestions about the 
> > >> same.
> > >>
> > >>
> > > I'll test this a little and see if I can see how it breaks.
> > >
> > > Overall I'm not really a fan of this design. It's just a hack to add
> > > attributes where they don't belong. Long term I think this will be hard to
> > > maintain.
> > >
> > >
> > >
> > If we want to return a response object we should return a response object.
> > Returning a magic list with attributes (or a dict with attributes, etc)
> > feels very, very wrong.
> > 
> > I'm not going to block this design, but I wish we had something a bit
> > better.
> > 
> > --Morgan
> 
> --
> Maho Koshiya
> E-Mail : koshiya.m...@po.ntts.co.jp
> 
> 
> 
> __
> 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

--
Maho Koshiya
E-Mail : koshiya.m...@po.ntts.co.jp



__
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] [python-keystoneclient] Return request-id to caller

[koshiya maho]

Hi, keystone devs,

Thank you for your many opinions about request id mapping.
I fixed this patch [1] by the way that Brant and Cao gave me suggestions [2].
Could you review it?

[1] https://review.openstack.org/#/c/261188/
[2] http://paste.openstack.org/show/495040/

Thank you,

On Wed, 20 Apr 2016 16:37:31 -0700
Morgan Fainberg  wrote:

> On Wed, Apr 13, 2016 at 6:07 AM, David Stanek  wrote:
> 
> > On Wed, Apr 13, 2016 at 3:26 AM koshiya maho 
> > wrote:
> >
> >>
> >> My request to all keystone cores to give their suggestions about the same.
> >>
> >>
> > I'll test this a little and see if I can see how it breaks.
> >
> > Overall I'm not really a fan of this design. It's just a hack to add
> > attributes where they don't belong. Long term I think this will be hard to
> > maintain.
> >
> >
> >
> If we want to return a response object we should return a response object.
> Returning a magic list with attributes (or a dict with attributes, etc)
> feels very, very wrong.
> 
> I'm not going to block this design, but I wish we had something a bit
> better.
> 
> --Morgan

--
Maho Koshiya
E-Mail : koshiya.m...@po.ntts.co.jp



__
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] [python-keystoneclient] Return request-id to caller

[Morgan Fainberg]

On Wed, Apr 13, 2016 at 6:07 AM, David Stanek  wrote:

> On Wed, Apr 13, 2016 at 3:26 AM koshiya maho 
> wrote:
>
>>
>> My request to all keystone cores to give their suggestions about the same.
>>
>>
> I'll test this a little and see if I can see how it breaks.
>
> Overall I'm not really a fan of this design. It's just a hack to add
> attributes where they don't belong. Long term I think this will be hard to
> maintain.
>
>
>
If we want to return a response object we should return a response object.
Returning a magic list with attributes (or a dict with attributes, etc)
feels very, very wrong.

I'm not going to block this design, but I wish we had something a bit
better.

--Morgan
__
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] [python-keystoneclient] Return request-id to caller

[Brant Knudson]

On Wed, Apr 20, 2016 at 6:31 AM, Duncan Thomas 
wrote:

> On 20 April 2016 at 08:08, koshiya maho 
> wrote:
>
>
>> This design was discussed, reviewed and approved in cross-projects [1] and
>> already implemented in nova, cinder and neutron.
>> At this point if we change the implementation then it will not be
>> consistent across core OpenStack projects.
>> For maintenance of the whole of OpenStack, I think that the present
>> method is best.
>> Please suggest.
>>
>
>
I haven't been asking for a complete redesign. I just want this to be
opt-in to minimize the chance of an impact on existing applications. We can
eventually deprecate the old behavior.

- Brant



> The fact that a cross-project spec is approved doesn't mean that it will
> end up being practical. If the cinder-client implementation had been found
> to break any none-trivial users then I wouldn't have hesitated.
>
> Cross project specs are not getting massive amounts of detailed attention
> from project teams, end even they were it is not possible to foresee all
> subtle problems at review time - they should be taken as guidance not
> gospel and expect to be reworked if it proves necessary.
>
> --
> Duncan Thomas
>
__
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] [python-keystoneclient] Return request-id to caller

[Duncan Thomas]

On 20 April 2016 at 08:08, koshiya maho  wrote:


> This design was discussed, reviewed and approved in cross-projects [1] and
> already implemented in nova, cinder and neutron.
> At this point if we change the implementation then it will not be
> consistent across core OpenStack projects.
> For maintenance of the whole of OpenStack, I think that the present method
> is best.
> Please suggest.
>

The fact that a cross-project spec is approved doesn't mean that it will
end up being practical. If the cinder-client implementation had been found
to break any none-trivial users then I wouldn't have hesitated.

Cross project specs are not getting massive amounts of detailed attention
from project teams, end even they were it is not possible to foresee all
subtle problems at review time - they should be taken as guidance not
gospel and expect to be reworked if it proves necessary.

-- 
Duncan Thomas
__
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] [python-keystoneclient] Return request-id to caller

[koshiya maho]

Hi Brant, David,

Thank you for your opinions. 

On Wed, 13 Apr 2016 13:07:55 +
David Stanek  wrote:

> On Wed, Apr 13, 2016 at 3:26 AM koshiya maho 
> wrote:
> 
> >
> > My request to all keystone cores to give their suggestions about the same.
> >
> >
> I'll test this a little and see if I can see how it breaks.
> 
> Overall I'm not really a fan of this design. It's just a hack to add
> attributes where they don't belong. Long term I think this will be hard to
> maintain.

This design was discussed, reviewed and approved in cross-projects [1] and 
already implemented in nova, cinder and neutron.
At this point if we change the implementation then it will not be consistent 
across core OpenStack projects. 
For maintenance of the whole of OpenStack, I think that the present method is 
best.
Please suggest.

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

Thank you,

--
Maho Koshiya
E-Mail : koshiya.m...@po.ntts.co.jp



__
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] [python-keystoneclient] Return request-id to caller

[David Stanek]

On Wed, Apr 13, 2016 at 3:26 AM koshiya maho 
wrote:

>
> My request to all keystone cores to give their suggestions about the same.
>
>
I'll test this a little and see if I can see how it breaks.

Overall I'm not really a fan of this design. It's just a hack to add
attributes where they don't belong. Long term I think this will be hard to
maintain.

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

[openstack-dev] [python-keystoneclient] Return request-id to caller

[koshiya maho]

Hi All,

I have submitted patches [1] for returning request-id to the caller 
on which Brant has raised his concerns [2];

Brant’s concern:
We've tried a couple of times to have the client return metadata for the lists 
returned 
and we wound up reverting the change both times because it broke some user --
https://review.openstack.org/#/c/285549/

I don't know what the solution is to the problem but this isn't going to work. 
Maybe we to add a flag or new functions or start a whole new client library so 
that
applications can opt-in to this.


I have tried this manually in my local environment and found that it is not 
failing 
with the patch suggested by Brant as well as with my changes.

Steps:
(1)clone openstack-infra/shade project
(2)create tox environment
(3)apply my patch (or above patch) to .tox environment
(4)run tests -- $tox -e py27 shade.tests.functional.test_xxx

You can see all tests are passing without any error. 
I have also verified that _ListWithMeta class is returned from keystoneclient 
by adding pdb in
keystoneclient/base.py _list method.

My request to all keystone cores to give their suggestions about the same.

[1] https://review.openstack.org/#q,topic:bp/return-request-id-to-caller,n,z
[2] https://review.openstack.org/#/c/261188/

Thank you,

--
Maho Koshiya
E-Mail : koshiya.m...@po.ntts.co.jp



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

[openstack-dev] [python-keystoneclient] Return request-id to caller

[koshiya maho]

Hi Keystone devs,

Blueprint [1] related to request-ids is approved for Mitaka and 
its implementation [2] is up for review for quite a long time. 

I would like to apply for a goal for this blueprint so that 
it can be included in Newton.

[1]
https://blueprints.launchpad.net/python-keystoneclient/+spec/return-request-id-to-caller

[2]
https://review.openstack.org/#/c/261188/
https://review.openstack.org/#/c/267449/
https://review.openstack.org/#/c/267456/
https://review.openstack.org/#/c/268003/
https://review.openstack.org/#/c/276644/

Thank you,
--
Maho Koshiya
E-Mail : koshiya.m...@po.ntts.co.jp



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

[openstack-dev] [python-keystoneclient] return-request-id-to-caller

[koshiya maho]

Hi,

I want to add support for returning 'x-openstack-request-id' in 
python-keystoneclient as per the design proposed in cross-project specs.

Cross-project spec has been already approved. :
https://specs.openstack.org/openstack/openstack-specs/specs/return-request-id.html

So, I'd like you to approve this BP. :
https://blueprints.launchpad.net/python-keystoneclient/+spec/return-request-id-to-caller

Thank you and best regards,

--
Maho Koshiya
E-Mail : koshiya.m...@po.ntts.co.jp



__
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] [python-keystoneclient] return-request-id-to-caller

[Brant Knudson]

On Tue, Dec 22, 2015 at 2:02 AM, koshiya maho 
wrote:

> Hi,
>
> I want to add support for returning 'x-openstack-request-id' in
> python-keystoneclient as per the design proposed in cross-project specs.
>
> Cross-project spec has been already approved. :
>
> https://specs.openstack.org/openstack/openstack-specs/specs/return-request-id.html
>
> So, I'd like you to approve this BP. :
>
> https://blueprints.launchpad.net/python-keystoneclient/+spec/return-request-id-to-caller
>
> Thank you and best regards,
>
> --
> Maho Koshiya
> E-Mail : koshiya.m...@po.ntts.co.jp
>
>
>
I put this on the meeting agenda for as a no-spec blueprint to approve.[1]
Since there's already a cross-project spec I don't think we need another
spec in keystone.

[1]
https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting#Review_of_Keystone_Blueprints_for_No-Spec_Requires_Status

 - Brant
__
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