Description of problem: The CLI fails to change configuration for EAP's Network Interface child resource, if the same resource with the same name previously existed and then was removed. There is an inconsistency between CLI API and UI as the following scenarion only fails while using CLI. Version-Release number of selected component (if applicable): JON 3.2.1 DR02 + EAP 6.2.0 How reproducible: always Steps to Reproduce: 1. Using CLI create Network Interface as a child resource of EAP server and name it "myInterface" 2. Change the configuration of this interface (e.g. any-address:false, any-ipv4-address:true, any-ipv6-address:false) 3. Check the configuration and confirm that it was properly altered. 4. Remove this resource (myInterface). 5. Repeat steps 1-2 Actual results: Configuration is not changed Expected results: Configuration is changed Additional info: After following this scenario, if you check the configuration of "myInterface" using UI (just view the Configuration -> Current tab for this resource) and then try to change the configuration using CLI, it works.
How exactly do you do #3? Via CLI you can either load Live resource configuration or last known configuration from server (those may be out of sync for some while - this is possible bug) If you check it via UI then we load live configuration and store it to DB as last known. Resource configurations appear to survive resource deletion/re-creation. My theory is, that after you create a new resource (with same name/resource key) for the second time, server still has last known configuration from previous update and thus claims there's no need to update configuration, because they're same. Then when you go to UI, it causes the server to load & save live resource configuration (and since that it is up-to-date) so further change is evaluated as difference and applied.
I only used CLI in order to check the resource configuration in step #3. Sepcifically I alter the configuration using upadteConfiguration() call and then I check that it was altered using getConfiguration(). If I first view the configuration using UI and then attempt to change it using CLI it works.
Can you please attach to the BZ the CLI script for the test case? Thanks.
Thomas, here is the script I use for reproducing this BZ, it follows the steps from description of this BZ -> after creating the Network Interface "myInterface" and changing its configuartion for the second time the script will fail on assert while checking the changed configuration.
Created attachment 935403 [details] CLI script to reproduce the BZ
I'm fairly sure this is due to our [stupid] DELETED status we use for resources that are deleted (physically deleted) as opposed to uninventoried. The resource actually does not go away and maintains some of the attached information it had when it was alive, which gets re-applied if and when that resource is re-created. Since the script does a res.remove(), that equates to a Delete. So, when you create the resource again it actually "restores" the previous resource. I think this is likely working as expected, even if confusing. I'm unassigning Libor and moving to post-ga to free Libor for 3.3.0 work.
Without looking too closely, I think we should do one of two things here: 1) Finally take this as an opportunity to remove the DELETED status altogether. This inventory status does almost nothing for us and causes all kinds of problems and special-case code. See https://lists.fedorahosted.org/pipermail/rhq-devel/2011-March/000662.html for an old discussion on why it should be removed. 2) Find out where the conflict is and add more special-case code that makes the DELETED resource look as if it does not exist. And return something like ResourceNotFoundException in response to the config update. I really prefer option 1. If you want to look at doing that I don't think anyone will complain. Make sure if you go down that path that you look at all the predefined queries that may have that status built in.
Bug 1168890 is fixed in master, this bug should be fixed too
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions