Open Stack

(inline)

On May 14, 2013, at 1:16 PM, Vishvananda Ishaya wrote:

> Can't we solve this by putting a attribute on the resource itself ("owner")? After all the project_id is really just an attribute on the resource. The policy could then be crafted via attribute matching instead of uri matching.

Oh Duh, I forgot we have tenant_Id as an attribute already. Yes, that can work.

The only issue there is that the policy needs to be different for different services.   By putting it in the URI:

1.  I could deploy the exact same policy in front of all of my other services. (I don't need different code to say get the owner in glance, and in nova, and in etc.)
2.  I don't need to make a separate call to get the project_id, I can make the decision based on the message request, which I already have at hand.

> 
> I don't see any reason to make the "owner" attribute special vs other attributes like state (policy could allow showing of "soft-deleted" vms) or flavor (policy could allow hiding some flavors). Including it in the uri or as a header seems like we are arbitrarily choosing one attribute of the resource and making it extra important. I don't really think that is justified.

In theory, I totally agree with you.  In practice, it's the one attribute I need for every single service I run and used by a common cross-service policy.. 

So it's a special case in that:

  1.  It's common across services.
  2.  It's accessed very frequently.

Having it in the URI just makes things easy and efficient....but if you expose the attribute, I can live with it...

....still, you're making more work for me :-)

Would it be difficult to make the project_id in the URI thing optional?  To put the logic in some middleware we can add and remove at will?  Or, at least, to work with other services so that  getting the project_id for resource a consistent call between services -- I can dream right...

Thanks,

-jOrGe W.