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