=== CyberJacob is now known as CyberJacob|Away [00:18] I have a brand new setup. I have two servers, maas is set up on one, and it's set to handle dhcp and dns. I'm now trying to boot a second machine with PXE turned on. [00:19] On the second machine, I'm just getting a TFTP timeout. Know what could be causing that? [00:19] PXE-E32 [00:20] CreativeEmbassy: I've seen a few reports of tftp timeouts lately [00:20] this is 13.10 maas? [00:20] bigjools: yeah. assumed the machine with MAAS would have already taken care of setting up TFTP, opening the port in the firewall, and whatever else. [00:20] it does not set firewalls [00:20] so check that [00:20] alright, I'll look that up [00:20] but it will start a tftp server [00:21] do you have maas managing dhcp? [00:22] Yeah. And DNS. [00:22] I just turned off DHCP on the main router to make sure it wasn't interfering. [00:23] if it's on the same network it will interfere [00:31] do you know what file is requested over tftp? pxelinux.0? [00:31] I want to try it on localhost first to make sure I can access it here, before I try to reboot the node and let it go again [00:32] nm, looks like it is that file === melmoth_ is now known as melmoth [00:49] not having luck. opened up ports 67, 68, 69. now the node isn't even able to talk to the controller via DHCP [00:49] it's late, and I need to head home. I'll be in here again tomorrow :) [00:49] thanks for your help === jam3 is now known as jam [06:50] morning all [06:50] anyone around who can answer 20 questions on MAAS epermial images? [06:51] NCommander: hit me [06:51] assuming you mean ephemeral images [06:52] bigjools, yeah, sorry, its early [06:53] bigjools, I'm looking at enabling MAAS for a new ARM subarchitecture, but MAAS's internals have changed a *lot* since the last time I looked [06:53] As best I can tell, instead of just preseeding an installer, it does some voodoo with iSCSI, and then I got lost [06:53] (I'm also having a lot of trouble getting a dev environment setup; issues with image importation) [06:53] none of this stuff has changed really [06:54] Well, how exactly are the ephemeral images used (I've not gotten to the point where I can actually get my cluster to run) [06:54] so to enable a new subarch you need to get it in simplestreams and then edit the maas-import-pxe-files filter. I think that's it. [06:54] ok [06:55] so they are obviously imported and stored on the cluster controller [06:55] next [06:55] when booting a node, maas supplies the kernel command line with the iscsi target of the image, depending on what its architecture us [06:55] is* [06:55] so it all depends on the arch/subarch getting set right on the node definition === CyberJacob|Away is now known as CyberJacob === mgz is now known as mgzh === allenap_ is now known as allenap [10:31] Hi, I have maas 1.4+bzr1693+dfsg-0ubuntu2~ctools0 installed but I don't see a /etc/maas/preseeds directory (as mentioned in stokachu's article http://astokes.org/automatically-configuring-vlans-maas/ ). Do I need a different version ? or has the location moved ? [10:32] it ought to be there [10:33] I am EOD now but perhaps allenap can help [10:34] thanks, I'll wait for him to pop in [10:36] I upgraded from 1.2 if that's relevant [10:48] morning mgz, is allenap hiding behind the fish tank ? [10:48] he's right beside me [10:49] unlike certain less reliable fellows [10:51] I seem to have an additional issue that juju is claiming my maas environment is not bootstrapped (I have recently added the cloud archive and cloud tools archive) [10:51] maas-cli maas files list shows a number of files including provider-state [10:52] but retrieving it seems to be failing [10:52] AttributeError: 'HttpResponse' object has no attribute '_is_string' [10:53] gnuoy: I am berating allenap about maas-cli now [10:53] thanks :) [10:54] mgz: http://blog.allenap.me/2013/06/workaround-for-uploading-files-to-maas.html [11:00] gnuoy: can you re-run the command with --debug (stick it near the end) [11:01] mgz http://paste.ubuntu.com/6335114/ [11:02] gnuoy: can you look at the log on the server side for the full traceback? [11:03] mgz http://paste.ubuntu.com/6335119/ [11:03] that looks like a masking error in the handling of an earlier exception [11:04] mgz, I have that message repeated every 5 minutes in the maas.log but nothing else that I can see [11:05] gnuoy: my best guess is your maas install is slightly hosed, you probably need a version bump to one or other python package [11:06] mgz, ok, let me look into that [11:07] mgz, ah, I had some packages that had been kept back [11:09] mgz, allenap, all fixed, thanks. I have a preseeds dir now and juju status is working again [11:09] ace. [12:09] bigjools, I'm at an absolute loss at how boot images are reported; I canmanually call tftpboot, and get a valid dict[] with images, but looking at web(app)s logs, I can never see the controller reporting it has images, thus the maas error messages aren't cleared [12:10] I can see in the log that its attempted to report [12:10] But there's no actual POST call made [12:17] [2013-10-31 08:16:42,295: DEBUG/PoolWorker-6] Not reporting boot images: don't have API key yet. [12:17] Ah [12:17] There's the problem [12:30] bigjools, how does the regional cluster get an API key? [12:55] mgz, allenap, any chance you know the necessary magic to get the regional controller to know its API key? [12:56] NCommander: sorry, didn't respond because I didn't understand the question [12:57] mgz, I've got a local setup of lp:maas locally because I'm trying to do platform enablement [12:57] mgz, right now, I'm stuck with "regional controller doesn't see disk images" issue, and looking at the logs when celeryd is running DEBUG, I'm getting complaints that the API key is missing [12:58] [2013-10-31 08:38:59,070: DEBUG/PoolWorker-5] Not reporting boot images: don't have API key yet. [12:59] NCommander: You're not going to like this, but I suggest working against the packages. [13:00] allenap, that's somewhat annoying ... [13:00] NCommander: Cluster controllers should be given some tokens in order to talk back to the region controller, but there may be some -fu in the packages. [13:00] allenap, I need this to land for trusty; working against saucy's code isn't going to help me much [13:01] * NCommander already has patches that fix some of the debug scripts [13:01] NCommander: It hasn't diverged much yet. [13:01] allenap, "yet" is a scary word :-) [13:01] NCommander: Obviously fixes will have to get into lp:maas, but I suggest doing enablement with packages. [13:02] NCommander: And I mean a daily PPA (https://launchpad.net/~maas-maintainers/+archive/dailybuilds), rather than those in the distro. [13:03] allenap, that's exceptionally annoying for doing work, as then I have to hunt down where all the libraries have ended up. [13:03] */grumbles* [13:03] Then again, I've already lost 2 days to this nonsense [13:03] * NCommander has been playing debug the breaking script :-/ [13:04] allenap, I can probably put my stuff in a series of quilt patches and rebuild the source packages from scratch ... [13:06] NCommander: That sounds good to me. We can then absorb those changes upstream once they're working. However, roaksoax is the packaging guy for MAAS, so I'll let him comment. [13:08] allenap, so the daily PPAs pull from trunk? (want to make sure my stuff is relatively sane) [13:09] NCommander: Yep. There's no recipe for trusty yet though. [13:22] allenap, well, fudge, in about 10 minutes I've gotten farther than I have in 2 days :-/ [13:23] NCommander: \o/ [13:25] NCommander: We're going to be charming up MAAS this cycle, and one of my goals is to make sure that it's as easy to deploy from branch as it is from packages. I think that should help this story. Sorry it's not there yet. [13:25] allenap, its fine, but I'd appreicate it if the dev documentation was a bit more in touch with reality . I'm fairly sure I'll have more questions === Spideyman is now known as Spideyman_afk === Spideyman is now known as Spideyman_afk === Spideyman is now known as Spideyman_afk === freeflying is now known as freeflying_away === Nik is now known as Guest97534 [16:07] Hi. Does anyone know anythig about "metadata request failed http://server/MAAS/metadata - internal server error 500" while commisining a node? The nodes fail to tag. [16:07] These nodes used to tag before [16:07] But failed after recommisioning [16:11] File "/usr/lib/python2.7/dist-packages/django/core/handlers/base.py", line 111, in get_response [16:11] .... [16:11] File "/usr/lib/python2.7/dist-packages/maasserver/api_auth.py", line 55, in is_authenticated [16:11] raise OAuthUnauthorized(error) [16:12] found those in the log. May be related [18:03] just curious, can I add other stuff to maas-dns somewhere, even for computers that aren't being provisioned by MAAS? [19:37] smoser, ping, so I need to cook an ephemeral image for a new subarch, and I was pointed to you :-) === Spideyman is now known as Spideyman_afk === Spideyman_afk is now known as Spideyman [20:42] the filename for the user preseeds can someone give me an example [20:42] included arch_subarch_series_nodename [20:42] i know what series and nodename should look like [20:43] is the prefix actually required in order to be the first in the lookup list [20:44] so amd64_generic_saucy would be selected before 'generic' [20:45] ah nm [20:45] helps if i read down [20:53] NCommander: I pointed you to smoser to point you at the maas ephemeral image generation script, which I think he has in bzr somewhere. Adding a subarch to a master script is a bit of a dubious proposition right now without coordination on what to do with the subarch field, kernels, etc. [21:07] you can specify your own mirrors, though [21:07] so you could do a local generation and then use that [21:08] rbasak, well, I'm trying to figure out what that will need; I think I can just set the arch field to "armhf+slayton" and call it good, but I'm not sure how hard it will be to bend those scripts === CyberJacob is now known as CyberJacob|Away === freeflying_away is now known as freeflying === freeflying is now known as freeflying_away