On 07/27/2011 06:10 PM, Joseph VLcek wrote:
Greg Blomquist and I have put together an Audrey design document for the 0.4.0 effort.
It can be found here: http://www.aeolusproject.org/page/Audrey-Conductor_Integration_0.4.0
Although we would appreciate input from anyone I'm requesting review feedback from the following people: John Dunning Hugh Brock Chris Lalancette Mark McLoughlin Carl Trieloff Brian Kearney
I am asking that all feedback be provided by COB one week from today, August 3, 2011. We are already moving forward with some development according to the presented design so direction changing feedback would be greatly appreciated as early as possible. If anyone needs more time please let us know.
I tried to provide XML examples that align with the format outlined in past discussion. If I missed that please let me know.
Thank you, Joe and Greg
aeolus-devel mailing list aeolus-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/aeolus-devel
aeolus-devel mailing list aeolus-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/aeolus-devel
On Tue, 2011-08-02 at 10:05 -0400, Carl Trieloff wrote:
Few comments:
First, on services, the goal is to be able to bootstap the instance. I don't like httpd being used as an example as that could be interpreted as software config and not infra startup config. Nicer example are starting puppet, Matahari, mounting an NFS share etc.
Then,
"Audrey provided and user provided config tooling
Currently some config tooling is provide along with the Audrey Start code. In the future more could be added. If a conflict arises between user provided config tooling and Audrey provided for a particular service the user provided tooling will be used and the Audrey provided tooling will be ignored.
If the user provides a Top-Level configuration tooling executable all other tooling will be ignored."
This section does not seem correct. only case I can think of here is if the image came from an OVA source and has the OVA activation daemon. Then Audry should be able to run the OVA activation daemon, and then it's boot config. We should also be able to tell it to skip calling OVA activation daemon if required.
Carl.
Thank you for the feedback Carl.
Our proposal covers setting up httpd, connecting to a puppet master, or even setting up an nfs mount because we put the control into the hands of any scripting language.
The Top-Level script is optional. So I believe what we are proposing will also support the OVA case if the user wants that.
If I'm misunderstanding something please let me know.
Thank you, Joe