On 08/10/11 - 10:55:53PM, Adam Stokes wrote:
Please have a look at wiki page and feel free to post comments here
in
the ML or make changes to the wiki itself.
https://github.com/matahari/matahari/wiki/Integrating-with-Aeolus
How Matahari can improve current communication implementation
In this one scenario continuously polling for configuration changes could easily be
eleminated using Matahari's push/pull capabilities without the wasted cycles on
continously asking if changes are required.
The Audrey component to Aeolus is similar to our Sysconfig agent as it downloads the
necessary configuration items and executes a top level script to perform the system
changes on the instance. In this scenario we could again use Matahari's console/agent
approach to handle retrieving configuration items through url or a blob and with our
associated type run Audrey if applicable.
While this is true, I view the polling for configuration changes as not a very
big deal. The thing is that the instance is basically idle anyway, so having
it sit in a busy loop waiting for configuration is fine. It does
generate some additional load on the config server, but in the general case I
actually expect this time period to be fairly short; the conductor launches
all of the instances in a deployment simultaneously, so the delays are only
those from the backend cloud.
Basically this comes down to a tradeoff for initial configuration. We can
either:
1) Stick with the simple HTTP REST stuff for initial configuration, at the
expense of some polling, or
2) Use the more advanced QMF/Matahari stuff, at the expense of making it
more complicated and forcing all users to have QPID/QMF and Matahari
installed on their images
I feel like 1) is simpler to understand for users, and more flexible (any
operating system can do REST requests). However, I'm curious to see what
others think here.
--
Chris Lalancette