19:01:35 <kushal> #startmeeting Fedora Cloud SIG
19:01:35 <zodbot> Meeting started Wed Mar 18 19:01:35 2015 UTC.  The chair is kushal. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:35 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:01:38 <rtnpro> yeah
19:01:45 <kushal> #topic rollcall
19:01:52 <kushal> .hellomynameis kushal
19:01:53 <zodbot> kushal: kushal 'Kushal Das' <kushaldas@gmail.com>
19:01:53 <rtnpro> .fas rtnpro
19:01:57 <zodbot> rtnpro: rtnpro 'Ratnadeep Debnath' <rtnpro@gmail.com>
19:01:57 <jzb> .hellomyname is jzb
19:02:03 <dustymabe> .hellomynameis dustymabe
19:02:03 <oddshocks> .hello oddshocks
19:02:04 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
19:02:08 <zodbot> oddshocks: oddshocks 'David Gay' <dgay@redhat.com>
19:02:08 <oddshocks> aw
19:02:12 <oddshocks> aw nice!
19:02:14 <jzb> d'oh
19:02:18 <jzb> .hellomynameis jzb
19:02:19 <zodbot> jzb: jzb 'Joe Brockmeier' <jzb@redhat.com>
19:03:27 <kushal> roshi, jsmith ?
19:04:02 * jsmith stumbles back to the computer, late as usual :-(
19:04:35 <kushal> Okay, I think we can move forward.
19:04:47 <kushal> #topic Action items from previous meeting
19:04:56 <kushal> * jzb get with base working group on docker image.
19:06:01 <kushal> I think this is same of #97
19:06:22 <kushal> #topic Maintaining Fedora docker images for f22 #97
19:06:27 <jzb> yeah
19:06:31 <jzb> OK - so minor progress
19:06:47 <jzb> I haven't gotten with the working group yet, I need to send a note to devel-
19:07:02 <jzb> which is sub-optimal, I didn't realize "base" didn't have a specific mailing list.
19:07:16 <kushal> jzb, so this is about testing the docker images from koji, correct?
19:07:31 <jzb> kushal: partially
19:07:34 <jzb> we have two or three issues:
19:07:39 <jzb> 1) defining the images
19:07:45 <jzb> 2) testing / keeping track of images
19:07:54 <jzb> 3) ensuring we promote the images
19:08:07 <jzb> I think the problems identified in the last batch (alpha) were fixed in the TC2 beta
19:08:22 <jzb> e.g. - no longer pulling in the wrong packages (server definition)
19:08:35 <jzb> but I need to sync with the appropriate folks on 2/3
19:08:43 <kushal> Okay.
19:08:55 <jzb> I will do that by next week unless someone else is burning to run with that.
19:09:21 <kushal> jzb, I guess I have some good news on the testing side of the images, I will talk more in the open floor.
19:09:31 <jzb> kushal: rock :-)
19:09:41 <jzb> EOF for me on this one, though
19:09:46 <kushal> Okay :)
19:09:51 <jzb> oh - other folks who want to test TC2 are welcome to do so
19:09:52 <dgilmore> jzb: I fixed up the kickstart
19:10:04 <jzb> I did fire it up and it does work more or less as expected.
19:10:05 <dgilmore> jzb: and I got koji patched today to name the images right
19:10:21 <kushal> dgilmore, thanks :)
19:10:22 <jzb> dgilmore: I initially read that as "got koji punched today"
19:10:28 <jzb> dgilmore: whatever you have to do...
19:10:33 <dgilmore> jzb: and I know at least 3 people have downloaded the arm docker base image
19:10:44 <dgilmore> jzb: :P
19:10:48 <dgilmore> no punching of koji
19:11:02 <jsmith> dgilmore: Can I tickle it instead?
19:11:06 * jsmith ducks and hides
19:11:28 <jzb> dgilmore: thanks
19:12:07 <dgilmore> jzb: we do need to come up with better processes for uploading the images to the docker registry
19:12:16 <dgilmore> upstream though is largely broken
19:12:48 <jzb> dgilmore: understood. Is that something Adam would be saddled with, I mean, responsible for?
19:13:00 <dgilmore> jzb: I do not think so
19:13:12 <jzb> dgilmore: who currently has the honor?
19:13:24 <dgilmore> jzb: lms5 manually does it
19:13:26 <kushal> jzb, I think lsm5
19:13:29 <jzb> OK
19:13:33 <dgilmore> because thats how upstream docker works
19:13:44 <dgilmore> lsm5 ;)
19:13:58 <jzb> Not sure if we can fix upstream...
19:13:59 <kushal> mattdm, welcome :)
19:14:03 <kushal> jzb, nope :)
19:14:05 * mattdm is here -- sorry clock goes so fast :)
19:14:13 <dgilmore> jzb: not sure we can
19:14:26 * dgilmore needs to run and pick up daughter from school
19:14:46 <kushal> Moving to the next ticket then.
19:14:53 <kushal> #topic Care and Feeding, Fedora Dockerfiles #84
19:15:03 <kushal> jzb, any update on this ^^?
19:16:01 <jzb> un momento
19:16:07 <scollier> kushal, dumb question, how do we link directly to that ticket?
19:16:32 <jzb> https://fedorahosted.org/cloud/ticket/84
19:16:32 <kushal> scollier, https://fedorahosted.org/cloud/ticket/84
19:16:43 <jzb> kushal: it might be useful to send the URL with the topic
19:16:46 <scollier> thanks.  i thought we could call it with the bot
19:16:58 <jzb> kushal: some progress, but no final results.
19:17:02 <kushal> jzb, yeah, will do that from now on.
19:17:05 <kushal> jzb, Okay.
19:17:14 <jzb> kushal: longer version - have started the discussion about dnf
19:17:25 <jzb> and looking for help in fixing yum -> dnf
19:17:33 <jzb> I believe scollier is still looking for someone to maintain the repo
19:17:39 <scollier> jzb, it's on my radar to help with that, yes.
19:17:40 <kushal> jzb, yup, even our cloudtoserver needs work on the same.
19:18:15 <jzb> scollier: I'm optimistically planning to do some work on that this weekend.
19:18:28 <jzb> now that we have an f22 docker image without the wrong package set :-)
19:18:58 <jzb> but we don't have a victim, er volunteer, to step up entirely.
19:19:05 <jzb> EOF
19:19:28 <scollier> i have maybe 5 things to do on fedora-dockerfiles
19:19:46 <kushal> jzb, add an action item for searching victim for dockerfiles :)
19:20:28 <scollier> 1. dnf 2. clean up READMEs for libvirt 3. atomic tool inclusion 4. CI 5. K8s integration.
19:21:27 <jzb> scollier: can you expand on #3, pls?
19:21:33 <jzb> scollier: I think I know what you mean, but I want to make sure.
19:22:39 <scollier> jzb, sure.  the LABELs patch was merged, which means we can work with the "atomic" tool now.
19:22:53 <scollier> jzb, which can abstract away some of the more complicated commands.
19:22:56 <scollier> to run containers.
19:22:58 <jzb> scollier: to include additional instructions
19:23:02 <scollier> install things into containers.
19:23:06 <jzb> not supported by Docker, necessarily?
19:23:07 <scollier> stop, uninstall containers.
19:23:41 <jzb> cool
19:23:48 <scollier> jzb, supported by docker & atomic
19:25:06 <kushal> scollier, jzb  can you please paste some more links here about the same which we can read later and learn more about the same?
19:25:14 <jzb> #action jzb help find scollier additional maintainer for dockerfiles
19:25:16 <scollier> kushal, sure, will do in a few min.
19:25:38 <jzb> #action jzb (and others) update dockerfiles for dnf
19:25:46 <jzb> who will take #2?
19:25:56 <jzb> (clean up readmes for libvirt)?
19:26:31 <kushal> jzb, which README(s) are these?
19:26:58 <scollier> kushal, no readmes here: https://github.com/fedora-cloud/Fedora-Dockerfiles/tree/master/libvirt
19:26:59 <jzb> kushal: scollier said 5 things to do
19:28:11 <kushal> jzb, scollier Okay, thanks.
19:29:03 <jzb> no volunteers?
19:29:20 <dustymabe> jzb I would but I'm swamped right now with school and work
19:29:36 <dustymabe> I just don't want to commit and not follow through
19:29:44 <jzb> understood
19:30:38 <kushal> Moving  on then.
19:30:56 <kushal> #topic Getting sha256sum published for the cloud images https://fedorahosted.org/cloud/ticket/93
19:31:15 <kushal> Last week I had a chance to meet lennart in fossasia.org
19:31:45 <kushal> Had a long discussion over this.
19:31:51 <kushal> 2 points from it:
19:32:17 <kushal> 1. We want a standardized filename for the same information, like SHA256SUM
19:33:27 <kushal> 2. The way systemd folks wants shasum and signature in two different files, can not be done in near future, but we should look into this during F23 or F24
19:33:48 <dgilmore> http://dl.fedoraproject.org/pub/alt/stage/22_Beta_TC2/Cloud-Images/x86_64/Images/Fedora-Cloud-Images-x86_64-22_Beta_TC2-CHECKSUM
19:33:52 <kushal> He is really against the idea of having two different parser in the codebase.
19:33:59 <dgilmore> we already have the sha256sums published
19:34:28 <kushal> dgilmore, Yes, just a standard name would help to find it easily, like SHA256SUM
19:34:40 <dustymabe> kushal: for #1 I have proposed in the ticket that we can keep the same name of the checksum file we already have and also have a symlink named SHA256SUM
19:34:42 <dgilmore> kushal: it is a standard name
19:34:52 <dustymabe> I think #1 can be solved with that
19:35:06 <dgilmore> kushal: we produce many different CHECKSUM files as part of a compose
19:35:07 <jzb> dgilmore: a name that never changes
19:35:17 <dgilmore> jzb: not going to happen
19:35:24 <kushal> dustymabe, yup, that can be a way, but we have to test it :)
19:35:32 <dustymabe> dgilmore: what about my proposal?
19:35:50 <kushal> dgilmore, reasons? Other than fixing many tools/scripts.
19:35:51 <dgilmore> dustymabe: its not okay
19:36:08 <dgilmore> kushal: people like to rsync all the images into a single location for one
19:36:41 <dustymabe> dgilmore: can you state what is wrong with the symlink solution?
19:36:44 <kushal> dgilmore, but we don't release them from a central place, and we can at least provide a standard way to search for the information.
19:37:51 <dgilmore> http://paste.fedoraproject.org/199747/26707461/
19:38:01 <dgilmore> that is all teh CHECKSUMS we create in a single compose
19:38:22 <dgilmore> dustymabe: 1 is that some mirrors do not have follow symlinks
19:38:35 <dgilmore> dustymabe: that it is inconsistent with everything we do
19:38:53 <kushal> dgilmore, all those checksum files are in different directories.
19:39:37 <dgilmore> kushal: yes, but people do things like rsync all the iso/images's and CHECKSUMS into one place to do different things
19:40:04 <kushal> dgilmore, we can keep both style names (files), that way we will still have the old style files intact when people rsync all in one place.
19:40:18 <dgilmore> it will cause confusion
19:40:36 <dgilmore> kushal: I am curious why there is a desire to change?
19:40:46 <dgilmore> what is the use case and the problem trying to be solved?
19:41:15 <dustymabe> https://fedorahosted.org/cloud/ticket/93
19:41:41 <dustymabe> I think the systemd folks are trying to "discover" images easier
19:41:44 <dgilmore> dustymabe: that does not really tell much of a story
19:41:52 <dgilmore> other than ubuntu does it and we should too
19:42:07 <dustymabe> as part of that they want to be able to find the checksum in a predictable way
19:42:22 <kushal> dgilmore, it says that finding the checksum file is difficult as the filename changes regularly.
19:42:24 <dgilmore> dustymabe: it is predictable
19:42:51 <dustymabe> dgilmore: yes predictable for Fedora
19:43:07 <dgilmore> I really do not see any good justification for something that breaks many use cases in use today
19:43:09 <dustymabe> but maybe not consistent with XYZ distro
19:43:41 <dgilmore> we can not use symlinks
19:43:43 <dustymabe> I'm not saying it is right that they want this change, I do understand where they are coming from though
19:44:06 <dgilmore> we can not be sure that mirrors will have follow symlinks turned on
19:44:10 <jzb> what's not entirely clear in this ticket
19:44:19 <dgilmore> and we have no control over the mirrors configs
19:44:40 <jzb> is what happens if systemd can find the images using nspawn
19:44:48 <dgilmore> jzb: what is not clear is a definite use case, and the benefit of making a disruptive change
19:45:10 <mattdm> dgilmore, what about adding a _copy_ of the file rather than a symlink?
19:45:33 <dgilmore> mattdm: I really think changing it at all will cause issues
19:45:56 <dgilmore> I would want a very specific known use case.
19:46:13 <mattdm> systemd nspawn is the specific use case
19:46:27 <dgilmore> I do not see one in the ticket. perhaps knowing how systemd-nspawn uses it would help
19:46:38 <dgilmore> mattdm: there is nothing stating how it works
19:46:43 <dgilmore> and why the change is needed
19:47:17 <jzb> mattdm: do I understand correctly this would give some sort of Docker search like capability to launch Fedora images using nspawn?
19:47:41 <dgilmore> mattdm: what exactly is the problem being solved?
19:47:58 <kushal> jzb, yes
19:48:01 * jzb needs to read up on nspawn
19:48:12 <kushal> jzb, and they want to verify the downloaded images.
19:48:13 <mattdm> I beleive lennart wants to use the files both an index to files in that directory and a checksum, both at once
19:48:19 <dgilmore> mattdm: how does systemd know where to go get an image? as I see it you have to feed it a url with the image. getting the matching checksum can be fed in also
19:48:20 <mattdm> kushal, is that correct?
19:48:40 <dgilmore> mattdm: there is way too much vague handwaviness here
19:49:05 <dgilmore> lets get some concrete things in place, exact use cases,
19:49:17 <kushal> mattdm, I am not sure about the part where nspawn gets the URL, I am yet to try it.l
19:49:27 <kushal> rtnpro, you have used it, any comments ^^ ?
19:51:11 <kushal> mattdm, dgilmore we can ask Lennart for more specific use cases with details on these open questions.
19:51:18 <kushal> I guess rtnpro slept.
19:51:20 <dustymabe> kushal: +1
19:51:20 <rtnpro> kushal, no :(
19:51:33 <jzb> who's going to take the action there?
19:51:37 <kushal> me
19:51:41 <jzb> we should probably write up a feature change for f23
19:51:51 <jzb> it's unlikely to happen by f22 at this point
19:52:00 <dgilmore> jzb: it is way too late for f23
19:52:03 <dgilmore> f22
19:52:15 <dgilmore> so yes a f23 change should be what is being worked towards
19:52:21 <jzb> dgilmore: I think we can squeak it in to f23 ;-)
19:52:30 <dgilmore> silly typos
19:52:34 <kushal> #action kushal wil ask Lennart for more specific use case and details  for #93
19:52:43 <dustymabe> kushal: I guess its not worth talking about #2 yet until we get some more info
19:52:54 <oddshocks> +1 for F23
19:52:58 <kushal> Btw, Lennart does not expect this to be in before F23 anyway.
19:53:35 <dgilmore> kushal: jzb: mattdm: etc. we could make a redirect for the CHECKSUM like we do for the cloud images themselves
19:53:44 <dgilmore> and that may suit the needs
19:53:56 <jzb> dgilmore: oh, you mean some sort of Apache redirect?
19:54:53 <dgilmore> jzb: like we do for the cloud images
19:55:15 <kushal> I guess we can continue this discussion over the list as we don't have much time left.
19:55:25 <dgilmore> http://cloud.fedoraproject.org/fedora-19.x86_64.qcow2
19:55:34 <dgilmore> http://cloud.fedoraproject.org/fedora-21.x86_64.qcow2
19:56:00 <dgilmore> which redirects to the right image
19:56:28 <dgilmore> but you would need a path in there
19:56:48 <dgilmore> http://cloud.fedoraproject.org/fedora/21/x86_64/SHA256SUM
19:56:52 <jzb> kushal: +1
19:57:03 <jzb> dgilmore: thx
19:57:08 <mattdm> I suggested awhile ago that we publish soemthing like https://cloud-images.ubuntu.com/releases/streams/v1/com.ubuntu.cloud:released:download.json
19:57:21 <mattdm> a "simplestreams" format json index to the images
19:57:30 * oddshocks remembers that
19:57:34 <mattdm> that might fill systemd's needs tooo
19:57:42 <kushal> mattdm, +1
19:58:10 <kushal> Moving to next ticket for now.
19:58:26 <kushal> #topic Atomic as separate spin (or, going the other way, main cloud edition)? https://fedorahosted.org/cloud/ticket/96
19:58:55 <dustymabe> mattdm: might be worth adding that link to the ticket.. good info
19:59:22 <mattdm> dustymabe good idea
19:59:23 * jsmith has to run to another meeting
19:59:38 <dgilmore> mattdm: seems useful
19:59:53 <kushal> mattdm, any points you want to say for #96?
20:00:06 <oddshocks> Unless something has changed on #96 since our last meeting, I'm still for C for F22, and A for F23
20:01:11 <dustymabe> I think we are still of the same opinion
20:01:20 <kushal> oddshocks, +1 for me too
20:01:31 <jzb> any votes against C for F22 and A for F23?
20:02:03 <dgilmore> A will mean that atomic is less visable
20:02:19 * mattdm still odesn't remember what letters he gave to which idea
20:02:29 <kushal> mattdm, :)
20:02:33 <dgilmore> mattdm: A is as a spin
20:02:37 <jzb> mattdm: that's a little humorous. :-)
20:02:40 <dgilmore> i.e. much less visable
20:02:40 <jzb> dgilmore: yes
20:02:46 <oddshocks> Hm. I think the spins page is quite popular, actually. I don't have the metrics, but I'd bet that people would notice an Atomic spin pretty quickly.
20:03:06 <jzb> though I am wondering
20:03:09 * dgilmore has no strong opinion
20:03:17 <oddshocks> Especially if we published an article in Magazine, etc.
20:03:23 <jzb> how much traffic to Atomic comes from "Get Fedora Cloud -> Atomic"
20:03:28 <kushal> Note: we are over our 1 hour meeting time.
20:03:33 <jzb> vs. "Project Atomic - Get Fedora Cloud -> Atomic"
20:03:33 <dgilmore> as a spin it will not be talked about in Media, it will not be on any of the main pages
20:03:41 <dgilmore> you have to know it exists and dig to get it
20:03:56 <oddshocks> The key factor, I think, is that we confirm that there is enough interest in participating in the spin's development. Enough people for a meeting, or whatever activities the different spin folks do to stay in touch
20:04:21 <jzb> here's a thought
20:04:30 <mattdm> media _do_ talk about our popular existing spins, fwiw
20:04:39 <mattdm> definitely not as much as the main offerings, though
20:04:40 <oddshocks> I mean, you have to know about the KDE or XFCE spins to get them, too, and plenty of folks use them
20:04:42 <jzb> how about I run with mattdm's idea and create a proposal page on the wiki
20:04:54 <jzb> and we can "officially" vote on the mailing list?
20:04:59 * oddshocks is always for a vote
20:05:07 <jzb> note that this would be a vote of the working group members
20:05:09 <dustymabe> jzb: +1
20:05:13 <jzb> though other opinions are welcome.
20:05:16 <kushal> I would love to see those numbers on how people find atomic images.
20:06:05 <oddshocks> jzb: +1 on getting that traffic data, too
20:06:26 <jzb> OK, silence == assent
20:06:44 <jzb> #action create proposal page on wiki for Atomic spin for f23 forward, call for vote on mailing list.
20:06:50 <jzb> er
20:07:04 <jzb> #action jzb create proposal page on wiki for Atomic spin for f23 forward, call for vote on mailing list.
20:07:11 <jzb> EFO
20:07:13 <jzb> er, EOF
20:07:17 <kushal> :)
20:07:27 <kushal> #topic Producing Updated Cloud/Atomic Images https://fedorahosted.org/cloud/ticket/94
20:07:30 <kushal> oddshocks, ^^
20:08:46 <oddshocks> I haven't heard anything on that,
20:08:49 <oddshocks> dgilmore: ? ^
20:10:29 <dgilmore> oddshocks: I am waiting on confirmation of testing to push it live
20:10:41 <dgilmore> or there to be bugs that need a respin
20:10:45 <oddshocks> Alright, then that's the status :)
20:11:09 <dgilmore> http://dl.fedoraproject.org/pub/alt/stage/21-20150309/ has the last updates compose
20:11:16 <oddshocks> dgilmore: do you need testers? we could note that in the meeting notes
20:11:37 <dgilmore> oddshocks: I do not need testers. but the cloud WG does
20:11:59 <dgilmore> and the Cloud WG needs to report back and say that its tested and okay to make live
20:12:28 <dgilmore> oddshocks: it is in the CloudWG's hands at this point in time
20:12:29 <kushal> dgilmore, I will do the tests and get back to you.
20:12:58 <kushal> I have tunir ready to run all of our cloud tests for the same.
20:13:30 <kushal> I was thinking about talking about it in the open floor, but anyway we are over time.
20:13:31 <oddshocks> \o/
20:13:40 <kushal> I will drop a mail to the list and blog on the same tomorrow
20:14:00 * oddshocks also has an open floor point, but will just email the list
20:14:25 <kushal> If there is nothing else, we can close the meeting today.
20:14:44 <dustymabe> +1
20:14:49 * oddshocks crickets
20:15:00 <kushal> 3
20:15:01 <kushal> 2
20:15:08 <kushal> 1
20:15:13 <kushal> #endmeeting