- George Dunlap
- Lokesh Mandvekar (Docker)
- Lars Kurth
- Pasi Karkkainen
Updates & Blockers
- Docker 1.3.0 going in today to centos7 - more correctly virt7-testing once built
Still awaiting response from Fedora whether golang crypto rhbz (see https://bugzilla.redhat.com/show_bug.cgi?id=1148704) implementation for kubernetes can go into fedora (which is a stepping stone to CentOS)
- Roadmap to GA for Docker:
- What needs to happen before we can say "OK, everyone, Docker for C7 is ready for you to use for real."
- Have you had a lot of people testing the packages you've put into virt7-testing? Haven't received many pings about it other than Evolution and kbsingh
- Alphacc: let's chat with kbsingh and Evolution for additional repos first if docker will be standalone (virt7-docker-*) ... some of this happened on the IRC chat
- ACTION Lokesh: Ping list re testing once 1.3.0 is available (maybe 2-4 weeks. Once we have a number of people testing it and no issues, then we should be ready to go live. )
- Where do we put this "public beta" -- just on CBS (which wasn't designed for a large number of people to connect to it), or somewhere else?
- KB confirmed cbs.centos.org/repos/ is OK - if there is an issue with infrastructure load revisit
- Evolution: I would like to see test repos signed with a testing key. I'm not generally a fan of unsigned packages.
- ACTION George: take this topic to the list under "path to GA" for Docker
2. Xen Project
- I made quite a bit of progress last week; I updated my "git am" thing to the 4.2.5 release, and then pulled forward to 4.4.1.
- alphacc *just* sent me a link to a successful build from the virt6 branch of the git repo, so hopefully that should be working now.
- I think to update to 4.4.1 I'll also need to re-compile libvirt, right?
- NOTE: we have not decided on a version of libvirt to use
there's a number of bugfixes/backports included in the libvirt bits which are included with c6/xen-4.2 - see https://nazar.karan.org/summary/xen!kernel.git
The main reason for having that for VHD image & qcow/qcow2 support
- pasik: qemu obviously does qcow*, and with xen 4.4 it should work. vhd isn't good in qemu afaik.
- George: Sure, I mean going forward. If we have specific criteria for keeping or removing, then we'll know if/when we can remove it.
- KB: if we drop it, change something - we'll need to make sure that existing installs dot get hurt in updates
- George: might have to try to prod some users to test stuff and tell us if it breaks.
- Pasik: for the time being i'd say pulling the xenserver blktap2.5 fork would be least bad thing to do - least surprise for users, because we've been shipping it so far
Agreements: Yes, 4.2 we have to leave it as it is. I think 4.4. I'll play around with updating to the most recent XenServer version.
<lars_kurth> Hi everyone [14:01] <lars_kurth> Who is here for the VIRT SIG meeting? * lsm5 * gwd <gwd> kbsingh said he was here too. <pasik> hello [14:02] <lars_kurth> Hi. Any agenda items? Note that I have to leave in 45 mins sharp <gwd> Well there's status and blockers for x4c [14:03] <gwd> And blktap2.5. <gwd> Status / blockers for docker? <lars_kurth> OK. Also can I ask gwd to send me the log afterwards * gwd nods <lsm5> gwd: for docker...1.3.0 going in today to centos7 [14:04] <gwd> I'd like to ask kbsingh about the decision to include blktap "2.5" <pasik> gwd: i think it was included because someone from citrix said it's better option than the stock blktap2 <pasik> gwd: and it's mostly for backwards compatibility; lots of centos5 xen users have file images, so using tap:aio: and/or qcow etc [14:05] <pasik> gwd: and i think libvirt also defaults to tap:aio: for file images <gwd> pasik: That's definitely true, but the question is, why do we want it at all? Could qemu take its place? *** imcleod (~email@example.com) has joined channel #centos-devel [14:06] <gwd> well anyway, let's start with first things first... <pasik> gwd: i don't think qemu/qdics in xen 4.2 was suitable.. <lars_kurth> can we do things in order? <gwd> lars_kurtH: Shall we start with docker update / blockers? <pasik> yep <lars_kurth> lsm5: you mentioned crypto was a problem package for docker <lars_kurth> at the last meeting [14:07] <lars_kurth> Agreed <lsm5> lars_kurth: not docker itself, but kubernetes <lsm5> lars_kurth: still awaiting reply from fedora if it's ok <gwd> lsm5: You mean 1.3.0 is going into virt7-testing, or the core virt7 repo (i.e., ready for general consumption)? <lsm5> gwd: i'll put into virt7-testing once built (should be in an hour) [14:08] <lars_kurth> lsm5: understood - here is what I think you said 'Still awaiting response from Fedora whether crypto implementation for kubernetes can go into fedora (which is a stepping stone to CentOS)' [14:09] <lsm5> gwd: unless you want me directly putting it into virt7 <lsm5> lars_kurth: yup <gwd> No, I was just asking. :-) <lsm5> let me put the rhbz for crypto here.. <gwd> So what's the roadmap to "GA" for Docker-for-C7? <gwd> I.e., what needs to happen before we can say, "OK, everyone, Docker for C7 is ready for you to use for real." [14:10] <lsm5> gwd: perhaps a kbsingh or Evolution question .. * lsm5 isn't certain :\ [14:11] <gwd> Have you had a lot of people testing the packages you've put into virt7-testing? <lsm5> gwd: haven't received many pings about it other than Evolution and kbsingh [14:12] <lars_kurth> I didn't follow the list lately: did we ask for people to test on the list ? That would be the first thing to do as a next step [14:13] <lsm5> golang crypto rhbz: https://bugzilla.redhat.com/show_bug.cgi?id=1148704 <gwd> Well I guess the first thing is: as far as you know, is what you're going to check in this afternoon something that is fully functional (at least at a basic level)? <lsm5> ahh ok <lsm5> will ping the list with 1.3.0 update <gwd> Or are there big pieces you think are missing? *** talori (~firstname.lastname@example.org) has joined channel #centos-devel *** bexelbie (bexelbie@fedora/bexelbie) has quit: Remote host closed the connection *** kushal (~kdas@fedora/kushal) has quit: Remote host closed the connection [14:14] <alphacc> lsm5: let's chat with kbsingh and Evolution for additional repos first if docker will be standalone (virt7-docker-*) <gwd> Once you think it's probably ready, we should try to get it tested for maybe 2-4 weeks. Once we have a number of people testing it and no issues, then we should be ready to go live. <lsm5> gwd: alphacc ack [14:15] <lsm5> gwd: big pieces missing ..probably not <gwd> Now, the next question is: Where do we put this "public beta" -- just on CBS (which wasn't designed for a large number of people to connect to it), or somewhere else? *** bexelbie (bexelbie@fedora/bexelbie) has joined channel #centos-devel <lars_kurth> gwd: who needs to make that call? Is this something for centos-devel? [14:17] <gwd> I guess that's probably the best place to discuss it. <lars_kurth> Who wants to pick that up and post to centos-devel [14:18] <lsm5> just checked with main kubernetes maintainer for fedora, we can get kubernetes going without golang crypto ... so i'll have that done later today .. <kbsingh> i thikn there is a conversation running there already, lets just close that off. <kbsingh> ( w.r.t repo ) <gwd> So who wants to write the e-mail? I have some ideas, so I'm happy to do it; but if lsm5 or lars_kurth want to I can yield to them. <lars_kurth> kbsingh: you mean "virt7-docker-*" repo or where do we put the beta? [14:19] <kbsingh> yeah, there is a conversation Evolution started about the whole upstreams thing. [14:20] <kbsingh> i dont think that closed off - but its going to be fairly central to what we do with the docker bits as well *** kushal (~kdas@fedora/kushal) has joined channel #centos-devel <kbsingh> the main things there that need attention are : what is and isnt considered an upstreams component, and then how do these things map to tag's in koji <gwd> "upstreams" was meant to be bleeding-edge stuff, right? <Evolution> right. I think we discussed a slightly different name though. [14:21] <Evolution> gwd: possibly not bleeding, but certainly freshly shaven. <gwd> :-) <kbsingh> gwd: yeah, also stuff with no real maintenance or centos specific support. eg. libvirt or qemu or docker - that just gets built when there is an upstream release <gwd> Well we don't need that 100% sorted out to start testing, right? [14:22] <gwd> We just need a reasonable place to point people for a public beta. [14:23] <lars_kurth> OK: am conscious of time - what's the concrete thing that needs to be resolved? <lars_kurth> gwd: agreed <kbsingh> gwd: yeah <gwd> Let me write an e-mail to the list about a "path to GA" for Docker, and we can talk about it there. <kbsingh> would that / could that. not just be the cbs.centos.org/repos/ ? [14:24] <gwd> It could as far as I'm concerned -- but there was some concerns about the workload. <kbsingh> lets thrash it out on the list <lars_kurth> kbsingh: if you say that's OK, there is no problem [14:25] <gwd> I mean, the load on the server. I guess we could start there and then move it off if it becomes a problem. <pasik> makes sense <pasik> better get started with something quick/easy <Evolution> I would like to see test repos signed with a testing key. I'm not generally a fan of unsigned packages. [14:26] <gwd> +1 <Evolution> for building, fine whatever. if we expect users to touch it, then it should be signed <gwd> OK, shall we take this to the list and move on? <Evolution> please. *** richardm75 (~email@example.com) has joined channel #centos-devel [14:27] *** dougsland (~dougsland@tchelinux/moderator/dougsland) is now known as dougsland_afk <lars_kurth> Anything else related to docker? <gwd> So re Xen: I made quite a bit of progress last week; I updated my "git am" thing to the 4.2.5 release, and then pulled forward to 4.4.1. <lsm5> lars_kurth: nothing else docker related for now [14:28] <lars_kurth> Evolution, Alphacc - not sure I have your names for the wiki notes *** darbinda (~firstname.lastname@example.org) has joined channel #centos-devel <gwd> alphacc *just* sent me a link to a successful build from the virt6 branch of the git repo, so hopefully that should be working now. <lars_kurth> lsm5: thanks <Evolution> lars_kurth: I'm JimPerrin on the wiki <pasik> gwd: good news! [14:29] <gwd> I think to update to 4.4.1 I'll also need to re-compile libvirt, right? <kbsingh> woo! <gwd> So I'll need libvirt in git.c.o. <gwd> Once we push 4.4.1 for C6, then I can start work on porting it to C7. [14:31] <pasik> did we already decide which libvirt version to use for virt6/xen-4.4.1 ? <lars_kurth> gwd: who knows re libvirt compatibility (Jim?) <Evolution> lars_kurth: I'm probably stomping on your toes a bit for docker, as I have plans for it... So I've been poking lsm5 for bits and pieces. <lars_kurth> pasik: I dont think so <lars_kurth> Evolution: that's OK - I am just facilitating (-: <gwd> Evolution: I think lars_kurth and I are just facilitating -- [14:32] <lars_kurth> OK, back to libvirt version (and I need to drop off at 14:50) <gwd> pasik: Hmm, yes, so that's something to look at <pasik> iirc there's a number of bugfixes/backports included in the libvirt bits which are included with c6/xen-4.2 [14:33] <gwd> And then updating to C7 -- I'll need to build the kernel; do we have a public git repo for that? Or should I just start one with the srpm? <gwd> Also, lights are flickering here, wouldn't be surprised if we got cut off by the storm... [14:34] <pasik> there is a git repo for the c6-xen kernel.. <gwd> pasik: Where is that? <pasik> gwd: let me see if i can find the url.. <kbsingh> most of the libvirt stuff was xl related wasent it ? [14:35] <kbsingh> this should all be in the mainline libvirt now <pasik> gwd: https://nazar.karan.org/summary/xen!kernel.git <pasik> kbsingh: yes, most of it was libxl related, and it didn't end up properly working after all.. *** Rastlinux (~Rastlinux@curly.txu.com) has joined channel #centos-devel [14:36] <gwd> OK, so the final thing I wanted was to talk about blktap2.5. <gwd> So was the main reason for having that for VHD image support? <pasik> gwd: vhd, yes <pasik> gwd: and also qcow/qcow2 <gwd> Hypothetically, if qemu had adequate vhd support, could we just drop blktap altogether? <pasik> gwd: like said i don't think qemu/qdisc backend worked properly with xen-4.2 .. [14:37] <gwd> pasik: Doesn't qemu do qcow/qcow2? <kbsingh> gwd: vhd file support is where it started from <pasik> gwd: qemu obviously does qcow*, and with xen 4.4 it should work. vhd isn't good in qemu afaik. <gwd> Sure, I mean going forward. If we have specific criteria for keeping or removing, then we'll know if/when we can remove it. :-) <kbsingh> if we drop it, change something - we'll need to make sure that existing installs dot get hurt in updates [14:38] <pasik> yeah, we need to test it properly.. libvirt also tends to prefer blktap <gwd> Yes. Which is a difficult thing to test ourselves -- we might have to try to prod some users to test stuff and tell us if it breaks. <gwd> libvirt> Well we can patch that out, I should think. [14:39] <pasik> yep <kbsingh> why do we want to drop it.. <gwd> Because the stuff in the Xen tree is completely unmaintained. <gwd> XenServer has their own fork, but they're basically not going to upstream it, and they have been considering other options for some time. [14:40] <kbsingh> ok <gwd> I'm not suggesting one thing or another as yet -- I'm just exploring the options. <pasik> for the time being i'd say pulling the xenserver blktap2.5 fork would be least bad thing to do <pasik> least surprise for users [14:41] <pasik> because we've been shipping it so far <gwd> Because there are now other people trying to use the in-tree blktap, and trying to fix bugs, which is a total duplication of effort. <gwd> So with my "XenProject" hat on I'm trying to sort out a solutiong going forward that works for all the parties involved (XenServer, distros, Fujitsu) <pasik> yep [14:42] <pasik> that's good <pasik> maybe we can try to patch the latest blktap2.5 bits to xen4.4 rpms, and see if it works properly <pasik> at least the older blktap2.5 bits do work ok with the xen 4.2 rpms [14:43] <gwd> This is part of the reason libvirt's "expose the implimentation details" policy isn't that great... if it just said, "Give me a vhd disk", we could let libxl sort out the best way to do that. If it says "Give me tap with aio", less flexibility... <pasik> gwd: true <kbsingh> so something for the 4.4 roadmap ? [14:44] <kbsingh> for the 4.2 tree's are we saying leave it as is <gwd> Well if downstreams are going to want blktap, I think the best option going forward would be for XenProject to take blktap2 out of tree entirely, and treat it as an exeternal project, similar to qemu, seabios, &c <gwd> Yes, 4.2 we have to leave it as it is. <gwd> I think 4.4. I'll play around with updating to the most recent XenServer version. *** JHogarth (~email@example.com) has quit: Ping timeout: 265 seconds [14:45] <pasik> sounds good <gwd> I've got some pointers from Michael Young at Fedora what might be involved in that. <lars_kurth> All agreed on this? <gwd> OK, anything further for lars before he disappears? <pasik> lars_kurth: at least i agree :) <kbsingh> yeah, sounds good to me [14:46] <lsm5> lgtm :) <lars_kurth> Going to have to go - minutes at http://wiki.centos.org/SpecialInterestGroup/Virtualization/2014-October21-minutes ... please add log and whatever else comes up *** imcleod (~firstname.lastname@example.org) has quit: Ping timeout: 255 seconds *** bexelbie (bexelbie@fedora/bexelbie) has quit: Remote host closed the connection *** mbrysa (mbrysa@nat/redhat/x-mnhkqqglpvfugcgj) has quit: Quit: Leaving [14:47] <gwd> BTW, lsm5, I take it you're still using koji with srpms? You don't have repos on git.c.o yet...? <lsm5> gwd: yup still koji with srpms [14:48] * DV__ notes that there is a email@example.com for discussion of libvirt APIs :) <kbsingh> i was going to get the git upgrade done today, but too many other things going on meant have had to push that out to this Friday, once that is done - the git <> koji workflow will get easier <gwd> OK. :-) <kbsingh> DV__: there was little / no libxl support in libvirt at the point when we patched it in locally. <pasik> gwd: about libvirt version for c6/xen-4.4 .. shall we discuss that here, or on the list? [14:49] <kbsingh> pasik: gwd: there is quite a bit of interest in having a new'ish / recent'ish libvirt for CentOS6/7 available ideally close to libvirt.org releases. *** imcleod (~firstname.lastname@example.org) has joined channel #centos-devel <kbsingh> if we can contribute into that, or just leech from that, we should consider it <gwd> Yeah, in theory we already agreed to use the most recent libvirt release until Xen support stabilizeg <gwd> *stabilized <pasik> ok [14:50] <kbsingh> ok <pasik> so centos7 libvirt isn't an option atm? <kbsingh> pasik: for centos6 ? <pasik> yep <gwd> One of the real limitations we have right now is testing, actually <kbsingh> what / how good is the xen support in that one <gwd> There are so many things we want not to break; I can do some decent smoke testing when it comes to basic Xen functionality, but if we're going to include upgrading from older versions of libvirt, I think we're going to need something more. [14:51] <gwd> I was talking with a guy named blip, who was interested in setting up a test system for Xen. [14:52] <pasik> gwd: i can also do all the basic testing, also with libvirt <pasik> gwd: i did it for c6/xen-4.2 aswell <gwd> pasik: OK, great. <pasik> but more testers the better, of course [14:53] <pasik> when we have some kind of "beta" we should ask people on the list to try it <gwd> So the next question would be, do we need signed builds for testing, and if so, what do we need to do to make that happen? [14:54] *** JHogarth (~email@example.com) has joined channel #centos-devel <kbsingh> were a week or more away from being able to sign stuff yet *** bexelbie (bexelbie@fedora/bexelbie) has joined channel #centos-devel [14:55] <pasik> i'm happy to test unsigned rpms, but for more broader testing signing would be good <gwd> kbsingh: So should we wait? Or put some stuff up with a "caveat emptor"? [14:56] <kbsingh> I'll let the SIG decide :) <gwd> OK, well thanks everyone! [15:00] <kbsingh> ta