19:01:59 #startmeeting Fedora Cloud SIG 19:01:59 Meeting started Wed Jan 21 19:01:59 2015 UTC. The chair is kushal. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:01:59 Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:02:09 #meetingname Fedora Cloud SIG 19:02:09 The meeting name has been set to 'fedora_cloud_sig' 19:02:19 #topic Roll Call 19:02:43 .hellomynameis oddshocks 19:02:44 oddshocks: oddshocks 'David Gay' 19:03:00 .hello roshi 19:03:01 roshi: roshi 'Mike Ruckman' 19:03:13 .hellomynameis kushal 19:03:14 kushal: kushal 'Kushal Das' 19:04:54 roshi, people vanished :) 19:05:34 so it seems :) 19:05:40 * gholms appears 19:05:42 .hellomynameis lsm5 19:05:44 lsm5: lsm5 'Lokesh Mandvekar' 19:05:46 * dustymabe got held up 19:05:54 .hellomynameis dustymabe 19:05:54 dustymabe: dustymabe 'Dusty Mabe' 19:06:11 #chair dustymabe oddshocks roshi lsm5 gholms 19:06:11 Current chairs: dustymabe gholms kushal lsm5 oddshocks roshi 19:06:33 .hellomynameis jzb 19:06:34 jzb: jzb 'Joe Brockmeier' 19:06:45 #chair jzb 19:06:45 Current chairs: dustymabe gholms jzb kushal lsm5 oddshocks roshi 19:06:59 hello 19:07:02 #chair scollier 19:07:02 Current chairs: dustymabe gholms jzb kushal lsm5 oddshocks roshi scollier 19:07:44 wondering if anyone else will join!! 19:07:55 anyway 19:08:10 #topic Action items from last meeting 19:08:17 * jzb propose the Vagrant feature for F22 19:08:22 * jsmith is finally here 19:08:31 #chair jsmith 19:08:31 Current chairs: dustymabe gholms jsmith jzb kushal lsm5 oddshocks roshi scollier 19:08:39 fyi https://meetbot.fedoraproject.org/fedora-meeting-1/2015-01-14/fedora_cloud_sig.2015-01-14-19.02.log.html 19:08:51 I don't know if that ever made it to the list 19:09:05 dustymabe, nope, I missed that. 19:09:19 Including another task :( 19:09:54 So who all submitted feature proposals for Fedora 22? 19:10:09 oooh, me! 19:10:26 * kushal is going discuss those links/proposals before going to tickets if everyone is okay :) 19:10:26 kushal: the one assigned to me (rocket) is still pending :( ...I'll get that done over this week 19:10:30 * going to 19:10:42 lsm5, have you submitted the proposal? 19:10:55 kushal: not yet ..is it too late ? 19:11:05 lsm5, yes :( 20th was the last date. 19:11:11 woah 19:11:16 kushal: does Rocket actually require a feature request? 19:11:43 jzb, lsm5 we can just have it, but adding that as a feature proposal means we can market it better. 19:11:56 * roshi did his too 19:11:57 In this case we will make sure that we market that well anyways :D 19:11:59 kushal: so should I still go ahead and file it? 19:12:02 kushal: exactly 19:12:45 lsm5, I guess, you can just keep working on the real technical work and update that proposal wiki as you find time. Because they will not accept any new proposal. 19:12:57 kushal: alright 19:13:26 I have submitted one proposal to use tunir to test Fedora Cloud images automatically. 19:13:53 jzb, How many proposals from you this time? 19:14:17 I guess langdon did a proposal on vagrant, not sure though if it went in on time. 19:14:51 I think I saw the announce 19:14:54 kushal: two 19:15:16 kushal: Vagrant (along with imcleod and langdon) and bare metal (with imcleod) 19:15:35 That means at least 4 proposals from the Cloud SIG, good :) 19:15:41 https://fedoraproject.org/wiki/Changes/Vagrant_Box_Atomic 19:15:54 https://fedoraproject.org/wiki/Changes/Bare_Metal_Atomic 19:15:55 https://fedoraproject.org/wiki/Changes/tunir 19:16:22 https://fedoraproject.org/wiki/Changes/Local_Test_Cloud 19:16:26 that one's roshi's 19:16:36 jzb, Thanks :) 19:16:50 Moving on then, we can discuss more on these at the open floor. 19:16:58 Sounds good... 19:17:11 https://fedorahosted.org/cloud/report/9 current meeting tickets 19:17:27 #topic support HVM instances in EC2 (#68) 19:18:10 oddshocks, do you know if the site has the new AMI ID(s) ? 19:19:32 Can anyone else please confirm that on the ticket later on? 19:19:58 confirm that the site has the new AMIs? 19:20:07 kushal: I don't 19:20:17 dustymabe, yes 19:20:17 I sent out that email with the list, and said to contact me if I could do anything to get them on the site 19:20:20 oddshocks, Okay 19:20:29 AFAIK robyduck used to be the one to do that 19:20:32 prior to F21 at least 19:20:39 he's the one that asked me for them to put them on the official site 19:20:40 oddshocks: I think we need to open a ticket with the web team? 19:20:42 the site just has AMIs listed 19:20:48 doesn't specify PV vs HVM 19:20:50 If I get access to the site, I'm more than happy to be the one to update them from now on 19:20:56 yeah those are all PV for base and HVM for atomic I bet 19:21:23 #action oddshocks should get access to the website to update AMI ID(s) 19:21:31 oddshocks, ^^ is that okay? 19:21:33 IDK the workflow for updating the site, but I am totally happy to pick it up 19:21:36 kushal: yes :) 19:21:50 oddshocks, Thanks :) 19:21:51 it'd probably make things a lot smoother since I'm usually the first person to notice new fedimg AMIs 19:21:52 sure! 19:21:59 oddshocks, hehe. 19:22:02 oddshocks: I believe that you need to grab the site via git and send a patch 19:22:09 EZ PZ 19:22:15 oddshocks: not sure that they give access to update directly right away 19:22:25 that's fine, I can send patches no prob 19:22:34 I'd have someone review changes first anyway. don't wanna be breaking anything 19:22:42 oddshocks: https://git.fedorahosted.org/git/fedora-web.git 19:22:47 * oddshocks clones 19:22:48 oddshocks: I *believe* that's right 19:23:03 Moving to next ticket then. 19:23:12 #topic publicize fedora-dockerfiles #84 19:23:21 jzb: hopefully you're right! Once you clone something, you can't unclone. It's the topic of many sci-fi stories 19:24:15 Anyone any tips on #84? 19:24:51 I've made no progress since last week 19:25:04 Okay, moving on then. 19:25:17 #topic Update Timezone for the docker images #91 19:25:23 This one is stuck on me. 19:25:38 we tested the new patch which worked, I should be able to commit it this week. 19:26:02 #action kushal should commit the new patch for docker kickstart and update #91 19:26:41 #topic Getting sha256sum published for the cloud images #93 19:26:48 This is something new. 19:27:06 The proposal actually came from systemd upstream in a mail 19:27:39 I have talked with nirik on IRC, he has asked me to open a corresponding rel-eng ticket. 19:27:43 http://mirror.pnl.gov/fedora/linux/releases/21/Cloud/Images/x86_64/ 19:27:59 the sums are there they just aren't *easy* to find 19:28:08 from the download page 19:28:09 dustymabe, Yeah, we release the info in a different way. 19:28:13 kushal: note also there's an existing ticket about that same thing from the virt folks. There is apparently already a standard they use... 19:28:27 nirik, Okay. 19:28:28 Standards are nice :-) 19:28:52 nirik, I think we should ask systemd to follow that standard instead :) 19:29:14 * nirik nods. 19:29:36 nirik, can you please paste link to that other ticket here? I have misplaced the link as it seems. 19:29:53 I need to go find it... in a fesco meeting, will take me a few. 19:30:14 nirik, okay, thanks 19:30:29 Anyone wants to add something to this ticket? 19:31:10 Moving on then. 19:31:52 I am skipping the openshift commons ticket as it is stalled. 19:32:11 There are two more tickets on Dockerfiles 19:32:18 kushal: still in process 19:32:20 Fedora Magazine Post: How to Use Dockerfiles #87 19:32:29 kushal: I think we can remove the meeting tag from "social media" there 19:32:36 Social Media for Dockerfiles #88 19:32:38 jzb, Okay 19:33:07 jzb, done. 19:33:34 #topic Decide whether to update cloud image to not include ruby #09 19:33:37 #topic Decide whether to update cloud image to not include ruby #90 19:33:51 Ruby is not there anymore. 19:33:58 Can we just close this ticket? 19:34:06 works for me 19:34:08 kushal: +1 19:34:13 if it's done, just close it :) 19:34:15 kushal: have the new images been pulbished? 19:34:20 published? 19:34:31 dustymabe, Nope, need to discus that in open floor. 19:34:41 kushal: good :) I wanted to discuss that 19:35:39 Closed that ticket. 19:35:47 #topic Open floor 19:35:52 I have two 19:36:07 1. We will have to release updated cloud images. 19:36:16 * langdon back if you need me about vagrant 19:36:20 dustymabe, ^^ you wanted to say something? 19:36:33 langdon, you can update us with the status :) 19:36:53 kushal: yep I was just wondering when we were going to start doing that 19:37:01 langdon, can you please create a ticket to the fedora-cloud track? It will be easier to keep tab then :) 19:37:02 kushal, uh... i believe jzb wrote the change (or most of it).. not sure what is next.. 19:37:07 I'm working with Digital Ocean and want to make sure they keep up :) 19:37:28 jzb, you or me? 19:37:37 langdon: I can create the trac ticket 19:37:38 kushal, he or i will create the ticket 19:37:45 jzb, cool thanks 19:37:51 kushal: just FYI - I think the bits we need are ready 19:38:03 kushal: it's going to be a matter of imcleod syncing with rel-eng 19:38:13 to get everything working in Koji 19:38:14 kushal, the imagefactory parts are.. i think it is as you say jzb 19:38:44 kushal, "someone" should also decide if there should be anything in the image besides a clone of cloud & atomic 19:38:58 jzb, I thought we are missing the repo structure part. 19:39:11 my suggestion would be just to clone cloud's / atomic's and wait for the bug report 19:39:14 langdon, for 21, we had those two and docker. 19:39:27 langdon, +1 19:39:29 kushal, oh.. docker + cloud? 19:39:32 so do all 3? 19:39:36 docker? 19:39:48 docker image? in Vagrant? 19:39:49 langdon, docker filesystem anyway does not have much 19:39:50 * jzb is puzzled 19:39:57 jzb, image. 19:40:14 langdon, I would prefer to release updated cloud and atomic images. 19:40:14 * langdon opening download site :) 19:40:23 kushal, updated? 19:40:33 langdon, with latest packages. 19:40:37 i assume they should be at the same cadence as isos or qcows 19:40:42 I'm not sure we're all talking about the same thing atm. 19:40:47 like why do something special 19:41:13 * kushal is talking about releasing updated cloud and atomic images in Fedora 21 land 19:41:36 kushal: OK. I think Langdon and I were talking about Vagrant ;-) 19:41:48 jzb, :) 19:42:10 * dustymabe was on kushal's wavelength 19:42:24 yes, we should release updated images 19:42:24 kushal, so.. i don't see a "docker" image.. just cloud and atomic (which adverts docker) here: https://getfedora.org/en/cloud/download/ 19:42:27 well, wait 19:42:31 kushal, dustymabe im still confused :) 19:42:38 we are releasing updates to Atomic 19:42:47 * langdon recognizes this as a normal state 19:42:49 langdon, docker image comes from docker hub. 19:43:11 jzb: yeah we are.. but I think they are talking about releasing a new "starting" point for atomic 19:43:13 jzb, Okay 19:43:16 kushal, ohhh.. "docker base image".. not "docker on fedora on an iso" 19:43:20 on the same cadence as the fedora cloud image 19:43:24 langdon, Yeah :) 19:43:41 "starting point" == new atomic image with updates baked in 19:43:51 dustymabe, jzb or in case if you do not want that, we can note down that too. 19:44:21 kushal: if we want to release updated images, I don't mind, but I'm not sure it's necessary 19:44:27 kushal: we don't release updated ISOs for instance 19:44:43 so.. for vagrant, I wanted to release a vagrant box of fedora-cloud and fedora-atomic everytime a new iso/qcow is released.. with the same bits... 19:44:53 jzb, yeah, but for cloud we decided that we will be releasing updated images. 19:45:11 kushal: and, I could be wrong here, an Atomic update that brings you from F21 -> F21 current would be less bandwidth than stock F21 -> F21 Current 19:45:17 langdon, Okay, how to create a box? can we do that from a raw file or qcow2? 19:45:31 jzb: it was one of the features for F21 cloud product 19:45:31 jzb, Okay. 19:45:39 kushal, ks file -> imagefactory 19:45:44 releasing updated cloud images throughout the release 19:46:54 roshi: yeah, I know 19:47:20 I think the question comes down to "What are the benefits of releasing updated images?" 19:47:36 security fixes for one 19:47:37 then you ask yourself: "do those benefits apply to both the cloud image and atomic?" 19:47:41 dustymabe, I think that was discussed during F21 release :) 19:47:43 kushal, jzb rebasing atomic: personally, i think you have to rebase the cloud images (regular and atomic) because no one yum updates/ostree update on a cloud server .. i don't think atomic is any different (in practice) for running in the cloud.. if it is running on bare metal though.. that would be an argument not to rebase... 19:47:50 dustymabe, atomic, I am not sure. 19:48:32 cause, as a consumer, i know x.y.z-atomic is working on the other copy of my hardware.. and i want to add a new hardware.. 19:48:41 and i can upgrade with rollbacks 19:48:44 langdon: fair 19:49:54 langdon, Okay. 19:49:57 so.. my comment is.. sorta.. cloud-wg should only be doing cloud-atomic where it should be the same as cloud-normal... and server-wg should be doing server-atomic where the rebasing follows server ... just to make a mess :) 19:50:18 langdon: wat 19:50:54 langdon: I think that'd be more cat wrangling than is needed 19:50:55 like... fedora-cloud is not meant to be used on bare metal.. just "in the cloud"... the problem with fedora-atomic is it can/should be used either in the cloud or on bare metal 19:51:28 and the update process is probably different for cloud-instances vs bare metal instances 19:51:47 langdon: they both use the same tree upstream right? 19:51:48 langdon: the division is really "what's legacy server" and "what's cloud-model" 19:51:50 * langdon pretends vms are not important :) 19:51:50 or is that incorrect? 19:52:01 langdon: not so much "what runs in cloud" and "what runs on bare metal" 19:52:15 * jzb has flashbacks to a similar discussion mid-2014 19:52:35 dustymabe, correct.. just "in the cloud" you rebuild/reinstall.. you don't rpmostree update (or whatever it is) 19:52:38 * misc point people to the latest stuff in systemd to show that cloud image may soon become container ready 19:54:06 ok.. so in my opinion running atomic in the cloud (and yes I do run atomic in the cloud) you do run rpmostree upgrade 19:54:27 but when I choose to rebuild my "cattle" if I could start at a newer image I would certainly choose to do that 19:54:39 so there is less to update when I run rpmostree upgrade 19:55:25 does that make sense? 19:55:51 dustymabe: makes sense, but I agree with langdon that the use case should be just standing up a new image 19:55:52 dustymabe, it does to me.. but.. if your "rebuild stuff" was fully automated, why would you bother to do updates? 19:56:18 langdon: you have a good point 19:56:34 by "fully automated" i include bringing up new servers, shifting traffic, killing old 19:56:36 but on the third hand 19:56:52 are we going to respin images every time there's an update or just monthly 19:56:55 ? 19:57:07 jzb: I would do it on the same cadence as the cloud image 19:57:13 too much overhead otherwise 19:57:14 the plan was monthly, I thought 19:57:26 monthly + security, correct? 19:57:28 roshi, that is what I understood. 19:57:32 jzb: correct 19:57:38 e.g. if a shellshocked comes in the day after a respin. 19:57:42 hopefully we don't have too many heartbleeds or shellshocks 19:57:44 propose a compromise? the main big button is always the rebased.. but there is a "history" link that gives you every one back to last major release.. or something like thta 19:58:04 langdon: not sure we need the old images, do we/ 19:58:05 er? 19:58:18 jzb, i think you do for the "pet" case 19:58:22 jzb, we do actually. 19:58:39 langdon: Do we really need the history of *every* previous image? 19:59:05 jsmith, maybe not.. maybe it is just current and original? 19:59:14 you can always upgrade to a point in between 19:59:35 langdon, jsmith we have to get an idea from the fedora-legal too. 19:59:55 jsmith: langdon when you say image? is there any chance you are referring to the upstream ostree? or are you actually talking about the qcow or raw.xz? 20:00:22 dustymabe, i mean the "qcow" (insert image format here) 20:00:34 but you also need the ostree somewhere too 20:00:50 hmm. I wonder if we're saving the ostree trees 20:01:17 jzb: not sure but we probably should be 20:01:20 * langdon wonders if those are sustainably farmed ostrees... 20:01:52 I think if we ever get to the point where ostree is as easy to use and manipulate as git.. that history would be useful 20:02:13 langdon: nice 20:02:24 * langdon bows 20:02:25 langdon: they are definitely cage-free 20:02:32 dustymabe, lol 20:02:56 ok so where do we stand? on the updates issue? 20:03:15 same cadence as cloud image? once a month + updates? 20:03:27 s/updates/security updates/ 20:04:21 For the cloud image: once a month + security fixes. 20:04:22 I think that sounds reasonable 20:04:31 What about the atomic then? 20:05:34 ^^ same cadence as cloud image 20:05:44 I was referring to atomic 20:05:45 I don't know enough about atomic to weigh in on this one 20:05:46 Okay. 20:06:10 dustymabe, can you please open a ticket for the next update release and note down this there? 20:06:17 * jzb is pulled into another meeting 20:06:18 kushal: yep 20:06:25 dustymabe, Thank you. 20:06:30 we also need to talk about at what point those image updates stop 20:06:40 but we can save that 20:06:43 for another day 20:06:46 I guess we can close this meeting now 20:06:55 It is 1:36am here. 20:07:00 kushal +1 20:07:10 +1 from me 20:07:35 I'm happy to help coodinate with the Fedora Security Team to decide when security updates warrant a rebuild 20:07:47 * gholms also gets dragged off 20:07:58 jsmith, +1 :) 20:08:03 sgtm jsmith 20:08:10 Closing the meeting now. 20:08:15 #endmeeting