| === CyberJacob|Away is now known as CyberJacob | ||
| === CyberJacob is now known as CyberJacob|Away | ||
| === MasterPieceF is now known as MasterPiece | ||
| === jfarschman is now known as MilesDenver | ||
| jgrassler | Hello | 15:58 |
|---|---|---|
| jgrassler | Does anybody know how MAAS determines the IP address it hardwires into boot images as its iscsi server address? | 15:59 |
| jgrassler | It seems to disregard the IP address configured for maas-region-controller/maas-cluster-controller | 15:59 |
| jgrassler | Which is a bit of an issue in my case: I'm deploying MAAS in an openstack instance, and its eth0 IP address is different from its public floating IP address | 16:01 |
| jtv | jgrassler: that sounds pretty exciting. | 16:02 |
| jtv | I think the address you want is the one that we call the "MAAS URL." | 16:03 |
| jtv | It's defined as the URL where cluster controllers and nodes can reach the region controller. | 16:03 |
| jtv | So whenever we need to tell cluster controllers or nodes the address where they can reach the region controller, that's the address we give. | 16:03 |
| jtv | You can change it through "dpkg-reconfigure maas-cluster-controller" on the cluster controller machine. | 16:04 |
| jtv | (Usually the cluster controller and the region controller run on the same machine.) | 16:04 |
| jgrassler | Yes, that's what I tried. | 16:04 |
| jgrassler | After which I deleted the images and had maas rebuild them. | 16:04 |
| jgrassler | But they still end up with the internal IP address. | 16:05 |
| jtv | That shouldn't be needed. Unless it was changed while I was doing other things, we don't encode the address into the images. | 16:05 |
| jgrassler | Interesting...how is the address communicated to the PXE booted system then? | 16:06 |
| jgrassler | Does it just use the DHCP-Server's next-address value? | 16:06 |
| jtv | IIRC we pass it on the kernel parameter. | 16:06 |
| jtv | Ahem. | 16:06 |
| jtv | Kernel command line, I mean. | 16:06 |
| jtv | The next-address (next-server? I forget) setting is only used for the PXE boot itself. | 16:07 |
| jgrassler | Ok, that's good to know. | 16:08 |
| jtv | Off the top of my head, it goes something like... Node wakes up; goes into PXE; gets DHCP address; requests PXE config from cluster controller; PXE config netboots the node into an install image. | 16:09 |
| jgrassler | Sounds sensible, yes | 16:09 |
| jtv | I really don't recall but presumably the iscsi address is in the PXE config there somewhere. | 16:09 |
| jtv | Ah, maybe what we pass on the kernel command line is just for rsyslog. | 16:10 |
| jgrassler | And that's what it looked like on the serial console back when we had our MAAS controller on a hardware node, too | 16:10 |
| jtv | I guess you're not using MAAS as the DHCP server? | 16:10 |
| jgrassler | No, that would take some dirty, dirty hacks in that scenario :-) | 16:11 |
| jtv | So you serve DHCP to nodes that are also on EC2? | 16:12 |
| jgrassler | But our hardware MAAS controller was not in charge of DHCP either | 16:12 |
| jgrassler | No, not at all | 16:12 |
| jtv | Ah, I misread the "no." :) | 16:12 |
| jtv | (My fault for asking a negative question — "no" can mean that you agree or that you disagree!) | 16:13 |
| jgrassler | No worries :-) | 16:13 |
| jtv | We don't normally test in that situation, so it's quite possible to run into trouble. | 16:14 |
| jgrassler | Yeah, it is somewhat unusual | 16:14 |
| jgrassler | But we didn't want to keep wasting a - fairly sizeable - hardware node on serving boot images | 16:15 |
| jgrassler | Hmm, interesting: https://gist.github.com/jgrassler/6567ce9aee97f8d54918 | 16:16 |
| jgrassler | Apparently the internal IP address does show up in the root images. | 16:17 |
| jgrassler | Never mind. I'm to close to calling it a day for now to properly escape meta characters in my regexes :-) | 16:19 |
| jgrassler | I.e. the grep triggered on this kind of thing: /boot/System.map-3.13.0-27-generic:c1020080 t cyrix_identify | 16:21 |
| jtv | jgrassler: the images import system _was_ recently rewritten, so I may be behind the times. But it seems strange to me to see the IP address in there. | 16:21 |
| jtv | Oh... | 16:21 |
| jtv | Now I see what you mean about the regexes. :) | 16:22 |
| jtv | Yeah, escaping those dots might change things. :) | 16:22 |
| jtv | Or use fgrep I guess. | 16:22 |
| jgrassler | At least now I know where not to look :-) | 16:27 |
| jgrassler | So I guess I'll delve into the code then - where would I start that? | 16:28 |
| jtv | I think in src/maasserver/pxeconfig.py. | 16:28 |
| jtv | Or maybe it's src/maasserver/api/... hang on. | 16:28 |
| jtv | When the node requests its PXE config from the cluster controller, the cluster controller asks the region controller "please compose a PXE config file for this node." | 16:29 |
| jtv | Ah: src/maasserver/api/pxeconfig.py | 16:29 |
| jgrassler | Ok...let's see where that ended up in the file system... | 16:30 |
| jtv | In there, look for the pxeconfig function. That's the region-controller function that ends up handling that request. | 16:30 |
| jtv | Oh, on an installed machine: | 16:30 |
| jtv | /usr/lib/python2.7/dist-packages/maasserver/api/ | 16:30 |
| jtv | (On older versions, the api subdir would not exist and you'd have to get... either pxeconfig.py or api.py.) | 16:31 |
| jgrassler | Thanks | 16:32 |
| jgrassler | I think 1.5.4 qualifies as an older version then | 16:32 |
| jtv | Whoops yes it does | 16:32 |
| jtv | On the bright side, fewer unfamiliar changes. :) | 16:32 |
| jgrassler | That's something :-) | 16:33 |
| jtv | It may have been /usr/lib/python2.7/dist-packages/maasserver/pxeconfig.py in that version. | 16:33 |
| jgrassler | It appears to be api.py | 16:33 |
| jtv | That's a shame. It was huge. | 16:33 |
| jgrassler | It's a bit problematic though...it's invoked from somewhere else | 16:34 |
| jtv | But come to think of it... why would 1.5 not give the MAAS_URL..? | 16:34 |
| jtv | Yes, it's invoked from the cluster controller, as part of its handling of the node's TFTP request. | 16:34 |
| jgrassler | And "somewhere else" supplies a local parameter. Said parameter is the cluster controller's IP address. | 16:35 |
| * jtv looks... | 16:35 | |
| jgrassler | So apparently the cluster controller is the confused party | 16:35 |
| jtv | That would be the party where the MAAS_URL is configured... | 16:36 |
| jtv | The cluster controller passes the parameters through its API request. | 16:37 |
| jtv | The cluster-controller code is, for hysterical raisins, in /usr/lib/python2.7/dist-packages/provisioningserver. | 16:37 |
| jtv | This is where it all gets a bit hard to follow. | 16:38 |
| jgrassler | From a quick glance it looks fairly messy, yes | 16:39 |
| jgrassler | I think I'll put that bit off until tomorrow. Here in UTC+2istan it's getting to be the time where my wife calls asking why I'm not home, yet :-) | 16:40 |
| jtv | Ah, I know that one. | 16:40 |
| jtv | Anyway, it comes from /etc/maas/pserv.yaml. | 16:40 |
| jtv | That's where it gets the URL. | 16:40 |
| jtv | And "dpkg-reconfigure maas-cluster-controller" rewrites that bit of YAML with the URL you enter. | 16:40 |
| jgrassler | Odd. | 16:40 |
| jgrassler | That file contains the public IP address. | 16:41 |
| jtv | @!# | 16:41 |
| jtv | Old instance still running for whatever reason..? | 16:41 |
| jtv | Anyway, run home. :) | 16:41 |
| jgrassler | No | 16:41 |
| jgrassler | I configured the packages with a preseed, no chance of that happening :-) | 16:41 |
| jtv | Oh make sure it's a URL you see there, not just an IP address. | 16:42 |
| jgrassler | Yes, it's an URL | 16:42 |
| jtv | Grrr | 16:42 |
| jtv | "Have you tried turning it off and on again?" | 16:42 |
| jgrassler | It's getting to be tricky, yes... | 16:42 |
| jgrassler | Countless time :-) | 16:42 |
| jgrassler | s/time/times/ | 16:42 |
| jtv | No that's fine for us binary types: zero, one, countless. | 16:43 |
| jgrassler | That box is provisioned through heat/puppet and rebuilds from scratch in ~10 minutes | 16:43 |
| jgrassler | Heh | 16:43 |
| jgrassler | And I made use of that mechanism a couple of times - to no avail | 16:44 |
| jtv | Oops, and I have to run! | 16:44 |
| jgrassler | Alright, let's run then :-) | 16:44 |
| jgrassler | Thanks for the help | 16:44 |
| jtv | np | 16:44 |
| * jtv runs | 16:44 | |
| === roadmr is now known as roadmr_afk | ||
| === jfarschman is now known as MilesDenver | ||
| === jfarschman is now known as MilesDenver | ||
| === CyberJacob|Away is now known as CyberJacob | ||
| === jfarschman is now known as MilesDenver | ||
| === CyberJacob is now known as CyberJacob|Away | ||
| === CyberJacob|Away is now known as CyberJacob | ||
| === roadmr_afk is now known as roadmr | ||
| === CyberJacob is now known as CyberJacob|Away | ||
| === CyberJacob|Away is now known as CyberJacob | ||
| === jfarschman is now known as MilesDenver | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!