19:02:30 <gregdek> #startmeeting Eucalyptus Images meeting, 9 December 2011
19:02:30 <eucabot|test> Meeting started Fri Dec  9 19:02:30 2011 UTC.  The chair is gregdek. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:02:30 <eucabot|test> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:02:35 <gregdek> Nope.  :)
19:02:40 <gregdek> #chair hspencer
19:02:40 <eucabot|test> Current chairs: gregdek hspencer
19:02:43 * gholms is in multiple meetings at once :\
19:02:55 <gregdek> gholms: yeah. we should move this one.
19:03:07 <gregdek> #topic roll call
19:03:09 * gregdek is here
19:03:17 * sdziallas is new here, lurking.
19:03:18 * gholms takes a seat in the bleachers
19:03:25 <gregdek> #meetingname images
19:03:25 <eucabot|test> The meeting name has been set to 'images'
19:03:27 * hspencer is here
19:03:31 <gregdek> (gholms, did I do that right?)
19:03:32 <dak419> here
19:03:41 <gholms> gregdek: Yep :)
19:03:44 <gregdek> hola sdziallas :)
19:04:19 <sdziallas> well hello there! :)
19:04:25 <gregdek> OK, looks like a nice handful of gentlefolk.
19:05:01 <cpt_yesterday> Hi
19:05:14 * gregdek rummages up the minutes from last time:
19:05:47 <gregdek> http://meetbot.eucalyptus.com/meeting-logs/eucalyptus-meeting/2011-12-02/eucalyptus-meeting.2011-12-02-19.01.html
19:05:53 <gregdek> #topic Old Business
19:06:17 <gregdek> Looks like a couple of TODOs there.
19:06:23 <hspencer> gregdek, we didn't do a good job that last meeting
19:06:38 <gregdek> hspencer: it was kinda loose.  We'll tighten it up.  :)
19:06:50 <hspencer> we gotta get better at using info and actions
19:07:01 <koolhead17> what are we upto?
19:07:05 <gregdek> There's been lots of side conversation here too, so it's still a little ragged because of that.
19:07:08 <gregdek> But we'll get there.
19:07:11 <hspencer> yep, agreed
19:07:16 <hspencer> so, i can give some updates
19:07:27 <gregdek> #topic hspencer gives updates
19:07:29 <gregdek> Shoot. :)
19:08:06 <hspencer> #info RT tickets were put in for Starter EMI page being published, and renaming URLs for Image Creator Guides
19:08:30 <gregdek> Awesome.
19:08:38 <gholms> :D
19:09:07 <gregdek> Any more, hspencer?
19:09:14 <hspencer> #info worked with Ian.  All old EMIs are moved to emis.eucalyptus.com
19:09:20 <hspencer> yea, there is more
19:09:23 <hspencer> way more
19:09:25 <hspencer> gimme a min
19:09:29 * gregdek waits :)
19:09:35 * gregdek is the impatient type.  ;)
19:09:52 * gregdek goes to look at emis.eucalyptus.com
19:10:10 <gregdek> xml. neat.
19:10:49 <hspencer> #info Ian created a python script to replace lists.pl that is used on eucalyptussoftware.com that lists the EMIs
19:11:32 <hspencer> #info the python script reads the tar-gzipped EMIs that we stored in Walrus that folks can download via the emis.eucalyptus.com instance
19:11:49 <gregdek> hspencer: where does that script live?
19:11:51 <hspencer> #info emis.eucalytpus.com is an instance that is using varnish
19:11:57 <hspencer> script lives in Walrus
19:11:58 <hspencer> :)
19:12:02 <hspencer> i am gonna look over it
19:12:10 <hspencer> then we are gonna put it into projects
19:12:14 <hspencer> that work?
19:12:21 <gregdek> Yep, awesome.
19:12:30 <gregdek> Add as an action?
19:12:46 <dak419> my turn yet? :-)
19:12:57 <gregdek> dak419: maybe hspencer has more.  ;)
19:13:03 <hspencer> #action review Ian's python script for listing contents in Walrus bucket.  Add script to projects
19:13:07 <hspencer> yep, i have one more thing
19:13:10 <dak419> he always has more.. need to cut him off at some point! LOL!
19:13:25 <gregdek> Not if he's reporting actual cool shit he's done, we don't!
19:13:26 <dak419> *heard Harold laugh from way over here!*
19:13:47 <gregdek> Once he starts talking about what he's *gonna* do, *then* we can cut him off.  ;)
19:13:48 <hspencer> #info kristina is working with me on renaming the URLs and having redirects to the link Archived Eucalyptus Certified EMIs
19:14:20 <gregdek> OK, I have some questions.
19:14:24 <gregdek> May I?
19:14:24 <hspencer> #info reviewed policies with Graziano cocnerning EMis
19:14:42 <hspencer> about how we can deploy EMIs based on different ditros
19:14:45 <hspencer> distros
19:14:55 <hspencer> this was done based upon concerning gholms brought up
19:15:03 <hspencer> the only major one is Fedora
19:15:10 <hspencer> CentOS we will review
19:15:14 <hspencer> gregdek, go ahead
19:15:21 <gholms> Careful, there is more at play than just that.
19:15:39 * gholms shuts up
19:16:19 <hspencer> gholms, yea, we checked hte policies
19:16:23 <hspencer> for the distros
19:16:37 <hspencer> we are lookin good for Debian and Ubuntu
19:16:40 <gregdek> First: the emis.eucalyptus.com site... is there a prettier interface for that?  Do we need one?
19:16:41 <gholms> hspencer is talking about trademark policies.
19:16:51 <gregdek> Ah, ok.
19:17:20 * gregdek suspects we'll be serving a lot of hotdoggy, iceweaselly images.
19:17:22 <hspencer> gregdek, didn't come up with a landing page for emis.euclayptus.com
19:17:30 <gregdek> D'you think we need one?
19:17:36 <hspencer> err, we can come up with one
19:17:40 <hspencer> i am down for it
19:17:43 <gregdek> Not sure we do yet, if it's all machine-readable-backend stuff for now.
19:17:45 <hspencer> first, i just wanted to get it up
19:17:52 <gregdek> Makes sense.
19:17:54 <hspencer> but, i think we should
19:18:01 <gregdek> action it?
19:18:04 <hspencer> but i think we shoudl update the infrastructure before deploying it
19:18:08 <gregdek> ok.
19:18:10 <hspencer> like have it load balanced
19:18:16 <hspencer> cause its gonna get heat
19:18:22 <hspencer> if we have  a published page
19:18:24 <hspencer> so
19:18:26 <hspencer> yea, lets action it
19:18:27 * gregdek notes we really need to make these tickets.
19:18:34 <hspencer> yep
19:18:45 * gregdek will go through and file tickets for all #actions from this meeting.
19:18:57 <gregdek> In fact, I should be doing that every meeting.
19:19:32 <hspencer> #action RT tickets to update instance infrastructure to have load balanced enironment for emis.euclayptus.com, and have a landing page for emis.eucalyptus.com
19:20:01 <hspencer> dak419, i am done
19:20:03 <hspencer> :)
19:20:04 <hspencer> OH
19:20:06 <hspencer> shit,
19:20:17 <hspencer> i didn't touch base with dak419 to update catalog.json
19:20:21 <hspencer> will do that today
19:20:25 <hspencer> so it will be marked off
19:20:28 <hspencer> as completed
19:20:32 <hspencer> k dak419 you are up
19:20:34 <gregdek> BEAST
19:20:35 <dak419> ok.
19:20:51 <dak419> I've been working with Vic to get the eustore QA test integrated with QA.
19:21:09 <dak419> It uses the eucalyptus/eutester framework and is the first test to use that framework in actual QA
19:21:21 <gholms> Nice!
19:21:22 <dak419> so, we're *inventing* a few things to get that up
19:21:29 <hspencer> CASH.MONEY!
19:21:36 <dak419> Hope to finish that today.
19:21:44 <hspencer> NICE!
19:21:51 <hspencer> dak419, can we get a list of those tests?
19:21:56 <dak419> also, been working with boot from EBS on new Euca 3 software.
19:21:58 <hspencer> we should publish those tests
19:22:05 <dak419> yes, that test is checked into github
19:22:05 <hspencer> and get community feedback for more tests
19:22:12 <dak419> under tests/eustore
19:22:15 <hspencer> you put it on projects?
19:22:25 <hspencer> can we get eustore on projects?
19:22:26 <dak419> it's just source code. python
19:22:30 <dak419> oh, I don't know
19:22:40 <hspencer> gregdek, should be put it there?
19:22:49 <gregdek> Yes.
19:22:50 <dak419> I have a bunch of info on the internal wiki and getting that onto projects would be fantastic.
19:22:56 <dak419> give that action to me
19:22:59 <gregdek> eustore is already on projects.
19:23:01 <gregdek> :)
19:23:09 <dak419> great. the memory fades.
19:23:17 <gregdek> Oh, no it isn't.
19:23:19 <gregdek> I'm an idiot.
19:23:21 <gregdek> eutester is.
19:23:23 <gregdek> Sorry.
19:23:24 <dak419> I'm just doing actions before they are assigned… or something like that
19:23:33 <dak419> ah .np.. new action!
19:23:49 <gregdek> To create the eustore project?
19:24:09 <dak419> sure, should it be under euca2ools or under images...hmm
19:24:14 <gregdek> Can I understand more about it?
19:24:22 <dak419> eustore?
19:24:27 <gregdek> The project.
19:24:40 <gregdek> You know, we can take that offline.
19:24:47 <dak419> sure, from my lightning talk in Sept, basic premise is that 12 steps to install a new image is now 2
19:24:50 <gregdek> When you announce it to the mailing list, I can ask my dumb questions then.  ;)
19:24:52 <dak419> that's the pitch
19:25:17 <dak419> much more to it, but when I get it on projects, it there will be reading material
19:25:22 <gregdek> #action gregdek will create eustore project and hand the keys to dak419
19:25:31 * gregdek goes to do that now, in fact...
19:25:32 <dak419> ohh, shiny new projet
19:25:40 <dak419> s/jet/ject
19:25:58 <dak419> back to bfebs
19:26:05 <dak419> since that relates to images
19:26:44 <dak419> there's a process for creating those images, which I'm working through to understand better. Trying to look out for the UX and ensure we have tools/scripts to make this as simple as possible
19:26:49 <dak419> (but no simpler)
19:27:20 <gregdek> (who wants to be a member of the eustore project?  let me know)
19:27:31 * gregdek raises hand.
19:27:34 <dak419> everybody, no doubt! :-)
19:27:40 * hspencer raises hand
19:27:42 <gregdek> Oh, nm.  bfebs = boot from ebs.
19:27:43 <gregdek> Sorry.
19:28:14 <dak419> yes… threw me the 1st time
19:28:38 <gregdek> dak419: You are now the proud owner of the eustore project.  Please polish it up, and ping me if you need help.
19:28:48 <gregdek> https://projects.eucalyptus.com/redmine/projects/eustore
19:28:54 <hspencer> honestly, shouldn't it be bfe?
19:28:58 <hspencer> not bfebs
19:28:59 <hspencer> lol
19:29:06 <gregdek> HA
19:29:13 <dak419> it's an acronym wrapped in an acronym
19:29:20 <gregdek> "Where did you get this image?"  "BFE!"
19:29:29 <gregdek> Anyway.
19:29:38 <hspencer> LOL!!
19:29:43 <gregdek> Sorry to interrupt, dak419.  What elese?
19:29:54 <gholms> If you want to be technically correct about it then it would be "boot from dynamic block volume" :P
19:29:59 <dak419> I think that's it. I smell pizza anyway
19:31:09 <gregdek> OK.  :)
19:31:13 <gregdek> Any other old business?
19:31:37 * gregdek looks at actual tickets.
19:31:39 <gregdek> One sec.
19:31:42 * gholms has two things, though they may not be old
19:32:14 <gregdek> .proj 14
19:32:15 <eucabot|test> gregdek: Issue 14 (New): 2.6.32 from debian sees xvda instead of sda - https://projects.eucalyptus.com/issues/14
19:32:27 <gregdek> So this one looks like it's been hanging around, and doesn't have an owner.
19:32:36 <gregdek> Anyone know what's up with it?
19:32:47 <hspencer> gregdek, have we discussed integrating this into RT?
19:35:02 <gregdek> hspencer: we have not.
19:35:13 <gregdek> We've been using this because it's the system at hand.
19:35:45 <gregdek> It's clear that we need a unified ticketing system, but we can't block in the meantime, basically.
19:35:51 <gregdek> And we *know* this one is community-facing, so.
19:36:15 * gregdek wonders if 14 should be handed to obino. :)
19:36:35 <hspencer> integrating this with RT would be good
19:36:47 <hspencer> nah, i think that we just make sure its integrated
19:36:51 <hspencer> projects is great
19:36:54 <hspencer> we can integrate it
19:37:09 * gregdek doesn't know what import/export functionality projects has.
19:37:16 <hspencer> yea
19:37:18 <hspencer> we can work on it
19:37:23 <hspencer> wanna action item it?
19:37:28 <gregdek> You want to take a crack at it?
19:37:49 <gregdek> I presume what you're talking about is just two-way ticket communication and closing on one side == closing on the other side?
19:38:04 * gregdek wonders if redmine has apis for that...
19:39:02 <gregdek> http://www.redmine.org/projects/redmine/wiki/Plugin_List
19:39:05 <gregdek> Nothing that I see.
19:39:09 <gholms> eucabot|test uses redmine's REST API
19:39:38 <gholms> Not sure if it is read-only or read/write
19:39:38 <gregdek> gholms: ah, that's useful.  Is it read-only or read-write?
19:39:42 <gregdek> Heh.
19:39:48 * gholms <-- faster :)
19:39:57 <gregdek> BY ONE SECOND.
19:40:17 <gregdek> So yeah, anyone have time to look into that? Maybe a good infra ticket...
19:40:39 <gregdek> #action gregdek will file ticket integration with RT as an issue in the infra queue
19:40:49 <gholms> Thanks
19:40:50 <gregdek> We'll assign it to some poor sucker then.
19:40:52 <gregdek> In the meantime:
19:40:58 <gregdek> does anyone know about the *actual* issue?
19:41:12 <gholms> What is the actual issue?
19:41:21 <gregdek> .proj 14
19:41:22 <eucabot|test> gregdek: Issue 14 (New): 2.6.32 from debian sees xvda instead of sda - https://projects.eucalyptus.com/issues/14
19:41:25 * gholms looked for it in /topic but it was out of date :(
19:41:33 <gregdek> Doh!
19:41:38 * gregdek dammits.
19:41:54 <gregdek> #topic Issue 14 (New): 2.6.32 from debian sees xvda instead of sda - https://projects.eucalyptus.com/issues/14
19:42:54 <gregdek> ...and still no answer.  OK, I'm assigning it to whomever filed it.  :)
19:43:06 <gholms> I think label support would be nice.
19:43:11 <gregdek> Any old business?  gholms, I know you have new business.
19:43:27 <gholms> Not sure if that can be done on a per-image basis, though :\
19:44:18 <gregdek> Ah, interesting.  This ticket is actually in the "Single Images" project, which rolls up to this one.
19:44:21 <gregdek> Good to know.
19:44:49 <gregdek> OK, no old business, so moving on.
19:44:55 <gregdek> #topic New business
19:45:01 <gregdek> gholms: you're up.
19:45:14 <gholms> Do you want the quick and easy one or the long and painful one?
19:45:16 <gholms> (first)
19:45:28 <gregdek> Quick and easy.  Let's clear the deck for the ugly.
19:45:31 <gholms> New meeting time
19:45:43 <gholms> We conflict with the Fedora Cloud SIG meeting in #fedora-meeting.
19:45:47 <hspencer> k
19:45:48 <gregdek> Yes.
19:46:04 <hspencer> so question becomes
19:46:06 <gregdek> We've got the principals here.  Can we agree now?
19:46:08 <hspencer> what has higher priority
19:46:09 * gholms gives gregdek a #topic
19:46:12 <hspencer> ?
19:46:16 <gregdek> #topic New meeting time
19:46:26 <hspencer> cause this may not be the first that a meeting conflicts with a distro specific meeting
19:46:35 <gholms> Indeed
19:46:42 <hspencer> so how do we handle it?
19:46:43 <gregdek> In this case, I think it's an important one, since we will have clear overlap -- we already have.
19:46:58 <gholms> The real question in your mind is whether it is worth moving this meeting over.
19:47:27 <gregdek> gholms: are there any irc meetings you regularly participate in?
19:47:31 <gregdek> Same goes for others.
19:47:50 <gholms> Fedora Cloud SIG, FESCo, Eucalyptus Images, Eucalyptus Community Infrastructure
19:48:06 <gregdek> We were also bitten by the fact that Fedora schedules its meetings in UTC, and daylight savings bit us.
19:48:54 <gregdek> I think we'll have to decide case by cse.
19:49:00 <gholms> +1
19:49:01 <gregdek> In this case: who thinks we should move?
19:49:07 * gregdek says yes.
19:49:13 <hspencer> +1
19:49:15 <hspencer> works for me
19:49:32 <gregdek> Any strong nos?
19:49:40 <gregdek> Or even weak nos?
19:50:14 <gregdek> OK, I like Friday for this one.  Maybe two hrs later?
19:50:21 <cpt_yesterday> Engineering meeting
19:50:26 * gregdek nods.
19:50:30 <gregdek> two hrs earlier?
19:51:01 <gregdek> that means 9am pacific.  Too early?
19:51:11 <cpt_yesterday> That could work as long as I don't need to wake up at 5am
19:51:36 <gregdek> hspencer: 9am pacific good for you?
19:51:44 <gholms> It risks colliding with the daily engineering meeting, but I'm not sure if that will last past 3.0's release.
19:52:05 * gholms is fine with that time
19:52:13 <gregdek> We could move 1 hour, but then we get bit by the Fedora cloud meeting moving back.
19:52:39 <gholms> Time for a whenisgood poll?
19:52:42 <gregdek> Yep.
19:52:50 <gregdek> #action gregdek will run whenisgood for new meeting time
19:52:54 <hspencer> err. actually
19:52:56 <hspencer> that will work
19:53:04 <gregdek> So 9am Friday?
19:53:13 * gregdek jumps on it.
19:53:23 <gregdek> #agreed meetings will move to 9am Pacific on Fridays
19:53:41 <gregdek> OK, gholms.  Tell us about the Big and Scary.
19:53:44 <hspencer> OH SHIT
19:53:45 <hspencer> no
19:53:46 <hspencer> wont' work
19:53:49 <cpt_yesterday> Run
19:53:53 <hspencer> just remembered
19:54:01 <hspencer> Tech services meeting moved to 9 AM
19:54:30 <gregdek> Shit.
19:54:34 <gregdek> OK, not agreed.
19:54:43 <gregdek> #agreed PSYCH. gregdek will run whenisgood.
19:55:34 <gholms> Heh
19:55:38 <gregdek> gholms has the floor.
19:56:18 <gholms> tl;dr: GPL compliance
19:56:43 <gholms> When we design the eustore service we need to take source distribution into account.
19:56:44 <gregdek> #topic Image GPL Compliance
19:56:46 <gregdek> Heh.
19:56:52 <gholms> #info When we design the eustore service we need to take source distribution into account.
19:57:12 <gholms> What exactly that means, I can't say.
19:57:54 * gregdek nods.
19:58:07 <gregdek> This is a huge pain in the ass for everyone who keeps persistent images of anything.
19:58:24 <gholms> Some of us had a very good conversation about what it would mean for us, especially in light of what AWS does.
19:58:26 <gregdek> Fedora has been grappling with it for years.  Anything we can learn?
19:58:38 <gregdek> And what does AWS do?
19:58:46 <gregdek> We should probably do exactly that. :)
19:58:58 <gholms> AWS lets one download sources for the ALAMI.
19:59:11 <gholms> They don't publish sources for stuff uploaded by $random_user
19:59:22 <gholms> But we aren't AWS.  We aren't a hosting service.
19:59:48 <gholms> So one could compare what the eustore does to handing out binary media instead.
20:00:00 * gregdek hrms.
20:00:18 <gregdek> One wonders how AMZN gets away with that stance. By not being the owners, I suspect.
20:00:19 <hspencer> gholms, i am trying to understand how that is the case
20:00:25 <hspencer> AH, nevermind
20:00:28 <hspencer> i see what you are saying
20:00:30 <hspencer> nevermind the question
20:01:10 <hspencer> gregdek, honestly, the direction of eustore development determines the direction of Eucalyptus
20:01:21 * gregdek nods.
20:01:23 <hspencer> as far as an infrastructure development point of view
20:01:33 <hspencer> how do you federate accounts
20:01:35 <hspencer> user accounts
20:01:42 <hspencer> federate private clouds
20:01:54 <gregdek> The weasel word way out of this *particular* bind is "you build the image, you take ownership of the legal standing of that image" with some kind of takedown mechanism.
20:02:02 <hspencer> yep
20:02:08 <gregdek> If we're going to be making any kind of public image store available.
20:02:12 <gregdek> BUT:
20:02:48 <gregdek> If we make *recipes* available, and prep some base images but encourage people to use something like boxgrinder to build images for themselves, we don't have the same problem.
20:03:06 <gregdek> I mean, we still have the problem for base images, of course. But we have that now anyway.
20:03:24 * gregdek hrms.
20:03:51 <gregdek> Yes, this is still a pretty fundamental question that I'm not convinced we've answered.
20:03:53 <hspencer> yea, its definitely a pickle
20:04:00 <gregdek> Do we want to be an image store, or a recipe store?
20:04:06 <gregdek> Or both?
20:04:10 <hspencer> i think its easier to do the later first
20:04:13 <hspencer> then image later
20:04:25 <gregdek> That's my sense too.
20:04:43 <hspencer> it will give us more time to come up with a plan on how we want to do an public image store
20:04:44 <gregdek> We must store a handful of images in the short term to bootstrap, right?
20:05:10 <gregdek> Which is essentially what emis.euca is now, aiui.  Yes?
20:05:14 <gholms> Not really; you can build an instance-store image on your workstation.
20:05:36 * gregdek thinks.
20:06:00 <gregdek> So is emis.euca still a PoC of the notion of "storing and delivering images"?
20:06:11 <gregdek> Or are users/customers actually dependent on it?
20:06:35 <gregdek> (we're past the hour, people can step away if they choose, but i'd like to keep going for those who can stay)
20:06:54 <gregdek> #topic image store versus recipe store
20:08:06 <cpt_yesterday> Currently what we've seen with partners is that they want to produce their own images and go from there
20:08:35 <cpt_yesterday> The concept of using something like cloudinit or puppet or chef to build out an instance after it has started still isn't a mainstream idea it seems
20:09:05 * gregdek nods.
20:09:29 <cpt_yesterday> I think that us pushing using scripts with basic images would help others see that you don't need an image for every task, you use your management solution to build from those basic images as needed
20:09:43 <hspencer> yep
20:09:44 <hspencer> i agree
20:10:09 <hspencer> we shoudl document how to enable cloud-init, bash script, chef, etc. in the image
20:10:20 <cpt_yesterday> But with certain people they will still want to create an image because they won't want to wait the 5 minutes or so that it might take puppet or cloudinit to pull packages from a repo and install and configure everything
20:10:23 <hspencer> then how to deploy solutions by passing infomration in via user-data
20:10:30 <hspencer> cpt_yesterday, thats true
20:10:35 <hspencer> different type of cloud admin
20:11:52 <gregdek> So it sounds like case 1 is "take a base image and trick it out using puppet et al" and case 2 is "take an image builder tool like boxgrinder and make your own image" and case 3 is "pick one of these preconfigured images".  Except that case 3 is hugely expensive and of marginal value if cases 1 and 2 work at all.  Is that fair?
20:12:44 <hspencer> well, preconfigured for what?
20:12:50 <hspencer> to utilized cloud-init?
20:12:57 <gholms> "httpd server"
20:12:57 <hspencer> puppet? bash?
20:13:00 <hspencer> AH ok
20:13:01 <gholms> "mysql server"
20:13:04 <gregdek> Yes.
20:13:11 <hspencer> well, it depends
20:13:16 <gregdek> Or, in the case I always used at AMZN, "drupal + varnish".
20:13:21 <hspencer> ya
20:14:00 <gregdek> Because AMZN (a) has massive storage and (b) has people creating images all the time, case 3 works great for them.  But it's still unclear to me if case 3 works for us.
20:14:18 <hspencer> yea
20:14:26 <hspencer> it depends on their private cloud setup
20:14:43 <gregdek> And I know that marketing loves the idea of "selling an image store", but when we get down to the level of details, I'm not sure what it means for us.
20:15:16 <gregdek> I much prefer the simpler case of "figuring out what's a pain in the ass for users and making it easier."
20:15:53 <gregdek> So if partners want to produce their own images, as cpt_yesterday says, should we doing similar to the rBuilder thing?  (shout out to mull, yo)
20:16:04 <gregdek> which seems like case 2 to me.
20:16:19 <hspencer> yep
20:16:22 <hspencer> agreed
20:16:45 <gregdek> which is why I've been playing with boxgrinder to figure out what works and what doesn't work there.
20:17:05 <gregdek> Any other image building tools we should be looking at?
20:17:14 * gholms uses yum
20:17:19 <hspencer> err, not sure
20:17:27 <hspencer> there is Suse Studio
20:17:32 <hspencer> it builds out images
20:17:34 <gholms> Ooh, there's an idea.
20:17:53 <koolhead17> but building a cloud image should b too easy
20:17:54 <koolhead17> :)
20:18:31 <koolhead17> using KVM and vnc magic
20:18:51 <koolhead17> http://cssoss.wordpress.com/
20:18:53 <gholms> If you're hell-bent on having a porcelain toolset for this then perhaps boxgrinder, appliance-creator, and suse studio would be worth looking into.
20:18:54 <koolhead17> see this
20:19:12 <koolhead17> tools will remain same even if we are using Eucalyptus :P
20:19:37 <gholms> That procedure would work really great if Eucalyptus supported images that can boot themselves.
20:20:28 <gregdek> Or is image building not that big a problem? :)
20:21:02 <koolhead17> gregdek: its not at all a big problem IMHO
20:21:03 <koolhead17> :P
20:21:33 <gregdek> gholms: when you say you use yum, do you mean "I take a base image and install whatever I want after the fact"?
20:21:58 <gholms> No, I install an operating system by hand from scratch using the package manager.
20:22:30 <gholms> Everyone always seems to bundle unnecessary crap on their images and shuts off SELinux so I build my own.
20:23:33 <gholms> This is not a simple procedure, hence my comment about poreclain toolsets.
20:23:59 <cpt_yesterday> debootstrap
20:24:26 * gholms hasn't used debian enough to speak about that
20:25:08 <cpt_yesterday> You can use it to put the bare minimum of a system into a file or partition using a debian repo
20:25:18 * gregdek nods.
20:25:34 <cpt_yesterday> I've been playing with building some smaller images as well that only have the very basics needed then you add what you need to it
20:26:31 * gregdek is thinking.
20:26:36 <gregdek> Maybe not clearly.
20:26:56 <gregdek> gholms: what's your sense of the value of the porcelain toolset in this case?
20:27:59 <gholms> In the Fedora/RHEL/etc case I think manual image setup is too difficult for those who don't know what they are doing or don't have time for trial and error.
20:28:42 <gholms> Can one run anaconda at the command line to install into a chroot/image/etc?
20:29:27 <gholms> Then again the Fedora guys use appliance-creator.
20:29:31 * gholms is scatterbrained
20:30:14 <cpt_yesterday> Yes. For most users we will need an easy way to do things
20:30:34 <cpt_yesterday> Again I've dealt with various partners for days due to the complexity of creating a working image at times
20:30:45 <gregdek> Bing.
20:30:48 <gregdek> All right, then.
20:30:53 <gregdek> Because that's been my experience too.
20:31:27 <cpt_yesterday> It would be good to have blogs and such explaining how to do it for the adventurous but for most they just want what's simple
20:31:33 <gregdek> I haven't played with SuSE Studio -- I was under the impression that it was a proprietary service, right?  Which is not necessarily bad, mind you.
20:31:39 <gholms> cpt_yesterday: +1
20:31:57 <cpt_yesterday> I believe so
20:32:21 <cpt_yesterday> We also have some issue with SuSE currently with how they do their kernel parameters at boot
20:32:48 <cpt_yesterday> SuSE images will not run with a stock Eucalyptus XML file last time we tried
20:33:28 <gregdek> Boo.
20:33:55 <gregdek> Which is a mark against them, probably: I imagine that getting SuSE studio to make friendly changes will be more and more difficult after Nat's departure.
20:34:37 <cpt_yesterday> They seemed to be open for collaboration a little while ago but I don't think that it went anywhere past a couple of meetings
20:35:04 <gregdek> Yeah.
20:35:32 <gholms> Their biggest goal seemed to be hosting eucalyptus builds on OBS.
20:35:40 <gregdek> OK, I'm not sure if this is helping anyone else, but it's helping me understand.
20:35:54 <gholms> ...which doesn't help us when it comes to image building. :(
20:37:46 <gregdek> Fair enough.
20:37:57 <cpt_yesterday> haha
20:38:25 <gregdek> All right, then.  Perhaps that's the note to end on, LOL.
20:38:46 <gregdek> Since we're way past time.  Anything else meeting-worthy, or has everyone wandered off?
20:38:49 <cpt_yesterday> gholms: Good job I think you hurt his feelings
20:39:01 <gregdek> I has a sad.
20:39:09 <gregdek> No, really, we're taking a lot of time here.
20:39:26 <cpt_yesterday> I believe it just ended up being the three of us
20:39:31 <gregdek> Hawt.
20:39:36 <gholms> Yup
20:39:43 <hspencer> i am here
20:39:52 <hspencer> i have been moving back and forth
20:39:55 <hspencer> been doin work
20:39:59 <gregdek> LOL
20:40:00 <cpt_yesterday> No you haven't
20:40:03 <hspencer> but this is a great discusion
20:40:07 <hspencer> lol
20:40:09 <hspencer> you right
20:40:19 <gregdek> "Instead of running my mouth with you dumbasses, I've been PRODUCTIVE."
20:40:21 <hspencer> i have just been listenin to bob marley..smokin out
20:40:37 <gregdek> All right.
20:40:48 <gregdek> So here's my takeaway, and then I'm done.
20:40:59 <gregdek> We have evidence that users find image building hard.
20:41:22 <gregdek> But they do want their own images, not our slunked-up versions of whatever, so build them they do.
20:41:47 <gregdek> So the porcelain toolset to which gholms refers seems like a good direction to go, and I'm gonna learn more about that myself.
20:41:54 <koolhead17> hspencer: haha.
20:42:18 * gholms gives gregdek a basket of #infos and #actions
20:42:43 <gregdek> :)
20:43:02 <gregdek> #info Evidence tells us that users have pain in building images.
20:43:23 <gregdek> #info Users would still rather have their own custom images that stock images in many cases.
20:43:57 <gregdek> #action gregdek will learn more about boxgrinder and other potential open tools for image building.
20:44:05 <gregdek> I think that about does it.  :)
20:44:10 <gregdek> Shall we adjourn?
20:44:15 <gholms> Let's.
20:44:20 <gregdek> #endmeeting