+++ This bug was initially created as a clone of Bug #817114 +++ Created attachment 580828 [details] multi_assemblies_deployable The attached deployable is used to launch 2 instances. Notice that the first assembly have a <services> block and the second does not. In theory, the second instance should not have made contact with configserver because it does not contain <services>. But that's not what happened: drwx------. 2 aeolus aeolus 4.0K Apr 26 16:38 958766c0-8fdf-11e1-879a-00215e203950 drwx------. 2 aeolus aeolus 4.0K Apr 26 16:38 957fa28c-8fdf-11e1-879a-00215e203950 drwx------. 2 aeolus aeolus 4.0K Apr 27 14:15 f4b0610a-9094-11e1-879a-00215e203950 drwx------. 128 aeolus aeolus 12K Apr 27 14:15 . drwx------. 2 aeolus aeolus 4.0K Apr 27 14:15 f4a87882-9094-11e1-879a-00215e203950 [root@ip-10-243-149-216 instances]# pwd /var/lib/aeolus-configserver/configs/instances [root@ip-10-243-149-216 instances]# As a result, this would lead to the following traceback from configserver: oauth_nonce=94162343&oauth_timestamp=1335550654&oauth_consumer_key=f4b0610a-9094-11e1-879a-00215e203950&oauth_signature_method=HMAC-SHA1&oauth_version=1.0&oauth_signature=jXq%2B%2FMtSGHSCXL2Onbff9O jqTew%3D&audrey_data=%7C%26%7C NoMethodError - undefined method `key?' for nil:NilClass: ./lib/config_handler.rb:182:in `update' /usr/lib/ruby/site_ruby/1.8/nokogiri/xml/node_set.rb:239:in `each' /usr/lib/ruby/site_ruby/1.8/nokogiri/xml/node_set.rb:238:in `upto' /usr/lib/ruby/site_ruby/1.8/nokogiri/xml/node_set.rb:238:in `each' ./lib/config_handler.rb:180:in `update' ./lib/config_handler.rb:173:in `each' ./lib/config_handler.rb:173:in `update' ./configserver.rb:225:in `PUT /params/:version/:uuid' /usr/lib/ruby/gems/1.8/gems/sinatra-1.2.6/lib/sinatra/base.rb:1151:in `call' /usr/lib/ruby/gems/1.8/gems/sinatra-1.2.6/lib/sinatra/base.rb:1151:in `compile!' /usr/lib/ruby/gems/1.8/gems/sinatra-1.2.6/lib/sinatra/base.rb:724:in `instance_eval' /usr/lib/ruby/gems/1.8/gems/sinatra-1.2.6/lib/sinatra/base.rb:724:in `route_eval' /usr/lib/ruby/gems/1.8/gems/sinatra-1.2.6/lib/sinatra/base.rb:708:in `route!' /usr/lib/ruby/gems/1.8/gems/sinatra-1.2.6/lib/sinatra/base.rb:758:in `process_route' /usr/lib/ruby/gems/1.8/gems/sinatra-1.2.6/lib/sinatra/base.rb:755:in `catch' /usr/lib/ruby/gems/1.8/gems/sinatra-1.2.6/lib/sinatra/base.rb:755:in `process_route' /usr/lib/ruby/gems/1.8/gems/sinatra-1.2.6/lib/sinatra/base.rb:707:in `route!' /usr/lib/ruby/gems/1.8/gems/sinatra-1.2.6/lib/sinatra/base.rb:706:in `each' /usr/lib/ruby/gems/1.8/gems/sinatra-1.2.6/lib/sinatra/base.rb:706:in `route!' /usr/lib/ruby/gems/1.8/gems/sinatra-1.2.6/lib/sinatra/base.rb:843:in `dispatch!' /usr/lib/ruby/gems/1.8/gems/sinatra-1.2.6/lib/sinatra/base.rb:644:in `call!' /usr/lib/ruby/gems/1.8/gems/sinatra-1.2.6/lib/sinatra/base.rb:808:in `instance_eval' /usr/lib/ruby/gems/1.8/gems/sinatra-1.2.6/lib/sinatra/base.rb:808:in `invoke' /usr/lib/ruby/gems/1.8/gems/sinatra-1.2.6/lib/sinatra/base.rb:808:in `catch' /usr/lib/ruby/gems/1.8/gems/sinatra-1.2.6/lib/sinatra/base.rb:808:in `invoke' /usr/lib/ruby/gems/1.8/gems/sinatra-1.2.6/lib/sinatra/base.rb:644:in `call!' /usr/lib/ruby/gems/1.8/gems/sinatra-1.2.6/lib/sinatra/base.rb:629:in `call' /usr/lib/ruby/gems/1.8/gems/rack-1.3.0/lib/rack/head.rb:9:in `call' /usr/lib/ruby/gems/1.8/gems/rack-1.3.0/lib/rack/commonlogger.rb:18:in `call' /usr/lib/ruby/gems/1.8/gems/rack-1.3.0/lib/rack/methodoverride.rb:24:in `call' /usr/lib/ruby/gems/1.8/gems/sinatra-1.2.6/lib/sinatra/base.rb:1272:in `call' /usr/lib/ruby/gems/1.8/gems/sinatra-1.2.6/lib/sinatra/base.rb:1303:in `synchronize' /usr/lib/ruby/gems/1.8/gems/sinatra-1.2.6/lib/sinatra/base.rb:1272:in `call' /usr/lib/ruby/gems/1.8/gems/rack-1.3.0/lib/rack/urlmap.rb:52:in `call' /usr/lib/ruby/gems/1.8/gems/rack-1.3.0/lib/rack/urlmap.rb:46:in `each' /usr/lib/ruby/gems/1.8/gems/rack-1.3.0/lib/rack/urlmap.rb:46:in `call' /usr/lib/ruby/gems/1.8/gems/thin-1.2.11/lib/thin/connection.rb:84:in `pre_process' /usr/lib/ruby/gems/1.8/gems/thin-1.2.11/lib/thin/connection.rb:82:in `catch' /usr/lib/ruby/gems/1.8/gems/thin-1.2.11/lib/thin/connection.rb:82:in `pre_process' /usr/lib/ruby/gems/1.8/gems/thin-1.2.11/lib/thin/connection.rb:57:in `process' /usr/lib/ruby/gems/1.8/gems/thin-1.2.11/lib/thin/connection.rb:42:in `receive_data' /usr/lib/ruby/gems/1.8/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `run_machine' /usr/lib/ruby/gems/1.8/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `run' /usr/lib/ruby/gems/1.8/gems/thin-1.2.11/lib/thin/backends/base.rb:61:in `start' /usr/lib/ruby/gems/1.8/gems/thin-1.2.11/lib/thin/server.rb:159:in `start' /usr/lib/ruby/gems/1.8/gems/thin-1.2.11/lib/thin/controllers/controller.rb:86:in `start' /usr/lib/ruby/gems/1.8/gems/thin-1.2.11/lib/thin/runner.rb:185:in `send' /usr/lib/ruby/gems/1.8/gems/thin-1.2.11/lib/thin/runner.rb:185:in `run_command' /usr/lib/ruby/gems/1.8/gems/thin-1.2.11/lib/thin/runner.rb:151:in `run!' /usr/lib/ruby/gems/1.8/gems/thin-1.2.11/bin/thin:6 /usr/bin/thin:19:in `load' /usr/bin/thin:19 50.112.194.231 - - [27/Apr/2012 14:17:28] "PUT /params/1/f4b0610a-9094-11e1-879a-00215e203950 HTTP/1.1" 500 30 0.0057 HTTP/1.1 500 Internal Server Error --- Additional comment from gblomqui on 2012-05-04 14:03:28 EDT --- The conductor logic in parsing the deployable should not send configuration to the config server if an assembly doesn't have any services. This error shows up in the config server when conductor sends essentially empty configs to the config server for an assembly. This only happens when the deployable has 2 (or more) assemblies and one assembly has services and one assembly does not have services. --- Additional comment from jprovazn on 2012-05-29 09:06:14 EDT --- the patch sent: https://fedorahosted.org/pipermail/aeolus-devel/2012-May/010594.html --- Additional comment from jprovazn on 2012-05-29 09:14:37 EDT --- I wasn't able to reproduce the exception in configserver both with or without the patch - maybe because of different configserver version. Anyway the patch makes sure that empty configuration is not sent to configserver.
pushed to 1.0.1: commit d5815d0f4aca57ea44203a8e796b7b2e8a361a19 If an assambly doesn't define any configserver params, config for this assembly is not sent to configserver. https://bugzilla.redhat.com/show_bug.cgi?id=817114
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: The conductor logic in parsing the deployable should not send configuration to the config server if an assembly doesn't have any services. An error occurs in the config server when conductor sends empty configs to the config server for an assembly. This happens when the deployable has 2 (or more) assemblies and one assembly has services and one assembly does not have services.
Using the same blueprint with 2 deployables, one w/ <services> and one without. drwx------. 284 aeolus aeolus 20K Jun 19 14:11 . drwx------. 2 aeolus aeolus 4.0K Jun 19 14:11 3ff6f650-ba3a-11e1-ae66-e83935c21f2c [root@deaddonkey instances]# pwd /var/lib/aeolus-configserver/configs/instances No error has been detected in /var/log/aeolus-configserver/configserver.log
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/RHBA-2012-1063.html