| === CyberJacob is now known as CyberJacob|Away | ||
| navidad | I'm having trouble commissioning. Everything seems to work fine until the very end and I get repeating messages of "request to http://mymaasserverip/MAAS/metadata/2012-03-01/ failed. sleeping 1.: '' " .. and then the number increments every few minutes | 00:17 |
|---|---|---|
| bigjools | couple of things to check:L | 00:17 |
| bigjools | s/L//. | 00:17 |
| bigjools | 1. Can your commissioning node reach the maas server ip? Routing? | 00:18 |
| navidad | it started happening after I upgraded from trusty -> utopic ie maas1.5 to 1.7 | 00:18 |
| bigjools | 2. Is the server up? | 00:18 |
| navidad | Yeah the routing is good, all pings work. Server is definitely up as it PXE serves and gets 99% thru the commissioning. | 00:19 |
| bigjools | do you have the cluster and the region on the same host? | 00:19 |
| navidad | yes I do | 00:19 |
| bigjools | ok can you check the maas.log and the maas-django.log on the host | 00:20 |
| navidad | two things I noticed, not sure if they're relevant. For some reason MAAS started giving the hosts a random two word hostname instead of the 5digit alphanumeric hostname | 00:20 |
| bigjools | that's expected | 00:20 |
| bigjools | (and sometimes hilarious) | 00:20 |
| navidad | secondly, its not registering said hostname into dns, i can ping all the old hosts created in 1.5 but none of the new ones | 00:20 |
| navidad | yeah i was laughing at some of the bizaare combinations it comes up with | 00:21 |
| bigjools | ok, something's not upgraded properly | 00:21 |
| bigjools | check the logs | 00:21 |
| navidad | yeah so im looking at the bind upstart and its running fine .. it returns dns for the old ones like i said | 00:21 |
| bigjools | something is wrong with the region controller | 00:21 |
| bigjools | it handles metadata requests (failing here) and writes the dns zone file (failing again) | 00:22 |
| bigjools | however | 00:22 |
| navidad | the django log has a few lines about python stuff being deprecated | 00:22 |
| bigjools | one thing to note in 1.7 that's different is that hosts don't get any IP until *started* | 00:22 |
| bigjools | did you add a static IP range in the cluster interface? | 00:23 |
| bigjools | (and did you read the release notes?) | 00:23 |
| bigjools | well, it's not quite released yet, but they're available | 00:23 |
| navidad | I have a dynamic IP range in the cluster interface, if thats what you mean.. a /24 | 00:24 |
| bigjools | with 1.7 you need to add another range | 00:24 |
| bigjools | well, from 1.6 onwards | 00:25 |
| navidad | for the maas host IP? | 00:25 |
| bigjools | for each cluster interface | 00:25 |
| bigjools | the old range is used for DHCP allocations; the new range is static allocations done by MAAS itself for allocated nodes | 00:25 |
| bigjools | once you put that in place it will start giving you IPs and DNS entries for nodes you allocate | 00:26 |
| bigjools | and start | 00:26 |
| navidad | is this in the release notes? i never saw this | 00:26 |
| navidad | Oh I kinda see what you mean. Can you put the same range in the dhcp+static range fields? Or should I just switch it to static only, if i want dns entries? | 00:33 |
| bigjools | no, needs to be different | 00:34 |
| navidad | nm it wont let me do the former, answered my own Q | 00:34 |
| bigjools | you need both ranges defined | 00:34 |
| bigjools | dynamic is now used only for commissioning and enlistments | 00:34 |
| navidad | that's confusing. So I could make the dhcp range a very small range, since i'll only be commissioning a few at one time?? | 00:35 |
| navidad | hmm so I moved the dhcp range to a smaller range, and tacked on a static range as well, but comissioning is still giving the same error with metadata failing. DNS also not updating still | 00:52 |
| bigjools | As I said, DNS won't update until a node is allocated and started | 00:52 |
| navidad | I guess it doesnt add DNS until it starts like you said, so that makes sense. But the metadata error is the problem | 00:53 |
| bigjools | and I asked you for the logs.... | 00:53 |
| navidad | cloud-init.log? | 00:54 |
| bigjools | navidad: maas.log and maas-django.log on the host | 01:03 |
| === menn0 is now known as menn0-afk | ||
| === menn0-afk is now known as menn0 | ||
| === roadmr is now known as roadmr_afk | ||
| === roadmr_afk is now known as roadmr | ||
| === roadmr is now known as roadmr_afk | ||
| === roadmr_afk is now known as roadmr | ||
| === CyberJacob|Away is now known as CyberJacob | ||
| === CyberJacob is now known as CyberJacob|Away | ||
| roadmr | hello maas folks. I have maas 1.7.0~rc3+bzr3299-0ubuntu1~trusty1 and I think there may be a bug with the boot-resource create functionality (uploading a custom image) | 08:46 |
| roadmr | I pass a "name" parameter when doing boot-resources create, but this name is not visible anywhere in the web UI | 08:47 |
| roadmr | as a result, I just have e.g. 2 custom images with no name, so when selecting one to deploy, I can't tell which is which :/ so I'm doing it blind essentially | 08:48 |
| bigjools | roadmr: please file a bug | 08:50 |
| roadmr | bigjools: will do. The name is visible if I list boot resources in the command line, so it looks strictly like a UI issue. Filing now... | 08:50 |
| bigjools | ok | 08:52 |
| roadmr | bigjools: https://bugs.launchpad.net/maas/+bug/1391421 | 08:59 |
| ubot5 | Ubuntu bug 1391421 in MAAS "Names of custom boot-resources not visible in the web UI" [Undecided,New] | 08:59 |
| bigjools | thanks roadmr | 09:10 |
| roadmr | bigjools: np, I could take a stab at fixing it myself but I probably won't have time this weel :/ | 09:11 |
| roadmr | week even | 09:11 |
| bigjools | roadmr: hopefully blake_r will see it and fix it :) | 09:11 |
| roadmr | \o/ | 09:12 |
| === roadmr is now known as roadmr_afk | ||
| bigjools | gmb: an easy one https://code.launchpad.net/~julian-edwards/maas/release-host-maps-fix-bug-1391411/+merge/241385 | 09:18 |
| === roadmr_afk is now known as roadmr | ||
| gmb | bigjools: On it. | 09:45 |
| gmb | Gah, too late. | 09:45 |
| jtv | gmb: :-P | 09:47 |
| jtv | allenap: David is right that the effective serialisation of transactions doesn't _have_ to be the commit order. | 09:48 |
| jtv | All that's required IIRC is that the database be left in a state that would be consistent with transactions being executed sequentially — in *some* order. | 09:49 |
| jtv | And until savepoints came along, that meant that failed transactions were basically hors concours. | 09:49 |
| jtv | AFAIK you could technically implement "serializable" by failing any transaction that came in while another was in progress... | 09:50 |
| jtv | (as long as either of them was serializable) | 09:50 |
| gmb | Aha! Power monitor! J'accuse! | 09:53 |
| allenap | jtv: Right, that's a good point. | 09:53 |
| allenap | Not what I want, but a good point nonetheless :) | 09:53 |
| gmb | Ah, mm, well, no exactly. Still, j'accuse a bit. | 09:53 |
| jtv | allenap: but I think your observation that this is really a serialisation failure was very powerful and might sway some people. | 09:54 |
| jtv | (At least, it's a serialisation failure if the conflicting row is not visible in your transaction.) | 09:55 |
| allenap | jtv: That would be what I would expect to see, yep. | 09:55 |
| jtv | Of course getting it implemented is a different story. If it would involve MVCC indexes, well, those have been a wishlist item for a long time I think. | 09:56 |
| allenap | jtv: For our case it would be enough to "upgrade" the duplicate key error to a serialization failure, which, finger in the air, might be doable without major plumbing. | 09:57 |
| allenap | jtv: But we can do that in the application too, for now. There are points at which we know the transaction is doomed, though we may have to discover some of them from use. | 09:59 |
| jtv | Quite. | 10:00 |
| gmb | allenap: Ping us when you've got a few mins, would you? | 10:24 |
| * gmb went all Lanky there. | 10:24 | |
| gmb | Ping *me* | 10:24 |
| libsysguy | I can't seem to find any info on adding custom user data to the commissioning script. Does anybody know how to do that? Basically I want to add chef to the cloud-init process | 14:05 |
| === jfarschman is now known as MilesDenver | ||
| === robbiew is now known as robbiew-afk | ||
| === robbiew-afk is now known as robbiew | ||
| === jfarschman is now known as MilesDenver | ||
| === CyberJacob|Away is now known as CyberJacob | ||
| === jfarschman is now known as MilesDenver | ||
| === jfarschman is now known as MilesDenver | ||
| === jfarschman is now known as MilesDenver | ||
| === CyberJacob is now known as CyberJacob|Away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!