Re: [openstack-dev] [keystone] Addressing issue of keysone token expiry during long running operations

2016-01-27 Thread Paul Carlton 

Jamie

At the Nova mid-cycle and John Garbutt suggested I reach out to you 
again to progress this issue.


Thanks

On 05/01/16 10:05, Carlton, Paul (Cloud Services) wrote:

Jamie

John Garbutt suggested I follow up this issue with you.  I understand
you may be leading the
effort to address the issue of token expiry during a long running
operation.  Nova
encounter this scenario during image snapshots and live migrations.

Is there a keystone blueprint for this issue?

Thanks




--
Paul Carlton
Software Engineer
Cloud Services
Hewlett Packard Enterprise
BUK03:T242
Longdown Avenue
Stoke Gifford
Bristol BS34 8QZ

Mobile:+44 (0)7768 994283
Email:mailto:paul.carlt...@hpe.com
Hewlett-Packard Enterprise Limited registered Office: Cain Road, Bracknell, 
Berks RG12 1HN Registered No: 690597 England.
The contents of this message and any attachments to it are confidential and may be 
legally privileged. If you have received this message in error, you should delete it from 
your system immediately and advise the sender. To any recipient of this message within 
HP, unless otherwise stated you should consider this message and attachments as "HP 
CONFIDENTIAL".


__
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] [keystone] Addressing issue of keysone token expiry during long running operations

2016-01-05 Thread Carlton, Paul (Cloud Services) 
Jamie

John Garbutt suggested I follow up this issue with you.  I understand
you may be leading the
effort to address the issue of token expiry during a long running
operation.  Nova
encounter this scenario during image snapshots and live migrations.

Is there a keystone blueprint for this issue?

Thanks

-- 
Paul Carlton
Software Engineer
Cloud Services
Hewlett Packard
BUK03:T242
Longdown Avenue
Stoke Gifford
Bristol BS34 8QZ

Mobile:+44 (0)7768 994283
Email:mailto:paul.carlt...@hpe.com
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 
1HN Registered No: 690597 England.
The contents of this message and any attachments to it are confidential and 
may be legally privileged. If you have received this message in error, you 
should delete it from your system immediately and advise the sender. To any 
recipient of this message within HP, unless otherwise stated you should 
consider this message and attachments as "HP CONFIDENTIAL".




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

Re: [openstack-dev] [keystone] Addressing issue of keysone token expiry during long running operations

2016-01-05 Thread Adam Young 

On 01/05/2016 05:05 AM, Carlton, Paul (Cloud Services) wrote:

Jamie

John Garbutt suggested I follow up this issue with you.  I understand
you may be leading the
effort to address the issue of token expiry during a long running
operation.  Nova
encounter this scenario during image snapshots and live migrations.

Is there a keystone blueprint for this issue?
This action should not be done with a token;  you can never have a token 
length long enough that it won't expire on some jobs.


Either do it using a trust, or make it something that the Nova service 
user can do without a token.  The latter is probably the easier choice.





Thanks



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


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

Re: [openstack-dev] [keystone] Addressing issue of keysone token expiry during long running operations

2015-12-20 Thread Jamie Lennox 
Hey Paul,

At the Tokyo summit we discussed a general way to make it so that user
tokens were only expiration tested once. When the token hits nova for
example we can say it was validated, then when nova talks to glance it
sends both the user token (or enough data to represent the user token) and
an X-Service-Token which is the token nova validated with and we say the
presence of the X-Service-Token means we should trust that the previous
service already did enough validation to just trust it.

This is a big effort because it's going to require changing how service to
service communication works at all places.

At the moment I don't have a blueprint for this. The biggest change is
going to be making service->service communication rely on keystoneauth auth
plugins so that we can have the auth plugin control what data is
communicated rather than hack this in to every location and so far has
required updates to middleware and future to oslo.context and others to
make this easy for services to consume. This work has been ongoing by
myself, mordred and morgan (if you see reviews to switch your service to
keystoneauth plugins please review as it will make the rest of this work
easier in future).

I certainly don't expect to see this pulled off in Mitaka time frame.

For the mean time more and more services are relying on trusts, which is an
unfortunate but workable solution.

Jamie

On 18 December 2015 at 22:13, Paul Carlton  wrote:

