Bug 790467

John, can you comment on effort required here?

I believe that the script in the master branch actually is not the most current version. I will double check and update this bug accordingly. The questions from Aleksnadar are still relevant though. A little background is necessary. That script was written with the intent for distribution of AMIs built in brew. The agent was to be packaged as an RPM and installed into /usr/share/jboss-on-<version>/agent. Agent preferences would be stored in /var/lib/jon-agent/data instead of the default location of ~/.java/.userPrefs. 


Those AMIs would be preconfigured with the JON agent. The value of JON_SERVER_URL  is expected to come from user-defined data passed to the machine instance at start up. The URL is expected to be either the private IP address or host name of the JON server. 

JON_AGENT_NAME is set to the INSTANCE_ID because the agent name needs to be unique and consistent across machine restarts as the agent name is used as the resource key for the host machine. The machine host name or IP address should not be used for the agent name.

If you have not already you may want to review http://rhq-project.org/display/JOPR2/Running+RHQ+in+EC2 for additional info on running in EC2.

(In reply to comment #3)
> I believe that the script in the master branch actually is not the most current
> version. I will double check and update this bug accordingly. The questions
> from Aleksnadar are still relevant though. A little background is necessary.
> That script was written with the intent for distribution of AMIs built in brew.
> The agent was to be packaged as an RPM and installed into
> /usr/share/jboss-on-<version>/agent. Agent preferences would be stored in
> /var/lib/jon-agent/data instead of the default location of ~/.java/.userPrefs. 

Very good, exactly our use case :)

> 
> Those AMIs would be preconfigured with the JON agent. The value of
> JON_SERVER_URL  is expected to come from user-defined data passed to the
> machine instance at start up. The URL is expected to be either the private IP
> address or host name of the JON server. 

Same here, users would configure AMI through user data. One concern I have though is that some information might not be available before starting the instance, for example IP address of agent (i.e. machine has more than 1 network interface or has VPN connections).

It would be good if it is made possible for user to put the configuration in a local filesystem file where the init script can read it. If you like we can talk or chat about this.

> JON_AGENT_NAME is set to the INSTANCE_ID because the agent name needs to be
> unique and consistent across machine restarts as the agent name is used as the
> resource key for the host machine. The machine host name or IP address should
> not be used for the agent name.

I believe INSTANCE_ID is a good default but I don't see any reason to limit user choice. It isn't hard to allow an override if provided by user.

> If you have not already you may want to review
> http://rhq-project.org/display/JOPR2/Running+RHQ+in+EC2 for additional info on
> running in EC2.

I know about this already, nice doc.

Thank you for looking into this issue!

I just committed the most recent version of the wrapper script to master. The commit hash is 27abe2b95ec5cac4971d5580b04d11a0a0570291. I wouldn't be surprised if you do run into problems with the script as it has not been used in some time.

Can you please summarize what exactly it is you want to do? The script was developed with the intent to provide for as close to zero configuration as possible so that when a user starts up an EAP AMI for example, the agent automatically starts up, connects to a JON server, and starts managing the EAP server, all with minimal to no manual user intervention.

Having the IP address of the agent machine before start up should not be an issue. You only need to know the JON server machine address. When the agent starts, it initiates a registration process with the JON server. The agent sends its IP address, among other things, to the server as part of that registration process. This registration process occurs every time the agent starts; so, if the IP address does change, the agent will send its current IP address to the server. In my investigation, I did not cover scenarios involving like VPN connections. I am not saying it is unimportant; rather, I just didn't have the time to cover some of these other situations.

As for putting the agent config file in a location that can be read by an init script and as for using something other than the INSTANCE_ID for the agent name, this is already possible. If you start the agent manually using the rhq-agent.sh script with the --cleanconfig option, you will be prompted to supply values for agent address, name, and server address. Those values are then stored in a java preferences file and used when the agent restarted in the future. Now it may be the case that the rhq-agent-wrapper-ec2 script is not checking to see if those preferences are already on the file system. If that is the case, the script could certainly be updated.

Setting this issue back to Target Release of JON3.0.1, so it can be considered for work in the short term.

I just realized that I did not push the commit. It has just now been pushed to the remote repo. See http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=3dc307d3649b404e7e4ee40781a51b91d8fde306.

Alek: "Can you please summarize what exactly it is you want us to do?"

Alek, take a look at http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=49c603c03da29e62db36cb719f30bc47bfb61ed9. It is the latest commit which is just a file renaming. The location from the project root is modules/enterprise/agent/src/etc/rhq-agent-wrapper-ec2.sh.

Unable to assign to the jon3.0.1 release until the changes required for this issue are clarified

triage to jon 3.1

Created attachment 566088 [details]
patch for rhq-agent-wrapper-ec2.sh

Please find attached a patch to the init script. As far as my testing goes, it should be flexible, yet retains original behavior if user does not need the additional features.

triage to jon 3.01 per asantos, crouch, mfoley, loleary

I think the patch in comment 13, and from my perspective, the important thing is to test to make sure everything works across agent machine restarts.

Please disregard comment 15. I have looked over the patched submitted in comment 13. It looks fine to me. From my perspective, the most important thing is to ensure that the script works across machine restarts. I am referring to the machines on which the agent runs, not the RHQ server And by working, I mean that the agent maintains connectivity with the JON server without manual intervention after the machine and agent restarts.

Aleksandar can you confirm you've tested the script as John describes in Comment 16, and that everything works as expected.

I have tested restarting the agent with this script. Connectivity is maintained as long as long as settings in the file stay correct.

Alek, but did you test across machine restarts?

Tested it works across restarts. Actually it handles changes of EC2 instance IP across stop/start cycles gracefully (when agent IP is NOT hardcoded of course).

Great, lets get this script into the next 3.0.1 build

This is in the latest RC 6 build available from here:

https://brewweb.devel.redhat.com//buildinfo?buildID=201462

Moving to ON_QA.

No action items for JON QE per comment #2.

Marking this VERIFIED per comment #20.

I don't see the patch applied to the RPM built into the brew buildID=201462. Can that be fixed?

This is fixed in build:
https://brewweb.devel.redhat.com//buildinfo?buildID=209751

Moving to ON_QA

Aleksandar, can you retest this build and report back on whether the fix works correctly in your environment?