That way we can also avoid scenarios where a resource provider submitting usage to an intermediate step in the pipeline. That's a great point, had not thought about that... So now with that we'll have a clear delineation between usage submission from a resource provider and its processing inside the Abacus pipeline. - Jean-Sebastien On Fri, Oct 9, 2015 at 5:05 PM, Saravanakumar A Srinivasan < sasrin(a)us.ibm.com> wrote: So, I'm wondering if it still makes sense to use the resource provider's token inside our *asynchronous* usage *processing* pipeline. Shouldn't we
require the individual processing steps to obtain their own tokens instead?
Initial thought was to use resource provider's token for real time
processing and for error and recovery or delayed processing scenarios we
wanted to use our own token.
I agree with your comments on the possibility of running into issues
when we use the resource providers' token while doing slightly delayed
processing. So will update the implementation to use our own token at
processing pipeline.
That way we can also avoid scenarios where a resource provider submitting
usage to an intermediate step in the pipeline.
Thanks,
Saravanakumar Srinivasan (Assk),
-----Jean-Sebastien Delfino <jsdelfino(a)gmail.com> wrote: -----
To: "Discussions about Cloud Foundry projects and the system overall." <
cf-dev(a)lists.cloudfoundry.org>
From: Jean-Sebastien Delfino <jsdelfino(a)gmail.com>
Date: 10/08/2015 10:30AM
Subject: [cf-dev] Re: Re: Re: [abacus] Usage processing authorization,
was: Usage submission authorization
OK that confirms what I thought. Thanks!
Assk, any thoughts as well? Did that make sense to you?
-- Jean-Sebastien
On Wed, Oct 7, 2015 at 6:09 PM, Piotr Przybylski <piotrp(a)us.ibm.com>
wrote:
Sebastien
So, I'm wondering if it still makes sense to use the resource provider's token inside our *asynchronous* usage *processing* pipeline.
Shouldn't we require the individual processing steps to obtain their own
tokens instead?
It seems natural that the Abacus should use its own token - or tokens to
authenticate and authorize steps in the pipeline. After the submission
Abacus 'takes custody' of the submitted data so it should be solely
responsible for authrizing its processing.
Piotr
Piotr Przybylski | IBM Bluemix | piotrp(a)us.ibm.com | 650-645-8213
[image: Inactive hide details for Jean-Sebastien Delfino ---10/07/2015
09:21:05 AM---Hi all, A few more thoughts on a different, but re]Jean-Sebastien
Delfino ---10/07/2015 09:21:05 AM---Hi all, A few more thoughts on a
different, but related subject.
From: Jean-Sebastien Delfino <jsdelfino(a)gmail.com>
To: "Discussions about Cloud Foundry projects and the system overall." <
cf-dev(a)lists.cloudfoundry.org>
Date: 10/07/2015 09:21 AM
Subject: [cf-dev] Re: [abacus] Usage processing authorization, was:
Usage submission authorization
------------------------------
Hi all,
A few more thoughts on a different, but related subject.
We're using the resource provider's token and scopes to authorize usage
*submission* to our usage collector service. I agree with that and have
confirmed it in my answer to Piotr's question below.
It also looks like we're using the resource provider's token as well to
flow usage data through our usage *processing* pipeline (after we've
authorized the usage submission, validated that usage and taken
responsibility for it). I'm wondering if we couldn't find a better
approach, as we will run into a number of issues with this:
- processing delays in the pipeline can cause the token to expire, at
that point the resource provider is out of the loop, can't do anything
about it, and it won't make much sense anyway to ask the resource provider
for a new token way after it has submitted its usage;
- when restarting an Abacus service and recovering after a processing
interruption, we don't have a valid resource provider token either;
- more generally, I find a bit odd to use the resource provider's token
in usage processing steps down the Abacus pipeline, as they're really just
processing usage passed to them by the previous Abacus processing step (or
could have just read that usage from one of our usage DBs, and again the
resource provider wouldn't be so relevant as it wouldn't even have written
that usage to that DB itself.)
So, I'm wondering if it still makes sense to use the resource provider's
token inside our *asynchronous* usage *processing* pipeline. Shouldn't we
require the individual processing steps to obtain their own tokens instead?
Thoughts?
-- Jean-Sebastien
On Tue, Oct 6, 2015 at 10:36 PM, Jean-Sebastien Delfino <
*jsdelfino(a)gmail.com* <jsdelfino(a)gmail.com>> wrote:
Hi Piotr,
> what kind of authorization is required to submit usage to Abacus ?
> Is the oauth token used for submission [1] required to have
particular scope, specific to resource or resource provider ?
A resource provider is expected to present an OAuth token with the
usage it submits for a (service or runtime) resource.
That OAuth token should include:
- a user id uniquely identifying that resource provider;
- an OAuth scope named like abacus.usage.<resource_id>.write.
The precise naming syntax for that scope may still evolve in the next
few days as we progress with the implementation of user story 101703426 [1].
> Is there a different scope required to submit runtimes usage (like
cf bridge) versus other services or its possible to use single scope for
all the submissions
I'd like to handle runtimes and services consistently as they're
basically just different types of resources, i.e. one scope per 'service'
resource, one scope per 'runtime' resource.
We're still working on the detailed design and implementation, but
I'm not sure we'd want to share scopes across (service and runtime)
resource providers as that'd allow a resource provider to submit usage for
resources owned by another...
@assk / @sasrin, anything I missed? Thoughts?
-- Jean-Sebastien
On Tue, Oct 6, 2015 at 6:29 PM, Piotr Przybylski <*piotrp(a)us.ibm.com*
<piotrp(a)us.ibm.com>> wrote:
Hi,
what kind of authorization is required to submit usage to Abacus ?
Is the oauth token used for submission [1] required to have
particular scope, specific to resource or resource provider ? Is there a
different scope required to submit runtimes usage (like cf bridge) versus
other services or its possible to use single scope for all the submissions
?
[1] - *https://www.pivotaltracker.com/story/show/101703426*
<https://www.pivotaltracker.com/story/show/101703426>
Piotr
|
