Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

3.0.0 version cannot create V2 tenant #666

Closed
wumingcheng opened this issue May 13, 2016 · 5 comments
Closed

3.0.0 version cannot create V2 tenant #666

wumingcheng opened this issue May 13, 2016 · 5 comments
Assignees
Milestone

Comments

@wumingcheng
Copy link

when I want to create a v2 tenant ,the "Builders.tenant()" was missing.

@auhlig
Copy link
Member

auhlig commented May 15, 2016

@wumingcheng Thanks for pointing that out.
I'll fix that and add some integration-tests next week.
As a workaround for the meantime you could use the KeystoneTenant.builder() directly.

gondor added a commit that referenced this issue May 17, 2016
@gondor gondor added this to the 3.0.1 Release milestone May 17, 2016
@gondor
Copy link
Member

gondor commented May 17, 2016

New 3.0.1-SNAPSHOT has been pushed

@auhlig
Copy link
Member

auhlig commented May 18, 2016

Looking at the Builders I think it makes sense to also divide by Identity version. So it would be clear which Role, User, etc. is being built or that a Group is not available when using v2.
So I would create a BuilderV2 for identity v2 and a BuilderV3 for id v3 which extends the current Builder-implementation.
That would be a minimal change which would only be breaking for the identity builders (other services would still be able to use the current Builder-API) would and would follow the pattern used in the OSClient, OSClientSession, .. .

Does this make sense @gondor, @dhague ?

@gondor
Copy link
Member

gondor commented May 18, 2016

I like that idea, will make things cleaner and allow for expansion

@dhague
Copy link
Collaborator

dhague commented May 18, 2016

Sounds good. Technically this could introduce a breaking change in 3.0, but if we do it quickly then I think that's OK - it's not like we have a big installed base of OS4J 3.0 users yet :-)
My feeling is that if we get it out quickly as 3.0.2 (maybe even 3.1) then we should be fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants