18:59:59 #startmeeting Cloud WG 18:59:59 Meeting started Wed Apr 8 18:59:59 2015 UTC. The chair is roshi. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:59:59 Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:00:11 #meetingname Cloud WG 19:00:11 The meeting name has been set to 'cloud_wg' 19:00:21 .hello oddshocks 19:00:22 oddshocks: oddshocks 'David Gay' 19:00:24 #topic Roll Call 19:00:28 .hello roshi 19:00:29 .fas Corey84 19:00:30 roshi: roshi 'Mike Ruckman' 19:00:33 Corey84: corey84 'Corey84' 19:01:38 #topic Previous Meeting Followup 19:01:41 * jzb to take the Atomic Spin idea to the Spin SIG 19:01:42 * dustymabe to update the ticket saying this will land in F22 19:01:47 jzb: ? 19:02:36 dusty's task is done 19:02:48 roshi: yo 19:02:54 .hellomynameis jzb 19:02:55 jzb: jzb 'Joe Brockmeier' 19:03:00 o/ 19:03:16 roshi: have not done that yet. 19:03:44 kk, no worries 19:03:49 any ETA in mind? 19:04:38 roshi: walters just reopened (temporarily) the discussion 19:04:44 roshi: so after that is closed again. 19:04:55 ok 19:04:57 thanks 19:05:01 roshi: note that we may not qualify for Spin as it includes copr builds 19:05:11 ah 19:05:23 Did not know that was a thing 19:05:26 so it may be we need to 1) either get an exception (possible but difficult) or 2) go with Remix instead of Spin 19:05:28 me either 19:05:47 basically anything for a Spin still needs to be built in Koji 19:05:49 per spot 19:05:57 good to know 19:06:08 any reason why stuff can't be built in koji? 19:06:49 roshi: we're building newer versions of the packages so ... 19:06:50 * roshi isn't that familiar 19:07:02 you can not use copr builds in a spin 19:07:18 dgilmore: yeah, we know :-) 19:07:20 it would have to be a remix, which is entirely on you to put together 19:07:39 if it's a remix, could it ever be blocking? 19:08:01 oh wait, this is in leiu of it being a blocker for F23, right? 19:08:08 an in the mean time fix 19:08:09 roshi: blocking what? we would be (and want to be) outside the regular release cycle 19:08:37 that's right, nvm - I'm just blabbering now 19:08:59 #info ignore the crazy guy in the corner talking to himself about remixes 19:09:24 alright, onto topics? 19:09:30 roshi: go for it! 19:09:48 #topic Maintaining docker images for F22 19:09:51 #link https://fedorahosted.org/cloud/ticket/97 19:10:44 you again jzb :) 19:10:55 * jzb grumbles about having to log into each fedora hosted trac instance separately 19:11:09 yeah, I haven't had time to update the ticket, but 19:11:23 1. The current tc8 docker image seems fine. 19:11:35 I think the problems we had early on are solved. 19:11:48 and we're going to be doing the testing of the docker image, not the base WG, right? 19:11:50 2. I've sent a note to -devel about the current location of the Docker images 19:11:51 good good 19:11:57 roshi: hang on, still typing ;-) 19:12:21 kk :p 19:12:27 hoping to move promotion and listing of the Docker images to Cloud 19:12:48 3. I haven't gotten as far as testing yet :-( 19:13:03 got a link to the mail sent to devel? 19:13:09 but I will bring that up in the location/promotion of the images discussion. 19:13:13 roshi: just a sec 19:13:22 thanks, it'll be useful in the meeting logs 19:13:55 #info https://lists.fedoraproject.org/pipermail/devel/2015-April/209742.html 19:14:28 thanks 19:14:38 and will update the ticket momentarily 19:14:45 sweet, thanks 19:14:51 anybody have anything else? 19:16:21 moving on then... 19:17:38 #Topic Dockerfiles care and feeding 19:17:41 #link https://fedorahosted.org/cloud/ticket/84 19:18:34 roshi: no update this week 19:18:34 * roshi is supposed to be helping with this, but have been doing release validation and making sure things are good to go before I head out on some PTO... 19:18:56 wfm jzb 19:20:14 anybody have anything for this ticket? 19:20:43 * roshi moves on 19:20:53 #topic sha256sums 19:20:58 #link https://fedorahosted.org/cloud/ticket/93 19:21:06 I think we can close this one and reopen it for F23 19:21:45 roshi: yeah 19:21:48 proposal: remove the meeting tag from this ticket until F23 19:21:51 +1 19:22:58 +1 19:23:18 * roshi removes the tag - counting jzb in favor due to his 'yeah' 19:23:49 #topic Updated Images 19:23:51 #link https://fedorahosted.org/cloud/ticket/94 19:24:18 I got nothing for this ticket 19:24:34 oddshocks: ^^? 19:25:13 Nothing more from me on that. 19:25:53 Is there really anything we have to worry about with that for F21? 19:26:02 and you're going to be shephearding that effort, right? 19:26:19 don't think so 19:26:24 per the last comment in the ticket 19:26:31 if it's done let's close the ticket. 19:26:35 we decided to leave it alone for F21 and start it for F22 19:26:43 +1 jzb 19:26:53 I don't know what else there is to do on that. I say +1, let's shove it off until F22 19:27:00 er, until after F21 release 19:27:20 F22 release you mean 19:27:21 ? 19:28:06 yes. 19:28:07 yes, that. 19:28:08 :P 19:28:24 * roshi closes the ticket 19:28:50 #topic Open Floor 19:28:57 that's all the tickets 19:29:05 so, I wanted to take a quick poll 19:29:06 ah. 19:29:15 out of the following: 19:29:21 1 - Cloud Base Image 19:29:29 2 - Atomic Host Image 19:29:35 3 - Vagrant Images 19:29:50 4 - Atomic Images (not the bare metal host) 19:29:55 5 - Docker Images 19:30:13 which of these are people under the impression they're release blocking for F22? 19:30:34 * roshi 1 19:30:43 1,2,4,5 19:30:50 ^^ should be 19:31:02 roshi: what's the diff between 2 and 4? 19:31:18 roshi: 1,3,5 19:31:20 one runs on bare metal and the other in the cloud 19:31:47 was my impression, anyways 19:31:56 oddshocks: ? 19:32:03 jsmith: ^^ 19:32:06 number80: ^^ 19:32:16 hm 19:33:07 I think I'm gonna agree with kushal. Definitely not 3. But we seem to be pretty focused on docker/atomic, and of course the base image should be blocking 19:33:33 jzb: What are your thoughts on why atomic shouldn't be a blocker? 19:33:49 * oddshocks probably doesn't fully grok the entire situation 19:34:05 oddshocks: because we're already proposing the 2-week spin/remix and not planning to have an Atomic Host f23 edition. 19:34:05 atomic will be a spin/remix 19:34:09 so outside the cycle 19:34:17 so I don't see any reason to block F22 if there's some bug in the process that afflicts it. 19:34:35 Ahhh 19:34:50 out of those, does anybody have any notes that fesco and QA are aware of more than 1 being a blocker? 19:34:55 because I don't have any 19:35:03 Alright, I'll revise my answer, then :P 19:35:11 the only one I know as blocker F22 is the base cloud image 19:35:55 and that's also the only on QA has been tracking, has criteria associated with it or any amount of testcases for it 19:36:02 That's the only one I'm 100% sure we should be blocking on 19:36:26 I think how the process should go is this: 19:36:40 oddshocks: we should absolutely be blocking on the Docker image if we're not. 19:36:55 jzb: Alright 19:37:15 we decide what we want to block on (too late for F22, IMO), we propose to fesco/qa/whoever, docs get written for it once decided (release criteria, test plans, etc) 19:39:47 thoughts? 19:40:18 roshi: I don't. 19:40:39 roshi: is there a checklist somewhere that we should follow for these new things? 19:40:55 not that I know of, but I can write one up 19:41:37 roshi: I kind of feel like much of my life these days is about finding out new and interesting things that aren't obvious but should have been done and now it's a bit too late to do them, but check back in six months. ;-) 19:41:51 I know the feeling :) 19:42:01 I just want to make sure we're on the same page 19:42:19 roshi: heck, at this point I'd settle for same book and chapter. 19:42:31 we're probably all in the same library. 19:42:34 I don't have strong feelings towards any of the particular images blocking or not blocking - I just want to make sure we're set up to succeed when we try to do them 19:42:41 maybe even the same Dewey Decimal section. 19:42:47 haha 19:43:13 so, unless someone has notes somewhere - the only blocker we have for F22 is the cloud base image 19:43:36 and the need for an impending vote when we have more people present 19:43:44 then a fesco ticket and fesco meeting 19:43:49 roshi: where would these notes *be*? 19:43:50 that sound about right? 19:43:59 devel list, meeting logs 19:44:06 any mailing list, actually 19:44:12 roshi: let's take a step back 19:44:25 roshi: what's the Official Sanctioned Process for declaring something a blocker? 19:44:37 afaik, there isn't one 19:44:37 e.g. who decides that? Us? FeSCO? 19:44:53 since in the past, it was fesco and the board maybe - and it was just desktops and arches 19:45:10 lemme see if I can summon mattdm 19:45:25 already invoked his name in cloud 19:46:07 adamw: maybe you would know? 19:46:23 adamw: what's the official decider for making something a release blocker or not? 19:46:42 haha, I just pinged him in #fedora-qa about it 19:46:51 roshi: he's here 19:46:52 * roshi mumbles something about great minds... 19:47:04 well, he's lurking at any rate. 19:47:17 yeah, I just know he monitors #fedora-qa pretty close 19:47:28 adamw, adamw adamw adamw 19:47:44 roshi, ^^^ adamw will notice this one. 19:47:52 sgallagh: just answered in qa channel 19:48:10 19:47 < sgallagh> roshi: For arches, I think that was basically a joint Board/FESCo decision 19:48:39 I think this is a new process that needs to come along with the fedora.next stuff 19:48:54 Sorry, what's the context here? 19:49:07 cloud has several differing images 19:49:18 and several differing ideas of what's blocking release 19:49:22 OK 19:49:27 I only know of one, which is the cloud base image 19:49:38 if you scroll up, you'll see a list of the images 19:49:49 So in terms of the release media, each of the Product WGs is supposed to decide that, include it on the PRD and communicate it to FESCo and QA 19:50:04 That was part of the initial planning stuff we did during the gap between F20 and F21 19:50:09 It was meant to be ongoing. 19:50:13 sgallagh: I think we may be in deep need of updating the PRD for Cloud 19:50:14 that was my impression 19:50:28 and we need to update the PRD and take it to fesco 19:50:30 jzb: Yes, without a doubt. 19:50:37 sgallagh: as I recall working on the PRD quite some time ago, finishing it, and I don't think we've referred to it since. 19:50:46 roshi: It's too late for F22, obviously. 19:50:50 we haven't really 19:50:52 sgallagh: a PRD review should be part of the prep process? 19:50:54 But yes, please update it early for F23 19:50:58 that's what I thought too sgallagh 19:51:00 jzb, we have to update it. 19:51:06 kushal: yes 19:51:17 jzb, that is actually in my TODO list. 19:51:38 I'll add a meeting item to track progess on updating that for F23 19:51:40 I'd say that decisions about blocking install media need to be approved before Alpha Freeze, but that's not a codified requirement. 19:51:44 Just sensible (IMHO) 19:51:52 +1 sgallagh 19:52:40 kushal: yay! does that mean we're off the hook? 19:53:02 jzb: The opposite. It means you can't slack off and then slip the release to finish :) 19:53:15 sgallagh: I <3 sensible, but maybe codifying that would prevent unhappiness later? 19:53:29 probably would be a good idea 19:53:30 jzb: Oh absolutely. 19:53:40 I just meant that I'm not authoritative, so take that for what it's worth 19:53:53 sgallagh: you're not? oh. 19:53:53 I think we just got stung by a new process we weren't really paying attention to and caught it late 19:53:55 (Occasionally authoritarian, but rarely authoritative) 19:54:19 jzb: I may be confusing you. 19:54:38 New blocking media MUST be approved by FESCo (who will always be expected to check with QA before doing so) 19:54:46 Right now, there's no official time this has to happen. 19:55:04 On my personal opinion, the policy should be "before Alpha Freeze", but it's not written down anywhere at present. 19:55:19 So in theory, FESCo could buck good sense and do so, but I'd vote against it :) 19:55:40 jzb, nope, my TODO list says get jzb to write the updated PRD 19:55:45 heh 19:56:04 sgallagh: wait, isn't "is/isn't blocker" part of feature proposals? 19:56:30 jzb: That would qualify as a "FESCo approval request" 19:56:51 are features meant to be for new blocking products though? 19:56:58 OK, so it's less wild west than I was thinking. 19:57:02 roshi: Excellent question 19:57:03 I see that as new included libs and whatnot 19:57:22 new apps/functionality - ie, features 19:57:37 I think I'd argue that if the Change was filed by a WG, then asking it to include blocking media is reasonable 19:57:38 a feature of a new car is the sun roof, not another model 19:57:46 I wouldn't necessarily say the same from J Random Contributor 19:58:15 roshi: I have no problem with that mechanism starting the process. 19:58:21 How we proceed from there is a matter of some discussion 19:58:30 for sure 19:58:52 (Also, we changed the term from Features to Changes for a reason) 19:59:35 Since these are meant to be high-value alterations to The Fedora Project, not necessarily technical or user-facing features of one or more editions 20:00:03 ah 20:00:15 sorry for the equivocation :) 20:00:49 ok, so what does this all mean for us *right now*? 20:01:31 sgallagh: I should know this, but 20:01:43 sgallagh: do we do any kind of release post-mortem? 20:01:51 IMHO, *right now* it means that https://fedoraproject.org/wiki/Cloud/Cloud_PRD?rd=Cloud_PRD#Delivery_Mechanisms provides the list of blocking media 20:02:05 I know marketing is *supposed* to, but I don't know if we do a project-wide one. 20:02:27 The Release Readiness Meeting usually doubles as such 20:02:31 But it's not really project-wide 20:02:59 roshi: ok, so now I've figured out why I believe Atomic is blocking 20:03:02 It's hard to do a project-wide meeting because it usually just ends up a flamewar on devel@ 20:03:05 roshi: http://fedoraproject.org/wiki/Changes/Atomic_Cloud_Image 20:03:16 roshi: under Contingency Plan 20:03:28 roshi: "Blocks product? Yes, Atomic Cloud Image (duh!)" 20:03:39 roshi: so, yes, there are notes! :-D 20:03:45 roshi: and it was accepted by FeSCO 20:04:12 so it would block the atomic cloud image, but does that mean full release? 20:04:25 I mean, I thought that line was kinda tautological 20:04:25 roshi: what's missing here, is that using the feature mechanism, there's no automatic approval / disapproval 20:04:46 roshi: you're right, but that's why I *thought* it ;-) 20:04:51 ah 20:04:57 that clears that up then 20:05:05 and why I thought it didn't 20:05:12 "Of course it blocks itself" 20:05:13 lol 20:05:51 roshi: yes, but if it's an accepted change we should make all necessary efforts to make sure it succeeds. 20:05:51 jzb: My advice at this point is to not expect that issues exclusive to Atomic Cloud Image will block the release 20:06:00 sgallagh: Agreed. 20:06:03 But *do* apply for Freeze Exception where needed. 20:06:06 +1 20:06:15 jzb: sorry, i'm multitasking. we don't have a super solid process for it, it's been kind of ad hoc and on the fly so far. 20:06:33 adamw: no worries, thanks. Maybe we should firm that up for 23. 20:06:43 in ye olde days we only *had* a few images so it was fairly obvious. 20:06:46 sgallagh: and I wonder if there's a way to do an informal postmortem. 20:06:52 without it devolving. 20:07:01 sgallagh: I think it'd be valuable. 20:07:09 jzb: Like I said, we usually end up doing some of that durng the Final Release Readiness meeting 20:07:16 I'm all for FE's and whatnot for atomic 20:07:27 But maybe ask mattdm to set up a formal townhall meeting or something 20:07:28 just wanted to nail down what would make us slip so we know ahead of time 20:07:42 sgallagh: +1 20:08:15 adamw: growth is painful. We seem to be experiencing pain, therefore we must be growing successfully, right? ;-) 20:08:39 i'll drink to that... 20:08:47 /me looks at all the eggshells around 20:08:52 same here 20:08:59 to the drinking 20:09:04 not sure about egg shells 20:09:28 * jzb notices we may have gone off the rails slightly 20:09:35 roshi: should we wrap it up? 20:10:15 yep - I think so 20:10:27 just wanted to try to reconvene in the same section of the library :p 20:10:32 * roshi sets the fuse 20:10:35 3... 20:10:46 2... 20:10:52 1... 20:10:57 thanks for coming folks! 20:11:01 #endmeeting