> Jamie
>
> John Garbutt suggested I follow up this issue with you.  I understand you
> may be leading the
> effort to address the issue of token expiry during a long running
> operation.  Nova
> encounter this scenario during image snapshots and live migrations.
>
> Is there a keystone blueprint for this issue?
>
> Thanks
>
> --
> Paul Carlton
> Software Engineer
> Cloud Services
> Hewlett Packard
> BUK03:T242
> Longdown Avenue
> Stoke Gifford
> Bristol BS34 8QZ
>
> Mobile:+44 (0)7768 994283
> Email:mailto:paul.carlt...@hpe.com
> Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks
> RG12 1HN Registered No: 690597 England.
> The contents of this message and any attachments to it are confidential
> and may be legally privileged. If you have received this message in error,
> you should delete it from your system immediately and advise the sender. To
> any recipient of this message within HP, unless otherwise stated you should
> consider this message and attachments as "HP CONFIDENTIAL".
>
>
>
__
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] [keystone] Addressing issue of keysone token expiry during long running operations

2015-12-18 Thread Paul Carlton 

Jamie

John Garbutt suggested I follow up this issue with you.  I understand 
you may be leading the
effort to address the issue of token expiry during a long running 
operation.  Nova

encounter this scenario during image snapshots and live migrations.

Is there a keystone blueprint for this issue?

Thanks

--
Paul Carlton
Software Engineer
Cloud Services
Hewlett Packard
BUK03:T242
Longdown Avenue
Stoke Gifford
Bristol BS34 8QZ

Mobile:+44 (0)7768 994283
Email:mailto:paul.carlt...@hpe.com
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN 
Registered No: 690597 England.
The contents of this message and any attachments to it are confidential and may be 
legally privileged. If you have received this message in error, you should delete it from 
your system immediately and advise the sender. To any recipient of this message within 
HP, unless otherwise stated you should consider this message and attachments as "HP 
CONFIDENTIAL".




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

Re: [openstack-dev] [keystone] Addressing issue of keysone token expiry during long running operations

2015-12-18 Thread Morgan Fainberg 
Right now the solution is to increase the token expiration time in keystone
config. I personally am working on a longer term solution but it is a ways
out (regarding changing how services pass authorization around internally).
Unfortunately the current architecture makes changing how token timeouts
affect long running tasks difficult until we make more forward progress on
separating user-to-service authorization and service-to-service
authorization.

--Morgan
On Dec 18, 2015 03:16, "Paul Carlton"  wrote:

> Jamie
>
> John Garbutt suggested I follow up this issue with you.  I understand you
> may be leading the
> effort to address the issue of token expiry during a long running
> operation.  Nova
> encounter this scenario during image snapshots and live migrations.
>
> Is there a keystone blueprint for this issue?
>
> Thanks
>
> --
> Paul Carlton
> Software Engineer
> Cloud Services
> Hewlett Packard
> BUK03:T242
> Longdown Avenue
> Stoke Gifford
> Bristol BS34 8QZ
>
> Mobile:+44 (0)7768 994283
> Email:mailto:paul.carlt...@hpe.com
> Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks
> RG12 1HN Registered No: 690597 England.
> The contents of this message and any attachments to it are confidential
> and may be legally privileged. If you have received this message in error,
> you should delete it from your system immediately and advise the sender. To
> any recipient of this message within HP, unless otherwise stated you should
> consider this message and attachments as "HP CONFIDENTIAL".
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] Addressing issue of keysone token expiry during long running operations

2015-12-18 Thread Steven Hardy 
On Fri, Dec 18, 2015 at 11:13:37AM +, Paul Carlton wrote:
> Jamie
> 
> John Garbutt suggested I follow up this issue with you.  I understand you
> may be leading the
> effort to address the issue of token expiry during a long running operation.
> Nova
> encounter this scenario during image snapshots and live migrations.
> 
> Is there a keystone blueprint for this issue?

FWIW we have now worked around this issue via trusts in Heat, as discussed
some time ago here:

http://lists.openstack.org/pipermail/openstack-dev/2014-October/048429.html

In summary, we have a (optional, defaulted to false) config option which
enables switching to a trust-scoped token, where we've created a keystone
trust delegating from the user making the request to heat and a trustee
user (a configurable user owned by the heat service)

We then make use of the keystoneclient auth plugin mechanism, which already
supports reauthentication for password based auth, including when scoped to
a trust:

https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/auth/identity/v3/password.py#L70

The heat patch where we introduced this feature is here:

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

I wrote a blog post a while back which may help if you need some context
around Heat's usage of Trusts:

http://hardysteven.blogspot.co.uk/2014/04/heat-auth-model-updates-part-1-trusts.html

HTH!

Steve

__
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