[07:10] <koolhead11> hi all
[13:13] <alexy> newbie question (cant find in docs): confirmation emails to new users comes with url:http://46.x.x.51/wiki/Special:ConfirmEmail/369f4ed3c6933061ee59c1108e1ff685. How can i change 46... to domain name? it is registered and responding in dns.
[13:15] <alexy> seems no definition in LocalSettings.php responsible for this and this ip arriving automatically from server settings?
[13:17] <alexy> oh... wrong room. sorry.
[14:34] <koolhead11> kim0, :P
[16:38] <smoser> hallyn, quick question...
[16:38] <smoser> i'm looking at /etc/init/lxcmount.conf
[16:39] <hallyn> y
[16:39] <smoser> http://paste.ubuntu.com/596096/
[16:39] <smoser> how is 'container' defined ?
[16:40] <hallyn> 'container=libvirt' is placed in envp by libvirt
[16:40] <smoser> and then, second question, why does fstab.lxc have nothing in it ?
[16:40] <hallyn> bc lxc doesn't need upstart to mount anything
[16:41] <smoser> ok..
[16:42] <smoser> would one expect that /proc would be populated inside an lxc container?
[16:42] <hallyn> yes
[16:42] <hallyn> both lxc and libvirt do that for you
[16:43] <smoser> ok. so if you had an entry in fstab.lxc, for /proc, what would happen ?
[16:43] <hallyn> you'd presumably just get proc mounted twice
[16:43] <smoser> would init/mountall mount over it ? i would assume it would notice it was already mounted.
[16:43] <hallyn> it's possible that it would return an error, and boot would fail
[16:43] <smoser> it does handle that correctly when the kernel mounts /dev/ as a tmpfs
[16:44] <smoser> so it must check at leas that.
[16:44] <hallyn> ?
[16:44] <hallyn> why would it return error when mounting /dev as tmpfs?
[16:45] <hallyn> smoser: are you having a problem with the boot sequence?
[16:45] <hallyn> smoser: I was going to ask zul (when I finish some little things) how nova+lxc is going at the moment.
[16:46] <smoser> hallyn, i was saying that in /lib/init/fstab, there exists an entry for '/dev/' as a tmpfs
[16:46] <smoser> but in most cases, the kernel will have already mounted /dev as a tmpfs before upstart comes up
[16:47] <smoser> so it has to be checking to see to avoid duplicate mounts
[16:47] <smoser> yes, thats what i was looking at
[16:47] <hallyn> could be, would make sense
[16:47] <hallyn> easy enough to test in the proc case :)
[16:49] <zul> the problem is /var/run is not coming up before cloud-init is bring run so no netowking, so no contacting of the metadata server for the instance
[16:50] <hallyn> zul: can cloud-init just wait for mountall to finish before starting?
[16:50] <smoser> hallyn, if upstart behaves sanely, then my theory is that you should have basically the same thing in /lib/init/fstab in /lib/init/fstab.libvirt
[16:50] <smoser> *except* for the things that cause problems.
[16:51] <hallyn> smoser: your theory is flawed then, as the obvious experiment has already been done and failed
[16:52] <smoser> oh?
[16:52] <hallyn> smoser: the reason your theory is flawed, though, is bc you're not thinking about the namespaces
[16:52] <hallyn> upstart can avoid re-mounting /dev and /proc, bc they are mounted where it wnats them
[16:52] <hallyn> but a lot of the cruft in /lib/init/fstab is not mounted where upstart wants them in a container
[16:52] <hallyn> so it doesn't realize they are already mounted
[16:53] <smoser> example ?
[16:53] <hallyn> /dev/root  :)
[16:55] <smoser> i did say "except for things that cause problems"
[16:59] <hallyn> most of it is simply not appropriate for a container, or already being mounted anyway.  I don't see the value in tossing entries back in just because they say 'optional' and aren't even getting mounted on the host - just bc they are on a host's version of the file.
[17:01] <hallyn> here's a q, what does 'showthrough' mean as a mount option
[17:01]  * hallyn googles
[17:01] <hallyn> wow, that's a fascinating one
[18:37] <koolhead17> hi all
[18:44] <kim0> koolhead17: hey
[18:46] <koolhead17> supp kim0
[18:46] <kim0> hey how's it going
[18:47] <koolhead17> awesome. am loving it :P
[18:47] <kim0> haha :) enjoy
[18:48] <koolhead17> kim0: few of the bugs got fixed in latest revision
[18:49] <kim0> yeah :/
[18:49] <kim0> it's such a young product
[18:49] <kim0> but it's moving rapidly
[18:59] <koolhead17> i am just happy
[19:12] <kim0> hehe
[19:29] <koolhead17> kim0: which team handles infra of launcpad?
[19:30] <kim0> the launchpad team :)
[19:30] <kim0> #launchpad
[19:34] <koolhead17> ok cool. next time run to them
[20:49] <smoser> hallyn, around ?
[21:39] <semiosis> problem... create a new EC2 instance from the official maverick AMI (ami-cef405a7), run apt-get update & apt-get upgrade, and it results in the following error...
[21:40] <semiosis> Errors were encountered while processing: language-selector-common E: Sub-process /usr/bin/dpkg returned an error code (1)
[21:40] <semiosis> this gets in the way of, for example, cloud-config puppet bootstrapping, and other stuff as well i'm sure
[21:42] <semiosis> looks like an updated language-selector-common package release today
[22:07] <semiosis> never mind, i found this... https://bugs.launchpad.net/ubuntu/+source/language-selector/+bug/766534
[22:19] <hallyn> smoser: sorry, what's up?
[22:19] <smoser> i have to run, hallyn...
[22:19] <hallyn> k
[22:19] <hallyn> i'll be on late
[22:19] <smoser> http://paste.ubuntu.com/596245/
[22:19] <smoser> hallyn, ^
[22:20] <smoser> that is the diff of 'initctl' list when running under libvirt-lxc and ec2 at the point in which cloud-init-nonet runs (MOUNTED /)
[22:20] <smoser> our problem is that udev isn't running early enough
[22:20] <smoser> i had suspected tha tthat was due to virtual-filesystems not having been emitted
[22:21] <smoser> by mountall.
[22:21] <smoser> but i'm not sure.
[22:21] <smoser> i will be back later to debug
[22:23] <hallyn> smoser: interesting.  ok.
[22:36] <hallyn> smoser: actually i'd wager what is happening is that udev is just slower to start because all containers and the host see the udev events
[22:37] <hallyn> and there's nothing to do about that, apart from introducing device namespaces in the kernel