20150922

Revision 1 as of 2015-09-22 17:41:31

Clear message

Agenda

Minutes

Review ACTION points from previous meeting:

  • rharper collect team thoughts on whether we should have something like numad and other NUMA related placement stuff

Wily Development

We are in final beta freeze for Wily.

Server & Cloud Bugs (caribou)

nothing to report

Weekly Updates & Questions for the QA Team (matsubara)

nothing to report

Weekly Updates & Questions for the Kernel Team (smb, sforshee, arges)

caribou arges smb apw to coordinate on bug 1496317 (crashkernel 128M), and/or ensure rls notes reflect workaround.

Upcoming Call For Papers

nothing to report

Ubuntu Server Team Events

OpenStack Developer Summit (Tokyo) coming up, several people attending.

Open Discussion

Wily default install dropping python2, need to be explicit with that as a dependency if/where needed.

Meeting Actions

* smoser and beisner to coordinate on bug 1488453 (hacluster failing V/W)

* caribou arges smb apw to coordinate on bug 1496317 (crashkernel 128M), and/or ensure rls notes reflect workaround.

Carried forward:

* rharper collect team thoughts on whether we should have something like numad and other NUMA related placement stuff

Agree on next meeting date and time

gaughen to chair on Tuesday 29th September 16:00 UTC to 17:00 UTC in #ubuntu-meeting

