[FrontPage] [TitleIndex] [WordIndex] 

This is a read-only archived version of wiki.centos.org

Attending

Updates & Blockers

1. Docker

2. Xen Project

IRC log

<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 (~imcleod@24.12.72.163) 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 (~timothy.l@n219077073220.netvigator.com) 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 (~richardm7@c-24-218-110-68.hsd1.ma.comcast.net) 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 (~darbinda@87-126-54-101.btc-net.bg) 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 (~hogarthj@91.215.166.4) 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 (~imcleod@24.12.72.163) 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 libvir-list@redhat.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 (~imcleod@24.12.72.163) 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 (~hogarthj@91.215.166.4) 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
2023-09-11 07:23