[CentOS-virt] Log from today's IRC meeting (June 3rd, 2014)

[Lars Kurth]

With slight re-ordering to keep related things together

<kbsingh> lars_kurth: Hi  [13:52]
<kbsingh> Are we doing this meeting on irc ?
<lars_kurth> kbsingh: yes, we are  [13:59]
<lars_kurth> gwd: Hi.  [14:02]
<lars_kurth> Alright. I didn't put an agenda together
<gwd> I've got a couple of things I wanted to bring up. [14:04]
<gwd> Who else is here for the meeting?
<lars_kurth> Please do. I think KB has some too
<jonludlam> Hello
<lars_kurth> gwd: seems we have jonludlam, kbsingh gwd and me so far [14:05]
<lars_kurth> Hi. Before we properly start. Any changes on actions on 
http://wiki.centos.org/SpecialInterestGroup/Virtualization/Status ?
<lars_kurth> So: no changes then?  [14:06]
<gwd> We chatted at the hackathon (with Daniel Barrange there) about 
libvirt versions
<jonludlam> That was a good session  [14:07]
<lars_kurth> gwd: what was the outcome/recommendation?
<gwd> What we said there was that libvirt/libxl driver isn't yet stable, 
so there's no point doing a "choose a version and stick with it" thing 
until it is.
<lars_kurth> gwd: that is what I was afraid of  [14:08]
<jonludlam> so libvirt becomes a 'tech preview' until it stabilises?
<gwd> Er, I don't think "tech preview"
<jonludlam> 'unstable'?
<gwd> More like, "Not enterprise". :-)
<jonludlam> ok
<pasik> hello  [14:09]
<jonludlam> hi pasik
<gwd> pasik: Hello
<gwd> You know, like the kernel we want to be "enterprise" and only 
update every 2+ years.
<lars_kurth> But that is only an issue for libxl, mot xm. Correct? If we 
are still talking Xen 4.4 that should not be an issue
<gwd> I don't think we want to encourage anyone to use xend if we can 
possibly help it.
<gwd> We need to transition people away from it.  [14:10]
<jonludlam> libvirt is a reasonable transition strategy though
<gwd> Is there a need for "enterprise libvirt"?  Is anyone using that?
<pasik> Hopefully we can get thinks into better shape with xen 4.4 + 
later libvirt
<lars_kurth> Agreed. How about the needs of KVM, oVirt, ... for libvirt
<pasik> with the current xen 4.2 packages basicly only xend is usable 
(with libvirt)
<gwd> pasik / euanh: We were just talking about how often to update the 
libvirt packages.
<jonludlam> ovirt will take a good deal of porting to work with xen
<lars_kurth> jonludlam: correct. But this SIG is not about Xen only  [14:11]
<jonludlam> true, but
<gwd> jonludlam: given how much hypervisor detail is exposed by libvirt, 
how reliable would a libvirt/xend -> libvirt/libxl transition go?
<jonludlam> What was said was that ovirt effectively doesn't need 
anything provided by what we're looking at in sig virt today [14:12]
<jonludlam> gwd, I don't think it would be too bad - it already 
autodetects whether to use xl or xm based on what's installed, if you 
connect to xen://
<gwd> lars_kurth: I think if someone wants to use oVirt+KVM, they can 
use the core libvirt.
<gwd> jonludlam: Sure, but as we found out, libvirt doesn't try very 
hard to hide the hypervisor details.  [14:13]
<jonludlam> qemu was mentioned in the meeting at the hackathon, but it's 
totally orthogonal to everything else in the SIG so far
<jonludlam> gwd, but the difference between libxl and xend is much 
smaller than between qemu and xen
<gwd> Sure; but it may still be a fairly major headache to get stuff to 
work.
<lars_kurth> kbsingh: any views? I thought you were worried about scope 
creep in the SIG.
<lars_kurth> Sorry: SIG  [14:14]
<gwd> And what actually works well with libvirt+xen at the moment 
anyway? xm/xl are better than virsh, IMHO
<lars_kurth> gwd: That is probably correct. On the other hand, we don't 
have an interface into Cloud SIGs until we have libvirt and/or xapi
<jonludlam> the xapi question was a bit clearer after the meetings. Anil 
and KB talked about an OCaml SIG that the virt SIG could
<gwd> lars_kurth: Yes, but those are not going to be enterprisey either. :-)
<lars_kurth> gwd: so what is the proposal
<gwd> The proprosals are: depend on
<gwd> 1) Choose a version of libvirt (1.2.3 maybe) and stick with it, 
backporting functionality we're missing.  [14:16]
<gwd> 2) Update the libvirt package when there's a new libvirt release 
until libxl support is mature enough
<pasik> gwd: I use virt-install often to install new VMs
<pasik> gwd: imho it's the easiest way to launch $distro installers in a 
PV domU  [14:17]
<gwd> #2 is easier for us, and will get us all the available libvirt/xen 
functionality; it's what we favored at the metting at the hackathon.
<pasik> gwd: and virt-install works with xen4.2+xend+libvirt in el6
<gwd> The only downside is that enterprise customers don't like such 
frequent updates.
<jonludlam> Daniel B said that #1 would be tricky, as they were 
refactoring the other bits of libvirt to make the xl plugin easier [14:18]
<DV> We really try to not break libvirt upstream, ideally having the git 
version run for regtests on libxl would be a good idea
<gwd> DV: Upstream Xen Project already does that.
<DV> * DV agrees with danpb , even in RHEL we rebase to try to avoid 
backporting
<gwd> Having a new libvirt shouldn't *interfere* with oVirt, 
virt-install, &c&c.  [14:19]
<DV> gwd: ah, good, are the result available publicly, if yes then maybe 
breakages should be reported on libvirt-list!
<DV> err libvir-list@
<gwd> DV: Can you mail me about that separately?  It's a bit off-topic 
for the current meeting. :-)  [14:20]
<DV> gwd: hum, the problem is that there is usually a few RHEL specific 
patches which used to be carried on libvirt builds
<lars_kurth> Related to the libvirt version discussion is 
http://lists.centos.org/pipermail/centos-virt/2014-May/003832.html
<pasik> gwd: and also virt-manager works OK with el6 xen4.2+xend+libvirt
<pasik> gwd: for basic VM management operations, and new VM installs
<DV> but I think we tried to reduce them as much as possible
<pasik> gwd: so maybe that answers your "And what actually works well 
with libvirt+xen at the moment anyway?"
<DV> pasik: ah, good to know !  [14:21]
<gwd> Just to be clear: the question is NOT "do we need libvirt".  Yes, 
we absolutely do.
<gwd> The question is, "Do we need a super-stable libvirt, or can we 
just update on new releases for the time being."  [14:22]
<lars_kurth> Related to that is then: how long would we be on cutting 
edge libvirt version (by gut feel)
<jonludlam> gwd, and, if we are updating to new releases often, is that 
with a view to converging?
<pasik> gwd: well, centos6 is an enterprise stable distro, se people 
expect things to be (at least semi) stable.
<pasik> gwd: we can of course make it clear libvirt will change more 
often.. [14:23]
<gwd> Well let's discuss this on the list.
<DV> * DV think within the SIG the rule 'things should be absolutely 
rock solid' could be relaxed, but only a bit   [14:24]
<gwd> kbsingh: Actually, that's another question: centos-devel isn't 
really that high traffic.  Would it make sense to have the development 
discussions held on there?
<gwd> OK, so that's going to be taken back to the list. [14:25]
<lars_kurth> OK: adding an action
<lars_kurth> gwd: are you OK to make a proposal?  [14:26]
<gwd> That's all the updates I have from the status: we're still waiting 
for the core CentOS team to get something set up to make contribution 
easier; there was some discussion of using koji, like Fedora.
<gwd> lars_kurth: Yes, I'll do that.
<lars_kurth> What next on the agenda?  [14:29]
<gwd> Did everyone see the Xen Hackathon meeting minutes? Anyone have 
any questions about that?
<lars_kurth> See 
http://lists.centos.org/pipermail/centos-virt/2014-June/003865.html for 
meeting minutes
<gwd> jonludlam: "...with a view to converging" -- you mean, to stop 
updating once libvirt+libxl is mature?  Yes, that was my idea.  [14:30]
<jonludlam> yes
<gwd> Cool.
<jonludlam> although exactly how to define maturity is left unspecified 
:-) [14:31]
<gwd> So I had one quick question for kbsingh -- should I merge my "git 
am" change into the main CentOS repo on github?  Is there anything else 
that need to get that actually built?
<lars_kurth> kbsingh: AYT?  [14:32]
<gwd> (Or maybe hughesjr ^)
<gwd> OK, I think most of what I had really needs kb's input. :-)  [14:34]
<lars_kurth> gwd: maybe ping kbsingh and/or hughesjr  an e-mail (or on-list)
<gwd> Related to the "build images" thing -- is there a better way to 
make images that doesn't require libvirt?  [14:35]
<lars_kurth> Any other items from 
http://lists.centos.org/pipermail/centos-virt/2014-June/003865.html that 
we need to discuss?
<gwd> The only tool like that I've ever used is xen-tools, which might 
be possible, but it would be nicer if there were something that could 
make images either for Xen or KVM.  [14:36]
<lars_kurth> It seems it may make sense to track jonludlam about Ocaml 
SIG and XAPI in the actions
<jonludlam> lars_kurth, sure
<lars_kurth> jonludlam: can you summarize that discussion briefly?
<jonludlam> I'll poke anil :-)
<jonludlam> Right: anil & KB discussed creating an OCaml SIG which would 
take the most recent version of the ocaml compiler: 4.01  [14:37]
<jonludlam> RHEL 7 will have 4.00.1 (not recent enough)
<jonludlam> SIG virt could then depend upon the OCaml SIG, but 
crucially, only the OCaml bindings from the sig virt would then depend 
upon the ocaml sig  [14:38]
<jonludlam> oxenstore doesn't need any runtime dependence on any ocaml libs
<lars_kurth> OK. Makes sense. So the ball is in Anil's court
<jonludlam> correct
<lars_kurth> gwd, pasik: re xen-tools ... anyone knows whether there is 
such a thing for Xen and KVM  [14:39]
<gwd> lars_kurth: I don't understand the question.  [14:41]
<lars_kurth> gwd: was referring back to xen-tools ... what I meant is 
whether virt-manager provides the same functionality + more than xen-tools
<gwd> lars_kurth: virt-install I think will do that, but it depends on 
libvirt; which seems to confuse some people.  [14:44]
<lars_kurth> gwd: re virt-install confusion. If we introduced something 
else, it is likely it will also confuse people. In any case may be 
better to rely on documentation  [14:45]
<gwd> virt-install> But I guess when we add an updated libvirt, then 
things should work more easily.
<jonludlam> lars_kurth, btw, I had another action to send a PR with 
updated RPM packaging layout as an RFC
<gwd> jonludlam: You should be able to d/l the tarballs manually though.
<gwd> jonludlam: And I had an action to send you a how-to build the 
sig-virt-xen repos
<jonludlam> yup!  [14:42]
<lars_kurth> jonludlam: OK, a new one? What is the context?
<gwd> jonludlam: But it turns out the binary-download thing isn't ready 
yet -- KB doesn't want the world spamming his (previously) private ftp 
server. They're trying to come up with a new system similar to Fedora, 
but it's not ready yet.  [14:43]
<jonludlam> gwd, ok - are there many that aren't in the current 
Xen4CentOS SRPM repo?
<gwd> (There was just someone on centos-virt complaining about how hard 
it was to build an image for Xen4CentOS and the poor documentation.)
<jonludlam> lars_kurth, the idea was to try to get the work done by Andy 
Cooper & co to reorganise the layout of the binary RPMs taken up
<lars_kurth> gwd: thank you. Got it  [14:46]
<lars_kurth> jonludlum: Added the action
<lars_kurth> Looks we are running out of steam. Anything else?
<gwd> No -- I think following up on the "where do oVirt and xapi go" 
discussion is the only other thing I had, but we need KB for that.
<lars_kurth> OK. Maybe it is better to do this on the next call. It's 
easier then  [14:49]
<gwd> OK -- any other business?
<lars_kurth> Alright: we are closed then  [14:52]
<gwd> OK, looks like we're done.