[jboss-as7-dev] Guidelines for managing management API versions of subsystems

[Brian Stansberry]

On 10/7/12 5:16 PM, Tomaž Cerar wrote:
> Hi,
>
> a new version of mgmt model is required when change is incompatible with
> previous model.
> basically if you would take your current model and try to apply it to
> previously released version of subsystem, would it work?
> If no, then new version is required & transformers has to be written to
> make sure compatibility in domain mode is preserved.

Note that transformation only needs to be done if it can actually do 
something useful. For example, the jacorb change made "0" a valid value 
for some attribute. If a config includes that new value, a slave running 
the old version won't be able to deal with that "0" and it's also not 
correct to transform it into a "1". So the slave will just have to 
ignore that profile, or if that's not possible the slave will have to be 
upgraded before a config with "0" can be applied.

Tomaz had the good idea of recording these kinds of issues on the master 
HC and making them visible through the management API so even if the 
slave is ignoring the resource, admins could still find out what the 
compatibility issues are. When we implement that some day I suspect 
using a transformer to record the information but do nothing else will 
be how it gets implemented.

> As for transformers go, I just started working on guide to help people
> out, you can find it at
> https://docs.jboss.org/author/display/AS72/Transformers (wip atm)
>
> We agreed that version bump in master should be done only on major &
> minor flags, micro version is reserved for 7.1/EAP branches.
> in this concrete case, change was done to 7.1 branch and same one was
> applied to master, hence master got just micro version bump, provided
> that jacorb subsystem didn't have any other changes that are in 7.1 branch.
>
> To go to details, change of that validator also changed the model, where
> min-value was now different this would cause model that worked on new
> definition could fail on old one.
>
> --
> tomaz
>
>
> On Sat, Oct 6, 2012 at 4:15 PM, Jaikiran Pai <jpai at redhat.com
> <mailto:jpai at redhat.com>> wrote:
>
>     Was just looking at some of the PRs and noticed that after a recent
>     change to Jacorb subsystem [1] we decided to bump the micro version of
>     that subsystem's management API [2]. What are the general guidelines
>     when it comes to bumping the management version of a subsystem? As far
>     as xsd changes are concerned, for EJB3, I've been making sure that the
>     version is bumped whenever there's a semantic change from a previous
>     released version. But I haven't so far touched the management version of
>     the EJB3 subsystem - in fact I had almost forgotten we had that. As a
>     specific example, I introduced a "default-security-domain" management
>     attribute for the EJB3 subsystem recently. Does this warrant a
>     management version bump?
>
>     [1] https://github.com/jbossas/jboss-as/pull/3175/files
>     [2] https://github.com/jbossas/jboss-as/pull/3197/files
>
>     -Jaikiran
>     _______________________________________________
>     jboss-as7-dev mailing list
>     jboss-as7-dev at lists.jboss.org <mailto:jboss-as7-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat