[CentOS-virt] Actions and IRC log from May 6th VIRT SIG meeting

Tue May 6 15:55:57 UTC 2014
Lars Kurth <lars.kurth at xen.org>

On 06/05/2014 15:31, Lars Kurth wrote:
> Hi all,
> I summarized actions on 
> http://wiki.centos.org/SpecialInterestGroup/Virtualization/Status 
> tagged with 06/05
> The meeting LOG is below
> Regards
> Lars
Didn't realize the log would turn out that bad. Here we go again ...

lars_kurth: How do you want to run this? We have a set of loose ends: 
the roadmap via
http://lists.centos.org/pipermail/centos-virt/2014-April/003763.html
kbsingh: if someone (lars_kurth) wants to just do it point by point we 
can run through those.
lars_kurth: And some open actions: 
http://wiki.centos.org/SpecialInterestGroup/Virtualization/Status
kbsingh: there is a 60 min hard stop at the end
jonludlam: hi all
lars_kurth: How about the following: Actions first, then George can do 
the roadmap?
kbsingh: ok, works for me
lars_kurth: Do we all have 
http://wiki.centos.org/SpecialInterestGroup/Virtualization/Status up?
kbsingh: I do
gwd:yep
pasik:yep
lars_kurth:kbsingh: there were 3 technical items on you. I know you and 
hughesjr and gwd had a
conversation last week. Is there anything that can be ticked off in the 
technical
category?
kbsingh:I believe gwd is setup with the basic workflow, and has git access
we only imported the main xen repo at this point, but if things are 
looking ok and
if the process is something we can work with - i can go ahead and import 
the rest of the repos
gwd:So it's imported into git.centos.org?
kbsingh:humm
lars_kurth: kbsingh: what would the URL be?
kbsingh:https://git.centos.org/project/sig-virt is where it should come 
up on
lars_kurth: definitely there
kbsingh:right, so the blocker was how are we going to organise the git 
repos on github - are
we going to setup some teams at the project level or the repos level
kbsingh:http://lists.centos.org/pipermail/centos-devel/2014-April/010175.html 
is the conversation
kbsingh:i dont believe we all got to a result there.
lars_kurth: Do we need to reply to this thread? Or is this more general?
gwd:Well you had asked about having a different org for each sig, and 
Karsten said that sounded
reasonable. Is there any reason not to give that a try for now?
lars_kurth: Can we close this now. Or do we just have an action to 
engage with the discussion?
gwd:I can reply to the thread.
kbsingh: There are a couple of threads that fall out from this, eg. 
where is the kernel going to be
maintained - and is every sig that needs a kernel then going to need to 
maintain the entire thing
or can we just have a single git repo, with sig's maintaining their own 
branches
hughesjr:I see a meeting in progress ...cool
lars_kurth: hughesjr: hi. A little painful on IRC, but welcome
lars_kurth: kbsingh: does sounds like a centos-wide decision that needs 
to be made. I propose to take an action
for gwd and me to replay to the respective threads.
gwd:Is there really a difference? Isn't that the point of DVCS?
kbsingh:gwd: for the sake of convenience, I'd say maybe we just trial 
the model of having everything under
/CentOS/ and if or when we run into a problem, we can try to change 
things around
gwd:That's certainly a lot easier to begin with.
kbsingh:ok
lars_kurth: Cool: I made a note
kbsingh:lets take that away then as a todo
lars_kurth: Added as new action. Gwd may need to tidy up if I misunderstood
gwd:kbsingh: So you're going to clone all the repos into git.centos.org 
and github.com/CentOS/ ?
kbsingh:I've replied to the thread as well
kbsingh:gwd: yeah, I can go ahead and do that as well - not online right 
now, but it can be done today
lars_kurth: Is “KaranbirSingh to put together list of repository names 
in Xen4CentOS such that we can use
it as a baseline” - still open?
kbsingh:yes. that should get resolved with the move
lars_kurth: Alright. Move to Community?
lars_kurth: My list policy item is still open
gwd:What was the list policy question? I forget.
lars_kurth: gwd: just send a reminder to people that posting to the list 
while not subscribed = mail discarded
Do we want to keep this, or change it?
gwd:discard> got it.
lars_kurth: And we were discussing whether kbsingh wanted to attend the 
Hackathon. I will need to know pretty
soon, as we are running out of space
kbsingh:I do want to come to the Hackathon. i believe there is some 
libvirt people as well ?
lars_kurth: Yes. Daniel Berrage. As well as some other Xen folks working 
on libvirt
OK. In that case, I will reserve a space and add you to the wiki
gwd:jonludlam: Do you know who from the XenServer team is coming?
jonludlam: dave scott, me, not sure about others
jonludlam:euanh, do you know?
euanh:I'm hoping to come
lars_kurth: Let me check – see 
http://wiki.xenproject.org/wiki/Hackathon/May2014#Confirmed_attendees
gwdjonludlam: For this meeting, knowing that you & dave are coming is 
sufficient I think.
jonludlam: David Vrabel and Andrew Cooper on that list
gwd:lars_kurth: You have an outstanding item to e-mail the -virt mailing 
list. Are you planning
on doing that? Does it make sense to do so if there are only a handful 
of places left?
lars_kurth: not doing it, as we don’t have space now
lars_kurth: kbsingh: OK, I will add a few more people as provisional to 
the list. kbsingh: will send instructions
to sign you up fully
kbsingh:there was also some word from ovirt guys. i dont know if they 
have someone local - but they ~
dont have xen support
lars_kurth: kbsingh: I need to know ASAP who that would be, if they want 
to get a space
kbsingh:ok, i can ping around
lars_kurth: kbsingh: great
pasik:iirc ovirt had some sort of Xen support in the beginning and then 
later they switched to "kvm only"
gwd:Hopefully with the improved libvirt support, getting xen support 
back in should be straightforward.
lars_kurth: pasik: I was copied on a thread which says that integrating 
ovirt with xen+libvirt may be non-trivial
as ovirt makes assumptions underneath libvirt
pasik:lars_kurth: yep
gwd:Shall we put that as another agenda item and finish going through 
the actions?
lars_kurth: there are no quick fixes. I would say let's get libvirt 
support better first and then look at next steps
pasik:lars_kurth: agreed
lars_kurth: gwd: How about adding it to longer term roadmap goals
lars_kurth: gwd: I will add an action on you to create a roadmap wiki 
page. Is that OK?
gwd:lars_kurth: Ack.
gwd:lars_kurth: We can certainly have a wishlist -- the question is 
who's going to do the work.
lars_kurth: gwd: good question. I think wishlist = looking for a volunteer
lars_kurth: OK. The last set of open actions was Publicty
lars_kurth: The state of play was that we got the centos board feedback, 
made fixes and reported back to Karsten
Karsten still has to ACK
lars_kurth: I asked for Advisory Board approval on the assumption that 
he would do so
lars_kurth: So the blocking issue is for the centos board to ACK
lars_kurth: kbsingh: can you take this on or chase Karsten?
kbsingh:lars_kurth: i can ping him
lars_kurth: thanks. Tracked everything in the minutes
lars_kurth: gwd: over to you
lars_kurth: gwd: I think we are all looking at 
http://lists.centos.org/pipermail/centos-virt/2014-
and responses
lars_kurth: Do we have any disagreements / open questions in this thread?
gwd:Roadmap> I sent out a mail with a basic discussion of what we talked 
about two weeks ago;
I don't think there were any additions or objections
gwd:So I'll make a concrete to-do list and post it on a wiki page.
kbsingh:cool
gwd:I think one thing kbsingh suggested is that we want to have most of 
the basic stuff sorted
out before RHEL 7 comes out in... what, June / July?
jonludlam: Not sure if this is the right time to bring this up, but I 
was wondering about bumping the version of ocaml used when building xen
pasik:I think the current xen4.2 rpms are built against ocaml3
jonludlam: yep
pasik:and there was/is the dev repo against ocaml4 aswell
jonludlam: I think at some point in xen4centos's history, there was 
ocaml4 in there
pasik:yep
pasik:so first we need to get the xen 4.4 rpms built, probably against 
ocaml4
gwd:What happened with that? I don't know any of the history
pasik:gwd: what happened is, we just decided to go with the "distro 
stock ocaml3"
because xapi stuff wasn't done yet
hughesjr:this issue is it breaks everything else ocaml in the distro
jonludlam: yes, ocaml is incredibly picky about versions
gwd:Not used to being enterprise yet, I take it...
hughesjr:that means, we have to take on also fixing other distro things 
that are ocaml
pasik:so do we want to first build xen 4.4 again ocaml3 ?
jonludlam: right, unless there's a way for things to co-exist
pasik:+st
hughesjr:jonludlam: I suppose we can do an SCL for xen stuff
gwd:and there's no way to have both versions somehow, and have each 
package use the library it needs?
jonludlam : recent version of ocaml are much happier about coexisting 
with other versions
hughesjr:gwd: if we do ocaml4 as an SCL that would work .. now if we can 
is another issue
jonludlam: hughesjr, would the SCL _contain_ xen then?
gwd:What does SCL stand for?
hughesjr:software collections
jonludlam: == coexistence of different versions of things
gwd:Software CoLlection. Nice.
pasik:xen 4.4.0 src.rpm (for fedora 21) here: 
ftp://ftp.funet.fi/pub/mirrors/fedora.redhat.com/pub/fedora/linux/development/rawhide/source/SRPMS/x/xen-4.4.0-3.fc21.src.rpm
gwd:pasik: kbsingh showed me how the basic CentOS build system works, so 
I'm going to try doing the 4.4 update once the repos are sorted out.
gwd:(Maybe after doing a more minor update as a test first.)
pasik:gwd: that sounds good
gwd:OK, so can we update to 4.4, then update libvirt, and look into 
doing ocaml for Xen as an SCL?
hughesjr:gwd: that sounds like a good plan
jonludlam: How would an SCL work if xen depends upon it?
gwd:Are there any other package updates we need to do?
pasik:so the first iteration of xen 4.4 rpms would be built against 
ocaml3, so there's an upgrade path from xen 4.2 rpms ?
DV:missed the libvirt/xen discussion earlier
lars_kurth: DV: I don't think we had a specific discussion before
DV:lars_kurth: just a few exchange on IRC ^^^
lars_kurth: gwd: I guess the question is which libvirt version
gwd:lars_kurth: On the list we decided 1.2.3, the same as Ubuntu 14.04.
(Or maybe it was 1.2.2 -- whichever one Ubuntu is using).
DV: lars_kurth: what is in Fedora 20 get backports, but it's a bit 'old' 
already
gwd:DV: We seem to be talking about libvirt now -- did you have a 
comment / question / concern?
hughesjr:lars_kurth: I think whatever version of libvirt is in ubuntu 
14.04 LTS is a good starting point (seriously :D)
gwd:libvirt 1.2.2 it was, I think.
DV:gwd: mostly watching, and seeing if there is pit to avoid
lars_kurth: We could agree on this for now and decide to upgrade later 
(after the Hackathon discussion)
gwd:DV: Well we're planning on updating to libvirt 1.2.2, and then maybe 
backporting important functionality
(such as live migration).
pasik:too bad el7 looks to have libvirt 1.1.1
DV:pasik: usually in RHEL there is a lot of backports, so base version 
not always a good indicator
DV:notes other SIGs may want libvirt updates without becoming over 
zealous might be worth checking around to minimize builds
gwd:DV: Noted. Know of any that we should coordinate with?
lars_kurth: DV, kbsingh: do you have any visibility to what other SIG's 
need? If not, we should maybe poll on the centos-devel list
kbsingh:lars_kurth: yes, and no. i think we should deliver something, 
anything, just ship it
gwd:I think going forward, all changes / pull requests will be posted to 
the centos-virt list,
so any specific change can be objected to when it actually gets submitted.
kbsingh:that gives people a target to point at otherwise we might get 
into massive wish lists
DV:kbsingh, if other sigs are not more advanced, ACk
gwd:kbsingh: That sounds like a plan.
lars_kurth: kbsingh: works for me
pasik:DV: yep
kbsingh:yeah, i think the virtsig is perhaps the best place at the moment
gwd:If kbsingh / hughesjr have their fingers in other sigs, they can 
bring us in when we need to
start coordinating about something.
lars_kurth: Works for me. So we agreed to start with 1.2.2?
gwd:That's what we talked about on the -virt list, and nobody has objected.
pasik:let's do what ubuntu 14.04 lts has; so libvirt 1.2.2
lars_kurth: Just confirming for the minutes. Agreed then.
kbsingh:1.2.2 works for me, if - (1) we have qemu rbd supported for both 
ceph and gluster ( libfgfacl )
DV:there have been a lot of libxl updates in 1.2.3, but you know better 
what you need
pasik:from earlier.. did we agree to build the first xen 4.4 rpms 
against ocaml3, so the
current users of el6 xen 4.2 rpms can upgrade smoothly ?
kbsingh:pasik: if we didnt, then we should
kbsingh:hughesjr: ^ ? ocaml3 ?
pasik:DV: those libxl updates need to be backported
jonludlam: pasik, does the ocaml version have much bearing on the upgrade?
gwd:Should we move the really technical discussion to the mailing list?
lalatenduM: kbsingh, I think libvirt 1.2.3 has few imp bug fixes for gluster
DV:pasik: and lot of code churn in 1.2.3, this may not be that easy
pasik:hmm
kbsingh:lalatenduM: in that case, maybe we should consider 1.2.3
lars_kurth: How about, we m we propose 1.2.2 on the list and ask for any 
backports necessary (pointing to patches)
gwd:Well if backporting is too hard, we can think about moving forward 
instead.
kbsingh:how about we decide on a 1.2.x and take the conversation to the 
lists to decide
pasik:so then let's move to 1.2.4 directly?
hughesjr:well .. if we maintain the same major version as ubuntu, things 
will work better in both places and
we can more easily reuse code
gwd:libvirt said they would do maintenance updates for any downstream 
actively using it; I think CentOS
would be big enough to be worth their consideration.
kbsingh:given DV has an eye on libvirt, what do you think ?
DV:Indent top-level labels by one space in ... Use K&R style for curly 
braces in ... that kind of patches
goes in the way of backports
DV:but hard to tell a priori if it really will make it hard
hughesjr:we can do whatever you guys want ... but centos is not intended 
to be fedora
gwd:Going with 1.2.2 was just an attempt to reduce the burden on upstream.
DV:gwd: Well if backporting is too hard, we can think about moving 
forward instead. : that's reasonable
gwd:Well let's look at 1.2.2 and try a few backports and see how it works.
DV:ack
lars_kurth: Agreed. Will add an action on gwd
DV: used to assemble RHEL libvirt builds for too long, some reflexes 
persists
gwd: DV: I'd much rather learn the easy way, from your experience, than 
the hard way, from my own.
DV:gwd: TBH the libvirt team use to rebase frequently, 6.1, 6.2, 6.3 ... 
because code changes fast and want to minimize backport loads
DV:gwd: that said being 0.0.2 behind means only 2 months, should be okay
pasik:jonludlam: about ocaml version: like said the current xen 4.2 rpms 
are built against ocaml3, and
if xen 4.4 rpms added ocaml4 as a requirement, then all the distro ocaml 
stuff would break in the
xen 4.2 -> xen 4.4 upgrade.. I don't think we want to do that.
pasik:jonludlam: so I'd say let's first build xen 4.4 against ocaml3; 
and then let's figure out the SCL
stuff so we can properly do xen 4.4 with ocaml4
jonludlam: pasik, they shouldn't be run-time requirements
jonludlam: pasik, btw, no problem starting with ocaml3 with a view to 
seeing how ocaml4 might turn out
pasik:jonludlam: ok
gwd:One thing we might want to talk about (maybe on the -devel list) is 
changing the "binary blob"
thing in the CentOS build system to make it earier to collaborate with 
people who don't have access
to the "blob repo" (sorry I don't know the proper terms for these things)
pasik:gwd: lookasides or something
kbsingh:gwd: ok, if you start that off, we can hash it out ( the 
lookaside thing )
gwd:Most of the blobs in Xen4Centos seem to be upstream tarballs. One 
option would be to have a URL
of the upstream, with a local cache to make builds reliable.
kbsingh:gwd: i guess people can still checkout and do local things, and 
the get_sources.sh could be injected into the git repo itself
pasik:gwd: I was able to do custom local rebuilds of centos src.rpms; I 
used the get_sources.sh
kbsingh:i am guessing there isnt a LTS sort of version - so we'd need a 
plan to keep things patched without
needing a system update every 2 months
gwd:pasik: The hard part would be pull requests.
pasik:gwd: true
kbsingh:gwd: pasik: pull requests on binary data will always be against 
( or well, used to be against ) a new srpm
so we just run the import
kbsingh:but we can also have remote urls in the .package.metadata file - 
and people can request merges against that
kbsingh:do we have any other major points on the agenda
gwd:I don't think so -- I'll kick off a discussion on -virt about 
packages to update
gwd:And make a roadmap wiki
lars_kurth: Anything else we need to discuss?
pasik:lars_kurth: I think we should write something about ocaml version
lars_kurth: pasik, jonludlam: no - can I get you to make a proposal on 
the list
jonludlam: I believe there's been some discussion before about the 
structure of the xen rpms - is that minuted anywhere?
jcpunk:^^+1
DV:gwd: my suggestions, use git, cherry pick from upstream into a set of 
commit bringing
what you want on top of your branch, use that as you patch list
kbsingh:jcpunk: +1 to what
jcpunk:looking for documented structure of rpms
DV:gwd: see the libvirt rpms from Fedora or RHEL they should be largely 
explicit
kbsingh:this was on the virt list ages ago. we essentially went with the 
carry-in-spec for the leaf nodes needed at build time.
gwd:DV: That seems reasonable.
jcpunk:kbsingh: ah, got it
kbsingh:i suspect jonludlam is talking about the entire wider scope
pasik:lars_kurth: yeah sure, jonludlam is probably the expert with ocaml 
stuff
lars_kurth: OK: will add action
jonludlam: right, interested in splitting dom0 rpms from domU, etc
kbsingh:jonludlam: i dont think we've had that conversation at this 
point. but we should
jonludlam: ok, perhaps next meeting then?
kbsingh:if we dont have any other items, i just want to bring one in - 
and this is past the scheduled hour, but worth talking about
lars_kurth: Maybe next time or on list?
jonludlam: gotta run to another meeting now
gwd:DV: I'm fairly new to RPM building: I take it there's a step where 
you explicitly export base.tip as a series of patches?
gwd:kbsingh: I've got time.
kbsingh:we have a bit of a problem with el7rc kernel not doing pv out of 
the blocks
gwd:That's not as a guest, right?
pasik:kbsingh: only redhat kernel team can do something about that..
kbsingh:when i say a bit of a problem - i mean this is a major train 
crash kind of problem,
given how much of hosting and cloud is pv only
pasik:gwd: redhat disabled xen pv support for el7 kernel
DV:gwd: yes you can ask git to give them a name based on commit text, 
and in the rpm spec you list them in order
pasik:gwd: (xen hvm is still supported)
kbsingh:pasik: right, i dont care about the rhel7 state of play, but we 
might need to do something in the centos ecosystem and own it locally
pasik:kbsingh: yep, definitely we should "fix" that for centos7
kbsingh:gwd: it is.. as a guest, cant run rhel7 as a pv guest. only 
hvm-pv and hvm ( of course )
kbsingh:I will get the git repos in place and the acl's setup this week 
for the xen stuff to happen
gwd:kbsingh: Oh, that's right. But does it have PVHVM support?
kbsingh:and we can maybe target a 4.4 build as a testing/qa process.
kbsingh:gwd: yes. pvhvm works
gwd:kbsingh: So are you thinking of having a CentOS guest kernel that 
supports PV?
pasik:yep
pasik:so probably just a small .config tweak
hughesjr:gwd: well, we will have a kernel that supports dom0 too at some 
point
DV:gwd: git log --pretty=%f -1 your-commit and use that as a base for 
the filename of the associated patch
kbsingh:gwd: i dont know - dont want to predecide and havent really 
spent any time thinking this
though - but i do know that we need to ( spend the time, think it 
through, do something )
kbsingh:lars_kurth are we calling this meeting closed ? ( i am already 
on the phone waiting for the next one to open )
lars_kurth: yes: let's call it closed
pasik:kbsingh: yes, i think we should have some kernel variant with 
"fixed" .config
gwd:Would the PV kernel be basically the same as the Xen4CentOS dom0? Or a
stripped-down version? Or were you thinking of taking the upstream RH 
kernel and
re-enabling PV (meaning another separate kernel branch to maintain)?
pasik:gwd: i think it should upstream-el7-kernel with just the .config tweak
hughesjr:gwd: we can do more than one if we want (or need to)
pasik:gwd: and any xen pv specific patches, if there's a need for those ever
pasik:gwd: so maintenance-wise it would be quite low effort.. hopefully
gwd:pasik: Well, one would hope...
gwd:And would that be a change to the main CentOS kernel? Or a separate 
package that's included for cloud targets?
kbsingh:change to main kernel would need quite a major reason, and a lot 
of shouting and requests -
I suspect we dont/wont get that initially.
kbsingh:we could carry it on the install media though... so its 
available to use right off the bat, post install
( specially if its the same version as the install / main kernel )
gwd:That sounds pretty do-able.
pasik:yep
gwd:OK -- lars_kurth, are you going to send out a meeting report?
lars_kurth: gwd: pointing to the actions and appending this log for now