Trusts in OpenStack4j

[plnordquist]

I'd like to be able to work with trusts using OpenStack4j but I don't know where it belongs in the code. Currently it looks like there is no place to manage V3 Keystone constructs like Trusts. I'd be willing to help implement this but need some guidance on a good place to stick this in OSClient, either in identityV3() or some other way to access it. The OpenStack documentation for trusts is at http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-trust-ext.html

I've also submitted pull request https://github.com/gondor/openstack4j/pull/310 to consume trusts. This just allows someone to consume an already created trust to access the resources it is sharing.

[gondor]

Thanks, I read the specification and have reviewed your pull requests. I've had a few ideas on how to handle V3 vs V2 api's and this definitely will enforce this adaption sooner than later. My current idea is to change the OSFactory to return a V3 OSClient when you authenticate against V3. This will allow V3 interfaces returned where applicable. I need to hash through the other scenarios and risks with doing this approach including re-constructing a client in another thread from an existing Access object. Give me a day to think about which approach will fit the overall API workflow to start the ground of handling V3 specific constructs as you mentioned.

[gondor]

@peter-nordquist So leaning towards returning a new V3 OSClient which will bind and return services that are V3 specific that have replaced V2. V2 services that don't have a V3 counterpart will be available as usual through the new client. What are your thoughts on this?

example:

OSClientV3 os = OSFactory.builderV3().../etc/.authenticate();
os.identity() // would return an IdentityV3Service
os.compute() // would return the Compute V2 (current service)
// etc - this way I could have things like
os.identity().domains().etc

[plnordquist]

Yeah that sounds good. I was trying to think of a way if you could keep compatibility between OSClient* classes but it seems difficult to do because of the changes in V3 (tenants->projects, using domains with projects and users, etc.)

[gondor]

I was having the same difficulty. I think in the longer term this will be ideal since we can keep adding V3 specifics to the V3 path. If I'm a V3 user then I'm benefiting from this since I can start to use V3 specific services as they get developed and V2 users (OSClient) stay unaffected.

The other idea I had that I don't like as much was keep the OSClient and start doing this:

os.identity() // V2 identity
os.identityV3() // V3 identity

The bad about that is if we didn't authenticate against V3 then the V3 services will error out, etc. It also adds confusion to new users learning to use the API.

[vishvesh]

Hi @gondor , would you mind sharing the status of this implementation? How about keeping os.identity() and adding V3 related services using something like ProjectService projects();, and adding domain objects such as Tenants, Projects, Groups, etc.? Is it feasible to use the same identity client os.identity()? Under the same identity() service, Tenants would be Projects (keeping Tenants for V2 compatibility), Users -> UsersV3 (if there is any change for Users), Domains, Groups for V3?

[olivierlemasle]

Hi @gondor,

Is there any new plan for this "Trusts" feature? I am under the impression that the work done by @peter-nordquist in #310 has been removed since OpenStack4j 3, am I right?

[auhlig]

@olivierlemasle I remember some errors with trusts while working on identity v3 so I removed it. That was right before the 3.0 release. Maybe it's not that much work to bring the support back. Are you familiar with trusts and like to take over?

[olivierlemasle]

@auhlig No, I just tested the "trusts" feature but I've never used it (and btw it didn't fit my needs).