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