Log

 16:00 <beisner> #startmeeting ubuntu-server-team
 16:00 <meetingology> Meeting started Tue Sep 22 16:00:47 2015 UTC.  The chair is beisner. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
 16:00 <meetingology> 
 16:00 <meetingology> Available commands: action commands idea info link nick
 16:00 <beisner> greetings, everyone
 16:00 <smoser> o/
 16:01 <beisner> #topic Review ACTION points from previous meeting
 16:01 <beisner> * rharper collect team thoughts on whether we should have something like numad and other NUMA related placement stuff
 16:01 <beisner> update, discussion re: the 1 action item from last wk? ^
 16:02 <arges> numad | 0.5+20150602-2 | wily/universe | source, amd64, arm64, armhf, i386, powerpc, ppc64el
 16:03 <arges> numatop | 1.0.3-0ubuntu1 | wily/universe | source, amd64, i386
 16:03 <arges> what other numa packages are needed?
 16:03 * hallyn has a feeling rharper is not around
 16:03 <beisner> yeah i'm not up to speed on that one.  rharper smoser ?
 16:04 <beisner> 321..  we can circle back when rharper arrives
 16:04 <beisner> #topic Wily Development
 16:04 <beisner> #link https://wiki.ubuntu.com/WilyWerewolf/ReleaseSchedule
 16:04 <smoser> yeah, no status thre. we'llw ait more on rharper next trime
 16:04 <smoser> but he is not here.
 16:04 <beisner> we are in final beta freeze
 16:05 <beisner> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-w-tracking-bug-tasks.html#ubuntu-server
 16:06 <beisner> do we need assignees for the triaged + confirmed bugs there?
 16:06 <smoser> looking
 16:07 <beisner> i'd also like to query for status/eta on bug 1488453
 16:07 <ubottu> bug 1488453 in openhpi (Ubuntu) "Package postinst always fail on first install when using systemd" [High,Confirmed] https://launchpad.net/bugs/1488453
 16:07 <smoser> woudl be good to look at the cve one, but it is old.
 16:07 <smoser> that one is assigned to me. you are bothered by it, beisner  ?
 16:08 <beisner> my bug 1479661 is a dup of that -- net effect is that hacluster isn't deployable to vivid or wily.
 16:08 <ubottu> bug 1488453 in openhpi (Ubuntu) "duplicate for #1479661 Package postinst always fail on first install when using systemd" [High,Confirmed] https://launchpad.net/bugs/1488453
 16:09 <smoser> beisner, i'll take a look
 16:09 <smoser> feel free to bother me
 16:09 <beisner> smoser, cool thanks.  bothered  ;-)
 16:10 <beisner> any other general bug discussion?
 16:10 <beisner> if not, moving on
 16:10 <beisner> #topic Server & Cloud Bugs (caribou)
 16:11 <caribou> nothing to mention, sir
 16:11 <beisner> thanks caribou
 16:11 <beisner> #topic Weekly Updates & Questions for the QA Team (matsubara)
 16:11 <matsubara> Hi beisner, nothing to report.
 16:11 <beisner> hi matsubara - ok cool.  thank you
 16:11 <beisner> #topic Weekly Updates & Questions for the Kernel Team (smb, sforshee, arges)
 16:12 <smb> I got nothing to report from our side. Are there any questions/requests from your side?
 16:12 <beisner> smb autobot polls the audience
 16:12 <caribou> smb: I got one
 16:12 <smb> yup?
 16:12 <caribou> smb: the kernel dump currently fails with crashkernel=128M
 16:12 <caribou> smb: looks like a initramfs size issue
 16:13 <smb> yeah, I think you were discussing with apw about that.
 16:13 <caribou> yes, but didn't get anywhere yet. Any chance we can address this before release ?
 16:13 <arges> caribou: is there a bug filed? : )
 16:13 <caribou> arges: yes looking for it atm
 16:14 <arges> i remember we changed the size at some point, or were thikning about it
 16:14 <caribou> bug #1496317
 16:14 <ubottu> bug 1496317 in kexec-tools (Ubuntu) "kexec fails with OOM killer with the current crashkernel=128 value" [High,Confirmed] https://launchpad.net/bugs/1496317
 16:14 <caribou> changing MODULES=dep in initramfs.conf works around the issue
 16:14 <caribou> brings the size of the initramfs from 29M to 12M
 16:14 <apw> smb, i think we should consider making an =dep initrd as well when kdump is installed
 16:14 <smb> Beside of increasing the reserverd mem again, the change for only building required modules into initramfs might be a bit late... Wasn't the question about whether this could be made as a part of kdump's postinst
 16:15 <arges> could that break things for people that need modules to boot and use kdump?
 16:15 <arges> need the modules that may be dropped by change from most to dep
 16:15 <smb> arges, only if the swap hw
 16:15 <apw> in theory not as they should have everything that they have loaded
 16:16 <caribou> we can fix that after release, it's not _that_ critical
 16:16 <apw> given all we do in there is mount / and copy the dump and then reboot
 16:16 <apw> but ... how to trigger the maintenance of _both_ sizes not so easy
 16:17 <caribou> apw: better to fix that after release then?
 16:17 <arges> yea so a cold boot would also need most ,but after kexec'ing we could have something more minimal.  What about bumping 128M?
 16:17 <apw> caribou, its a change i dont know the magnitude of for sure
 16:18 <caribou> apw: then let's hold on to it, since there is a known workaround
 16:18 <caribou> apw: maybe document it in the release notes
 16:19 <arges> i think that's reasonable
 16:19 <caribou> apw: better to find a secure option for LTS
 16:20 <smb> caribou, I guess one of those but nothing to be decided in the scope of the meeting
 16:20 <caribou> arges: ok good for me
 16:20 <beisner> interesting.  ok so, an action to coordinate on the bug & rls note bits.
 16:20 <smb> Best way is to bother us one of there days again
 16:20 <beisner> #action caribou arges smb apw to coordinate on bug 1496317 (crashkernel 128M), and/or ensure rls notes reflect workaround.
 16:20 * meetingology caribou arges smb apw to coordinate on bug 1496317 (crashkernel 128M), and/or ensure rls notes reflect workaround.
 16:20 <caribou> beisner: you can action me on this one
 16:20 <ubottu> bug 1496317 in kexec-tools (Ubuntu) "kexec fails with OOM killer with the current crashkernel=128 value" [High,Confirmed] https://launchpad.net/bugs/1496317
 16:20 <beisner> and a belated action from prev topic...
 16:20 <beisner> #action smoser and beisner to coordinate on bug 1488453 (hacluster failing V/W)
 16:20 * meetingology smoser and beisner to coordinate on bug 1488453 (hacluster failing V/W)
 16:20 <ubottu> bug 1488453 in openhpi (Ubuntu) "Package postinst always fail on first install when using systemd" [High,Confirmed] https://launchpad.net/bugs/1488453
 16:20 <apw> caribou, i suspect a kdump specific hook for the kernel postinst which uses like /boot/kdump/ to maek skiny ones
 16:21 <caribou> apw: will look into that
 16:21 <apw> caribou, sounds good
 16:21 <arges> need crashkernel=auto
 16:22 <beisner> thanks.  anything else for the kernel team?
 16:22 <beisner> #topic Upcoming Call For Papers
 16:23 <beisner> proposals, anyone?
 16:23 <beisner> which really leads to:
 16:23 <beisner> #topic Ubuntu Server Team Events
 16:23 <beisner> events, anyone?
 16:24 <beisner> openstack developer summit tokyo is in ~1mo.   several people will be there representing various interests.
 16:24 <beisner> #topic Open Discussion
 16:24 <beisner> shall we mention the python 2 wily thing?
 16:25 <beisner> i imagine that will be impactful to many juju charms, and other non-juju use cases.
 16:25 <beisner> openstack charms have workarounds in-flight in the dev/next branches.
 16:26 <beisner> smoser, other thoughts and/or summary of the status and happenings on that?
 16:27 <smoser> sure.
 16:27 <smoser> python2 is gone from default ubuntu server installs
 16:28 <smoser> that includes maas installs, server ISO installs and cloud images
 16:28 <smoser> you can very easily 'apt-get install python2' or any application that correctly depends on python2
 16:28 <beisner> ^ >= Wily, right?
 16:28 <smoser> correct.
 16:28 <beisner> thanks smoser
 16:29 <smoser> you'll see issues if you assumed /usr/bin/python
 16:29 <smoser> and further issues if you assumed 'import <something>' would work with that /usr/bin/python
 16:29 <smoser> this is a knonwn problem at this point with many charms and maas
 16:30 <smoser> (maas uses ephemeral images and assumes it can invoke /usr/bin/python)
 16:30 <smoser> so...
 16:30 <smoser> your opeiotns to address such thigns:
 16:30 <smoser> a.) use python3
 16:30 <smoser> b.) install python2
 16:30 <smoser> c.) use some sort of 'python2or3'
 16:31 <smoser> i started https://gist.github.com/smoser/8904199bb8f00a90dd04
 16:31 <smoser> which has just about no doc, and woudl only be very useful if it were installed in ubuntu images
 16:31 <smoser> but the idea woudl be that instead of '#!/usr/bin/python' or '#!/usr/bin/env python'
 16:31 <smoser> you could:
 16:31 <smoser> #!/usr/bin/env py2or3 -myaml
 16:32 <smoser> and this would select a python2 or 3 that had yaml available
 16:32 <smoser> not yet implemented is the -I2 or -I3 flags that would then cause install if nothing was found suitable
 16:33 <smoser> that would allow you do do:
 16:33 <smoser> #!/usr/bin/env py2or3 -myaml -I3
 16:33 <smoser> and if you had executed that as root, you'd not know anything other than your program ran as you expected (just a bit slow with 'apt-get install' in the middle)
 16:34 <smoser> anyway, thats what i have for that topic.
 16:34 <beisner> great, thanks smoser
 16:34 <smoser> thanks for raising that, beisner . i'm sure it will cause fun for people in the next months.
 16:34 <beisner> alright, so:  assume not.  define and install dependencies accordingly.   and/or follow the gist and consider it as an option.
 16:35 <beisner> i'm sure we'll be tracking that closely, thx again smoser
 16:35 <beisner> #topic Announce next meeting date, time and chair
 16:35 <beisner> same time same day same channel,  gaughen will be your host.
 16:35 <beisner> thank you all, have a great day!
 16:35 * gaughen crosses fingers!
 16:35 <gaughen> thanks beisner!
 16:35 <beisner> #endmeeting