16:06 <smoser> #startmeeting ubuntu-server-team 16:06 <meetingology> Meeting started Tue Aug 25 16:06:49 2015 UTC. The chair is smoser. Information about MeetBot at http://wiki.ubuntu.com/meetingology. 16:06 <meetingology> 16:06 <meetingology> Available commands: action commands idea info link nick 16:06 <smoser> #topic Review ACTION points from previous meeting 16:07 <smoser> seems like agenda did not get updated i think... 16:07 <smoser> as my caction item bug 1461242 there is fixe 16:07 <ubottu> bug 1461242 in cloud-init (Ubuntu Vivid) "cloud-init does not generate ed25519 keys" [Medium,Confirmed] https://launchpad.net/bugs/1461242 16:07 <smoser> i'll remvoe that 16:07 <smoser> other item listed there is : 16:07 <smoser> Thoughts about numad 16:08 <smoser> anyone know of more content on that ? 16:08 <rharper> I've not poked the team 16:08 <smoser> ok, well please add that to TODO list / bump its priority 16:08 <rharper> smoser: it's a background action item for me to collect team thoughts on whether we should have something like numad and other NUMA related placement stuff 16:09 <smoser> #action rharper collect team thoughts on whether we should have something like numad and other NUMA related placement stuff 16:09 * meetingology rharper collect team thoughts on whether we should have something like numad and other NUMA related placement stuff 16:09 <smoser> #topic Wily Development 16:09 <smoser> #link https://wiki.ubuntu.com/WilyWerewolf/ReleaseSchedule 16:09 <smoser> beta1 freeze is thursday. 16:09 <smoser> and we're past feature freeze now. 16:09 <smoser> so ffe will have to be opened for any new features uyou want. 16:10 <smoser> anything else ? 16:10 <smoser> #subtopic Release Bugs 16:10 <caribou> yes, 16:10 <smoser> ok... go caribou 16:10 <caribou> nm, I'll bring that up at my turn 16:10 <caribou> carry on 16:11 <smoser> k 16:11 <smoser> #subtopic Release Bugs 16:11 <smoser> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-w-tracking-bug-tasks.html#ubuntu-server 16:12 <smoser> loading... 16:13 <smoser> i have one there for keepalived , bu have been out for thelast two weeks. 16:13 <smoser> i'll try to get proress on that by next week. 16:13 <smoser> anyone interesated in others ? 16:13 <smoser> seems like wesley may hav made progress on https://launchpadlibrarian.net/214863711/wily-debdiff 16:13 <smoser> err.. on https://launchpadlibrarian.net/214863711/wily-debdiff 16:13 <smoser> someone want to shepard that through ? 16:14 <smoser> ok. well, that one at very least seems like we shoudl do some mocvement on it. 16:14 <magicalChicken> smoser: Yeah, I got a fix uploaded for that one 16:15 <magicalChicken> smoser: I need someone to sponsor it though 16:15 <smoser> oh. ok. magicalChicken i can see if i can do that for you. 16:15 <magicalChicken> smoser: Awesome, thanks 16:15 <rbasak> I'm behind on sponsoring team bugfixes. Shall I gather a list maybe of who in the team is waiting on sponsorship and try and work through them? 16:15 <rbasak> Though if smoser wants to work on this one feel free :) 16:16 <smoser> thanks. for those playing along at home, magicalChicken == wesley 16:16 <rbasak> magicalChicken, smoser: note: on my very quick glance you need to s/Closes/LP: #/ in the changelog entry. Closes refers to Debian bugs so it won't autoclose the LP one otherwise. 16:16 <smoser> i'm way behind on other things too as a week out did. 16:16 <smoser> so i'll leave that to rbasak or smoser 16:16 <smoser> and we'll move on, but yeah, you want to reference the ubuntu bug with: 16:16 <rbasak> I'll happily take an action to sponsor all outstanding sponsorship requests before the next meeting. 16:17 <magicalChicken> rbasak: Aah, i didn't know that. I'll fix that 16:17 <smoser> LP: #1478149 16:17 <ubottu> Launchpad bug 1478149 in python-tornado (Ubuntu Wily) "python-tornado tests fail against python3.5" [High,Triaged] https://launchpad.net/bugs/1478149 16:17 <rbasak> mag no problem! 16:17 <smoser> moving on. 16:17 <smoser> k ? 16:17 <smoser> #topic Server & Cloud Bugs (caribou) 16:17 <caribou> my request for sponsorship of the rsyslog merge didn't get picked up 16:17 <caribou> & we're passed FF 16:17 <rbasak> Sorry :-/ 16:17 <caribou> I'dl like the audience opinion on going for FFE on this one 16:18 <caribou> so it gets its bits shaken before LTS 16:18 <rbasak> I was swamped around feature freeze and didn't manage to get through all requests. 16:18 <rbasak> I still have a pile of FFEs to do. 16:18 <caribou> rbasak: no worry, I pinged a few others who were swamped as well :) 16:18 <smoser> caribou, your rsyslog ? 16:18 <caribou> I have a potential sponsor now if I get the FFE through 16:18 <smoser> oh. merge. 16:19 <rbasak> I'm not sure it makes sense to FFE everything we missed. It just means that we have less time to fix bugs. 16:19 <caribou> smoser: yes, current is 7.4.4 and debian has 8.9.0 16:19 <smoser> i'd personlly feel ok to push a ffe for rsyslog. 16:19 <smoser> as we would like to have that newer version for x 16:19 <rbasak> OTOH I have no objection to individuals driving their own FFEs. 16:19 <smoser> and having it cook longer would be good 16:19 <caribou> I'm fine with preparing it & let the server team drive it 16:20 <rbasak> I don't want to take on driving more FFEs - I have a number I'm taking care of already 16:20 <rbasak> And if I take on more, then they're only going to slip anyway. 16:20 <caribou> rbasak: true; ok I'll lead this one & may ask for help on my way 16:20 <smoser> ok. well, then . seems like unless someone steps up that will drop 16:20 <smoser> :-( 16:21 <caribou> smoser: it won't, I'll do it 16:21 <rbasak> I'm fine with that caribou - thanks. 16:21 <smoser> ah. ok. good. 16:21 <smoser> #topic Weekly Updates & Questions for the QA Team (matsubara) 16:21 <smoser> caribou, above, if you do have questions, please feel free to ask. 16:21 <matsubara> nothing new to report smoser 16:21 <caribou> smoser: k 16:21 <smoser> #topic Weekly Updates & Questions for the Kernel Team (smb, sforshee, arges) 16:21 <smb> Nothing here that I can think of right now. Are there questions? 16:23 <smoser> k 16:23 <smoser> #topic Upcoming Call For Papers 16:23 <smoser> anything here ? 16:24 <smoser> i dont have anything. 16:24 <smoser> #topic Ubuntu Server Team Events 16:24 <smoser> anyone speaking or attending soon and want to mention ? 16:24 <smoser> #topic Open Discussion 16:24 <rharper> smoser: on the bcache-tools sru to trusty 16:25 <smoser> ah. yeah. 16:25 <rharper> smoser: you were saying that we probably don't need the TB exception since we wouldn't be regressing things vs. upstream ? 16:26 <smoser> unles we put it into an image, then we're virtually guaranteed to not regress aything 16:26 <rharper> wouldn't it go into either cloud image or ephemeral? or just rely on them to pull it down from archive as needed ? 16:26 <rbasak> I don't think the SRU team will accept it under current SRU policy without a TB-approved exception, but we can see. 16:26 <rharper> updated curtin for example, will auto pull in lvm2, mdadm and bcache-tools 16:26 <smoser> sru team would probasbly accept it. 16:27 <smoser> other than putting it into an image. 16:27 <smoser> if its not in an image, then it wont regress anything. 16:27 <smoser> its generally ok to put new things ito old releases for important feature / hardware enablement./ 16:27 <rbasak> I agree that it probably won't regress anything. I'm sure the SRU team won't object on that basis either. 16:27 <smoser> but putting it into a maas ephemeral image means it becomes part of the default install of a maas from ubuntu 16:28 <smoser> which i can see as possible potential for regression 16:28 <rbasak> But AFAIK no "important feature" has ever been SRU'd as new package that wasn't hardware enablement without a TB exception. 16:29 <rharper> in either case (as I have a write up for the TB); the bigger issue IMO is the edge testing on bcache-tools 16:29 <rbasak> Anyway, it doesn't really matter. It won't create extra or duplicate work whichever way we decide to approach this, so I don't mind either way. 16:29 <rharper> while both server and maas teams have been using the bcache-tools package and bcache feature 16:29 <rbasak> If the SRU team want an exception from the TB then we can ask for one - there won't be any harm done. 16:30 <smoser> rharper, well, putting buggy bcache-tools into trusty isnt necessarily bad on its own. 16:30 <rharper> I don't feel those have been edge tested, ie, what happens when we drop the cache device, changing cache modes, recovery, twiddling the sysfs writable values on bcache; 16:30 <rharper> smoser: it's an LTS 16:30 <rharper> so it can hurt for longer 16:30 <smoser> except for when it is annoyingly buggy 16:30 <smoser> and bcache-utils *is* annoyingly buggy 16:30 <rharper> well 16:30 <rharper> sorta 16:30 <rharper> the main function doesn't appear that way 16:31 <rharper> but it's quite awkward to deal with 16:31 <smoser> right. 16:31 <smoser> which could happen unintentionally 16:31 <rharper> which is why I started on that bcache-release script to help folks "cleanup" the mess 16:31 <rharper> yes 16:31 <smoser> thats the point i think is important really. 16:32 <smoser> is that you're essentially suggesting it become part of a default install 16:32 <smoser> and thus it requires significantly more thought 16:32 <rharper> as per maas request 16:32 <smoser> than just adding a package to the archive that will not be used by someone unless they "opt in" 16:32 <rharper> to make trusty ~= vivid ~= wily w.r.t storage config features 16:32 <rharper> ok 16:33 <smoser> so.. i'd say go to TB i guess. 16:33 <rharper> and include some bits on in archive, vs. in image 16:33 <smoser> and be clear that your intent is to add it to a "default install". as i think thats the intent. 16:33 <rharper> and a follow up with maas, can they get by with 'in archive' vs. 'in image' 16:34 <smoser> if instead curtin will install it into the ephemeral image and then into the target only when it is needed, then it requires much less scrutiny in my opintion 16:34 <smoser> becase even then, its essentially "opt in" by a user of maas. 16:34 <rharper> that's how it is today 16:34 <rharper> and unless maas complains about the extra hit to archive to pull in deps 16:34 <rharper> likely not since we're not going to put lvm2 nor mdadm into default install, no ? 16:35 <rharper> smoser: it didn't seem likely given your discussion re: mdadm + mail dep in #ubuntu-devel the other week 16:35 <rbasak> That's going to slow down the install though, no? 16:35 <rharper> so I don't think bcache-tools not in default install is a significant burden since it still has lvm2 and mdadm to install 16:35 <rharper> rbasak: indeed 16:35 <rbasak> We don't really want curtin to have to install packages locally in the long term. 16:35 <rharper> but we'd need all 3 deps to be in 16:35 <smoser> shoot. i had to follow up on that... i thought the discussion ended with 'lets add it'. 16:35 <rbasak> It might be acceptable for Trusty though. 16:35 <rharper> smoser: maybe it did; I only saw the initial discussion w.r.t the mail deps 16:36 <smoser> i'm on same page with rbasak. 16:36 <rharper> folks saying, no if I have a raid I really would like to have it send an email if something is wrong (w.r.t the madm dep on postfix) 16:36 <smoser> we want the default install to have those things, so we should work to get them into wily and then X 16:36 <smoser> but if we can live with trusty being less than perfect than that is good. 16:36 <rharper> so trusty and vivid need runtime deps installed via curtin 16:37 <rharper> wily could be fixed and in=place for x 16:37 <rbasak> Yeah. X is only round the corner now anyway. 16:37 <rharper> trusty and vivid 16:37 <rharper> but, yes 16:37 <rharper> unless you rebuild those images IIUC 16:37 <smoser> well the images are re-built, but we'd have to add those packages. 16:37 <rharper> sure 16:38 <rbasak> That's a good point. If you implement in curtin with a test, it'll always be possible to get a local speed up by hacking your local ephemeral image if it matters to you. 16:38 <smoser> ok. so i think this is beaten. i guess you should go ahead to TB. 16:38 <smoser> rharper, and we should get those packages into wily cloud and maas images. 16:38 <rharper> smoser: ok, can you add the action items then ? 16:38 <rharper> are we OK with the level of edge testing then ? 16:39 <smoser> #action rharper send email to TB about bcache-utils into trusty 16:39 * meetingology rharper send email to TB about bcache-utils into trusty 16:39 <rharper> that was the only thing holding me back before sending to TB 16:39 <caribou> bcache-utils == bcache-tools ? 16:39 <rharper> yes 16:39 <smoser> right 16:40 <smoser> #action smoser, rharper get other packages into cloud-image necessary for storage features. 16:40 * meetingology smoser, rharper get other packages into cloud-image necessary for storage features. 16:40 <rharper> smoser: ok, I'm good 16:41 <smoser> #topic Announce next meeting date, time and chair 16:41 <smoser> next meeting will be Tuesday, September 1 at 16:00 UTC 16:41 <smoser> chair will be gnuoy 16:41 <smoser> #endmeeting