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

Handle Multiple Versions of EAP/Wildfly #64

Open
cpitman opened this issue Apr 8, 2015 · 10 comments
Open

Handle Multiple Versions of EAP/Wildfly #64

cpitman opened this issue Apr 8, 2015 · 10 comments
Labels

Comments

@cpitman
Copy link
Contributor

cpitman commented Apr 8, 2015

Hey guys (@itewk @fuero),
What are your thoughts on handling multiple versions of Jboss? Up to this point we have essentially targeted a single version (EAP 6.x), but that obviously can only go so far.

We could generate different resources for each version, and then have them nested one level deeper: jboss_admin::resource::eap6::subsystem_osgi. Is there anything else we can do?

@itewk
Copy link
Contributor

itewk commented Apr 8, 2015

@cpitman that maybe the only option. Though one possibility to kick around is that in my use of jboss_admin when I was implementing the use of Role Based Auth I used a lot of onlyif statements like this "'(result == "6.0.0.GA") || (result == "6.1.0.GA") of :read-attribute(name=product-version)'" to decide if I could actually configure the RBAC or not.

Maybe we could have some way to tag subsystems and parameters with a version range they are supported in and then compare that against the current version and only error if there is a missmatch?

But part of me thinks this would be wholly unmaintainable if there is large divergence in the API.

@itewk
Copy link
Contributor

itewk commented Apr 8, 2015

@cpitman another spit ball idea is, should there be different branches of the project for each version?

@fuero
Copy link

fuero commented Apr 8, 2015

Actually, I ran into your module halfway through writing my own wildfly module :-).
I agree with @itewk's branching idea, it was the first thing that popped into my head too.
It all hinges on the stability of JBoss/Wildfly's API.

@cpitman
Copy link
Contributor Author

cpitman commented Apr 8, 2015

If we did branching, would we also publish each branch as a different module to puppet forge? IE jboss_admin_eap6, jboss_admin_wildfly8, etc?

@itewk
Copy link
Contributor

itewk commented Apr 8, 2015

@cpitman that would probably make sense, but then at that point if there is enough overlap, doing the nesting idea like you said sounds like less to maintain in the long run

@itewk itewk added the question label Apr 8, 2015
@cpitman
Copy link
Contributor Author

cpitman commented Apr 8, 2015

And from looking at the schema generated by wildfly 8, it isn't particularly stable from major version to major version

@itewk
Copy link
Contributor

itewk commented Apr 8, 2015

@cpitman i think I circle back to your original idea then. Except it breaks all of us already using the module and we have to update. But that's probably just me, so not to huge of a deal.

@itewk
Copy link
Contributor

itewk commented Apr 8, 2015

but then we have to decide do we do a different namesapce for each minor version or just major or what?
cuz then that would break my use case of being able to dynamically use 6.0.0 through 6.3.4

@jairojunior
Copy link

Personally, I don't like the idea of multiple branches. I think we should strive for a single interface that hides multiple version-specific behaviours.

Something like Postel's Law: Be conservative in what you do (check version before do something), be liberal in what you accept from others (have a single flexible interfaces (i.e. options hash)).

@itewk
Copy link
Contributor

itewk commented Apr 22, 2015

@jairojunior i agree that would be ideal but how would we actually handle that? Especially with the auto generated nature? ANy thoughts?

Maybe in the short term we go with multiple namesapces, then aim for a single namespace in the future.

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

No branches or pull requests

4 participants