[02:02] <bashgeek> hi
[02:02] <bashgeek> is there any installation guide to install ubuntu on a remote system via. rescue console?
[02:47] <troy> good day folks
[08:22] <ubijtsa2> fabbione: no worries..
[08:22] <fabbione> morning
[08:22] <fabbione> i am not worried :)
[08:22] <fabbione> what' s up?
[08:23] <ubijtsa2> I was going to ask you about setting a hard stack limit in /etc/security/limits.conf
[08:24] <ubijtsa2> testing it last night though showed there being no difference in memory usage on a freshly booted system
[08:24] <fabbione> hmmm i am not too happy about changing these defaults
[08:24] <ubijtsa2> it had been suggested to me it could make as much difference as 100MB on a full Gnome desktop..
[08:25] <ubijtsa2> the default of the system seems to be allocating 8MB of stack, and lowering that to 512kB was the suggestion
[08:26] <ubijtsa2> as it turns out, it probably will not make that much difference.. hence the 'no worries' comment :)
[08:26] <fabbione> nope
[08:26] <fabbione> that's just wrong
[08:27] <fabbione> that's not the default alloc on the stack.
[08:27] <fabbione> it's max amount of stack a user can allocate
[08:27] <fabbione> if you hit the limit, the process is killed
[08:28] <fabbione> so something like that will just break in some corner cases
[08:28] <fabbione> = BAD
[08:28] <ubijtsa2> Mmhmm.. I wanted to ask you about it last night, but while rebooting I encountered oddities with zeroconf
[08:28] <ubijtsa2> hence why I was not back on IRC when you replied
[08:30] <ubijtsa2> still, half a meg of stack should be more than adequate..
[08:31] <fabbione> -> REJECTED
[08:31] <fabbione> it breaks stuff in corner cases
[08:31] <fabbione> and you don't want that
[08:32] <fabbione> 8MB is more than fine
[08:32] <fabbione> and again, it is a limit
[08:32] <ubijtsa2> I understand..
[08:32] <fabbione> it's not allocated by default
[08:37] <neuralis> fabbione: long time no see
[08:37] <neuralis> fabbione: how are things?
[08:38] <fabbione> hey neuralis
[08:38] <fabbione> i am fine and you?
[08:46] <neuralis> pretty good, moved back to cambridge a week ago, horribly busy
[08:46] <fabbione> i believe that
[08:47] <neuralis> how's server-candy coming along?
[08:47] <fabbione> we are at 2/3 more or less
[08:47] <neuralis> nice!
[08:47] <fabbione> there are things that needs to be done
[08:47] <fabbione> but we are getting there
[08:48] <fabbione> we won't manage to get /etc in RCS
[08:48] <fabbione> but otherwise we are okish
[08:48] <neuralis> hmm, too complicated or other problems?
[08:48] <fabbione> mainly the changes in bzr
[08:49] <fabbione> bzr is changing too fast to be good for 5 years
[08:49] <fabbione> and i didn't want the overhead of other RCS
[08:49] <neuralis> yeah, good decision
[08:49] <fabbione> there are also the 3rdy part tools that need packaging or something
[08:49] <fabbione> assuming we can redistribute them
[08:49] <fabbione> but that's like a couple of days of work
[08:50] <neuralis> although, for just versioning /etc, bzr 0.7 would probably be just fine
[08:50] <fabbione> my point is that the bzr backend is changing fast
[08:50] <fabbione> so let say we ship 0.7 in dapper
[08:50] <fabbione> it might not be compatible with dapper+1
[08:50] <fabbione> figure in 5 years
[08:50] <fabbione> so you might not be able to use the repos for cross merging
[08:51] <fabbione> and that's one of the most interesting features about having all /etc in RCS
[08:51] <neuralis> right.
[08:51] <fabbione> cherry-pick this change from the test-server... boom
[08:51] <neuralis> well, bzr should stabilize quite a bit by dapper+1, so hopefully we can do it then.
[08:52] <fabbione> did you hear anything from the cluster guys?
[08:52] <neuralis> nope.
[08:52] <fabbione> i guess they won't match our deadlines
[08:53] <fabbione> oh well.. we will work it out for dapper+1 hopefully
[08:53] <neuralis> it sounds like they'll still put out openssi packages for dapper, just not through ubuntu channels
[08:53] <fabbione> that's sick.. but ok
[08:53] <fabbione> if they prefer that way
[08:53] <neuralis> they don't, but there just wasn't enouh time to meet UVF
[08:53] <neuralis> *enough
[08:53] <fabbione> well they need to meet Feature Freeze
[08:54] <fabbione> that's in 13 days
[08:54] <ajmitch> bzr guys are hoping to have 0.8 in dapper, with the understanding that there be some stability in branch formats & API (though probably not for 5 years)
[08:54] <neuralis> ajmitch: they're aiming for 6-12 months.
[08:54] <ajmitch> not nearly enough for a 5-year distro support
[08:54] <neuralis> fabbione: to be honest, i think it's better for ubuntu not to have it in officially for dapper. it's not stable enough.
[08:54] <fabbione> neuralis: ok
[08:55] <neuralis> fabbione: so let them put out packages separately and get testing, and we can look at official inclusion for dapper+1
[08:55] <fabbione> neuralis: right, but we will land in the exact same problem
[08:55] <fabbione> dapper+1 won't have .15
[08:55] <fabbione> probably .18 or something
[08:56] <fabbione> if the openssi guys don't start tracking recent kernels, it will be the same as Xen for hoary/breezy/dapper...
[08:56] <fabbione> anyway i need to reboot my ws
[08:56] <fabbione> brb
[08:56] <neuralis> ok
[09:06] <fabbione> re
[09:13] <neuralis> fabbione: around feature freeze, i'd like to chat with you briefly about everything that went into server, to make sure i don't forget anything
[09:14] <fabbione> sure
[09:15] <fabbione> assuming i can remember all of it :)
[09:15] <fabbione> but i think we should chat about it today
[09:15] <fabbione> so if there is something i did overlook
[09:15] <fabbione> there might be time to get it done
[09:15] <neuralis> sure
[09:15] <neuralis> would you like to do it now or later?
[09:15] <fabbione> i just need about 20 minutes to finish something
[09:16] <neuralis> sure. ping me when you're back.
[09:16] <fabbione> yup
[09:42] <fabbione> re
[09:42] <fabbione> neuralis: still around?
[09:44] <neuralis> fabbione: yep
[09:45] <fabbione> ok where do you want to start?
[09:45] <neuralis> i just went over the list of all dapper specs
[09:46] <neuralis> relevant to servers are HardwareTestingCatalog, CommunityServerHardwareTesting, KernelServerRoadmap, TestingServerHardware, ServerCandy, UbuntuClusters
[09:46] <neuralis> we should probably talk only about the last two
[09:46] <fabbione> KernelServerRoadmap is implemented
[09:46] <fabbione> in terms that we have the kernels
[09:46] <fabbione> we need to make them the defatuls for server CD
[09:47] <fabbione> and probably do some more config tuning
[09:47] <fabbione> nothing really fancy is left there
[09:47] <neuralis> right, i just want to find out specifically what was changed in them, although i suppose i can just look at the .config
[09:47] <fabbione> basically -server doesn't have PREEMPT, HZ=100
[09:47] <fabbione> and a bunch of modules have been removed from -desktop
[09:48] <neuralis> sound, DRM removed, i imagine
[09:48] <neuralis> eah
[09:48] <neuralis> *yeah
[09:48] <fabbione> like for example OCFS2 and GFS
[09:48] <fabbione> no, sound is there
[09:48] <fabbione> you might want a streaming server "use case"
[09:48] <fabbione> but clearly you don't need OCFS2 on your workstation
[09:48] <neuralis> right.
[09:49] <fabbione> -server on i386 is only 686+SMP
[09:49] <fabbione> it has basic numa support
[09:49] <fabbione> -server-bigiron is pushed to the limit of 64CPU or something
[09:49] <fabbione> with bignuma support
[09:49] <neuralis> got it.
[09:49] <fabbione> Ben's definition of -server-bigiron was really good
[09:50] <neuralis> the one posted to -devel? i remember reading it :)
[09:50] <fabbione> yeah that one
[09:50] <neuralis> okay. so that gets rid of kernel, and i know what's been going on with the three server specs, so let's talk about server-candy and ubuntu-clusters.
[09:51] <fabbione> yup
[09:51] <fabbione> for Cluster i only managed to keep GFS and OCFS2 updated to a decent level
[09:51] <neuralis> okay. slurm didn't make it in due to licencing issues, correct?
[09:52] <fabbione> slurm is GPL
[09:52] <fabbione> but it links with ssl
[09:52] <neuralis> but links against openssl
[09:52] <neuralis> right
[09:52] <fabbione> and i never got around to ask all upstreams for permissions
[09:52] <fabbione> or try to port it to gnutls
[09:53] <neuralis> i think asking for permission is impractical; probably too many contributors
[09:53] <maswan> how about torque then?
[09:53] <fabbione> neuralis: i agree
[09:53] <maswan> slurm seems to have less licensing issues though, just a gnutls port..
[09:53] <fabbione> neuralis: there are also tons of libs that slurm uses.. they have the same issue
[09:54] <maswan> I got rather confused trying to read the torque license
[09:54] <fabbione> maswan: i don't remember testing torque.. neuralis did you?
[09:54] <neuralis> fabbione: no, there were reasons why we didn't look at it
[09:54] <fabbione> i don't remember tbh
[09:55] <neuralis> fabbione: i think it's very non-free
[09:55] <fabbione> ok
[09:55] <maswan> neuralis: I'm not so sure, acutally. There are a bunch of non-free clauses, but they were time-limited and expired in 2002 or something like that.
[09:56] <neuralis> maswan: i'll take a closer look, but i doubt we can do this in time for dapper.
[09:57] <neuralis> maswan: also, slurm seems to be a much more accepted solution, so i'd really rather that we get that in.
[09:57] <neuralis> maswan: the people who really need a resource manager on dapper are few enough that they probably don't mind deploying one by hand.
[09:58] <neuralis> fabbione: let's continue
[09:58] <fabbione> yup
[09:58] <neuralis> fabbione: drbd, ganglia, lvs?
[09:58] <fabbione> we can look at ganglia and lvs
[09:58] <fabbione> that's just question of promoting them to main
[09:59] <neuralis> right
[09:59] <fabbione> for drdb.. dunno.. we have plenty of these solutions already
[09:59] <neuralis> hmm. examples?
[09:59] <fabbione> aoe, gnbd, nbd...
[10:00] <fabbione> is there something really special about drdb that others don't have?
[10:01] <neuralis> nbd just lets you use a remote disk locally. isn't that correct?
[10:01] <fabbione> yes
[10:01] <fabbione> like aoe or gnbd
[10:02] <neuralis> fabbione: right. that's not what drbd is for.
[10:02] <fabbione> what does drdb does in short
[10:02] <fabbione> ?
[10:02] <neuralis> fabbione: drbd is network raid1. it gives you actual drive replication over the network.
[10:02] <neuralis> in realtime.
[10:03] <fabbione> ok
[10:03] <fabbione> than we want it
[10:03] <fabbione> is the code stable?
[10:03] <neuralis> it's not changing much, and it works solidly in heavy production.
[10:04] <fabbione> ok
[10:04] <fabbione> do you have an url handy?
[10:04] <neuralis> there is a kernel module component, obviously. is that a problem?
[10:04] <neuralis> http://drbd.org
[10:04] <fabbione> i might as well get it done today
[10:04] <fabbione> no
[10:04] <fabbione> well .. it depends of course on how intrusive this thing is
[10:05] <neuralis> it's relatively isolated, i believe.
[10:05] <fabbione> i will check
[10:05] <fabbione> now i am almost a git guru :)
[10:05] <neuralis> :-D
[10:06] <neuralis> it should, in theory, apply cleanly to .15.
[10:06] <fabbione> yeah
[10:06] <fabbione> we need to see if it works even if applied :)
[10:06] <neuralis> right.
[10:07] <fabbione> ok next..
[10:07] <fabbione> i guess there is no more for Cluster
[10:08] <neuralis> okay, will you pursue the promotion of keepalived, ipvsadm, ganglia, drbd0.7-utils to main?
[10:09] <fabbione> do we need keepalived?
[10:09] <fabbione> we didn't mention it in the spec
[10:09] <neuralis> fabbione: yes, we did; it's part of LVS
[10:09] <fabbione> oh right
[10:09] <fabbione> i missed the ()
[10:09] <neuralis> np
[10:10] <fabbione> i think i can manage to ask for promotion..
[10:10] <fabbione> i am sort of utterly overloaded
[10:10] <neuralis> do promotion reports need to be filed, or is it just a matter of asking?
[10:11] <fabbione> we need to fill the forms
[10:12] <neuralis> by when?
[10:12] <fabbione> there is no real deadline for it
[10:12] <fabbione> but it would be better if we can at least test the packages before we do so
[10:13] <neuralis> right. i'm almost totally unavailable until march; is there anyone else on the server team we can get to do the reports?
[10:13] <fabbione> <-
[10:14] <fabbione> or infinity
[10:14] <fabbione> well actually
[10:14] <fabbione> everybody can do the report
[10:15] <fabbione> but it would be better if that somebody is a known source and could test the pkgs as well
[10:15] <fabbione> it will spare pitti the time to review it again
[10:15] <neuralis> why don't we get one or two of the 12 ubuntu-server guys to write the reports, and you or infinity can test the packages
[10:16] <fabbione> we can try.. do you want to write a mail to -server asking for it?
[10:16] <neuralis> (have most of the ubuntu-server guys actually done something for ubuntu server? writing server specs or doing some actual ubuntu-server work should be a prerequisite for joining, i think.)
[10:16] <neuralis> fabbione: yes, i'll take care of it. if we don't hear back in a few days, i'll get back in touch with you about it.
[10:17] <fabbione> ok
[10:17] <neuralis> ok, shall we move on to server-candy?
[10:20] <fabbione> yup
[10:21] <neuralis> server test suite (really burn-in suite) on the cd. i think benc is assigned to work on this. do you know if there's been progress?
[10:21] <fabbione> no progress that i know of
[10:21] <fabbione> i think it was assigned to somebody else...
[10:21] <fabbione> anyway
[10:21] <fabbione> i doubt that will ever happen
[10:21] <neuralis> why's that?
[10:22] <fabbione> because i haven't seen progress so far
[10:22] <fabbione> and there isn't much time left for it
[10:22] <maswan> neuralis: Sure. slurm also seems much cleaner, torque has lots of cruft.
[10:23] <neuralis> maswan: yes.
[10:23] <fabbione> Third party software inclusion is like i said above
[10:24] <fabbione> we got a list that needs investigation
[10:24] <fabbione> together with mdy
[10:24] <fabbione> and packaging
[10:24] <neuralis> fabbione: hm. well, if we can include stress and iperf on the cd, writing a totally simple script to run them isn't a big deal.
[10:24] <neuralis> we can then build a real interface for dapper+1.
[10:24] <fabbione> neuralis: are they in main or universe?
[10:25] <neuralis> universe, we haven't needed them in main before.
[10:25] <fabbione> hmm ok
[10:25] <fabbione> that means that the machine can be stress tested only after installation
[10:26] <fabbione> ok let's keep this as a point..
[10:26] <neuralis> they're both tiny packages; do you think it'd be a problem to promote them to main?
[10:26] <fabbione> i don't think that's an issue
[10:26] <fabbione> i am more thinking of: "Hey i installed -server and the stress tools crash my box... wtf"
[10:27] <fabbione> it would be more useful to be able to test the box before
[10:27] <fabbione> like for instance.. from the live CD
[10:27] <neuralis> we were talking about having this on the -server install cd, no?
[10:27] <fabbione> yes
[10:27] <fabbione> we can ship them
[10:27] <neuralis> you should be able to hit F<something> on the install screen to drop into shell and launch a script that runs the burn-in suite
[10:28] <fabbione> yes but to run something that's in a .deb you need to install it first
[10:28] <fabbione> in d-i you need the udeb
[10:28] <fabbione> that's probably a day of work to get it done
[10:28] <neuralis> can we get that in for dapper?
[10:29] <fabbione> i dunno.. i don't think i will have the time
[10:29] <neuralis> sorry, let me just make sure i'm understanding this right
[10:29] <fabbione> sure..
[10:29] <neuralis> afaik, we already ship a recovery mode on the cd that drops us into the shell
[10:29] <fabbione> yes
[10:30] <neuralis> if we provide stress and iperf as simple binaries available from that shell, problem solved, no?
[10:30] <fabbione> but that assumes that your system is already installed with ubuntu
[10:30] <fabbione> my understanding was that the test suite should run before
[10:30] <neuralis> ah!
[10:30] <neuralis> i didn't know the recovery mode required an ubuntu installation; that's not how the debian cds work, i believe
[10:30] <fabbione> it's the same infrastructure
[10:30] <fabbione> well
[10:30] <fabbione> hold on
[10:31] <neuralis> sure.
[10:31] <fabbione> the recovery mode is able to mount /
[10:31] <fabbione> it doesn't check if it is Debian or Ubuntu or RedHat
[10:31] <fabbione> my problem is to ship the binaries in the rescue mode
[10:31] <maswan> but you can also get a shell without recovery mode, just a plain busybox shell without any mounted /
[10:31] <fabbione> maswan: that too
[10:32] <fabbione> that's why i am mentioning shipping the binaries in rescue mode
[10:32] <fabbione> they need to be available in d-i
[10:32] <neuralis> fabbione: okay, now we're on the same page. should i e-mail infinity or benc and see if they have the time to roll them into the appropriate udeb?
[10:32] <fabbione> works for me
[10:33] <fabbione> whatever doesn't involve me to add stuff to my TODO list is OK
[10:33] <neuralis> :) let's continue - 3rd party /vendor software inclusion. you have the list, how much do you think will get done?
[10:34] <fabbione> it depends from the licence of this stuff
[10:34] <fabbione> and how much mdy can convince vendors to allow us to redistribute
[10:34] <neuralis> okay. mdy is working on that, i assume? when do we expect to know?
[10:35] <fabbione> no idea
[10:35] <fabbione> he is in Japan or somewhere around there
[10:36] <neuralis> ah. okay, i'll ask about it again closer to the end of the month, or e-mail him.
[10:36] <fabbione> ok
[10:36] <fabbione> point him to the page on the wiki
[10:36] <fabbione> i am pretty sure i told him
[10:36] <neuralis> is there a separate page other than ServerCandy?
[10:36] <neuralis> yes, found it
[10:36] <fabbione> https://wiki.ubuntu.com/ServerExtApps
[10:37] <neuralis> ok, moving on, central snakeoil stuff was worked on during the distrosprint, how far did we get there?
[10:37] <fabbione> we do have the basic ssl-cert infrastructure
[10:37] <fabbione> i already migrated a bunch of servers
[10:37] <fabbione> there are a few left
[10:37] <fabbione> that should be finished by end of next week
[10:37] <fabbione> infinity is to cleanup ssl-cert to be nicer
[10:38] <neuralis> sounds good. i'll ask again about details in ~10 days.
[10:38] <neuralis> md5 checker: still blocking on elmo/admins?
[10:39] <fabbione> yes
[10:39] <fabbione> the code is there and i tested it locally
[10:39] <fabbione> works for me
[10:39] <fabbione> that's all i know
[10:40] <fabbione>  /etc we already discussed
[10:40] <neuralis> should i ping the admins, and if so, who specifically?
[10:40] <fabbione> nah
[10:40] <fabbione> i am on their necks almost every day
[10:40] <fabbione> so is mdz
[10:40] <neuralis> ok, sounds good
[10:41] <neuralis> i think that's all. did we miss anything?
[10:41] <fabbione> so i think that generally we look good
[10:41] <neuralis> yes, we're in very good shape.
[10:41] <fabbione> seed management, but that's something that needs to be done step by step
[10:41] <fabbione> and we already discussed most of it already
[10:41] <fabbione> there is stuff i want to kick out of server cd
[10:41] <fabbione> and i am waiting for Kamion to merge the -server seeds into the standard branch
[10:42] <neuralis> right
[10:42] <fabbione> and that's about it i think
[10:43] <neuralis> great. thanks for your time! i'll send out the e-mails we talked about and follow up on loose ends later.
[10:43] <fabbione> perfect
[10:43] <fabbione> thanks to you
[10:44] <neuralis> sure. one final question -- are we planning to include the md5 checker in a special mode on the server cd? e.g. do you have an udeb ready, or are we taking a different approach?
[10:45] <fabbione> it's already integrated into rescue mode
[10:45] <neuralis> rock.
[10:45] <neuralis> okay, i have everything i need, and i'll talk to you soon. cheers.
[10:46] <neuralis> (4:45AM here, time to get some sleep.)
[10:46] <fabbione> night :)