Handle Multiple Versions of EAP/Wildfly

[cpitman]

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]

@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]

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

[fuero]

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]

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]

@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

[cpitman]

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

[itewk]

@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]

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]

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]

@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.