future of Boxgrinder ... building cloud images

[R P Herrold]

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

[Mo Morsi]

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/01349...

[Andy Grimm]

On Tue, Dec 18, 2012 at 11:15 AM, R P Herrold <herrold(a)owlriver.com&gt; 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(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/cloud

[boxgrinder-dev] future of Boxgrinder ... building cloud images

[David Busby]

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(a)owlriver.com&gt; 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<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
>

[R P 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

[Matthew Miller]

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?


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Mo Morsi]

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

[Matthew Miller]

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.

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;