On 30 July 2013 13:00, olivier sallou <[email protected]> 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 <[email protected]> > >> On 9 July 2013 08:35, olivier sallou <[email protected]> wrote: >> > >> > >> > >> > 2013/7/8 Anders Ingemann <[email protected]> >> >> >> >> 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 [email protected] >> >> with a subject of "unsubscribe". Trouble? Contact >> >> [email protected] >> >> Archive: >> >> >> http://lists.debian.org/camcogxezp7fdpa2txv2j0xcwe8k-i9+cstuwbskvklzwapf...@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.).
