18:08:33 <walters> #startmeeting
18:08:33 <zodbot> Meeting started Wed Sep 17 18:08:33 2014 UTC.  The chair is walters. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:08:33 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:09:13 <walters> first item that comes to mind is compose status
18:09:21 <walters> and the mirrormanager thread
18:10:16 <dgilmore> we have atomic in in RC1
18:10:31 <dgilmore> we do not yet have things done for nightly
18:10:47 <dgilmore> right now we do not have mirrormanager running right for f21
18:11:22 <walters> #link http://dl.fedoraproject.org/pub/alt/stage/21_Alpha_RC1/Cloud/Images/x86_64/
18:11:49 <dgilmore> I need to put the actual atomic tree up
18:12:16 <walters> any blockers for that that anyone can help with?
18:12:30 <walters> has anyone tested these images?  I'm downloading now
18:12:40 <dgilmore> walters: no idea
18:13:18 <walters> i think SOP would be to fill in https://fedoraproject.org/wiki/Test_Results:Fedora_21_Alpha_RC1_Cloud ?
18:13:48 <walters> probably need to duplicate this matrix for atomic vs mainline cloud
18:13:59 <dgilmore> http://dl.fedoraproject.org/pub/alt/stage/atomic/ has teh atomic tree
18:14:04 <dgilmore> walters: likely
18:15:47 <walters> done now
18:15:54 <walters> that tree is from RC1?
18:16:07 <dgilmore> walters: yes
18:16:09 <walters> #link http://dl.fedoraproject.org/pub/alt/stage/atomic/
18:16:20 <dgilmore> its whats installed into the atomic cloud image
18:16:32 <walters> cool
18:18:00 <walters> what are the next steps for the mirroring work?
18:18:36 <dgilmore> i do not know
18:18:56 * nirik reads up
18:19:19 <dgilmore> we do need to get things made nightly
18:19:31 <dgilmore> and get that out somewhere
18:21:28 * roshi is here
18:22:30 <walters> once we have the mirror up, we need to figure out whether we bake in the metalink XML into the image, or create a fedora-release-atomic package that contains config
18:22:40 <walters> er, bake the metalink URL
18:23:29 <dustymabe> fedora-release-atomic sounds like a good idea.. then again. I guess we can't really change it on the fly
18:23:33 * jbrooks is here, late, reading scrollback
18:23:51 <walters> hmm, i'm running into cloud-init issues
18:23:55 <dustymabe> so there wouldn't be much point.. other than just having things nice and neat
18:24:11 <dustymabe> walters: any specifics?
18:24:27 <walters> http://fpaste.org/134330/09782451/
18:25:09 <dustymabe> what user-data did you supply?:
18:25:16 <roshi> walters I can speak to the matrices for testing atomic later in the meeting
18:25:18 <dgilmore> walters: has it ever worked?
18:25:39 <walters> dgilmore, yeah
18:26:01 <dustymabe> walters: FYI this might help you find more info: http://dustymabe.com/2014/09/08/capture-elusive-cloud-init-debug-output-with-journalctl/
18:26:09 <walters> with the "it" here being a large collection of changing RPMs not regularly subject to automated testing
18:26:10 <dustymabe> but you probably already know about that
18:26:43 <walters> anyone else want to give the image a try?
18:26:52 <jbrooks> walters, I will
18:27:44 <walters> hmm
18:27:45 <dustymabe> walters: can you paste up the debug output from cloud-init?
18:29:41 <walters> there's not more useful info
18:29:56 <walters> anyways we can debug the image async from this meeting
18:30:45 <walters> there was gpg, but that requires more ostree work on top of the existing metalink code
18:31:59 <walters> beyond that, at some point soon we should talk about the atomic f22 plans and how stuff like lorax will work, how we share compose tooling with fedora rel-eng...but cloud image for f21 first
18:33:12 <walters> anyone have other items?
18:34:15 <roshi> if I can interject :)
18:34:24 <roshi> testing for Atomic
18:34:31 <walters> yep
18:34:52 <roshi> well, the current docs for Cloud I wrote only for the cloud base image
18:35:20 <roshi> atomic didn't stick out as anything close to a release blocker in my head
18:35:54 <walters> right
18:35:59 <roshi> after talking to #fedora-cloud and mattdm it appears that the goal is to have atomic be a potential release blocker
18:36:33 <roshi> if this is something that's going to happen (or wanted to happen), then we need to take a good look at the release criteria and how atomic fits into it
18:36:52 <roshi> as well as draft testcases to validate against those criteria (or the existing criteria)
18:37:30 <roshi> for the time being, (if it's enough), I can just add another table to the current Cloud matrix
18:38:07 <walters> can you link to that?
18:39:07 <roshi> sure
18:39:10 <roshi> https://fedoraproject.org/wiki/Test_Results:Fedora_21_Alpha_RC1_Cloud
18:39:55 <walters> right, i edited that page just earlier to duplicate the x86_64 matris
18:39:57 <walters> *matrix
18:40:04 <walters> (note atomic is x86_64 only)
18:40:51 <roshi> ah, you did it already :)
18:41:18 <roshi> my question is: is that enough coverage to say "Yes, our Atomic image is good for GA"?
18:41:40 <roshi> if it's a very different image than the base cloud image, I wouldn't think that would be enough coverage
18:42:58 <walters> we clearly need docker testcases
18:44:47 <roshi> without a doubt
18:44:57 <roshi> I'm learning docker bit by bit
18:45:03 <dustymabe> walters: we should be able to write a script that will easily do a smoke test on docker
18:45:22 <roshi> as I learn how it's supposed to act, I can write test cases - but it might be slow as I learn
18:45:25 <dustymabe> roshi: I can help
18:45:29 <roshi> for sure dustymabe
18:45:45 <walters> ah...is the idea that the tests that include _base_ apply to all products?
18:46:12 <roshi> but even if we have automated tests (which we want, and taskotron will be able to handle in the future) we should have them written out so they can be run manually as well
18:46:30 <dustymabe> roshi: sure
18:46:43 <roshi> the "base" in the testcase names just means that we're referencing the same testcase on the wiki as the other matrices
18:47:31 <roshi> so first -> what do we want to test -> document it -> write test cases -> write automated tests based off those testcases
18:47:38 <roshi> as I see it anyways
18:49:13 <walters> #action create docker test case/atomic test cases for release criteria
18:49:25 <walters> any other agenda items?
18:50:01 <roshi> also, make sure we don't need new release criteria
18:50:01 <number80> (actually, we need rpm-ostree test cases, other could be derived from the existing ones)
18:50:45 <walters> number80, also a good point, at the moment the client is intentionally limited to upgrade/rollback plus some informational commands, but yes
18:52:23 <number80> I did try the atomic image on openstack and it's in good shape actually
18:52:46 <number80> but I don't know the current corner cases we should test
18:52:50 <walters> really?  ok, so i have local cloud-init issues then
18:53:12 <dustymabe> walters: yeah I was able to use an image from about 2 weeks ago with cloud-init
18:53:18 <walters> ok cool
18:53:24 <dustymabe> with openstack
18:53:47 <walters> the next step is to add the above tree as a remote and upgrade
18:53:48 <number80> walters: maybe this could be added to the test matrix for cloud
18:53:57 <number80> *nods*
18:54:01 <roshi> for sure
18:54:24 <dustymabe> fyi I tried similar things with CentOS7 atomic.. thats when I hit a bug in partx
18:54:28 <dustymabe> https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2014-September/msg00014.html
18:55:17 <walters> right
18:55:21 <dustymabe> actually this mail describes it better: https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2014-September/msg00004.html
18:55:56 <dustymabe> walters: I assume you are aware of that issue
18:56:09 <walters> yes, blocked on storage rework
18:56:48 <dustymabe> walters: you mean "rework" of our storage strategy for atomic?
18:57:06 <walters> that was what i was thinking, though we could try backporting partx i guess
18:57:44 <dustymabe> yeah. we could come up with a strategy that doesn't need it I guess.. but that assumes we only deliver an image with a single partition
18:57:53 <dustymabe> is there a chance of that?
18:58:19 <dustymabe> FYI this only affects CentOS.. it is fixed in util-linux in F21
18:58:26 <dustymabe> sorry to hijack the meeting
18:59:14 <number80> dustymabe: this is #atomic upstream channel so it's not out of topic :)
18:59:28 <walters> that's all i had for the moment, i'll debug login issues and then return to working on content set issues
18:59:35 <dustymabe> number80: i guess you are right :)
19:02:36 <dustymabe> sounds like we can close the meeting.
19:02:42 <walters> #endmeeting