[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: build-debian-cloud python version preview



On 30 July 2013 13:00, olivier sallou <olivier.sallou@gmail.com> wrote:
Hi,
I just wanted to let you know that I am having progress at building an open nebula (raw image) image with your scripts.
Architecture of your scripts are really fine to use common stuff while getting possibility to extend it easily. It really works fine.

For the moment I still use a dedicated provider directory with a copy of ec2 provider with some customization. Once everything is ok, I plan to see which tasks could be a "common" set of tasks to place them in common and keep specific stuff in my provider. I will not touch however the ec2 part to avoid breakage.

Olivier


2013/7/9 Anders Ingemann <anders@ingemann.de>
On 9 July 2013 08:35, olivier sallou <olivier.sallou@gmail.com> wrote:
>
>
>
> 2013/7/8 Anders Ingemann <anders@ingemann.de>
>>
>> Hi everybody
>>
>> The first preview release of my python version of the
>> build-debian-cloud bootstrapper is ready and available at
>> https://github.com/andsens/build-debian-cloud/tree/python
>
>
> Thanks for the preview. I gonna have a look at the scripts. I plan to test
> it and add things for OpenNebula.
>
> One remark however.
> You put tasks and assets scripts in a provider dir (ec2 and future ones..).
> this means that we will need to "clone" tasks that would be common to all
> providers.
>
> Could the tasks be in a more global dir (possibly with sub dir for very
> specific tasks) like below (just for example)
>
> tasks/
>         -- bootstrap.py
>         --/ec2
>                 --/ebs.py
>
> Olivier
>
>
>
>>
>> I would welcome any suggestions for improvement.
>> Keep in mind that this is not a stable release, a lot of polishing is
>> needed before that can happen.
>>
>> Some of the features are:
>>
>> * The desired image is configured entirely via a JSON manifest file
>>   * Manifests are validated by a json schemas
>>   * Support comments
>> * Proper support for different providers
>> * The task based system has been completely revamped
>>   * Higher granularity increases reusability of tasks across providers
>>   * Tasks are neatly organized into modules
>>   * A task dependency graph is built to determine the execution order
>> * Support for rollback actions if something fails
>> * Logfiles
>> * All output from invoked subprocesses is logged
>>
>> This is version actually works (!), you can bootstrap an image by running
>> ./build-debian-cloud manifests/ec2-ebs-pvm.manifest.json
>>
>> Anders
>>
>>
>> --
>> To UNSUBSCRIBE, email to debian-cloud-request@lists.debian.org
>> with a subject of "unsubscribe". Trouble? Contact
>> listmaster@lists.debian.org
>> Archive:
>> CAMcOGXEZp7FdPa2TxV2J0xCWE8K-i9+cstUwBSkvkLzWAPF6MA@mail.gmail.com" target="_blank">http://lists.debian.org/CAMcOGXEZp7FdPa2TxV2J0xCWE8K-i9+cstUwBSkvkLzWAPF6MA@mail.gmail.com
>>
>
>
>
> --
>
> gpg key id: 4096R/326D8438  (keyring.debian.org)
>
> Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Hi Olivier

I actually forgot to mention that. Right now *all* tasks are in the
ec2 provider dir, I did this because making tasks generic from the
get-go would make no sense.
With only one provider there wasn't a pattern to generalize from.
If you think anything can be reused, feel free to rip the guts out of
the ec2 provider and stick it in the common/ folder.
There should probably be a task/ folder in there instead of a simple
module. Same goes for assets I guess.



--
gpg key id: 4096R/326D8438  (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

> Architecture of your scripts are really fine to use common stuff while getting possibility to extend it easily. It really works fine.
Yes! That was my aim, great to hear :-)

> Once everything is ok, I plan to see which tasks could be a "common" set of tasks to place them in common and keep specific stuff in my provider. I will not touch however the ec2 part to avoid breakage.
I think this is the way to go. Let's get a running version first and then see what parts can be merged. Please note I implemented the S3 bootstrapper as well, so we might have even more common tasks now (loopback volume etc.).

Reply to: