[04:28] <roaksoax> bigjools: thoughts? http://pastebin.ubuntu.com/6952628/
[04:29] <bigjools> roaksoax: you probably have the system python package installed
[04:29] <bigjools> the wrong one I mean
[04:30] <roaksoax> bigjools: yeah, a higher version that the one requireD: http://paste.ubuntu.com/6952634/
[04:34] <roaksoax> bigjools: ok, it seems a information issue. I didn't have daemontools installed and it complained about python-amqplib it seems
[04:34] <bigjools> roaksoax:  which branch is this?  amqplib is not in trunk
[04:35] <roaksoax> bigjools: this is trusty trunk on saucy
[04:35] <bigjools> oh it won't work on saucy
[04:35] <roaksoax> bigjools: yeah can see that now
[04:35] <bigjools> :)
[04:35] <roaksoax> bigjools: anyway, I guess I'll fix the test in question tomorrow then
[04:35] <roaksoax> bigjools: anyway, ttyl!
[04:36] <bigjools> roaksoax: cheers!
[04:38] <jtv> roaksoax: I'm just landing a UI for showing the commissioning results that we have in the database.
[04:39] <jtv> It's not great, but I couldn't take the lack of visibility any more.  :)
[04:39] <jtv> Look for a link at the bottom of a node's details page.
[05:28] <jtv> I do wish we could link from documentation straight to specific methods in the API documentation.
[05:35] <jtv> bigjools: last planned branch for the Advanced Networking lane is up for review.
[05:35] <bigjools> jtv: sweet
[05:35] <bigjools> jtv: api docs need anchors, you mean?
[05:36] <jtv> Yup.
[05:36] <jtv> And/or a big notice about what those anchors are.  :)
[05:40] <bigjools> jtv: "connecting a node and a network that are not connected is not an error"
[05:40] <bigjools> don't understand
[05:40] <bigjools> as in, literally, I don't know what you mean by this
[05:40] <jtv> Oops.  That should be disconnecting.
[05:40] <jtv> Typo.
[05:40] <bigjools> ah!
[05:40] <bigjools> jtv: while you're at it
[05:41] <bigjools> jtv: in the preceding sentence that starts with "Or", the comma after "network" should be after the "Or"
[05:41] <bigjools> or, don't start a sentence with "or"
[05:41] <bigjools> :)
[05:41] <jtv> And while you're at it: https://code.launchpad.net/~jtv/maas-test/typo-2014-02-18/+merge/206851
[05:42] <bigjools> heh, done
[05:43] <jtv> Thanks.  Ah, I see now: it was a typo the other way around.  I typed "not" when I meant "already."
[05:43] <jtv> So: connecting a node and a network that are already connected is not an error.
[05:51] <bigjools> jtv: can I do a super quick pre-imp
[05:54] <jtv> bigjools: sure, modulo my laptop's boot time.
[05:54] <bigjools> jtv: call away when ready
[05:55] <jtv> Mind if I get coffee too?
[06:03] <bigjools> jtv: no, actually can you hang on, I need to make a quick call
[06:03] <jtv> OK
[06:03] <jtv> Had some trouble logging in again, but it's working now...
[06:06] <bigjools> jtv: we should have had a call anyway, oops sorry.  hang on, on hold here
[06:07] <jtv> No, that's tomorrow.  Want to do your pre-imp tomorrow? :-)
[06:12] <bigjools> jtv: oh heck :)
[06:12] <bigjools> calling you now
[08:44] <jtv> rvba: one thing I really miss is an ability to link from documentation straight to individual API calls (or handlers).
[08:45] <rvba> jtv: that's a good point.  We could add anchors for every method.
[08:45] <rvba> s/every method/all the methods/
[08:46] <jtv> For all I know they might already exist...
[08:46]  * jtv wonders why the maas-enlist package has a maas-commission.install
[08:48] <rvba> jtv: they do not exist: https://maas.ubuntu.com/docs/api.html
[08:50] <jtv> Then they should.  :)
[08:50] <jtv> Wonder why that page is not loading at the moment...
[08:51] <jtv> Ah here it comes
[08:54] <jtv> Yup.  No anchors.  Not even any id attributes that we could use as of HTML5.
[08:54] <rvba> This page could be improved.  All the information is there but it's a bit difficult to follow because it's not greatly formatted.
[08:54] <jtv> Yes, it's pretty ugly — hard to see what the structure is.
[08:55] <rvba> Indeed.
[08:55] <jtv> We could get a lot of improvement out of just generating headers for the handler classes, I think.
[08:56] <jtv> With anchors, obviously.
[08:56] <rvba> Like you said earlier, I think we want anchors for every single method.
[08:57] <jtv> Yes, that would be even better.
[08:57] <jtv> But ideally I'd want both.
[08:57] <rvba> Agreed.
[13:24] <gmb> rvba: Do you remember how to fix "RuntimeError: Timed out waiting for dnsmasq lease for 52:54:00:f1:4d:cd." when running maas-test? It's happening all the time now on canonistack.
[13:24] <gmb> ISTR we ran into this way back when.
[13:36] <rvba> gmb: sorry, I don't remember (I don't even remember seeing this error).
[13:36] <gmb> Gnargh.
[13:39]  * gmb tries bouncing libvirt
[13:44] <rbasak> gmb: that error's from uvtool. uvt-kvm is waiting for the MAC address of the VM to appear in /var/lib/libvirt/dnsmasq/default.leases so that it can pick up its IP
[13:44] <rbasak> gmb: I'm interested to know if the issue is that the timeout is too short, or if something has changed to cause it to never work.
[13:48] <gmb> rbasak: Okay. Anything I can do to aid debugging?
[13:50] <rbasak> gmb: a few things I guess, if you want to work with me?
[13:50] <rbasak> gmb: first, can you pastebin "virsh dumpxml <machine-name>"?
[13:51] <rbasak> gmb: "virsh list" should give you a list of machine names. Perhaps you only have one?
[13:51] <rbasak> I think maastest uses a UUID or something
[13:51] <gmb> rbasak: It does. Give me 5 minutes just to wrap up what I'm doing and I'll get started.
[13:51] <rbasak> gmb: sure
[14:00] <gmb> rbasak: http://paste.ubuntu.com/6954532/
[14:03] <rbasak> gmb: does the MAC in the error match the one on line 42?
[14:03] <jtv> Hi rbasak — I see my problem wasn't a fluke and gmb had the same thing
[14:04] <rbasak> Next question after that. Does maastest use the --log-console-output option to uvt-kvm?
[14:04] <gmb> rbasak: Well, no, because the one in the error is an old one; we tear down the VM when m-t finishes (I've hacked it to leave it lying around).
[14:05] <gmb> rbasak: Not AFAIK; will check.
[14:05] <rbasak> gmb: while you're there, please add "--password foo" for testing.
[14:05] <rbasak> gmb: then we can log in on console and examine the VM from the inside
[14:05] <gmb> rbasak: Okay, on it.
[14:05] <rbasak> gmb: if you can remove --log-console-output if it's in use (otherwise no worries)
[14:05] <gmb> rbasak: It isn't. I'll add the --password option
[14:05] <rbasak> gmb: then, before it's timed out, you should be able to run "virsh console <machine-name>" and see a VT login, and then log in as ubuntu/foo
[14:06] <gmb> k
[14:07] <rbasak> From there, I'm interested to know if the VM has an IP on the same range as what dnsmasq on your host listens on (virbr0 interface on the host by default I think)
[14:08] <rbasak> If it helps, "uvt-kvm wait" takes a --timeout option, which is the number of seconds to wait before timeout.
[14:09] <gmb> rbasak: Okay, it might be as simple as specifying that, but let me take a look anyway.
[14:09] <rbasak> Or, you might see through the VT that the VM is taking too long to boot for some reason.
[14:10] <rbasak> Looks like the default timeout is two minutes
[14:11] <gmb> rbasak: Right. So, I think the VM is taking too long to boot, and uvt-wait is puking. I'll try upping the timeout; the console was pretty sluggish.
[14:12] <rbasak> Hmm, OK. I noticed that nested KVM is unusually slow on canonistack. Didn't think it was quite that bad.
[14:13] <rbasak> Manpages are on the way, BTW. I'll try writing a diagnostics section, too.
[14:13] <gmb> rbasak: Yeah, we've seen that all the way through m-t developmnet. In fact m-t warns you about trying to run nested KVMs for that reason.
[14:13] <gmb> rbasak: Brilliant, thanks.
[14:13]  * rbasak goes afk for a while
[14:14] <rbasak> gmb: happy to see uvtool being useful. BTW, I have a bunch of changes in trunk that I'll land in universe soon. I don't think it'll break maastest at all, but look out for it.
[14:44] <rharper> what's the best way to disable pserv.log?
[14:52] <roaksoax> rharper: why would you want to disable pserv.log?
[14:54] <rharper> at least the version I have is 99% filled with ACKDatagram when sending data over tftp
[14:54] <rharper> 2014-02-14 19:33:49+0000 [RemoteOriginReadSession (UDP)] Datagram received from ('10.245.0.130', 49156): <ACKDatagram(blocknum=12844)>
[14:55] <roaksoax> rharper: that's fixed
[14:55] <rharper> running: python-maas-provisioningserver   1.4+bzr1693+dfsg-0ubuntu2.2~ctools0 on a precise host
[14:55] <jtv1> That gets sent to /dev/null by default, I thought...
[14:55] <roaksoax> rharper: shouldn't show more of that stuff
[14:56] <roaksoax> rharper: check /etc/maas/pserv.yaml?
[14:56] <roaksoax> rharper: you can disable it there
[14:56] <rharper> roadmr: cool, so, unccomment or /dev/null ?
[14:56] <rharper> err, roaksoax ^^
[14:56] <roadmr> rharper: hello :)
[14:57] <rharper> roadmr: sorry; tab completed, meant for roaksoax
[14:57] <roadmr> rharper: I know, at this point I'm just pulling your leg :)
[14:57] <rharper> hehe
[15:38] <roaksoax> rharper: /dev/null IIR
[15:38] <roaksoax> rharper: /dev/null IIRC
[15:38] <rharper> thanks
[22:01] <Guest3232> Hi, when you deploy a service using juju etc, does it run on a single node? Im trying to umderstand the benefit of openstack on maas
[22:04] <roadmr> Guest3232: a service can have several units, each *unit* runs on a single node (if I understand correctly)
[22:05] <roadmr> Guest3232: as for openstack and maas, they're two different environments from juju's point of view
[22:05] <roadmr> Guest3232: if you juju deploy to your maas environment, by default it will deploy each unit on a separate machine
[22:06] <roadmr> Guest3232: if you juju deploy to the openstack environment, it should deploy each unit to a separate *virtual machine* (depending on how openstack is set up, many VMs may share the same physical machine)
[22:06] <roadmr> Guest3232: interestingly you can use juju to deploy openstack on a maas cluster, then use the same juju to deploy other services to that openstack cluster (hope I'm not confusing you)
[22:07] <Guest3232> Lol
[22:08] <Guest3232> So, with openstack a vm can span several nodes and run applications on it, but with just maas it runs om
[22:09] <Guest3232> on one machine only? With max resources of amsingle
[22:09] <Guest3232> *a single machine?
[22:10] <Guest3232> Im trying to work put the point of openstack if maas already spreads applications over several machines
[22:11] <roadmr> Guest3232: strictly speaking maas doesn't do that; it's juju doing the deployment on several machines
[22:11] <roadmr> Guest3232: maas just provides the machines for juju to deploy services
[22:11] <Guest3232> Ah i see
[22:11] <roadmr> Guest3232: I guess it depends on what the underlying hardware is
[22:11] <Guest3232> So at what point is openstack > juju
[22:12] <roadmr> Guest3232: same thing :) openstack is a "provider" of "machines" for juju to deploy services on
[22:12] <roadmr> Guest3232: the difference is that maas provides actual bare-metal machines (hence metal as a service) whereas openstack provides virtual machines
[22:13] <Guest3232> Ah cool, so i could get away with running web services, hadoop etc straight off maas and not bother with openstack?
[22:13] <Guest3232> If i use juju
[22:13] <roadmr> Guest3232: and I guess it depends on your hardware and scaling needs. If you have 10 really beefy machines, you can put openstack and juju deploy to openstack, so you can create say hundreds of VMs on your beefy servers and host 100s of units/services
[22:14] <roadmr> Guest3232: OTOH if you have 1000 lower-powered micro-servers, you could use maas and juju-deploy to that, so each unit gets its own, tiny hardware instance
[22:14] <Guest3232> Will juju put more than one application on a server if it thinks it can handle it?
[22:14] <roadmr> Guest3232: You could, yes. I suggest you read up on openstack and what benefits it offers you
[22:15] <Guest3232> Hmm ok thx
[22:15] <Guest3232> :)
[22:15] <roadmr> Guest3232: not unless you tell it to, and moreover, per the juju documentation, charms may not cooperate with each other
[22:15] <roadmr> Guest3232: "they will happily trample over other charms hosted on the same machine"
[22:15] <Guest3232> Ok so potentially with just juju, youll under use the full machines power
[22:15] <roadmr> Guest3232: exactly
[22:15] <Guest3232> Aaaah
[22:16] <roadmr> Guest3232: say you juju deploy wordpress and mysql to a maas cluster, each will get their own machine even if they could run on a single one
[22:16] <Guest3232> Ah i see
[22:16] <roadmr> Guest3232: for this simple example it's OK, but imagine a complex setup needing 10 different services
[22:16] <Guest3232> Not ideal
[22:16] <Guest3232> Ok cool so ill look at openstack
[22:16] <roadmr> Guest3232: with maas you'd need 10 physical machines
[22:17] <roadmr> Guest3232: with openstack potentially one would suffice, and 10 VMs would be spun up on that same hardware
[22:17] <Guest3232> I guess i was hoping to move away from having to keep loads of vms patched etc
[22:17] <roadmr> Guest3232: bear in mind, though, that openstack *does* require deployment on multiple machines (read the docs!)
[22:17] <roadmr> Guest3232: I have a toy openstack cluster here and it uses 10 machines
[22:17] <roadmr> Guest3232: but if the nova-compute node is beefy enough it could potentially host 100 VMs
[22:18] <roadmr> Guest3232: so see, you can host 100 units which would require 100 machines with maas alone, but using only 10 physical machines
[22:18] <Guest3232> Yeah ok cool i understand now
[22:18] <Guest3232> So is there a charn style way to deploy within openstack
[22:18] <Guest3232> *charm
[22:19] <Guest3232> Or is it manual creation and setup of an o/s via a new vm
[22:19] <Guest3232> Then adding httpd, sql etc and setting up the service
[22:20] <roadmr> Guest3232: oh you can juju deploy to an openstack cluster :)
[22:20] <roadmr> juju deploy -e openstack wordpress
[22:20] <roadmr> (assuming you have an openstack environment configured)
[22:20] <roadmr> Guest3232: I have to go now, sorry, good night!
[22:20] <Guest3232> Thx later
[23:19] <bigjools> morning roaksoax
[23:29] <roaksoax> bigjools: howdy!