Currently, configserver will not work with conductor if they're both on the same box because they're both going to compete for port 443. We need to amend this issue. <weshay_hm> segfault, you guys mentioned that config server and conductor "can not be" or "shouldnt be" on the same server <segfault> weshay_hm, cannot be, because of a conflict on port 443 <weshay_hm> k.. makes sense <hewbrocca> segfault: that's gonna be an issue <segfault> hewbrocca, how so? <hewbrocca> we're being asked to make everything work on one box
adding ce-sprint-next bugs to ce-sprint tracker for this release
I thought we decided we weren't going to try to support this for 1.0? Should this really be a blocker?
we'll talk about it next triage
History... jrd 2011-12-16 11:20:34 EST Status NEW ASSIGNED not good.. moving back to new.. this is a CF-1.0.0 issue
holy type.. I mean CF-1.1.0 sorry.. stupid fingers
holly typo... man I need a new keyboard... In summary... Dont mess w/ this bug until we start work on CF-1.1.0
Updating version to 1.0 (found in version)
Think this should have had QE ack. moving it back.
The fix for this bug is to allow the aeolus-configserver-setup tool to configure configserver to setup apache configs in conductor's apache dropfile location, if aeolus-configserver-setup realizes that it's being run on a box where conductor is installed and setup. The user flow for setting up configserver and conductor on the same box becomes: 1) install aeolus-all 2) install aeolus-configserver 3) run aeolus-configure [-p PROFILE] 4) run aeolus-configserver-setup The change for aeolus-configure to create an apache dropfile location will be released with 1.1. So, upgrading aeolus-configure is a prereq for this to work.
https://github.com/aeolusproject/audrey/commit/aed50d0f9a229535dce9052163dd3d2e94d9e845
Configuration works, but cannot add the configserver into conductor. The following error is observed: Could not validate Config Server connection (url: https://hp-sl390s-01.rhts.eng.bos.redhat.com/configserver/). 404: Not Found One note is that I inputted https://hp-sl390s-01.rhts.eng.bos.redhat.com/configserver/ into the field initially. But when the error occurred, the url modified to https://hp-sl390s-01.rhts.eng.bos.redhat.com/configserver (note, last "/" has been stripped out).
Conductor POST: https://github.com/aeolusproject/conductor/pull/79 Configserver COMMIT: https://github.com/aeolusproject/audrey/commit/b3e32376f61d8d33e16c5d4a55f9b188488c020b Configserver BREWED: https://brewweb.devel.redhat.com/taskinfo?taskID=4913135 The problem was two-fold: 1) Conductor was not correctly constructing the request to a configserver when the configserver service was not running the server's root context. In other words, conductor always expected configserver to be running at https://servername/. 2) If the apache proxy pass for configserver was configured to run at a non-root context (i.e., https://servername/configserver/), then the configserver's service needed to run at the same non-root context (i.e., http://localhost:4567/configserver/) in order to preserve the request's original base path and keep oauth signature verification happy. With these patches, when the aeolus-configserver-setup script recognizes that the aeolus-configserver service is being installed alongside conductor, it will ensure that the service's root context matches the root context of the proxy pass in the apache configuration for configserver (http://localhost:4567/configserver/ will match https://servername/configserver/). Additionally, conductor will now correctly construct requests to the configserver even when the configserver is not running at a root context. Keeping the status of this change on "POST" until the Conductor change is reviewed and merged.
Fully testing this fix requires a rather specific setup. 1) Conductor installed and configured for rhev 2) Configserver installed and configured on the same box 3) The configserver added to the rhev provider account in conductor a) ensure that the server URL appears as: https://EXTERNAL_SERVER_FQDN/configserver 4) A deployable with services associated with the assembly(ies) 5) Image(s) built for the assembly(ies) in the deployable and pushed to rhev To test the fix, launch the deployable to the rhev provider account. Expected results: the instance(s) start up and configure as expected. Questions: Q. Why does it need to be rhev? A. It needs to be rhev (or vsphere) in order to ensure that the launched instances are able to access the configserver running alongside the conductor box. Instances launched in EC2 would not be able to reach back into an internal network to see the configserver for configuration data. Q. Where is a deployable with services? A. Some examples can be found in github (https://github.com/aeolusproject/audrey/tree/master/examples). The wordpress example is the most complete example. However, there are smaller examples in the "deployables" directory. Q. Where can I get the latest configserver (0.4.11)? A. Check the brew build location from comment #14. Q. The aeolus-configserver-setup script says to use "https://FQDN/configserver/" as the server URL. But the instructions above say to use "https://EXTERNAL_SERVER_FQDN/configserver". Where's the trailing slash? A. It's inconsequential whether you add the slash or not. However, conductor will trim the slash before saving the server URL.
Added Doc Text
Created attachment 618513 [details] output from aeolus-configserver-setup
Created attachment 618514 [details] configserver.conf from httpd
using aeolus-configserver-0.4.11-1.el6cf I'm still experiencing some troubles with the configserver validation, as per comment 13 """ Could not validate Config Server connection (url: https://qeblade22.rhq.lab.eng.bos.redhat.com/configserver). 404: Not Found """ The missing '/' at the end of the URL parsed from the web form seems to be causing the problem. btw, the configuration step completes successfully, see the attached aeolus-configserver-setup.out and configureserver.conf
Giulio, thanks for looking at this! did you update your conductor installation with the patch from comment #14: Conductor POST: https://github.com/aeolusproject/conductor/pull/79 Without that patch, conductor will not be able to correctly connect to the config server running on the same box.
Created attachment 618711 [details] audrey.log from target VM thanks for the head up, I applied the patch and the validation in conductor is now working still, instances deployed via conductor are failing in getting the params/values from the configserver; the the audrey.log attached from a target vm
works as expected, required a restart of delayed_job, not only thin (thanks Greg)
Unit tests pass; merging and pushing to master/1.1: commit e302f5ad8c481d1e4cc3b54be2ddd2fc42b854b2 Author: Greg Blomquist <gblomqui> Date: Wed Sep 26 21:30:21 2012 -0400 BZ 751088 (refix): Configserver and conductor on same box https://bugzilla.redhat.com/show_bug.cgi?id=751088 This patch changes the way conductor builds the request paths when talking with configserver. Previously, conductor assumed that configserver ran at the root context of the server (i.e., "http://configserver/"). Now, conductor can adapt to a configserver that runs at a non-root context (i.e., "http://servername/configserver"). (cherry picked from commit 6c6aa269ba5b3fb5e0a13fd4e1442110c510b7af)
Created attachment 620905 [details] adding configserver works [root@ibm-x3690x5-01 models]# rpm -qa | grep "conductor" aeolus-conductor-daemons-0.13.16-1.el6cf.noarch aeolus-conductor-0.13.16-1.el6cf.noarch aeolus-conductor-doc-0.13.16-1.el6cf.noarch [root@ibm-x3690x5-01 models]# rpm -qa | grep "configserver" aeolus-configserver-0.4.11-1.el6cf.noarch [root@10-16-120-185 ~]# cat /var/log/audrey.log 2012-10-03 09:37:58,157 - INFO : audrey:1351 Invoked audrey_script_main 2012-10-03 09:37:58,281 - INFO : audrey:1380 <Instance of: CSClient Version: 1 Config Server Endpoint: https://ibm-x3690x5-01.rhts.eng.bos.redhat.com/configserver Config Server oAuth Key: 717b26f6-0d5f-11e2-8cbd-00215e5d12a2 Config Server oAuth Secret: XCMeAqszN8zt5pVsAGRO0nmQW1E1GHukKcwW8QlebXj5hbikKV Config Server Params: Config Server Configs: Temporary Directory: Tarball Name: eot> 2012-10-03 09:37:58,282 - INFO : audrey:952 Invoked CSClient.get_cs_tooling() 2012-10-03 09:37:58,292 - INFO : audrey:684 Invoked unpack_tooling() 2012-10-03 09:37:58,296 - INFO : audrey:909 Invoked CSClient.get_cs_configs() 2012-10-03 09:38:33,110 - INFO : audrey:614 Execute Tooling command: /var/audrey/tooling/user/test/start 2012-10-03 09:38:33,114 - INFO : audrey:614 return code: 0 2012-10-03 09:38:33,114 - INFO : audrey:614 Start Output of: /var/audrey/tooling/user/test/start >>> Starting httpd: [ OK ] Wordpress should now be available at http://10.16.120.185/wordpress <<< End Output 2012-10-03 09:38:33,115 - INFO : audrey:924 Invoked CSClient.get_cs_params() 2012-10-03 09:38:33,189 - INFO : audrey:522 Invoked generate_provides() 2012-10-03 09:38:33,678 - INFO : audrey:939 Invoked CSClient.put_cs_params_values() [root@10-16-120-185 ~]#
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2012-1516.html