[06:13] <jtv1> bigjools: ->
[06:13] <bigjools> jtv: ←
[06:13] <bigjools> did we just ping with arrows?
[06:13] <jtv> Sort of.
[06:13] <jtv> Bough & arrough.
[06:14] <jtv> Anyway.  I phased my sketch of the changes according to my Baby Steps maxim.
[06:14] <jtv> Here's what I'd like to do at this point:
[06:14] <jtv> First, get an idea of what changes we want over the whole stretch.
[06:14] <jtv> So that includes the multiple-interface-DNS change.
[06:15] <jtv> Get a grip on the changes it requires to the DNS config generators etc.
[06:15] <jtv> Then, decide whether (1) it makes sense to keep the phasing I outlined (where we do multiple DHCP interfaces first), and (2) anything can be done in parallel.
[06:16] <jtv> Make sense?
[06:16]  * bigjools digesting
[06:17] <bigjools> jtv: ok yes that's fine
[06:18] <bigjools> parallel is good
[06:18] <bigjools> as is baby steps
[06:18]  * bigjools fixorates trusty failures
[06:19] <jtv> Right now it looks to me as if it's pretty easy just to remove the restriction on multiple DHCP-managed interfaces, and the get_dns_managed_interface makes it easy to grep for reliance on the remaining (for now) restriction limiting us to one DNS-managed interface.
[06:20] <jtv> But a bit more exploration first may be wise.
[06:21] <jtv> To support multiple DNS-managed interfaces, obviously we need to take a closer look at how we manage DNS configs, but also at what options we offer to the user.
[06:22] <jtv> I'd particularly like to get a handle on the difference between (i) supporting resolution of hostnames to interfaces on the various networks, and (ii) providing name resolution to client interfaces on the various networks.
[06:23] <jtv> For resolution, can we simply resolve a node's hostname to all of its interfaces?
[06:24]  * jtv struggles with clarity
[06:24] <jtv> I mean: nodes can be both clients to our DNS, and hosts resolved in our DNS.
[06:27] <jtv> Should a node have a single hostname, mapping to all its IP addresses?
[06:35] <jtv> Currently the DNS code only maps a node's hostname to an IP address leased to its oldest MACAddress object.
[06:38] <bigjools> right
[06:38] <bigjools> this falls under some of the other fixes we wanted to do
[06:38] <bigjools> ie boot from a maas-controlled management network, but the DNS should resolve to a different NIC
[06:41]  * bigjools goes to deal with ants. 
[06:41]  * bigjools realises this is an Archer cliché
[06:42]  * jtv smugly sidesteps the cliché for another one.
[06:45] <bigjools> they are antliminated
[06:46]  * jtv cringes at attempted wordplay
[07:11] <ging> is there a way to get more logging/debugging info with maas? every time i have an issue i find it very diffcult to find out where it is going wrong
[07:15] <bigjools> ging: can I help with something in particular?
[07:15] <bigjools> all the logs are under /var/log/maas/
[07:15] <bigjools> there are a few different logs
[07:16] <ging> at the moment my nodes in kvm are failing tests while commisioning
[07:16] <bigjools> which tests?
[07:17] <ging> 00-maas-01-lshw and 00-maas-02-virtuality
[07:17] <bigjools> and what are you seeing?
[07:17] <ging> it instantly shuts down the vm so i can't see what is going on
[07:18] <bigjools> what makes you say it's failing?
[07:18] <ging> it says failed 2/ and lists those 2
[07:18] <ging> 2/5
[07:18] <bigjools> ok
[07:19] <bigjools> well don't worry too much it doesn't affect normal operations, it'll just be missing some info in the database
[07:19] <jtv> We don't expose the commissioning results  anywhere in the UI, do we?
[07:19] <bigjools> no
[07:19] <bigjools> you have to DB-dive
[07:19] <bigjools> this is something we should sort out I suppose!
[07:20] <bigjools> ging: there's a database table called NodeCommissioningResult, the result logs will be in there
[07:20] <ging> ok thanks i will have a look
[07:21] <ging> do you think if i disable pxe boot on the vms they'll actually be working then ?
[07:21] <jtv> No, that'll stop them from working with MAAS at all.
[07:23] <ging> is it the postgres db that maas is using?
[07:23] <bigjools> yes
[07:52] <ging> i can't even get into the database
[07:55] <bigjools> use "maas shell" and then:
[07:56] <bigjools> from metadataserver.models import NodeCommissioningResult
[07:56] <bigjools> from metadataserver.models import NodeCommissionResult
[07:56] <bigjools> sorry
[07:57] <bigjools> for n in NodeCommissionResult.objects.all()
[07:57] <bigjools>   print n
[07:57] <bigjools> or similar
[07:58] <bigjools> jtv: want some cheap karma? https://code.launchpad.net/~julian-edwards/maas/fix-celery-callbacks-bug-1270713/+merge/202250
[08:03] <bigjools> you lost your chance!  ok then gmb how about you?
[08:03] <jtv> Don't worry, I'll take it.
[08:03] <bigjools> ha!
[08:03] <bigjools> it's a one liner
[08:03] <jtv> I am known for my one-liners.
[08:04] <bigjools> eye liners more like
[08:05] <jtv> Tramp!
[08:11] <jtv> bigjools: will your change cause any problems for the cloud-archive version?
[08:11] <ging> does maas shell have a man page?
[08:11] <bigjools> jtv: no idea, don't care. cloud archive should update if so.
[08:12] <bigjools> ging: http://maas.ubuntu.com/docs is better
[08:12] <jtv> I think we include the generated man pages there nowadays.
[08:13] <bigjools> jtv: thanks for reviewiewiewiewering
[08:14] <jtv> Yeahyeahyeah I know I know
[08:15]  * bigjools out for a while
[08:43] <ging> would a lack of connection to the repositories cause the commisioning tests to fail?
[08:45] <jtv> Yes, it would
[08:45] <jtv> The node connects to a proxy running on the region controller, and the proxy connects to the repository.
[08:48] <ging> i think this could be where it is going wrong
[08:49] <jtv> I think the lldp scripts would also fail though.
[08:49] <jtv> Because those need to install lldp.
[08:51] <jtv> And the virtuality script doesn't look as if it needs any networking.
[08:51] <jtv> In fact I don't see how that script could fail at all...
[08:52] <jtv> ging: if you can run that maas-shell loop, that should provide error output for the commissioning scripts.
[08:57] <ging> jtv: i couldn't get it to run
[08:57] <jtv> Where did it fail?
[08:58] <ging> it imported NodeCommisionsResult but the next bit gave me a syntax error
[08:58] <ging> and i have no understanding of this syntax
[08:59] <jtv> Did it say where the error happened?  If it's a traceback, just the last entry should be enough.
[08:59] <jtv> Where it names a file and a line number.
[08:59] <rvba> ging: run this: '[n for n in NodeCommissionResult.objects.all()]'
[08:59]  * jtv searches
[09:01] <ging> rvba with the braces and the quotes or neither?
[09:02] <rvba> ging: just what's inside the quotes (i.e. with the braces).
[09:02] <jtv> That's meant to be run within the maas shell though — that failed to start, right?
[09:02] <ging> no i'm in the maas shell
[09:03] <ging> this is what i get with the braces
[09:03] <rvba> jtv: Julian forgot the ':' at the end of the loop statement.
[09:03] <ging> [<NodeCommissionResult: NodeCommissionResult object>, <NodeCommissionResult: NodeCommissionResult object>, <NodeCommissionResult: NodeCommissionResult object>, <NodeCommissionResult: NodeCommissionResult object>, <NodeCommissionResult: NodeCommissionResult object>, <NodeCommissionResult: NodeCommissionResult object>, <NodeCommissionResult: NodeCommissionResult object>, <NodeCommissionResult: NodeCommissionResult object>]
[09:03] <jtv> Ah!
[09:04] <jtv> Well, that's the objects.  Now for the contents.  :)
[09:04] <jtv> We can start with the metadata:
[09:05] <jtv> for n in NodeCommissionResult.objects.all():
[09:05] <jtv>     print(n.name, n.script_result)
[09:06] <jtv> That'll tell us which ones succeeded and which ones failed (in case there's any misunderstanding there).
[09:06] <rvba> bigjools: rarg, looks like the celery upgrade broke quite a few things :/
[09:08] <ging> do i need to end the print command with something? nothing happens
[09:08] <jtv> Try pressing enter another time.
[09:09] <ging> TypeError: 'NodeCommissionResult' object is not callable
[09:13] <jtv> Er...
[09:14]  * jtv is not seeing it
[09:15] <ging> got it now
[09:15] <ging> didn't have enough of an indent
[09:16] <ging> h no i had a typo
[09:16] <jtv> The most interesting output will be the non-zero results, of course.
[09:20] <jtv> My system is upgrading; I'll drop out soon, hopefully briefly.
[09:47] <ging> so far i can see what tests are failing, but i don't know how to get the actual output of the tests, or is that it just pass or fail ?
[09:51] <ging> ah n.data gives me something
[09:57] <bigjools> guys, FYI: http://docs.celeryproject.org/en/latest/whatsnew-3.0.html
[09:57] <bigjools> rvba,jtv, allenap, gmb ^
[09:58] <bigjools> rvba: notice the "Celery will automatically use the librabbitmq module if installed" :)
[09:58]  * jtv goes offline.  Will not be back for a while after all.
[09:58] <rvba> bigjools: that part I know :).  We managed to work around that.
[09:58] <bigjools> I know
[09:59] <bigjools> the task chaining stuff is cool
[09:59] <rvba> Hopefully the core problem will get fixed at some point.
[09:59] <bigjools> it's clearly a bug in the rabbit lib
[09:59] <rvba> Yep
[10:00] <bigjools> aaaanyway I have to do kids' bedtime
[10:03] <ging> should my maas server be listening as a proxy on port 8000? because it currently doesn't it has a proxy on 3128 but apt running on commisioning it trying to connect to it on port 8000
[10:07] <bigjools> ging: check the settings page to see what is configured. The proxy is squid-deb-proxy but I can't remember what its default port is.
[10:07]  * bigjools wishes all good night
[10:11] <ging> changing thing on the setting page seems to make no difference
[10:18] <ging> restart of squid deb proxy and it now listens on 8000
[11:09] <ging> squid deb proxy crashes every time i connect to it, i'm not sure why
[11:09] <ging> but that is definetely my problem
[11:31] <rvba> allenap: does that problem ring a bell? http://paste.ubuntu.com/6785337/
[11:32] <rvba> allenap: this is when I run 'make' in the branch where I upgraded testttools to 0.9.34.
[11:32] <allenap> rvba: It could be that you’ve got python-mimeparse installed locally.
[11:33] <rvba> Ah, good point.
[11:33]  * rvba checks
[11:33] <allenap> rvba: Or that testtools 0.9.33 needs a newer version than is pinned in versions.cfg.
[11:33] <rvba> allenap: no, not installed.
[11:33] <rvba> allenap: python-mimeparse is not mentioned in versions.cfg
[11:34] <allenap> rvba: Ah, it ought to be then.
[11:36] <rvba> allenap: why?  If it's not mentioned, doesn't just mean any version is okay?
[11:36] <rvba> doesn't it*
[11:41] <rvba> allenap: can you remind me what command I should run to get buildout to write versions.cfg?
[11:54] <allenap> rvba: bin/buildout -v buildout:allow-picked-versions=true
[12:02] <rvba> allenap: Fu&%ing A!  Looks like it did the trick.  Thanks!
[13:59] <tomixxx> @jtv, matsubara: are u online? do you remember my MAAS-problem: one maas-server with two network-card-interfaces, one card connects to a private switch with two other nodes and one interface connects to the uni network
[14:21] <jpds_> tomixxx: Probably not at this time, but you're better off looking at http://shop.canonical.com/product_info.php?products_id=658
[14:26] <tomixxx> jdps: ty but i guess i will keep the free-of-charge server ;)