Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1150580

Summary: Failure when removing security domain configuration in the ejb-security-interceptors quickstart
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: Nikoleta Hlavickova <nziakova>
Component: QuickstartsAssignee: Stuart Douglas <sdouglas>
Status: CLOSED CURRENTRELEASE QA Contact: Nikoleta Hlavickova <nziakova>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 6.4.0CC: bsutter, darran.lofthouse, jkudrnac, kkhan, nziakova
Target Milestone: DR10Keywords: Regression
Target Release: EAP 6.4.0Flags: sgilda: needinfo-
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-08-19 12:42:37 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
CLI script - configure security domain
none
CLI script - remove security domain none

Description Nikoleta Hlavickova 2014-10-08 13:02:10 UTC
Description of problem:
{"JBAS014653: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-2" => "JBAS014762: Removing services has lead to unsatisfied dependencies:
Service jboss.outbound-socket-binding.ejb-outbound was depended upon by service jboss.remoting.endpoint.subsystem.outbound-connection.ejb-outbound-connection"}}

Version-Release number of selected component (if applicable):
EAP 6.4.0.DR4

How reproducible:
always

Steps to Reproduce:
1. follow instructions in the quikstart's readme file
2. Remove the Security Domain Configuration by Running the JBoss CLI Script

Actual results:
failure, see above

Expected results:
security domain is successfully removed

Comment 5 sgilda 2014-10-10 14:13:56 UTC
Reassigning to Darran at his request.

Comment 7 Darran Lofthouse 2014-10-15 10:30:00 UTC
Ok the good news is to reproduce the error only running the two CLI scripts is required, deploying, running and undeploying the quickstart is not required.

Comment 8 Nikoleta Hlavickova 2014-10-15 11:39:05 UTC
Created attachment 947191 [details]
CLI script - configure security domain

Comment 9 Nikoleta Hlavickova 2014-10-15 11:39:34 UTC
Created attachment 947192 [details]
CLI script - remove security domain

Comment 10 Nikoleta Hlavickova 2014-10-15 11:40:39 UTC
Attached the 2 CLI scripts from quickstarts.

Comment 11 Darran Lofthouse 2014-10-15 11:58:19 UTC
Stuart, I am passing this your was as it appears to be a side effect of a change you made for the following commit: -

https://github.com/jbossas/jboss-eap/commit/cd54777b0bbde9d0b0e6ebc0c65584df2d06933f

You can see the attached CLI scripts but essentially the problem is the following two commands that are executed within a batch: -

/subsystem=remoting/remote-outbound-connection=ejb-outbound-connection:remove
/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=ejb-outbound:remove

The change that you have made means the runtime step of the first operation only occurs if context.isResourceServiceRestartAllowed() is true - previously it occurred regardless.

The remove step for the second operation is run regardless without checking that value.  This is what is leading to the service dependency issue.

Maybe the same change needs to be made to the 'remote-destination-outbound-socket-binding' - in the affected CLI script we are already recommending running in a batch followed by a reload.

Comment 12 Stuart Douglas 2014-10-15 22:49:00 UTC
Any change that removes services should require the allow-resource-service-restart header to take effect. I think the solution here is to make the same change to the outbound socket remove.

Comment 14 Darran Lofthouse 2014-10-16 09:35:14 UTC
+1 @stuart, I think your original changes are fine - the part that is now missing is that there are additional services that need to be given the same treatment.

I would recommend that any service that can be set as a dependency of the services affected so far is given the same treatment otherwise additional variations of this error could occur.

@sande No in this case Stuart is suggesting additional changes to our codebase which make sense - then end result would be that the script would begin to work again.  In general unless it can be demonstrated a script is flawed the quickstart scripts should not be modified for subsequent EAP changes unless they are going to take advantage of new configuration capabilities - these are the scripts we recommend customers use as a template so we have to assume they may have done that.

Comment 15 sgilda 2014-10-16 14:21:37 UTC
@darran: Thanks for the clarification. I agree that we need to fix any flawed scripts, so let me know if you find any. 

I will wait for word from you and @stuart that the fix is in.

Comment 19 sgilda 2014-11-10 23:28:56 UTC
Based on the pull above, I will mark this as ready for retest in DR10.

Comment 22 Nikoleta Hlavickova 2014-11-24 07:33:49 UTC
Verified with EAP 6.4.0.DR10.