=== freeflying_away is now known as freeflying
=== CyberJacob is now known as CyberJacob|Away
[01:33] <bigjools> roaksoax: I am landing a change to the cluster worker that will require it to have bind privs on port 68.  I use authbind in the development environment but how do you want to approach this in packaging?
[01:35] <roaksoax> bigjools: im not home now(from the cell) but can we discuss this later?
[01:35] <roaksoax> binding to 68 might cause problems with otjet services
[01:35] <roaksoax> smoser ^^
[01:36] <roaksoax> other*
[01:36] <bigjools> roaksoax: it uses SO_REUSEADDR
[01:36] <bigjools> no problem discussing later
[01:36] <roaksoax> cool
[01:36] <roaksoax> ttyl
[01:37] <smoser> i'm on my way out. and i'd have to think about this.
=== Beret- is now known as Beret
[04:05] <roaksoax> bigjools: ok, so where's the branch, why is it needed, and what impliations do you think it will cause?
[04:52] <bigjools> roaksoax: it's to detect dhcp servers, it has to bind to source port 68.  end of.
[04:54] <roaksoax> bigjools: right, so what will bind to it?
[04:54] <bigjools> roaksoax: the cluster worker
[04:56] <roaksoax> bigjools: what other servicces use port68?
[04:56] <bigjools> roaksoax: it's the dhcp client source port
[04:56] <roaksoax> bootpc		68/tcp				# BOOTP client
[04:56] <roaksoax> bootpc		68/udp
[04:56] <bigjools> so I hope nothing
[04:56] <bigjools> but even if there is something it doesn't matter
[04:57] <bigjools> I have tested locally with dnsmasq running and it's fine
[04:57] <bigjools> so, how can you sort this out in packaging?
[04:57] <roaksoax> bigjools: "This packet identifies that a client is searching for an IP address. The packet uses UDP port 68 as it's source address for the client, since it does not have an IP address that refers back to the client."
[04:57] <bigjools> dude the branch has landed and it ain't gonna change
[04:58] <roaksoax> bigjools: i'd need more information that that really. It seems that it is the port used by a dhcp-server to discovery clients right? so what happens if you bind that port and DHCP is useless?
[04:58] <roaksoax> what happens if it create DHCP issues?
[04:58] <bigjools> no, it is not used by a dhcp server
[04:59] <bigjools> dhcp serves on port 67
[04:59] <roaksoax> bigjools: udp        0      0 0.0.0.0:68              0.0.0.0:*                           15106/dhclient
[04:59] <bigjools> that's the client
[04:59] <roaksoax> bigjools: so dhclient seems to bind to port 68
[04:59] <bigjools> yes, they all do
[04:59] <bigjools> that's why the cluster worker does it
[05:00] <roaksoax> bigjools: right, but have you tested this on a client that uses dhclient to obtain IP address?
[05:00] <bigjools> think about this
[05:00] <roaksoax> bigjools: note that I'm not against using the part, I just want to understand the implications of doing so
[05:00] <bigjools> why would your machine, which is running a dhcp server, also be running a dhclient?
[05:01] <roaksoax> bigjools: because mymachine obtains a DHCP from a router
[05:01] <bigjools> you can't do that you'd be running two dhcp servers
[05:01] <roaksoax> bigjools: my machine does not have a static IP address and DHCP's from another DHCP server
[05:01] <bigjools> so unless you configure them not to cross, it's stupid :)
[05:02] <bigjools> anyway I have tested this and it works fine even if you have a dhcp client running already
[05:02] <bigjools> it uses SO_REUSEADDR
[05:02] <bigjools> the point of the feature is to help idiots from shooting themselves in the foot by running more than one dhcp server
[05:04] <roaksoax> bigjools: yeah I understand that, I just want to make sure doing so doesn't coonflict with other operations mof the OS
[05:04] <roaksoax> if this is tested and doesn't then cool
[05:04] <bigjools> it won't
[05:04] <roaksoax> if it does, then sucks
[05:04] <roaksoax> as i said
[05:04] <roaksoax> I just want to understand the implications of doing so to make sure nothing will break
[05:04] <roaksoax> anyway
[05:04] <bigjools> it is very careful to use a transaction ID on the probe packet
[05:04] <bigjools> so won't clash
[05:04] <roaksoax> send me what you need for the packaging to email
[05:04] <roaksoax> i'm off now
[05:05] <bigjools> good night roaksoax
[05:05] <roaksoax> night
[05:05] <roaksoax> bigjools: is this a new daemon or what?
[05:05] <bigjools> roaksoax: no
[05:06] <bigjools> part of celery
[05:06] <roaksoax> bigjools: so then I don't think we will need packaging changes then
[05:06] <roaksoax> if it is being run by maas-region-celery
[05:06] <bigjools> does it run as root?
[05:06] <bigjools> if not we need changes to set up authbind
[05:07] <roaksoax> bigjools: it runs as maas user/pass
[05:07] <roaksoax> user/group
[05:07] <roaksoax> exec /usr/sbin/maas-region-celeryd --logfile=/var/log/maas/celery-region.log --schedule=/var/lib/maas/celerybeat-region-schedule --user=maas --group=maas
[05:08] <bigjools> so needs to be exec authbind --deep /usr/sbin/maas-reg.....
[05:08] <bigjools> after setting up /etc/authbind/byport/68
[05:08] <bigjools> or similar
[05:09] <roaksoax> bigjools: ok, please send me that over email, my eyes will explode soon -> ved
[05:09] <roaksoax> bed
[05:09] <bigjools> ok :)
[07:27] <jtv> bigjools: shall I update the daily PPA to include the DHCP-probing code?
=== CyberJacob|Away is now known as CyberJacob
[07:38] <bigjools> jtv: no it won't work yet, needs packaging changes
[07:41] <jtv> That's unfortunate because my dhcp-checking branch for maas-test requires it.
[07:42] <bigjools> jtv: well go ahead anyway it'll just traceback in the celery log
[07:42] <bigjools> jtv: hit rebuild on the recipe
[07:42] <jtv> Shouldn't I land an update to the changelog first?
[07:42] <bigjools> no, daily build will DTRT
[07:43] <bigjools> recipes are fkin awesome
[07:43] <jtv> But we already have a build from yesterday in there, and it uses an old revision of trunk...
[07:43] <bigjools> when you hit rebuild it will pull latest trunk
[07:43] <jtv> Ah!
[07:43] <jtv> That is nice.
[07:43] <jtv> I'm all motivated to go back to work on LP.  :)
[07:43] <bigjools> lol
[07:46] <ticking> Say, does somebody know if MAAS supports non pxe hardware? e.g. mac pros
[07:46] <bigjools> ticking: sort of
[07:47] <bigjools> provided it can tftp to the right place it'll get boot resources
[07:47] <ticking> but the avahi boot image is unsuported right?
[07:47] <bigjools> yeah that's getting junked entirely in 14.04
[07:48] <ticking> so there is no standard way of using tftp anymore?
[07:49] <bigjools> define standard
[07:50] <ticking> boot cd/stick, configure, connect, be happy ^^
[07:50] <bigjools> normally the machine requests pxeconfig first, but other hardware like arm that doesn't pxe will request a specific tftp path
[07:50] <ticking> ah I see, so the hardware does the tftp
[07:50] <bigjools> tftp is nothing to do with avahi
[07:51] <bigjools> avahi was just a way for the installer cd to discover the maas server
[07:51] <bigjools> but in the real world nobody is going to go around sticking CDs in hundreds of racks
[07:52] <ticking> ah I see, the wiki is worded as if there was a way to load the boot image with the help of some provided base system
[07:53] <bigjools> the general idea is that machines will be discovered from the maas server using ipmi
[07:54] <bigjools> it'll then attempt to power them up using ipmi and they'll hunt for a dhcp server which directs a pxe boot
[07:54] <ticking> yeah, I have a ton of decent mac pros lying around, being able to configure them quickly and painlessly would be nice
[07:54] <ticking> but they only support wake on lan, no pxe no tftp boot
[07:54] <bigjools> WoL is nasty
[07:54] <bigjools> you have no way of powering off
[07:56] <ticking> for now I'm only concerned with at least booting them ^^
[07:57] <bigjools> I can't remember offhand how to direct machines to tftp from the right place when not using pxe
[07:57] <ticking> Interestingly it seems that mac pros do indeed support tftp ^^
[07:57] <ticking> so thanks for the pointer
[07:58] <bigjools> are they power?
[07:58] <bigjools> because maas doesn't know about power :)
[07:59] <jtv> PowerPC, that is.
[07:59] <ticking> hrhr no
[07:59] <ticking> intel
[07:59] <ticking> x64
[08:02] <ticking_> lol, liiks like I
[08:02] <ticking_> looks like I killed my switch with the netboot ^^
[08:17] <tom___> hi, what is the minimum # of nodes required to deploy a MAAS server?
[08:17] <jtv> Absolute minimum?  One node, plus one server.
[08:18] <tom___> can the node be a VM? (Virtual Box VM)
[08:18] <jtv> I think it can, but MAAS won't create it for you.
[08:19] <tom___> I want to learn how to setup Openstack with Ubuntu, and don't have many machines.
[08:19] <tom___> I can create the VB VM, and add it to MAAS?
[08:19] <tom___> ok, I get it
[08:19] <jtv> I don't know if virtualbox can simulate a BMC though.
[08:19] <tom___> what is a BMC?
[08:20] <jtv> Baseboard management controller.  It's what lets MAAS reboot a node remotely.
[08:20] <tom___> No, VB probably not support that
[08:21] <tom___> I have some old PC, is BMC a requirement for the hardware?
[08:21] <jtv> Effectively, yes.
[08:21] <jtv> You might get by with manual handling of the power switch, but that's not going to be as convenient.
[08:22] <jtv> I know there are virtual machine managers out there that do support it though.
[08:22] <tom___> does MAAS power cycle the nodes often? Or only when it do the initial OS install?
[08:22] <tom___> which VM manager?
[08:23] <jtv> Might have been KVM...
[08:23] <jtv> MAAS reboots a machine as part of commissioning, once to install it, and then once again at the end of installation IIRC.
=== jam1 is now known as jam
[08:24] <tom___> so I can probably try to manually reboot the box.
[08:24] <jtv> I think so.  Once the machine is deployed, it's basically yours to boot at will.
[08:25] <tom___> after installation, there's no need to physically reboot the node
[08:25] <jtv> Right.
[08:27] <tom___> thanks
[08:27] <jtv> I'd be curious to know how it works out!
[08:29] <tom___> will let you know
[08:34] <jtv> Thanks.
=== CyberJacob is now known as CyberJacob|Away
[09:05] <tom___> @jtv, http://marcoceppi.com/2012/05/juju-maas-virtualbox/
[09:06] <tom___> someone managed to get maas to work with VirtualBox.
[09:06] <jtv> \o/
[09:06] <jtv> Thanks for that pointer.
[09:28] <gmb> rvba: I'm seeing this this morning when I run m-t on my Saucy machine. Any idea WTF is going on? http://paste.ubuntu.com/6518779/
[09:30] <jtv> gmb: any chance that you're running an older uvtool?  I can still create VMs with uvtool directly.
[09:31] <gmb> jtv: No, this is after an apt-get update.
[09:40] <jtv> gmb: I was just wondering if maybe you weren't using the right PPA.
[09:42] <jtv> gmb: for comparison, I'm running uvtool 0~bzr66~ubuntu13.10.1
[09:42] <gmb> jtv: Good thinking. I'll check.
=== wgrant_ is now known as wgrant
[11:32] <rbasak> gmb: I see: "qemu: at most 2047 MB RAM can be simulated" in that pastebin. How much system RAM do you have on that machine?
[12:45] <gmb> rbasak: 4GB. And it was working last week.
[12:45] <rbasak> gmb: which release are you on?
[12:45] <rbasak> gmb: (of Ubuntu)
[12:45] <gmb> Saucy
[12:46] <rbasak> Ah. I see that you already said, sorry.
[12:47] <rbasak> gmb: I'm not sure what's going on there, but it seems to be an issue with qemu/kvm or your system, not libvirt or uvtool, if that helps.
[12:47] <gmb> rbasak: It helps me narrow it down, certainly. I'll try poking at a few things. Thanks.
[12:47] <rbasak> gmb: perhaps try lowering the --memory option and see if that helps?
[12:47] <gmb> That was going to be the first thing I poked :)
[12:48] <gmb> rbasak: Yeah, that works. --memory 2047 is _fine_
[12:48] <gmb> (I hadn't noticed that option until just now)
[12:48] <rbasak> gmb: there's no i386 vs. amd64 thing going on here, is there?
[12:49] <rbasak> 2048 is a magic boundary point for some things I think.
[12:49] <rbasak> Ah
[12:49] <rbasak> The line says arch=i386
[12:49] <rbasak> Hmm
[12:49] <rbasak> uvtool doesn't actually care about that. It never specifies the required arch to libvirt, so that's just the image arch, rather than the guest machine arch.
[12:49] <rbasak> I wonder if that's a bug.
[12:50] <rbasak> gmb: are you on an i386 or amd64 kernel?
[12:51] <gmb> rbasak: uname says i686
[12:52] <rbasak> gmb, rvba: I think http://bazaar.launchpad.net/~maas-maintainers/maas-test/trunk/revision/81 introduced this, but only on i386 machines, like gmb's.
[12:52] <rbasak> You're asking for --memory 2048, but gmb is getting an i386 guest, which doesn't support that.
[12:53] <gmb> rbasak: Yeah, I just came to the same conclusion. I'll revise that value down by one.
[12:53] <rbasak> Currently uvtool has no provision for setting guest architecture, except through --template. I wonder if that needs to be addressed.
[12:54] <rbasak> gmb, rvba: it might be worth considering and documenting a minimum memory requirement for maas-test.
[12:54] <gmb> Right.
[12:56] <rbasak> Other related thoughts: perhaps it's because the guest doesn't support pae by default, which is uvtool bug 1256658.
[12:56] <ubot5> bug 1256658 in uvtool "Default guest instance misses some commonly expected features on Intel architectures" [Undecided,New] https://launchpad.net/bugs/1256658
[12:56] <rbasak> (rather than an inherent i386 limitation)
[12:56] <rbasak> gmb: I'd be interested to know if it works if you use a template that is patched according to comment 1 in that bug.
[12:57] <rbasak> (for memory >= 2048)
[12:58] <gmb> rbasak: I'll check in a second. bear with me.
[12:58] <rbasak> Thanks!
[13:04] <gmb> rbasak: Nope, still get the memory error with that snippet in place.
[13:05] <rbasak> gmb: just to check, did you patch its use in maas-test, rather than the (unused) system one?
[13:05] <gmb> rbasak: Yes, I patched the template we use in maastest/kvmfixture.py:383 (KVM_TEMPLATE).
[13:06] <matsubara> gmb, allenap: are you guys using the MAAS lab? I see a running instance there
[13:06] <allenap> matsubara: Not me.
[13:07] <gmb> matsubara: Not me.
[13:07] <rbasak> gmb: OK, thanks. I'm not sure what's going on there. For now, I think --memory=2047 is probably sensible then.
[13:08] <gmb> rbasak: Cool, thanks for helping me out.
[13:08] <rbasak> np. Good to know what sorts of issues people will hit.
[13:08] <rbasak> I'd never considered the host/guest arch selection before.
[13:37] <ticking> say, what does adding a node via the ubuntu install disk really do? there seems no informatiuon whatsoever on this online
[13:40] <ticking> does it require ubuntu 12? lan boot enabled? wake on lan enabled?
[13:42] <ticking> also what happened to maas-import-isos?
[13:42] <gmb> ticking: IIRC it allows you to boot up a node using the Ubuntu CD and then have MAAS provision that node; I'm not clear on the details of how that works, but the plan is to drop it for 14.04.
[13:43] <gmb> ticking: I believe -import-isos went away and we now have maas-import-ephemerals / -import-pxe-files. Don't quote me on that, though; -import-isos was before my time.
[13:43] <ticking> gmb, ah thanks, it seems broken already with 13
[13:43] <gmb> ticking: 13.what?
[13:44] <rbasak> maas-import-pxe-files calls maas-import-ephemerals by default, unless that changed recently.
[13:44] <rbasak> You can trigger a simple run from the web UI as well I think.
[13:44] <ticking> 13.10
[13:44] <ticking> rbasak, cool thanks :)
[13:44] <rbasak> ticking: how is it broken?
[13:45] <ticking> rbasak, node shuts down, but does not register with maas
[13:46] <rbasak> Hmm. Not sure about that. Grabbing console output might help you debug the cause for that.
[13:46] <ticking> rbasak, yeah I would if it didn't autoshutdown
[13:48] <rbasak> You can modify the cloud-init userdata for the enlistment case to change that. I can't remember the details though. Somewhere in /etc/maas/templates probably.
[13:50] <ticking> rbasak, I'll try that thanks
[14:35] <ticking> I give up ^^ using pxe just makes sense
[14:41] <roaksoax> rbasak: ping
[14:41] <roaksoax> err
[14:42] <roaksoax> rvba: ping
[14:42] <gmb> roaksoax: He's unavailable today.
[14:42] <roaksoax> gmb: thanks!
[14:42]  * gmb notes that he has the Good Ship MAAS pretty much to himself this afternoon.
[14:43] <gmb> Now there's a disturbing idea.
[14:43] <mgz> it's okay, you can't sink it in an afternoon
[14:43] <gmb> mgz: No, but I can start rewriting it in Go.
[14:43] <mgz> :D
[15:16] <ticking> gmb, you have my sword, and my go!
[15:17] <gmb> :)
=== jpds_ is now known as jpds
=== teknico_ is now known as teknico
=== CyberJacob|Away is now known as CyberJacob
=== CyberJacob is now known as CyberJacob|Away