in the IRC channel, I am advised by 'msavy' that Boxgrinder is on a path to end as a project, and transition into: http://imgfac.org/
which uses underneath: oz https://github.com/clalancette/oz
Seemingly also, the former (and somewhat broken) appliance-creator goes away
My goal is to be able to get to an TUI tool: image building image that accepts kickstart config files as input, and emits runnable new images of various type, and it looked as though I could graft on the needed elements to Boxgrinder. There is a lot of churn, for example on the Fedora 'cloud' sig mailing list, and on corresponding Debian list, on what to include, or exclude from pre-built cloud images.
I think those 'cloud' working groups are solving the wrong problem at the wrong place, [some want JEOS to include a listening sshd, and package install tool; others want rsync, or man, or more, or less ... the preferences never end and there is no 'right answer']
An: image building image decouples those design preferences and moves solving those issues into a flat text specification ( a 'ks.cfg', etc) that will work well in a version control system (unlike using a GUI front end which does not)
-- Russ herrold
On 12/18/2012 11:15 AM, R P Herrold wrote:
I think those 'cloud' working groups are solving the wrong problem at the wrong place, [some want JEOS to include a listening sshd, and package install tool; others want rsync, or man, or more, or less ... the preferences never end and there is no 'right answer']
Not sure if this is on or off topic, but I wrote a tool [1] to demo deltacloud [2] on fedora-devel [3] a little while back
It uses the same tdl format oz does to setup a specified config on the cloud. In retrospect, I made the tool too complicated, instead of manually parsing the TDL, what I should have done is just use Oz once the instance is setup w/ deltacloud.
If nothing else this would give us a very quick way to test out the imagefactory templates without waiting for the long and bandwidth intensive image building process.
If anyone is interested in this please just +1 the idea here (a few people did so privately in response to this email [4]).
Give me a small team (a coder, tester, packager, and promoter) and I can make this happen and have it done rather quickly. I can do it myself but it will take longer as I have committed to other work at the time being.
(note I will be on break w/ all other US RH associates next week).
-Mo
[1] https://github.com/movitto/mycloud/blob/master/mycloud.rb [2] http://deltacloud.apache.org/ [3] http://lists.fedoraproject.org/pipermail/devel/2012-November/173298.html [4] https://lists.fedorahosted.org/pipermail/aeolus-devel/2012-December/013491.h...
On Tue, Dec 18, 2012 at 11:15 AM, R P Herrold herrold@owlriver.com wrote:
in the IRC channel, I am advised by 'msavy' that Boxgrinder is on a path to end as a project, and transition into: http://imgfac.org/
which uses underneath: oz https://github.com/clalancette/oz
Seemingly also, the former (and somewhat broken) appliance-creator goes away
appliance-creator going away is somewhat separate, because (as I'm told) it's functionality is being rolled into lorax, which more tightly couples it to anaconda. For your desired kickstart-based approach to image building, which I also prefer, there may be some merit to doing this.
My goal is to be able to get to an TUI tool: image building image that accepts kickstart config files as input, and emits runnable new images of various type, and it looked as though I could graft on the needed elements to Boxgrinder. There is a lot of churn, for example on the Fedora 'cloud' sig mailing list, and on corresponding Debian list, on what to include, or exclude from pre-built cloud images.
I think those 'cloud' working groups are solving the wrong problem at the wrong place, [some want JEOS to include a listening sshd, and package install tool; others want rsync, or man, or more, or less ... the preferences never end and there is no 'right answer']
+1 ... those conversations are mostly just bikeshedding. In an ideal world, users will be comfortable enough with image building that having an "official" image will be mostly meaningless. I think that the world of cloud users isn't quite there yet, for whatever reason. What we provide them as a default image in the meantime should be a useful set of packages, not an absolutely minimal one, but that's the not goal being pursued.
An: image building image decouples those design preferences and moves solving those issues into a flat text specification ( a 'ks.cfg', etc) that will work well in a version control system (unlike using a GUI front end which does not)
To be fair, the GUI front-end could be creating text artifacts and shoving them into a version control system; that's exactly what rPath/rBuilder did years ago, and I suspect SuSE Studio does as well. I haven't looked at Image Factory yet, but if it's not doing this, I suspect it won't be interesting to very many people. Also, FWIW, the reason given on the cloud list for the move toward oz was the need to build images for other OSes and distros. The requirements of a tool for cross-distro image builds is quite different from what you (and I) want, and I'm actually happy to see them be clearly separated, to be honest. Today I happily use ami-creator, and someday I may happily use lorax; I'm simply not the target audience for Image Factory / Oz, and that's okay.
Andy
-- Russ herrold _______________________________________________ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud
On Tue, Dec 18, 2012 at 11:32:09AM -0500, Andy Grimm wrote:
+1 ... those conversations are mostly just bikeshedding. In an ideal world, users will be comfortable enough with image building that having an "official" image will be mostly meaningless. I think that the world of cloud users isn't quite there yet, for whatever reason. What we provide them as a default image in the meantime should be a useful set of packages, not an absolutely minimal one, but that's the not goal being pursued.
I'm unclear on what you mean here. What is not the goal being pursued, by whom?
Hi Russ,
I think you'll find it hard to get any traction here kickstarts especially in the "cloud front" are used increasingly less in favour of bootstrapping an instance with puppet / chef for provisioning above and beyond the base os.
The tdl format is somewhat of a stop gap between kickstarts and fully fledged provisioning I have found, and a good project providing many example tdls is the Aeolus project: http://www.aeolusproject.org/
Myself I have gone the way of kickstarts -> boxgrinder -> oz -> puppet.
Also of note, puppet manifests as they use a ruby DSL version control very well, I can not vouch for chef however.
Cheers
David
On Tue, Dec 18, 2012 at 4:15 PM, R P Herrold herrold@owlriver.com wrote:
in the IRC channel, I am advised by 'msavy' that Boxgrinder is on a path to end as a project, and transition into: http://imgfac.org/
which uses underneath: oz https://github.com/**clalancette/ozhttps://github.com/clalancette/oz
Seemingly also, the former (and somewhat broken) appliance-creator goes away
My goal is to be able to get to an TUI tool: image building image that accepts kickstart config files as input, and emits runnable new images of various type, and it looked as though I could graft on the needed elements to Boxgrinder. There is a lot of churn, for example on the Fedora 'cloud' sig mailing list, and on corresponding Debian list, on what to include, or exclude from pre-built cloud images.
I think those 'cloud' working groups are solving the wrong problem at the wrong place, [some want JEOS to include a listening sshd, and package install tool; others want rsync, or man, or more, or less ... the preferences never end and there is no 'right answer']
An: image building image decouples those design preferences and moves solving those issues into a flat text specification ( a 'ks.cfg', etc) that will work well in a version control system (unlike using a GUI front end which does not)
-- Russ herrold
On Tue, 18 Dec 2012, David Busby wrote:
I think you'll find it hard to get any traction here kickstarts especially in the "cloud front" are used increasingly less in favour of bootstrapping an instance with puppet / chef for provisioning above and beyond the base os.
well known, but the non-idempotent, and 'successive approximation' nature of such solutions converging to a configuration makes such tools less compelling than a using kickstart against a 'repoclosed' universe of packages.
I am interested in the building of 'base JEOS' images to our virtualization service, that are then handed off as 'gold masters' for clinets who THEN inject their certificates, keys and credentials. There are of course security and liability implications in releasing images keyed to masters not known to the end user, and kickstart solves them well, and the devops tools less well
The tdl format is somewhat of a stop gap between kickstarts and fully fledged provisioning I have found, and a good project providing many example tdls is the Aeolus project: http://www.aeolusproject.org/
I am generally aware of it as a project, and I think follow a blog on the matter, but not a mailing list. I'll remedy that and read for a bit. But packaging Ruby has been a 'bear' and seemed to be 'not well solved' yet. I have no aversion to Ruby -- we use it on a project internally -- but adding random 'gems' not well understood as to versioning and security model, is troubling
-- Russ herrold
On 12/18/2012 12:38 PM, R P Herrold wrote:
I am generally aware of it as a project, and I think follow a blog on the matter, but not a mailing list. I'll remedy that and read for a bit. But packaging Ruby has been a 'bear' and seemed to be 'not well solved' yet. I have no aversion to Ruby -- we use it on a project internally -- but adding random 'gems' not well understood as to versioning and security model, is troubling
Related, I've been mentoring students hacking on the http://www.isitfedoraruby.com/ website to bring some sanity to the world of the ruby platform.
Have been meaning to send an update to fedora-devel and the ruby-sig mailing list for the longest time, but keep getting sidetracked (ya'll know what thats like ;-) ).
-Mo
On Tue, Dec 18, 2012 at 11:15:53AM -0500, R P Herrold wrote:
I think those 'cloud' working groups are solving the wrong problem at the wrong place, [some want JEOS to include a listening sshd, and
I think right now, we need to do both.