[15:58] <jgrassler> Hello
[15:59] <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
[16:01] <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:02] <jtv> jgrassler: that sounds pretty exciting.
[16:03] <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:04] <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:05] <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:06] <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:07] <jtv> The next-address (next-server?  I forget) setting is only used for the PXE boot itself.
[16:08] <jgrassler> Ok, that's good to know.
[16:09] <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:10] <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:11] <jgrassler> No, that would take some dirty, dirty hacks in that scenario :-)
[16:12] <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:13] <jtv> (My fault for asking a negative question — "no" can mean that you agree or that you disagree!)
[16:13] <jgrassler> No worries :-)
[16:14] <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:15] <jgrassler> But we didn't want to keep wasting a - fairly sizeable - hardware node on serving boot images
[16:16] <jgrassler> Hmm, interesting: https://gist.github.com/jgrassler/6567ce9aee97f8d54918
[16:17] <jgrassler> Apparently the internal IP address does show up in the root images.
[16:19] <jgrassler> Never mind. I'm to close to calling it a day for now to properly escape meta characters in my regexes :-)
[16:21] <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:22] <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:27] <jgrassler> At least now I know where not to look :-)
[16:28] <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:29] <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:30] <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:31] <jtv> (On older versions, the api subdir would not exist and you'd have to get... either pxeconfig.py or api.py.)
[16:32] <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:33] <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:34] <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:35] <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:36] <jtv> That would be the party where the MAAS_URL is configured...
[16:37] <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:38] <jtv> This is where it all gets a bit hard to follow.
[16:39] <jgrassler> From a quick glance it looks fairly messy, yes
[16:40] <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:41] <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:42] <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:43] <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:44] <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