14:00:34 <mattdm> #startmeeting
14:00:34 <zodbot> Meeting started Thu Jun  5 14:00:34 2014 UTC.  The chair is mattdm. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:34 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:00:45 <mattdm> #meetingname cloud
14:00:45 <zodbot> The meeting name has been set to 'cloud'
14:00:55 <mattdm> #meetingtopic Hello Everybody
14:01:05 <mattdm> hi all! who is here?
14:01:06 <oddshocks> Hello!
14:01:09 <roshi> .fasinfo roshi
14:01:10 <zodbot> roshi: User: roshi, Name: Mike Ruckman, email: mruckman@redhat.com, Creation: 2013-08-24, IRC Nick: roshi, Timezone: US/Mountain, Locale: en, GPG key ID: , Status: active
14:01:14 <zodbot> roshi: Unapproved Groups: magazine marketing
14:01:14 <number80> .hellomynameis hguemar
14:01:17 <zodbot> roshi: Approved Groups: docs +qa fedorabugs qa-admin cla_done cla_fpca
14:01:20 <zodbot> number80: hguemar 'Haïkel Guémar' <karlthered@gmail.com>
14:01:42 * number80 note I can't type fast
14:01:43 <imcleod> mattdm: Ian here.
14:01:57 <mattdm> I know that jzb can't make it
14:02:08 <mattdm> #info skipping a few jzb items because he can't make it today
14:03:03 <mattdm> anyone else around?
14:03:22 <lsm5> i'm here
14:03:23 <scollier> mattdm, here
14:03:30 * geppetto is here
14:03:57 <mattdm> lsm5 are you around re docker image stuff?
14:04:11 <lsm5> mattdm: yup
14:04:19 <mattdm> ok cool. let's get started with that
14:04:28 <mattdm> #topic crucial questions on Docker image deliverable
14:04:36 <mattdm> #link https://fedorahosted.org/cloud/ticket/65
14:04:47 <mattdm> What "Fedora" exactly is the image going to contain? Fedora Server?
14:04:48 <mattdm> Fedora Cloud? Will it be a part of either of those products? If not,
14:04:50 <mattdm> what is its status, exactly? Who's responsible for it? Is it considered
14:04:52 <mattdm> a primary or frontline or whatever Fedora deliverable? Who's going to
14:04:54 <mattdm> test it? How's it going to be promoted in relation to all our other
14:04:56 <mattdm> deliverables?
14:05:07 <mattdm> adam asks some good questions and I want to make sure we are on the same page with answers
14:06:05 <mattdm> that paste kind of failed at least in regard to prettiness. :)
14:06:10 <number80> POV: minimal image so people could use it to customize it through dockerfiles like scollier already does
14:06:36 <mattdm> Yeah. I think our plan is to deliver the base image through releng and then the dockerfiles as we are doing
14:06:51 <mattdm> anyone think otherwise? :)
14:07:25 <mattdm> I think the big question is how release-blocking we want to make this.
14:07:48 <mattdm> And I guess that partly depends on our ability to deliver updates
14:08:20 <mattdm> which I guess brings us to https://fedorahosted.org/cloud/ticket/59
14:08:37 <mattymo> If I were to set release cycle, I would do weekly updates if it was completely automated. Monthly otherwise.
14:08:44 <mattdm> which jzb signed up for but I don't think has been able to get to yet.
14:08:58 <mattdm> mattymo if you want to help jzb with that policy i'm sure it would be appreciated
14:09:02 <imcleod> Any reason why the update cycle should differ between cloud images and Docker images?
14:09:20 * imcleod thinks not
14:09:26 <mattdm> I agree, probably not.
14:09:35 * mattymo agrees
14:09:47 <imcleod> In which case, the task is really "when should we update all delivered Fedora image artifacts, regardless of the container or VM they are running in"
14:10:24 <mattdm> actually, reading the ticket I just linked, there's a distinction -- that one is about when the one-step-dowstream fedora-dockerfiles trusted builds should be rebuilt
14:10:30 <mattdm> which is a little separate
14:10:57 <mattdm> So, I guess here's the actionable decision....
14:11:23 <mattdm> Is the docker base image intended to be on the same level as the cloud images?
14:11:31 <mattdm> or is it of secondary importance
14:11:42 <imcleod> mattdm: If one is not obsessively concerned with absolute minimal-ness, it's trivial to take an existing disk image build (for cloud, for example) and docker-ize it.  Trivial = virt-tar-out -> docker import -> docker push
14:11:44 <mattdm> I'm in favor of considering it primary, if we have the resources to pull it off.
14:12:23 <mattymo> We're in a nice position where Fedora's docker image is far more compact and lightweight than some other distros. Keeping quality high can only help.
14:12:25 <imcleod> So I think it should be relatively straight-forward to release an acceptable Docker base image derived from the cloud images we have already committed to.
14:12:38 <mattdm> imcleod with the imagefactory stuff, we should be able to treat this almost exactly like another spin in koji, right?
14:12:51 <number80> +1 for primary
14:13:08 <lsm5> +1
14:13:16 <number80> (let's ride that dockah dockah dockah craze)
14:13:31 <imcleod> mattdm: Potentially, yeah, though it may require some additional koji glue.  Also, as Factory is Anaconda based, we may loose some of the minimal-ness that mattymo is talking about.  If that is seen as critical/differentiating then it's probably worth further discussion.
14:13:48 <mattdm> Okay, so, I think we have SIG consensus but maybe not quorum of voting members. I'll post this to the list as a lazy-consensus issue.
14:14:05 <mattdm> #action mattdm to post docker-base-as-primary to list as lazy consensus issue
14:14:19 <geppetto> I'll go along with a +1
14:14:25 <imcleod> +1 for primary
14:14:33 <geppetto> the only thing I'm worried about is any docker newness holding up the cloud images
14:14:49 <geppetto> but that's probably nothing to worry about.
14:14:53 <geppetto> :-o
14:15:02 <imcleod> I, for my part, will not let Docker block cloud.  :-)
14:15:08 <mattdm> So given those things, I think the best approach is "produce in koji by any means necessary, make refinements for the future"
14:15:35 <mattdm> that might involve it being bigger than ideal initially
14:15:59 <number80> +1 for best effort
14:16:18 <mattdm> imcleod can the current imagefactory plugin deal with a non-bootable resulting image? that is, no kernel or bootloader and maybe a fake systemd?
14:16:49 <imcleod> mattdm: Yes.  But it still needs to be an image generated via Anaconda.  If we can get Anaconda into the business of generating non-bootable images, Factory can work with them.
14:17:09 <walters> imcleod, it already supports --no-bootloader or something like that
14:17:26 <imcleod> mattdm: And it needs rpm to be installed.  (There were semi-serious discussions about having Docker images with neither yum nor the rpm stack.)
14:17:26 <mattdm> and it *deifnitely* supports horrible kludges in %post :)
14:17:28 <mattymo> ami-creator works wonderfully for a centos image
14:17:49 <mattymo> imcleod, -1000. It needs to feel like a real system that people can use without any learning curve
14:18:12 <walters> imcleod, https://git.fedorahosted.org/cgit/anaconda.git/commit/?id=036f68a1cbd64a21b76b0a368b9f991a25b33da3
14:18:30 <mattdm> mattymo context, there?
14:18:39 <mattymo> mattdm, which comment?
14:18:41 <walters> imcleod, base images without a package manager are going to only have very specialized use cases
14:18:45 <mattdm> the -1000?
14:18:50 <imcleod> walters: Awesome.  I might start to fiddle with that Anaconda feature.
14:18:59 <imcleod> walters: Agreed.  I am not advocating them in the general case.
14:19:17 <mattdm> We're definitely going to want rpm in there and we're a long way off from being able to put yum anywhere else
14:19:19 <mattymo> mattdm, because fedora base image is a building block. It needs to be easy to build any docker-based app on top of it, and it should behave relatively similar to how other distros place themselves out there.
14:19:22 <imcleod> walters, mattymo: Far from it, in fact.  I think the delivered image should have rpm and yum and be immediately capable of yum installs without modifications.
14:19:40 <imcleod> OK.  I think there is violent agreement on this point.
14:19:42 <mattdm> I think we may all be in violent agreemnt here
14:19:42 <mattymo> imcleod, we are in agreement.
14:19:45 <mattdm> jinx!
14:19:47 <imcleod> Apologies for bringing it up.
14:19:51 <imcleod> :-)
14:19:55 <mattdm> no it's good to be clear
14:20:23 <number80> -1 to have no package mgmt stack in the docker base img
14:20:45 <imcleod> +1 to rpm and yum in docker base image - #docker
14:20:48 <mattdm> okay, so let's go on to the next thing :)
14:21:24 <mattdm> #topic start communication/collaboration on cloud image update
14:21:34 <mattdm> #link https://fedorahosted.org/cloud/ticket/51
14:21:43 <mattdm> roshi any progress or notes on this?
14:22:09 <roshi> nothing of note
14:22:22 * mattdm notes that the openssl security update today didn't get a "needs a respin" from the security team
14:22:41 <roshi> but in regards to automated testing of images
14:22:42 <mattdm> but it made me think that it sure will be nice when we have this in place :)
14:22:55 <roshi> which touches a part of this ticket
14:23:27 <mattdm> #link https://fedorahosted.org/cloud/ticket/38
14:23:30 <mattdm> also that ^
14:23:36 <roshi> taskotron is moving along nicely, but afaik we still don't have any tests that are automatable
14:23:38 <mattdm> #info "Automatic Smoketests on Image Build"
14:23:55 <mattdm> no tests in gneeral or no tests for cloud?
14:24:13 <roshi> from what I can tell, at this point even if taskotron was ready we don't have cloud tests to plug into it
14:24:40 <mattdm> oh yes!
14:24:48 <mattdm> #info put cloud tests here https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs/ticket61
14:24:50 <roshi> there are two testcases, testing images in different providers, but they're manual and require account creds
14:25:06 <frankieonuonga> sorry I am late
14:25:09 <number80> roshi: could we at least write acceptance tests scenarios ?
14:25:10 <mattdm> roshi we're going to need to do things which require account creds -- no way around that
14:25:15 <mattdm> hi frankieonuonga!
14:25:25 <frankieonuonga> mattdm: whats up mate
14:25:28 <frankieonuonga> :-)
14:25:40 <mattdm> frankieonuonga current topic is tests for cloud images
14:25:50 <roshi> acceptance test scenarios would be great - and then we can take those drafts to the QA meeting
14:26:01 <roshi> I kinda figured mattdm
14:26:03 <frankieonuonga> ok . I will catch up...you guys just go ahead . I am here
14:26:07 <number80> (i hope we could hold a taskotron/cloud hackfest at flock - even in the lobby)
14:26:08 <walters> most interesting on this topic i think would be pulling in a local metadata service
14:26:19 <mattdm> #halp please start writing test ideas and putting them in https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs/ticket61
14:26:32 <roshi> ping tflink
14:26:49 <roshi> he might not be available - travelling from the Bodhi2 FAD
14:26:53 <number80> mattdm: #help or it won't be in the minutes :)
14:27:14 <roshi> but I don't know that taskotron has a place for holding creds at this point
14:27:18 <mattdm> number80 nope, it must be halp. help gives help :)
14:27:29 <number80> my bad :)
14:27:33 <oddshocks> ha!
14:27:35 <mattdm> roshi can you check in that? kind of critical
14:27:44 <roshi> yeah - I can
14:27:55 <mattdm> #action roshi to check on taskotron holding credentials
14:28:19 <mattdm> #info walters' local metadata service idea is also interesting because a lot of tests can be run that way
14:28:23 <roshi> even if we had to have an internal (to infra) buildslave or something, we need to script out the checks to those external services anyway
14:29:03 <roshi> because even then, trusted users (people with account creds) could run the checks locally
14:29:21 <roshi> which lowers the overhead and makes testing easier
14:29:32 <roshi> and could be plugged into taskotron when it's ready
14:29:58 <number80> eutester might something worth to take a peek at: https://github.com/eucalyptus/eutester (gholms ?!)
14:31:19 <mattdm> walters: does min-cloud-agent support any sort of local metadata service?
14:33:04 <mattdm> eh that might be going too far into the weeds right now anyway :)
14:33:30 <roshi> could be, but I wanted to bring it up
14:33:32 <mattdm> anyone want to volunteer to start writing some tests in whatever rough form?
14:33:35 <imcleod> I'll throw out that the OpenStack folks, for QA purposes, have almost limitless rights to launch instances in both the HP and RackSpace clouds.
14:33:51 <imcleod> We might ask after something similar.
14:34:08 <roshi> it'd be good to get with them and figure out what they have set up and how
14:34:09 <frankieonuonga> mattdm: I would like to volunteer for that
14:34:11 <mattdm> imcleod yes we should.
14:34:19 <mattdm> #action frankieonuonga to start writing some test cases
14:34:41 <mattdm> frankieonuonga cool. I'm sure the fedora-qa people (including roshi) can help you get started
14:34:56 <mattdm> and let's go to the next thing
14:34:56 <roshi> I feel it's going to take some work to have automagical tests for cloud images
14:34:56 <frankieonuonga> mattdm: thanks
14:35:04 <frankieonuonga> roshi: can we get started after the meeting
14:35:09 <roshi> sgtm
14:35:10 <frankieonuonga> just to get me up to speed pplease
14:35:13 <mattdm> roshi: yes. definitely. but so worth it :)
14:35:17 <roshi> yup
14:35:20 <mattdm> #topic Deliverables and release engineering changes for Fedora.Next
14:35:21 <roshi> :)
14:35:25 <mattdm> #info https://fedorahosted.org/cloud/ticket/50
14:35:34 <mattdm> or link. whatever :)
14:35:46 <mattdm> in any case, jzb was going to file some tickets. not sure of status.
14:35:57 <mattdm> but I went ahead and created the kickstarts so there's that. :)
14:36:12 <mattdm> will maybe need to get more people acccess to the spin-kickstarts git
14:36:27 <mattdm> but for now I don' tthink there's anything more to say so let's go to the next agenda item
14:36:40 <mattdm> and final agenda item :)
14:36:48 <mattdm> #topic Project Atomic tracker
14:37:09 <mattdm> walters: I put this here for you but left it kind of vague :)
14:37:37 <mattdm> Of our deliverables/changes, this is the most dramatic
14:37:46 <walters> ok so
14:37:58 <walters> i've been working some on updating the fedora rawhide compose to new rpm-ostree tooling
14:38:09 <walters> we also have a server racked but not yet provisioned in fedora infra
14:38:27 <walters> but a lot of open questions; i started a thread here: https://lists.fedoraproject.org/pipermail/rel-eng/2014-May/017850.html
14:38:46 * mattdm looks at thread
14:38:51 <mattdm> #link https://lists.fedoraproject.org/pipermail/rel-eng/2014-May/017850.html
14:39:00 * frankieonuonga goes to look at thread
14:39:16 <walters> i am also backing off a bit from actively hacking on min-cloud-agent, as I'm feeling spread thin
14:39:19 <roshi> (iirc, meetbot automatically #links any url)
14:39:37 <mattdm> (roshi I think only when it's the start of a line)
14:39:53 <mattdm> walters yeah that's fair
14:39:57 <roshi> (ah)
14:40:00 <walters> but i'll be posting new fedora atomic bits within two weeks i think
14:40:04 <mattdm> anyone else want to hack on min-cloud-agent? :)
14:40:12 <frankieonuonga> mattdm: count me in
14:40:17 <frankieonuonga> this should be fun
14:40:17 <mattdm> what about the releng integration?
14:40:33 <mattdm> frankieonuonga yes but if you have to choose I think the test stuff is more urgent
14:40:48 <mattdm> not that there's anything wrong with fun :)
14:40:54 <frankieonuonga> ok, i start with test
14:41:01 <number80> testing could be phun
14:41:03 <dgilmore> walters: i need to look at the links you posted but I suspect we still have more unasked/unanswered questions
14:41:17 <frankieonuonga> mattdm: but this I will still like to have a look
14:41:27 <mattdm> frankieonuonga yep :)
14:42:24 <mattdm> walters is "FAI" n that message "Fedora Atomic Initiative"?
14:42:44 <walters> mattdm, yeah
14:42:57 <walters> dgilmore, yep just need to have a process for a continuing conversation i think
14:43:13 <dgilmore> walters: we will get though it all
14:43:18 <dgilmore> and work something out
14:43:29 <mattdm> I think that the answer for that question right now is that the Fedora Cloud Docker Host is morphing into Fedora Atomic, so there will just be that.
14:43:29 <walters> on the plus side the new compose tools are better and now several new contributors have successfully composed trees locally and tested it
14:44:28 <mattymo> mattdm, do atomic images represent super-minimal rpm-less docker containers that run a single preinstalled app?
14:44:46 <dgilmore> walters: we should be able to setup the atomic kickstart to use anaconda to make trees in koji today, but we may need some patching to deal with the output properly
14:44:49 <mattdm> mattymo no. :) this is the host that docker containers run *on*
14:44:59 <mattdm> mattymo with whatever contents they happen to have.
14:45:34 <mattymo> I'll reserve commentary and speculation for outside this meeting. Carry on.
14:45:41 <mattdm> we'll need both the trees and the installed image -- two separate outputs
14:45:55 <walters> dgilmore, there are some circular issues here as the anaconda needs to pull from composed trees, so koji would have to talk to whatever server is hosting the rawhide trees
14:46:19 <dgilmore> walters: composed tress in what sense?
14:46:44 <walters> dgilmore, what rpm-ostree does:  commit rpms to an ostree repository
14:47:13 <walters> like how lorax makes a CD image, except you can actually pull updates incrementally
14:47:23 <dgilmore> walters: well we will be starting from nothing
14:48:07 <walters> the other alternative is to keep it all as a secondary process outside of koji, so the same rpm-ostree server would also run lorax to make anaconda images and then use those anaconda images to make further images like a cloud base
14:48:15 <dgilmore> walters: we may not have a good answer here
14:48:28 <dgilmore> walters: secondary process means we do not do it
14:48:33 <walters> i'm looking at some steps down that path
14:48:45 <mattdm> let's... make it a primary process then
14:49:04 <number80> +1
14:49:38 <dgilmore> walters: the builders can talk to kojipkgs which is where we put nightly composes
14:50:11 <walters> an important question here is whether we want to *automatically* regenerate derived data (ostree trees, install images) or have it be a manual process
14:50:24 <walters> now I personally would much prefer automatic, Koji is oriented towards the latter
14:50:25 <mattdm> no new manual porcesses, please
14:50:32 <dgilmore> TC and RC compose is a bit different, but we would be able to get the access to read things, we just need to see how it all fits, and righgt now there is too many unknowns
14:51:05 <walters> dgilmore, yeah just starting with read-only access makes a ton of sense
14:51:20 <dgilmore> walters: it will be manual/automatic as part of the nightly autopmated comoposes and the manually kicked off TC and RC composes
14:52:16 <dgilmore> walters: but it needs to be integrated into the framework of release composition, and not a manual off the side do something special thing
14:52:43 <walters> right, definitely
14:52:44 <dgilmore> anyway this is kinda derailing the meeting
14:53:46 <mattdm> and it's almost time to wrap up the meeting. so -- are there decisions needing to be made now?
14:53:51 <mattdm> and or specific help needed?
14:54:27 <dgilmore> mattdm: right now we need to work out how we do things and how they integrate
14:54:28 <walters> i think we should decide on inside or outside of koji
14:54:39 <dgilmore> walters: inside is the only choice
14:54:51 <walters> before you were saying outside
14:55:04 <dgilmore> walters: no I think you mis understood me
14:55:08 <dgilmore> miss
14:55:28 <dgilmore> walters: we have a long term goal to do all of the releng compose tasks inside of koji
14:55:30 <walters> ok can we schedule a call with a shared whiteboard or something?
14:55:40 <walters> where we can draw arrows between boxes and stuff =)
14:55:50 <dgilmore> walters: we can read an existing tree and teh install tree via http
14:55:51 <mattdm> +1 to having the people who can make this happen work it out :)
14:56:05 <dgilmore> walters: I am okay with that
14:56:11 <dgilmore> walters: where are you based?
14:56:29 <walters> dgilmore, westford
14:56:32 <dgilmore> I can see if i can get funding to come and sit face to face for a few days
14:56:48 <dgilmore> walters: I will see if I can get there and sit down with you
14:56:58 <walters> ah that would be very good yeah
14:57:11 <walters> let's take this to email?
14:57:14 <mattdm> #info walters, dilmore, whoever else needed to meet to work on getting releng/atomic needs met
14:57:40 <mattdm> also possibly an area to pull in oddshocks
14:57:58 <mattdm> and with that....
14:58:01 <mattdm> #topic open floor
14:58:05 * oddshocks waves
14:58:10 <mattdm> Three minutes. anyone else got anything? :)
14:58:23 <oddshocks> uhmuhmuhm
14:58:34 <mattymo> I would like to see more Fedora sponsored docker containers on index.docker.io
14:58:40 <mattdm> I think jzb will be back to chair next week. if not, anyone else want to volunteer?
14:58:53 <mattdm> mattymo me too. have you talked to scollier?
14:58:55 <mattymo> it would be incredible to see something like a koji container just sitting out there for anyone to play with
14:59:25 <scollier> mattdm, mattymo, i agree, that would be cool
14:59:33 <oddshocks> status update for me: automatic image upload service pulling down image files and emitting fedmsgs upon successful download (to an internal FTP service, for example). about to hook in already-existing fedora_ec2 scripts to upload images as AMIs to every EC2 region, which will also emit a fedmsg
15:00:01 <roshi> oddshocks: where does that code live?
15:00:09 <mattdm> oddshocks: that is *awesome*
15:00:25 <frankieonuonga> I am out folks...see you on email land :-)
15:00:26 <oddshocks> and that's where I am. current code is at https://github.com/oddshocks/fedimg, but during the infra meeting today i'm probably going to ask if peeps want it at gh.c/fedora-infra or in the cloud SIG GH org
15:00:41 <oddshocks> also need to add a fedora git remote for folks opposed to GH
15:00:46 <jsmith> One quick thing from me: Thoughts on what you'd like to see as far as Cloudy documentatoin from the docs team?
15:01:06 <jsmith> I'm trying to coordinate things here, and have brought it up in a couple of meetings, but I haven't heard any response
15:01:16 <mattdm> oddshocks sounds good.
15:01:25 <mattdm> jsmith yeah. we can do better for you :)
15:01:40 <number80> jsmith: do you have folks from the SIG to show up at your meetings ?
15:01:41 <jsmith> I just don't want to leave it to the last minute
15:01:56 <jsmith> number80: No, so that's why I volunteered to show up at the Cloud meetings and lurk :-)
15:02:05 <number80> jsmith: great :)
15:02:06 <mattdm> #halp docs team needs input from us on cloud docs
15:02:21 <mattdm> We're over an hour but I think this is worth spending some time on....
15:02:28 <roshi> docs meetings are mondays at 1400 UTC, right?
15:02:49 <scollier> mattymo, i'd be happy to work with you on some of those extra services.  However, I'm about to be out of pocket for about 5 weeks.
15:02:55 <jsmith> roshi: That sounds right.
15:03:03 <mattdm> I think it would be good to have basic documentation to accompany each of our images
15:03:06 * roshi missed this weeks meeting :-/
15:03:18 <jsmith> mattdm: The Docs team is happy to help clean up/tag/publish the docs, but we're not experts on all the moving pieces
15:03:27 <mattdm> That is: 1. Cloud base image, and how to launch in various cloud providers
15:03:30 <jsmith> mattdm: I agree -- basic docs for each image would be awesome
15:03:37 <mattdm> #halp that includes experts to write the basic contents
15:03:53 <number80> 2. building - customizing images
15:03:59 <mattdm> 2. big data image -- refer to base docs for launching, give details on waht can be done
15:04:05 <mattdm> heh number collision!
15:04:10 <number80> :)
15:04:21 <number80> A cripple was faster !
15:04:32 <mattdm> 3. Fedora Atomic image -- how it's differnet, how updates work,etc. and particularly, how to run stuff on it with docker
15:05:04 <jsmith> Question: Do we want to do this under the framework of the "Cloud Guide", or separate guides?
15:05:06 <mattdm> for 3, we may be able to point to upstream docs some, but it'd be nice to have self-contained quick starts
15:05:29 <jsmith> I'm happy to do the legwork to get the framework in place -- just let me know how you'd prefer to have the docs setup
15:05:43 <mattdm> jsmith I don't know. Having it all in one place has some appeal, but can be a little intimidating too.
15:05:49 <mattdm> What do you think?
15:05:55 <scollier> mattdm, for the images hosted on index.docker, I was thinking about de-coupling the docs from there (the broken readme's), and pointing to an external page.
15:05:59 <jsmith> mattdm: There's nothing that says we can't have both, either...
15:06:16 <jsmith> mattdm: Both as chapters in the Cloud Guide and as separate guides...
15:06:25 <mattdm> scollier yeah. I have a request in for a feature to allow soemthing other than readme.md in the index, btw.
15:06:47 <mattdm> jsmith as long as that doesn't confuse people
15:07:04 <jsmith> mattdm: Aye :-)
15:07:24 <jsmith> mattdm: Since we have the Cloud Guide in place now, I guess I'd propose we use that for now
15:07:32 <mattdm> works for me
15:07:38 <jsmith> mattdm: And from there, it'd be really easy to split the pieces out into separate guides
15:08:07 <jsmith> The current outline for the Cloud Guide has suffered a lot of bitrot -- probably time to revisit it and rework it around the three or four items mentioned above
15:08:35 <mattdm> jsmith yah.
15:09:18 <mattdm> possibly, rename in some way to focus on cloud _guest_ images, and have something separate for openstack, eucalyptus and other IaaS on Fedora
15:11:21 <number80> we may focus on eucalyptus/cloudstack as they have featured and updated content on deploying stuff on fedora
15:11:54 <number80> they == openstack
15:14:31 <mattdm> number80 yeah, but separate. :)
15:14:39 <mattdm> okay, anything else for open floor?
15:15:20 <mattdm> okay! thanks everyone!
15:15:26 <mattdm> #endmeeting