Patching changes in EAP 6.2- let us know what you think!

Latest response

The maintenance changes we've announced for EAP 6.2 and beyond are a response to feedback on the maintenance releases from earlier EAP 6 releases. We're interested in keeping the feedback loop open and expanding it. If you have any feedback or questions about the new model, please post them here!

While you're at it, check out and participate in our other recent EAP community discussions.

Responses

How will this work in a domain master/slave configuration? Can the patches be applied remotely or do we apply on an individual host by host basis?

Patches must be applied on an individual basis with the current feature. But, individual hosts can be patched from the domain master remotely.

Are there any plans of integrating this feature with JON? My current customer was interested in knowing whether going forward they could apply these patches via JON?

Yes Niraj, that will be supported in JBoss ON 3.3 which will be available in h2 of 2014

Thanks Alan!

Is it possible to individually patch different domains that use the same core binaries and are running on the same host but have different domain configurations?

Hi,
can i install jboss eap 6.2 with java jdk 7u45? need to installed this on both win2012 and RHEL6.
Thanks.

Yes. See https://access.redhat.com/site/articles/111663 for supported configurations.

The "there are no other individual patches in use" restriction on individual patches presented at:

https://access.redhat.com/site/articles/625673

would have definitely not been workable for us to maintain a stable production environment at times in the past when there were numerous one-off fixes needed within a relatively short time frame. It seems that if there are multiple critical individual fixes needed that meet the other criteria then RedHat should provided an individual patch that combines the fixes or else change the policy to support multiple individual fixes.

You can look back on the number of patches for previous releases that were simply to combine one or more conflicting one-off fixes to get a sense for when this was necessary for conflicting changes, but much more common in our case is when two non-conflicting one-off patches are applied to the same version. The new policy would seem to prevent that.

Scott

Scott, you raise some good points and I've requested someone reach out to you regarding these.

Will a cumulative patch also take us from 6.2 to 6.3 or will that still be a new install to upgrade?

I don't believe it will Todd. A new install will still be required to upgrade the server but there may be an option for this. I'll double check and update here if needs be.

In researching a defect we discovered in EAP 6.2, I discovered the following RedHat KB article (https://access.redhat.com/solutions/1158363) which states:

"With the release of JBoss EAP 6.3 on August 6th, 2014, the maintenance stream for EAP 6 shifted to EAP 6.3 for various reasons. Unfortunately, there will be no further cumulative patch updates for EAP 6.2."

The 6.2 patching policy documents (https://access.redhat.com/articles/547663, https://access.redhat.com/articles/625673, https://access.redhat.com/articles/547673) include the following statements:

  • Individual Patches (formerly ”one-off patches”) will only be provided if “there are no other individual patches in use”
  • “The application of multiple individual patches in a single environment may lead to unanticipated product configurations which can lead to unexpected behavior.”
  • “An individual patch addresses a single issue and is not not [sic] tested in combination with any other patches.”

This means we effectively get a maximum of one IP after the last CP is released. I opened a case to clarify and was told that it was in fact accurate that there would be no new CPs for EAP 6.2. In my opinion the combination of no new Cumulative Patches for previous minor versions and a practical maximum of one Individual Patch means that the effective actively patched lifecycle for each EAP 6.x minor release is about 7 months. In my opinion this stands in stark contrast to previous EAP minor revisions, and I did some research to understand the effective patched lifetimes of previous EAP versions better:

4.2: Jun 2007 (release) - April 2010 (CP 09) 34 months active support
4.3: Jan 2008 (release) - Sept 2011 (CP 10) 44 months active support
5.0: Nov 2009 (release) - March 2013 (last patch) 38 months active support
5.1.0: Sep 2010 (release) – March 2014 (last patch) 41 months active support
5.2.0: Jan 2013 (release) - (still the active branch and being patched), at least 21 months active support, likely significantly longer

6.2: Dec 2013 (release) - June 2014 (CP 04) 7 months active support

I find a fairly stark difference in effective version lifetimes with this new policy. The effective lifetime of EAP 6.3 promises to be about the same as EAP 6.2 since I believe EAP 6.4 is planned to be released in November or December 2014, after which I believe the current plan is for no new EAP 6.3 CPs. RedHat contends in the case I opened that patching has always been “single stream”, but I did some research to understand that and do not believe it to be the case. I see significant overlap in active patching between previous versions:

6.0.1 released Dec 2012
6.1.0 released May 2013

By my count there were 44 patches for 6.0.1 released after 6.1.0 was released. Similar, compare 5.1.2 and 5.2

5.1.2 released Dec 2011
5.2.0 released Jan 2013

By my count there were 37 patches for 5.1.2 released after 5.2.0 was released. I can personally attest our organization ran for a long time with both 5.1.2 and 5.2, counting on those patches and getting fixes back ported to both versions.

In my opinion this patching policy is going to put us in a major bind attempting to field stable, patched production infrastructure for our major vendor applications and our shared infrastructure. Our ISVs typically certify on a specific minor version and are OK with cumulative patches on top of that but need to re-certify for a new minor version. I believe the new patching policy sets a pace that no vendor trying to bring a stable product to market can match and that large enterprises will be extremely hard pressed to keep pace with. As of today the EAP 6 versions our major ISVs are certifying on (6.0.1 and 6.2.0 for instance) are already out of date with no more cumulative fixes coming and us needing to beg for Individual Patches. Even if we are able to get patches they will put us on an untested path and introduce a likelihood of system instability. Neither application is even close to performance or production deployments where we are most likely to uncover container defects. That does not seem like an acceptable risk to me, and so I am raising this issue to the community to get more visibility.

I think the new patching policy would be easier to swallow if the JBoss EAP defect rate was lower, but we have encountered dozens of significant production-impacting defects in EAP 5.2 and continue to do so. We've hit over a dozen critical defects in EAP 6.x and have literally zero applications in production yet. This lack of quality means we need to be greatly concerned with the patching policy. I cannot think of any other enterprise software vendor that expects customers to do a "full install" replacement about every seven months to be able to keep a supported/patched infrastructure.

Stated plainly, I believe the EAP 6.2+ patching policy as it is being implemented significantly reduces the value of our EAP support contract and significantly increases the migration effort that will be required from enterprise customers to maintain supported and actively patched infrastructure. Our message to RedHat has been that we want to avoid no-value infrastructure migration cost and it seems like this policy does the opposite of that and directly increases EAP total cost of ownership by mandating significant and frequent migrations.

I’m am interested to understand if other customers are aware of these ramifications of the 6.2+ patching policy, what sort of impacts they expect it might have and how they are mitigating the risk.

Regards,

Scott