14:05:46 #startmeeting 14:05:46 Meeting started Thu May 29 14:05:46 2014 UTC. The chair is jzb. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:05:46 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:05:54 #meetingname Fedora Cloud SIG 14:05:54 The meeting name has been set to 'fedora_cloud_sig' 14:06:25 #chair mattdm number80 oddshocks red_trela 14:06:25 Current chairs: jzb mattdm number80 oddshocks red_trela 14:06:34 * geppetto is here 14:06:43 #chair geppetto 14:06:43 Current chairs: geppetto jzb mattdm number80 oddshocks red_trela 14:06:46 thanks Gibba 14:06:52 er, geppetto 14:06:54 sorry Gibba 14:07:01 You're welcome ;-) 14:07:03 tab complete ftw ;) 14:07:09 yep 14:07:24 #topic Next Week's Chair 14:07:35 Ok, before we get started, I will be traveling next week 14:07:40 so - any volunteers for chair? 14:07:54 I should be able to make the meeting, but I won't have bandwidth to do any prep at all. 14:08:22 I can do it if no one else jumps up 14:08:32 I'll have to give an important presentation tomorrow in a week, so I'll likely skip the meeting 14:08:48 going once, going twice... 14:09:12 I win! 14:09:20 #action mattdm chair next week's meeting. 14:09:53 #topic next steps on test plan 14:10:00 #info https://fedorahosted.org/cloud/ticket/61 14:10:17 roshi, are you around? 14:10:20 OK, mattdm created a meeting ticket about the test plans 14:10:38 I am I am :) 14:10:46 #chair roshi 14:10:46 Current chairs: geppetto jzb mattdm number80 oddshocks red_trela roshi 14:11:11 roshi do you want to update on this? 14:11:26 sure 14:12:00 QA has been working on 'test outlines' for all the WG's 14:12:25 in order to get a decent guess as to how much testing there will be 14:13:18 Adam sent out an email regarding the test plans and release criteria 14:13:52 https://lists.fedoraproject.org/pipermail/cloud/2014-May/003899.html 14:14:14 what we need to discuss is blocker bugs and release criteria 14:14:39 as a product, does it make sense/help us to have our own blocker process? 14:15:18 roshi: is that a rhetorical question or should we chime in here? :-) 14:15:44 chime in, or respond to list I suppose :) 14:16:04 roshi: OK. tl;dr, I think yes. But I'll try to respond in more detail to the list if that's preferred. 14:16:05 as for me, I think at least *tracking* and tagging our blockers would be good 14:16:36 but it would likely require someone from the cloud SIG to be able to make QA blocker meetings 14:16:37 +1 for our own tags 14:16:41 I agree that having a specific cloud blocker list is good 14:17:29 one for all cloud or one per image? 14:17:38 yesterday I discovered another dhclient bug which prevents fedora working on GCE 14:17:50 good question red_trela 14:18:15 all? 14:18:28 red_trela: one per image, I think? 14:18:50 hmmm 14:18:51 trying to think of a case where one image would be blocked but another wouldn't. 14:19:15 there could be some sort of ostree problem -- do we block the whole thing for that? 14:19:17 blockers are big bugs 14:19:20 (probably yes) 14:19:46 or a problem with hadoop 14:19:56 or any of the nice differencies 14:20:03 mattdm: that's a good example, if one image depends on something another image doesn't. 14:20:24 but then again, we'll recognice by component, what images are actually affected 14:20:49 I think we basically need one list with subsections, and maybe a ranking on how important 14:21:01 figure QA should state whether it worries them if our blocker bug says NG while 2 out of 3 images are actually GO 14:21:22 there could always be a F21CloudFinalBlocker and then put the actual image in the whiteboard 14:21:31 you could search that way easily 14:22:41 zooz can you put that gce issue in https://fedorahosted.org/cloud/ticket/5 14:22:47 I don't see how that would be different from our release blocking desktops 14:23:02 an issue in one app can cause a NG 14:23:23 mattdm, sure. (I am working on figuring out what fails exactly and write a patch for it) 14:23:45 roshi: sounds good to me 14:24:10 which? 14:24:29 roshi yeah. it's just a big switch to go from "gui apps can stop us" to "we have to worry about whether hadoop works" 14:24:42 roshi: one blocker bug with whiteboard usage 14:25:16 mattdm: why's that a big switch? 14:25:22 and also, this seems tied to our updates plans...the current process relies heavily on whether something can be fixed in an update 14:25:41 jzb maybe not a switch, exactly, but an expansion 14:26:02 mattdm: the process itself doesn't, but the decisions that are made in regard of blockers 14:26:08 any component in the DE could stop us - so it doesn't feel that different to me 14:26:15 red_trela right, yeah. that's a basic assumption 14:26:18 mattdm: but on the cloud side, we don't have to care if GNOME works, which is a bonus :-) 14:26:32 we just have to care if our packages work 14:26:34 true :) 14:27:03 so anyway... what are our immediate action items here? 14:27:46 I think probably take it to the cloud@ list and discuss Blocker process and Release Criteria 14:28:35 to the list! then 14:28:40 also see 14:28:42 https://fedorahosted.org/cloud/ticket/4 14:28:48 #info new release criteria for post-f20 cloud image 14:29:09 I put some random things in there already. the ticket itself is not the best way to track, though 14:29:17 roshi: so is QA actually asking for our input here or is that independent of their work? do they have any opinion on this? 14:29:30 mattdm: how do you want to track it? Wiki? 14:29:47 it something that's up for discussion, that needs to be figured out 14:30:04 QA is looking for input from all the WGs for this 14:30:06 jzb yeah I think pretty much all of Fedora QA stuff is wiki focused 14:30:20 roshi: okay, thanks for the clarification 14:30:43 90% of our stuff is wiki 14:30:53 * roshi really wants to change that someday 14:31:13 so, punt to list? 14:31:19 roshi for now, is there a particular wiki page where we should put things? 14:31:30 and then, yeah, +1 for punt-to-list :) 14:31:47 can you edit in my Cloud_Docs page? 14:32:02 that's the only place I can think of atm 14:32:17 I don't know this is being tracked anywhere but lists 14:32:52 roshi: yes, looks like we can 14:33:13 we can just make a page there - if it suits you all 14:33:15 my proposal is to track the general progress in the ticket but put specific things in the wiki draft 14:33:35 wfm 14:34:03 are we at the end of this one? 14:34:19 yup, afaict 14:34:23 groovy 14:34:37 #topic Process for determining when and why Docker trusted images need to be rebuilt 14:34:45 #info https://fedorahosted.org/cloud/ticket/59 14:35:03 paging scollier :) 14:35:06 I don't think we managed to discuss this last time, since we didn't really meet last week. 14:35:43 does anyone want to volunteer to draft a policy for discussion? 14:35:59 mattdm: depends 14:36:08 mattdm: do we have a similar policy I can cheat off of? :-) 14:36:34 I think we are kind of in uncharted territory, unfortunately. 14:36:35 (anything remotely similar will do.) 14:36:37 ah 14:36:47 OK 14:36:55 we do also need something similar for non-docker images 14:37:09 I'll take the bullet - it'll be wildly in need of other eyes, but I can do the first draft. 14:37:19 but since right now, we don't update any images except when the security response team says we need to 14:37:31 and then we all panic and run around like crazy and stay up all night 14:37:36 * mattdm wants to not do that anymore 14:37:54 mattdm: you've certainly picked the right industry 14:37:57 *cough* 14:38:22 jzb awesome thanks. I think having a strawman to work against is perfect 14:38:25 we need a CI like process for images and you'll be able to take some sleep when it happens 14:38:36 number80 +1111111111111!!!! 14:38:40 #action jzb create the first draft for people to pick at for when Docker trusted images need a rebuild. 14:38:57 did number80 just volunteer to set up a CI process for images? 14:39:12 I think so 14:39:18 that's what it sounded like to me 14:39:31 jzb: if it can wait 2 weeks, why not :) 14:39:36 once oddshocks gets the upload service going, we're much closer :) 14:39:36 * number80 still one-armed 14:39:49 number80: how's the healing? 14:40:17 as long as nobody keeps slapping me there, it'll be fine ;) 14:40:22 although I guess the docker trusted builds are a separate thing 14:40:48 they're triggered by a push to github 14:40:55 #info assigned jzb ticket #59 14:40:56 oddshocks understanding of the build process would be helpful though 14:41:16 so really it is the policies we need more than anything 14:41:22 OK, anything else on that topic? 14:41:32 right 14:42:59 right, moving on. 14:43:58 #topic start communication/collaboration on cloud image updates 14:44:06 #info https://fedorahosted.org/cloud/ticket/51 14:44:17 mattdm left this open for "a status update next week" 14:44:17 this is still roughly in the same spot 14:44:30 roshi: nothing new to report/discuss 14:44:31 Taskotron has moved to a two week release cycle 14:44:31 ? 14:44:36 jzb this is kind of related to the docker image update policies -- some of the same questions 14:44:49 K 14:45:07 things are moving forward and getting issues/features done at a decent clip (as far as I can tell and have been told) 14:45:18 oddshocks getting the image uploader working also counts as things moving forward here :) 14:45:30 and dgilmore started a bit of conversation with the mirrors 14:45:37 once it gets to the point tasks can be written and run then we can start working on cloud tasks 14:46:02 but I will add the desire to do updated images to the current thread adamw started about fedora.next qa in general 14:46:10 mattdm: For sure. Still missing a RH account/credentials (haven't heard back from paul), but I'm making progress 14:46:38 my question is: what tests are currently done to cloud images that we want to move to taskotron? 14:46:52 or is this a "from scratch" effort? 14:47:00 I guess second 14:47:25 oddshocks paul is out sick for the whole week so far 14:47:32 roshi kind of from scratch 14:47:58 I thought I remembered you saying that, but I was hoping I was mis-remembering ;P 14:48:07 roshi the complete state of current tests is: 14:48:09 http://fedoraproject.org/wiki/QA:Testcase_EC2_AMI_Validation 14:48:19 mattdm: bummer. was hoping that we'd be able to shake the RH People folks a bit so they give me an account so I can record my hours and get internal FTP and AWS creds 14:48:24 https://fedoraproject.org/wiki/QA:Testcase_OpenStack_Image_Validation 14:48:53 oddshocks let me see what I can do 14:49:16 right, the tests you need an account to perform, right? 14:50:36 oddshocks I think most of what you'll need isn't internal -- get from #fedora-admin and releng 14:50:43 we can discuss this more in channel (automated tests) if there's more to do jzb 14:50:51 sounds good. 14:51:02 * roshi doesn't want to take all the time with his questions :) 14:51:14 we have a fedora community account in ec2 which we can use for the automated testing .... need to figure out how to handle credentials in taskotron 14:51:18 and same with internal openstack 14:51:24 OK, I think the other two tickets still tagged "meeting" are in process 14:51:41 any objections to skipping those this week? 14:52:07 * mattdm looks 14:52:18 yeah it's kind of all more of the same 14:52:46 OK 14:52:52 one last thing I wanted to raise this week 14:53:04 #topic Guidelines for Creating Dockerfiles 14:53:14 #info https://github.com/fedora-cloud/Fedora-Dockerfiles/wiki/Guidelines-for-Creating-Dockerfiles 14:53:50 We've already started on this a bit, but I think eventually RHT is going to be creating its own policies for Dockerfiles 14:54:02 currently RHT inherits its packaging guidelines from Fedora 14:54:19 but would like to work on Dockerfile guidelines with Fedora, and probably the CentOS project 14:54:43 I'd like to suggest/discuss working on a set of guidelines through Project Atomic instead of just one per project 14:54:44 * roshi needs to read up on Docker 14:54:49 thoughts, comments, flames? 14:54:59 * misc wonder about the parsability of dockerfile 14:56:03 not sure project atomic is the right place to do so (not saying it isn't, though) but working together is always better 14:56:59 any other thoughts? 14:57:34 I think coordination is good 14:57:56 but we need to make it clear to people looking for Docker on Fedora that we actually have an easy story for that 14:57:59 I don't know enough about it to have a proper thought 14:58:16 and aren't asking people to go running around the internet to get help 14:58:45 mattdm: good point 14:59:23 OK, anything else this week? 14:59:32 going once... 15:00:06 oddshocks, want to summarize what you're doing? 15:00:10 Sure 15:00:14 i know it's early in the process :) 15:01:52 Where I am right now is basically I have written a basic fedmsg consumer to get Koji messages via the hub-consumer approach. When images are built and fedmsg tells us, my service will upload the images to our cloud providers. i've pinned down https://libcloud.apache.org as a library I can use to easily upload to a number of services such as EC2 and Rackspace 15:02:12 Goal right now is to get EC2 and our internal Fedora FTP server getting images, then from there move on to Rackspace and whatnot 15:02:35 so that's the short term. i expect to have something working to show next week :) 15:02:45 oddshocks: did you consider deltacloud ? 15:02:49 oddshocks: what do you mean by "internal Fedora FTP server"? 15:03:25 number80: Haven't seen it 15:03:51 oddshocks: take a look, some of the guys maintaining it are lurking around ;) 15:03:59 dgilmore: I was told we need uploads to "an internal Ftp server" which basically consists of moving files onto an NFS drive I have been told 15:04:08 i think this might have to do with it... 15:04:29 oddshocks internal ftp server is _fedora_ internal, not rh internal, by the way -- sorry if that wasn't clear 15:04:38 I don't actually know the details, but dgilmore will 15:04:39 deltacloud and libcloud are about the same (both apache projects, too) but one is written in ruby and one in python...and there's also jcloud, written in java ;) 15:04:40 mattdm: that was clear. :) 15:04:51 jclouds* 15:05:21 A link on the old KojiPlan wikipage linked to this but it's a broken link now: https://dl.fedoraproject.org/pub/alt/cloud 15:05:48 oddshocks: we really need a mash like tool for images and livecds. to pull together a tree. and then its a rsync 15:05:54 * mattdm thought deltacloud is dead upstream 15:06:19 oddshocks: likely we will put things in /pub/fedora not /pub/alt 15:06:19 :/ 15:07:08 dgilmore even nightlies? 15:07:26 anyway, there's probably details here that we don't need everyone for. :) 15:07:27 mattdm: it sure doesn't look very healthy 15:07:33 OK 15:07:36 mattdm: under rawhide 15:07:44 dgilmore cool 15:07:49 In fact, I wonder if Apache should consider shutting it down. 15:08:04 s/shutting it down/moving it to the attic/ 15:08:04 mattdm: dgilmore: I'd be happy to hear more and get more details on what I should best do :) 15:08:12 OK, let's tie this meeting up 15:08:29 jzb: +1, thanks 15:08:30 going to shut it down in 60 unless someone has really pressing topic. 15:09:20 OK 15:09:25 see you all next week 15:09:29 #endmeeting