15:02:38 #startmeeting Virt SIG 15:02:38 Meeting started Tue Jan 26 15:02:38 2016 UTC. The chair is gwd. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:02:38 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:02:47 #chair sbonazzo lsm5 kbsingh 15:02:47 Current chairs: gwd kbsingh lsm5 sbonazzo 15:03:04 #chair Jehane 15:03:04 Current chairs: Jehane gwd kbsingh lsm5 sbonazzo 15:03:27 lsm5: It's been a while for Docker -- you want to go fist? 15:03:30 *first 15:04:54 gwd: yup 15:05:11 #topic Docker update 15:05:12 #info currently building 1.9.1 and docker-master-1.10 15:05:52 #info along with golang 1.5, and now I see a funny thing that golang needs some royalties in the form of free distribution of tom sawyer along with the package o_O 15:06:09 #info checking with the fedora maintainer what all that really is about and if we're ok to remove it 15:06:21 is Tom Sawyer on public domain ? 15:06:36 #info also got Jehane on board, who will be handling docker-distribution and maybe other packages too 15:07:00 #info no progress on rkt yet, but it's been approved on the Fedora side, so it'll hopefully come soon on centos land too 15:07:13 that's about it for now, sorry about the lag 15:07:20 Jehane: apparently so 15:07:37 It is, yes. I assume they mean in electronic form? :-) 15:07:47 gwd: yup :) 15:07:57 sbonazzo? 15:07:58 is this docker with or without the RH patchset ? 15:08:05 ( that you are building ) 15:08:14 kbsingh: all with RH patches 15:08:18 ok 15:08:19 gwd sure 15:08:24 then what is the release plan for that docker ? 15:08:27 #topic oVirt updates 15:08:34 sbonazzo: lets close on docker first :) 15:08:40 #undo 15:08:40 Removing item from minutes: 15:08:56 kbsingh: sorry 15:09:03 noworries, welcome to irc lag 15:09:08 #info centos-release-docker in the works too, i'll have that out within this week, and we could put 1.9.1 out for release as well 15:09:22 i meant package updates lag :| 15:09:27 lsm5: the first thing to get done is to get this docker stack into buildlogs.centos.org - we dont need the release package for that 15:09:48 lsm5: its worth getting some testing on the packages, with them sitting out in the buildlogs repos, so folks seem them as they would on mirror.c.o 15:09:59 kbsingh: ack, how do I put them there? 15:10:16 lsm5: RemiFedora can hook you up :) 15:10:30 kbsingh: ack, i'll check and follow up 15:10:31 or gwd for that matter, i suspect both of them have done this before 15:10:44 kbsingh: But it is easier to test if there's a release package that has the buildlogs repos in it (disabled by default) 15:10:50 lsm5: once we have that, it would be good to announce it to centos-devel along with that the update policy around that is likely to be 15:11:04 i know a few people are keen on using this, but dont know status etc 15:11:05 what does update policy include? 15:11:06 gwd: agree. 15:11:25 lsm5: https://github.com/CentOS-virt7/centos-release-xen would be a good starting point 15:11:28 lsm5: just whatever you think is going to be the way to keep updates going ( as in, its going to track XX ver from docker.io etc ) 15:11:37 gwd: sure thing, i'll look 15:12:21 guess that's about it from my side, also i'm always on the lookout for co-maintainers :) 15:12:30 let me know if anyone's interested 15:12:36 There's been a discussion on centos-virt about how to do major version updates (i.e., xen 4.4 to xen 4.6) that is probably worth thinking about for Docker as well. 15:12:57 gwd: ack, i look that up too 15:13:00 (We'll get to that later in the meeting) 15:13:02 i'll* 15:13:34 cool 15:13:36 OK, ready to move on? 15:13:39 yea 15:13:46 we shold action something here 15:14:02 #action lsm5 to get centos-release-docker and bug reports filed for wider testing 15:14:06 if thats how it works 15:15:15 sbonazzo? 15:15:24 #topic oVirt updates 15:15:39 #info oVirt 3.6.2 has been released upstream this morning 15:16:08 #info host node side rpms are already in virt sig repos tagged for release 15:16:34 lsm5: ref: https://wiki.centos.org/SIGGuide/Content/BuildLogs 15:16:37 I think that's all on my side 15:17:08 #topic Xen update 15:17:41 #info CentOS 7 basically ready for release; already on mirrors, just needs centos-release-xen pushed to centos-extras 15:17:46 A bit more needs to be done there first though 15:18:18 #info Update to Xen 4.6 announced for C6, this caused some discussion on the list about how to do updates in a non-disruptive way 15:18:38 #info updated to Libvirt 1.3.0 (most recent release). Probably needs some testing on ARM 15:19:04 I think that's it for actual updates. 15:19:21 The next thing to discuss is the update policy. 15:19:25 is there anything coming up in the next week w.r.t xen that needs attention from the core sig side ? eg. the sign and push stuff ? 15:19:36 mostly, since, Fosdem etc 15:19:58 kbsingh: I don't think so. I'm focusing on my talk for FOSDEM this week. 15:20:02 ok 15:20:25 kbsingh: Also, before we push the 4.4 -> 4.6 update, we need to decide how we're going to do those thing. Did you read the thread on centos-devel about that? 15:20:36 well for posterity I'll summarize it here anyway. 15:21:13 The basic argument was that a major update like 4.4 -> 4.6 shouldn't just be pushed out through yum without some action from the admin; particularly as 4.6 finally gets rid of xend 15:21:16 please ( no, its on the list of lists to catchup ) 15:21:36 right, xend lost might be a problem for folks with scripts / automation etc 15:22:22 So people understood the idea of only maintaining one package going forward, but most of the people who voiced an opinion favored having a new package called "xen46" which conflicted (but didn't obsolete) the existing xen package. 15:23:11 that can cause serious carnage when components are installed for deps 15:23:15 eg. if something needs xen 15:23:58 Hmm, shouldn't they depend on functionality (e.g., existence of libraries &c) rather than package names? 15:24:16 they do 15:24:34 which is why you can have xen44 installed and have it replaced with xen46 since something needed: xen 15:24:55 it maybe simpler to have a new centos-release-xen46 15:25:05 and have a seperate repo for xen466 15:25:18 and have that centos-release conflict with the centos-release-xen44 15:26:05 That sounds like a bit of a hassle. 15:26:08 hhorak: nice work fixing the CI tests today 15:26:20 ...dealing with Yet Another CBS Tag. :-) 15:26:50 we went around a few circles for gluster on this as well, and the only cleanish way that this works is by sgregating the repos 15:27:13 Apparently RH does this for some of their packages, right? mysql, mysql55, &c? 15:28:03 mostly, working to move down the scl route for stuff like this 15:28:06 or containers 15:29:04 What packages would actually depend on Xen itself? Most things should require something Xen provides ; e.g., xen-hypervisor-abi >= X 15:30:24 are you not already building 44 and 46 into different cbs tag's 15:31:05 Yes, I am -- but as far as testing goes, ATM I just have {CBS, buildlogs, mirrors} x {C6, C7} 15:31:46 This would add x {44, 46} for all of the testing. 15:32:58 well, you dont need to test 44 anymore if you are not building for it anymore :) 15:33:10 kbsingh: So just to be sure I understand: The issue is that there are dependencies in spec files like "Requires: xen-ocaml = %version-%release" ; and this would break because you'd actually have xen46-ocaml instead. 15:33:25 gwd: amogst things, yes 15:33:55 and any common code you have ( libvirt? ) would need to work for both versions 15:34:03 Dominic: it was high time already 15:34:12 or you'd need each of them to be split, into their own paths, and managed 15:34:49 Yeah, that starts to get a bit crazy. I definitely don't want libvirt13 and virt-managerNNN 15:34:49 gluster/openstack both do multiple versions ( but they support both ) and split by different centos-release- files 15:36:38 the other thing to keep in mind is : when willyou deprecate 44 ? when can we purge that content from mirror.c.o 15:37:24 I don't plan on sending any more updates to xen44. (Or I didn't, but now I may have to if there are XSAs that come out before we can get whatever our new setup in place) 15:38:07 So if we went with the centos-release-xenNN thing, do we want to: 15:38:19 1) Always have just centos-release-xenNN (no centos-release-xen anymore) 15:38:59 2) Have centos-release-xen depend on whatever the most recent centos-release-xenNN is (so you get automatically upgraded unless you uninstall centos-release-xen 15:39:35 3) Have the first centos-release-xen be whatever is the first release for that CentOS version, and have centos-release-xenNN for subsequent ones 15:39:45 I'm sort of split between #2 and #3. 15:44:15 No opinions? :-) 15:44:25 yeah, #3 becomes hard to manage though - assume in a years time, there might not be a xen44 repo 15:44:35 gwd: i was debating with myself :) 15:44:56 OK, well maybe we can let it stew for a bit and come back to it. :-) 15:44:59 otoh, its always nice to have a centos-release-xen that always works, so we dont haveto / need to keep updating docs 15:45:09 maybe worth thrashing out in the list 15:45:56 Well I think the big point on the list was that *most* people don't want to have major updates go through if you just do "yum update". 15:46:06 The details of how to do that differ. 15:46:26 (Although, I honestly can't imagine just running "yum update" without checking to see what you're getting...) 15:46:36 so in this case, a 'yum list updates' will no longer show updates for Xen- itself, but nothing at all 15:46:51 however, if centos-release-xen was available, they'd need to check for it manually 15:47:15 or have something in centos-release-xen provide something that might be considered an update to centos-release-xens Yes. 15:47:49 have centos-release-xen44-obsolete 15:47:50 then a yum list updates would show you 'centos-release-xen46' 15:48:21 But wouldn't "yum update -y" then grab centos-release-xen46 automatically (which is what we don't want)? 15:50:13 would 15:50:36 so i thikn we should resolve this on the list, let those guys workout what side of the fence looks greener 15:50:57 because what happens is that we take away the auto-update and make it into a communicate-new-ver problem 15:51:28 Well so far there are 1-2 "I always want the latest version" people, and 4-5 "I only want to upgrade if I do something specifically" people. 15:52:14 I mean, honestly, I think you should *never* run "yum update -y" on your production servers... 15:52:23 right 15:52:39 but i think this is a case in point on how hard we've tried to not break an existing install over the years, that folks do 15:53:20 even then, i think its always good to know whats going through 15:53:39 and in many cases, even more so with more than a few machines, it makes sense to run a local repo and manage / release content to it 15:53:47 then have the machines run against that repo with yum -y upgrade 15:54:05 ( when pointing to your own offline repo ) 15:55:36 OK, well let's think a bit more about that and discuss it on the list / at the next meeting. 15:55:56 ack 15:56:21 I'll ping the openstack / gluster / ceph guys to the convo as well, its going to hit all of them at some point and its worth having a consistent msg there 15:56:30 #info gwd will be at FOSDEM this weekend; I have a talk here: https://fosdem.org/2016/schedule/event/secresponse/ 15:56:46 #topic AOB 15:56:51 Anything else? 15:57:20 I didn't manage to change my train ticket, so I won't make the CentOS Dojo unfortunately. 15:57:54 :( 15:57:59 we should have the sessions recorded 15:58:58 Cool. 15:59:00 OK, thanks everyone! 15:59:03 #endmeeting