| === jfarschman is now known as MilesDenver | ||
| === jfarschman is now known as MilesDenver | ||
| === jfarschman is now known as MilesDenver | ||
| === jfarschman is now known as MilesDenver | ||
| === jfarschman is now known as MilesDenver | ||
| === jfarschman is now known as MilesDenver | ||
| === jfarschman is now known as MilesDenver | ||
| === jfarschman is now known as MilesDenver | ||
| === jfarschman is now known as MilesDenver | ||
| === CyberJacob|Away is now known as CyberJacob | ||
| === CyberJacob is now known as CyberJacob|Away | ||
| === jfarschman is now known as MilesDenver | ||
| === jfarschman is now known as MilesDenver | ||
| === jfarschman is now known as MilesDenver | ||
| === dankolb- is now known as dank | ||
| === jfarschman is now known as MilesDenver | ||
| jgrassler | Good afternoon. | 12:53 |
|---|---|---|
| jgrassler | How does MAAS determine a newly declared machine's FQDN if it is not in charge of DHCP/DNS? | 12:53 |
| jgrassler | We may have a bit of an issue with that since we overprovision our PXE address space, i.e. there are more physical machines than IP addresses. | 12:55 |
| jgrassler | We only started doing this recently, and before overprovisioning started the machines would get random FQDNs when they appeared in MAAS. | 12:56 |
| jgrassler | Now, with overprovisioning in place, freshly enrolled machines that got previously assigned IP addresses suddenly show up with their PXE IP adress' reverse entry (which is bad since it causes duplicates). | 12:58 |
| jgrassler | s/enrolled/declared/ | 12:59 |
| jgrassler | It wouldn't be so bad if we could just change the FQDN and be certain MAAS will continue to recognize this machine as this machine even if it gets a different IP address somewhere down the line. | 13:02 |
| jgrassler | E.g. we wouldn't have a problem if MAAS uses a machine's MAC addresses, serial number or some other identifier _not_ related to its primary interface's IP address :-) | 13:03 |
| jgrassler | Is that the case? | 13:03 |
| jtv | jgrassler: it all starts with the two address ranges. | 13:15 |
| === jfarschman is now known as MilesDenver | ||
| jtv | While a machine is allocated, it's got an address in the static range. This is where you get DNS resolution etc. | 13:16 |
| jtv | You can also allocate a static address to a specific interface. | 13:17 |
| jtv | For other machines, addresses are temporary and you can't really count on them or on their hostnames — we have the IP-based hostnames basically as an historical workaround. | 13:17 |
| jtv | At the time, we automatically generated fixed DNS entries for all possible IP addresses in the range. | 13:19 |
| jtv | (In older versions, the human-configured hostnames resolved as CNAMEs to those IP-based ones.) | 13:20 |
| jtv | If you're short on IP addresses this may not help much, but with the new setup, you should have a dynamic address range that can probably be overprovisioned because nodes don't stay there; and a static range that should be large enough to accommodate all user-allocated static addresses. | 13:21 |
| jgrassler | That is what we are doing right now, yes. | 13:23 |
| jgrassler | We have a sufficiently large static range and a small PXE range. | 13:23 |
| jtv | OK that helps. | 13:23 |
| jtv | Or should. | 13:23 |
| jtv | When you deploy a machine, it should still come up with just the static address and its corresponding A-record hostname. | 13:24 |
| jgrassler | How is that host name determined? | 13:24 |
| jtv | It's configured under Edit Node. | 13:24 |
| jgrassler | A reverse lookup on the PXE interface's address? | 13:24 |
| jtv | No, we tell the DHCP server to serve a particular address to that interface. | 13:25 |
| jgrassler | Now there's where I run into trouble...our MAAS controller is separate from the DHCP server :-( | 13:25 |
| jtv | And that means we can't control the addresses. :( | 13:25 |
| jgrassler | Yes. | 13:26 |
| jgrassler | It's not much of a problem if (1) the hostname configured under "Edit Node" trumps whatever a node's PXE interface address resolves to and if (2) MAAS identifies that node by something like its MAC address or serial number, i.e. if a different node with the same address showing up doesn't cause trouble. | 13:27 |
| jtv | Just to make sure: when you say "the node's PXE interface address," you mean the address it gets from DHCP while it's netbooting, right? I mean, not its BMC or anything. | 13:28 |
| jgrassler | Correct, yes. | 13:28 |
| jtv | MAAS itself does know the node by its MAC addresses. Still thinking about the rest. | 13:29 |
| jgrassler | That sounds like we may not have a problem, in fact :-) | 13:29 |
| jtv | Ah-ah-ah those sound like FLW :) | 13:30 |
| jgrassler | FLW? | 13:30 |
| jtv | Famous Last Words. | 13:30 |
| jtv | (Sorry. I collect TLAs.) | 13:30 |
| jtv | Anyway. | 13:30 |
| jtv | I'm having trouble parsing your point (1), probably because it doesn't match my own mental model very closely. It may help if I just complete the picture of how it works: | 13:31 |
| jtv | In the "normal" mode of operation, we do two things for a node: | 13:31 |
| jgrassler | Sounds good. I'll fill in the gaps (if there are any :-)) | 13:31 |
| jtv | (Ahem. A node being deployed. Not just any node.) | 13:32 |
| jtv | 1. We tell dhcpd: if this interface asks for an IP address, give it X. | 13:32 |
| jtv | 2. We tell bind: resolve the node's configured hostname to X. | 13:32 |
| jtv | There's no adaptive logic inbetween. So if the node sneakily acquires a completely different IP address, e.g. from a foreign DHCP server, there is nothing that adjusts to that. | 13:33 |
| jtv | Which makes total sense in a model where we only serve DNS if we're also serving DHCP. | 13:34 |
| jgrassler | 'sneakily acquire a different IP adddress' sumps it up pretty well :-) | 13:34 |
| jtv | I find colourful language an underutilised facility in IT. | 13:34 |
| jgrassler | s/sump/sum/ | 13:35 |
| jtv | Sump it up. I like that. | 13:35 |
| jgrassler | Then again, that typo is oddly fitting, yes | 13:35 |
| jtv | Now. If we *don't* serve DHCP, then Spock has a beard. | 13:35 |
| jgrassler | Yes, unfortunately we seem to be in that universe :-) | 13:35 |
| jtv | Also, in this universe, nodes get whatever IP addresses they get, MAAS isn't aware, and the hostnames you configure for them just don't go anyway. | 13:35 |
| jtv | Glad to see some people still know their classics. You caught my meaning there. | 13:36 |
| jgrassler | Anyway, I shall endeavour to quickly sketch the sick and twisted flavour of reality we have to deal with around here: | 13:37 |
| jtv | *chuckle* | 13:37 |
| jtv | Go ahead, sump it up for me. | 13:37 |
| jgrassler | 1) A node gets installed with PXE address X and whatever host name MAAS' database contains (i.e. what I put in there manually through the web interface or API) | 13:38 |
| jtv | But the DHCP server is not MAAS's? | 13:39 |
| jgrassler | No. | 13:39 |
| jtv | OK | 13:39 |
| jgrassler | 2) After the node is finished installing our bootstrap scripts perform their magic based on the machine's configured host name (and not on whatever reverse entries for the machine's addresses say) | 13:39 |
| jgrassler | 3) At some point our bootstrapping scripts bring up the node's real network interfaces, configure bonding on them and receive the node's real IP address through DHCP on bond0 (that's the sneaky bit) | 13:41 |
| jgrassler | So far so good. | 13:41 |
| jgrassler | But now I'm getting a bit worried about (4): A different node comes up with PXE address X | 13:41 |
| jtv | And those reverse entries are in your own DNS server? | 13:41 |
| jgrassler | (due to overprovisioning) | 13:42 |
| jgrassler | Yes, but they are essentially meaningless | 13:42 |
| jtv | OK | 13:42 |
| jgrassler | (Not being permanently assigned to any node at all) | 13:42 |
| jgrassler | And I won't have to worry about (4) if MAAS keeps identifying the node that went through steps (1) to (3) by its MAC address, even if it receives a different address on its PXE interface. | 13:43 |
| jtv | Right. Then essentially, MAAS will simply not know the machine's IP address, and that should be fine as long as it knows the BMC address. | 13:44 |
| jgrassler | BMC address? | 13:45 |
| jtv | Where you control power etc. for the node. | 13:45 |
| jgrassler | Ah, perfect. That one is static :-) | 13:45 |
| jtv | Excellent. | 13:45 |
| jgrassler | Thanks | 13:46 |
| jtv | I think while the node is allocated, its address really doesn't matter to MAAS. | 13:46 |
| jgrassler | That's one major worry taken care of. | 13:46 |
| jgrassler | No, definitely not. | 13:46 |
| jgrassler | We tested this, and it's been found to work just fine. | 13:47 |
| jtv | Perfect. My only slight hesitation was with requests that the node makes to the API. | 13:47 |
| jtv | It would have been possible for the server to identify the node based on the request's IP address, but I'm fairly sure that we don't do that. | 13:48 |
| jtv | (I spend a lot of my time imagining ways for things to go wrong.) | 13:48 |
| jgrassler | We'll I'll be sure to test this. | 13:48 |
| jtv | Now, AFAICS MAAS shouldn't even show any IP address for your node. | 13:48 |
| jtv | Which of course does mean that you need to figure out which node is which. | 13:49 |
| jgrassler | That's not a problem, we can go by the BMC address or MAC address. | 13:49 |
| jtv | OK | 13:50 |
| jgrassler | It is tedious, but we'll only have to do it once. | 13:50 |
| jtv | Technically I suppose it's information we could record, but we can't make many guarantees about it because we don't know the dhcp server's policies. | 13:50 |
| jtv | Thanks for the reviews allenap. | 14:16 |
| === jfarschman is now known as MilesDenver | ||
| allenap | You're totally welcome. | 14:22 |
| === jfarschman is now known as MilesDenver | ||
| bstillwell | Are there any 1.6.1 packages for trusty? | 16:41 |
| bstillwell | newell: Figured out the problem I was having yesterday was caused by an incomplete image import... | 16:50 |
| newell | bstillwell, glad you got it figured out :) | 16:50 |
| newell | sorry I had to run off | 16:50 |
| bstillwell | np, btw do you know if there are any 1.6.1 packages for trusty? | 16:50 |
| newell | I would have to look | 16:51 |
| newell | I know there are rc 1.7 packages | 16:51 |
| newell | rc = release candidate | 16:51 |
| bstillwell | I'm looking at using MAAS for some CentOS machines, and I see there's beta support for using curtin on those. | 16:51 |
| newell | https://launchpad.net/~maas-maintainers/+archive/ubuntu/stable | 16:52 |
| newell | looks like 1.6 is all there is as I don't see a stable 1.6.1 package | 16:52 |
| newell | blake_r is the one who implemented CentOS support so he would know more detailed answers about anything CentOS related | 16:53 |
| bstillwell | Are there any CentOS images I can use with curtain or instructions on how to make an image? | 16:53 |
| bstillwell | blake_r: ? | 16:53 |
| bstillwell | Where are the 1.7 rc packages? | 16:53 |
| bstillwell | I don't have a problem helping test them. | 16:53 |
| newell | https://launchpad.net/~maas-maintainers/+archive/ubuntu/dailybuilds | 16:54 |
| newell | those are in the daily build | 16:54 |
| bstillwell | cool, thanks! | 16:54 |
| newell | there is also a 1.6.1 in there it looks like | 16:54 |
| newell | npo | 16:54 |
| newell | np* | 16:54 |
| blake_r | bstillwell: you should use maas-maintainers/testing | 16:54 |
| bstillwell | blake_r: Do those pull in the CentOS images? | 16:55 |
| blake_r | bstillwell: they do not pull in CentOS images, the CentOS images have yet to be released | 16:56 |
| bstillwell | blake_r: ahh, are there instructions somewhere on how to create your own? | 16:56 |
| newell | bstillwell, as blake_r just mentioned the latest 1.7 rc packages are in https://launchpad.net/~maas-maintainers/+archive/ubuntu/testing | 16:57 |
| bstillwell | newell: thanks, I'll try them out. :) | 16:57 |
| blake_r | bstillwell: not currently, sorry | 16:57 |
| blake_r | bstillwell: still working on that | 16:57 |
| bstillwell | blake_r: bummer | 16:58 |
| === CyberJacob|Away is now known as CyberJacob | ||
| bstillwell | I believe I've found an area of the documentation that needs updating: | 21:20 |
| bstillwell | http://maas.ubuntu.com/docs1.7/install.html | 21:20 |
| bstillwell | There's a note about getting the most recent release from the Canonical cloud archive using 'sudo add-apt-repository cloud-archive:tools' | 21:20 |
| bstillwell | but if you actually try to do that on trusty it gives you: KeyError: 'release' | 21:21 |
| === jfarschman is now known as MilesDenver | ||
| Joshka | Hey everyone! I have a question... | 23:37 |
| Joshka | How long should it take to commission a node in MAAS? | 23:37 |
| Joshka | And what exactly is happening when it is in a "commissioning" state? | 23:38 |
| === CyberJacob is now known as CyberJacob|Away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!