| === vladk|offline is now known as vladk | ||
| === CyberJacob|Away is now known as CyberJacob | ||
| === CyberJacob is now known as CyberJacob|Away | ||
| === med_ is now known as 1JTAAEE11 | ||
| jtv | allenap: can't say I like the split-range solution, but I do appreciate the potential rabbit hole... So the default is just a split-down-the-middle kind of line? | 09:12 |
|---|---|---|
| allenap | jtv: I think bigjools was falling on the side of making the static range bigger than the dynamic range. 1:3 maybe? | 09:19 |
| jtv | Thinking out loud... I guess the need for the dynamic range depends on two factors: hosts that you want in the dynamic range, and lease times for transient leases. | 09:22 |
| === vladk is now known as vladk|offline | ||
| jtv | If we had separate networks, I guess it might make sense to restrict routing of BMC addresses, and just leave the BMCs in the dynamic network. But I guess that's not applicable to the split range. | 09:23 |
| === vladk|offline is now known as vladk | ||
| jtv | So the dynamic range would be unallocated machines and additional unmanaged local services. | 09:24 |
| jtv | You'd mostly want local services exposed on reliable IPs though, so probably not much of that. | 09:25 |
| jtv | Hmm... maybe in the future if we found that a bunch of machines only work for other machines on the same network. | 09:27 |
| jtv | Allocating static IPs won't be any great pain though unless it becomes a part of security policy, and we couldn't recommend that with a split range. | 09:28 |
| allenap | jtv: To complicate matters, apparently BMCs are often put on separate networks anyway, and given static addresses by hand. | 09:29 |
| allenap | Maybe that simplifies things :) | 09:29 |
| jtv | They should be, yes — unless admins decide that it's a fully controlled network. | 09:30 |
| jtv | I wonder if that includes "tabletop clusters." I wouldn't mind forcing an opinion about this, but I would mind raising the threshold to getting set up. | 09:30 |
| jtv | It'd be annoying to set up a MAAS with a /24 network and 100 machines plus BMCs, and find that we can't DHCP them all. | 09:31 |
| jtv | OTOH, "don't do that then." | 09:32 |
| allenap | jtv: I think it’s only a policy decision by larger customers. Tabletop clusters are probably all single network | 09:32 |
| allenap | jtv: Indeed it would :-/ | 09:32 |
| jtv | The initial setup period may be an example of a situation we think of as uncommon: loads of unallocated machines. | 09:33 |
| jtv | So I would say that the static and dynamic range must both be large enough to accommodate all your machines anyway. Fifty-fifty may simply be the easiest way to "sell" that notion. | 09:34 |
| jtv | Maybe we should describe the problem as “minimising the cost to your network's address range.” | 09:35 |
| jtv | If we do a 3:1 split one way or the other, then the worst case is requiring 4 times as much IP space as the machines would normally require. | 09:36 |
| jtv | That's OK if we can _reliably_ model the needs; the best case is requiring ⅓ more IP range than the bare machines need, which is nice. | 09:37 |
| jtv | It's also OK if we can _reasonably_ ask people to work around a shortage if it appears. | 09:38 |
| jtv | (We can perhaps ask people to move dynamically-addressed machines to static addresses, but not the other way around.) | 09:39 |
| jtv | OTOH if we run out of dynamic addresses we can "borrow" from the static range. | 09:42 |
| allenap | jtv: Given the use of containers and, when they’re on the same network, BMCs, we may want to have the dynamic range be a multiple of the static range. | 09:42 |
| allenap | rather than the other way around. | 09:42 |
| jtv | Yeah. It doesn't suit the steady state very well though. | 09:42 |
| jtv | We could also treat the dynamic range as nothing more than a loading dock for the static range. | 09:44 |
| jtv | Where everything that shows up in the dynamic range gets lifted into the static range. | 09:45 |
| jtv | (Assuming we can find a way to convince systems that their old DHCP lease is worthless and they need to request a new one.) | 09:45 |
| jtv | Sorry for re-doing much of the Austin discussion; there wasn't quite enough time to go through the whole problem and solution there IIRC. | 09:46 |
| allenap | jtv: That would be okay. It implies that we need a way to allocate static addresses to containers and BMCs. | 09:47 |
| jtv | Yes, we'd effectively be managing our own DHCP but piggybacking on dhcpd for the protocol niceties. | 09:48 |
| allenap | jtv: I think the reason we keep circling back to this conversation is that the split-range solution is not much of a solution. It’s giving us a new set of headaches. | 09:48 |
| jtv | Yes... Horrible unforeseen complications aside I quite liked the idea of link-local addresses myself. | 09:49 |
| jtv | I'll say this for the fifty-percent solution: it puts a simple and reasonable upper bound on the cost to your address range. | 09:50 |
| jtv | |range| ≥ 2×|nics| + 2 | 09:51 |
| jtv | (Where the +2 comes from broadcast & base addresses) | 09:52 |
| allenap | jtv: Sounds good to me. Without a clairvoyant AI in MAAS I doubt we’ll do any better :) | 09:52 |
| jtv | You don't need a clairvoyant AI. You need a paranoid one. | 09:53 |
| jtv | Clairvoyance is great for average cases, but paranoid limits worst cases. | 09:53 |
| allenap | Hehe. Or Go. Go solves everything. | 09:54 |
| === kentb-out is now known as kentb | ||
| === matsubara is now known as matsubara-lunch | ||
| jtv | Who's up for a pre-imp about DNS changes for the new DHCP range? | 15:11 |
| allenap | jtv: I am. Sorry I didn’t see this until now. | 16:03 |
| allenap | jhobbs: Thanks for testing the lease parsing thing. | 16:03 |
| rkdemon2 | Hi, | 16:04 |
| jhobbs | allenap: np | 16:04 |
| allenap | jhobbs: One thing: you need to change the verification-needed tag to verification-done. | 16:04 |
| rkdemon2 | I am new to this entire domain of openstack/maas etc. I am trying to deply juju on my platform. As a precurosr I needed to have a maas cluster up: I created a maas cluster with one node (can add more), but one for now. The "nodes" on the maas server page shows this: ubuntu1 52:54:00:b7:fb:7e Commissioning default | 16:06 |
| rkdemon2 | I am looking for a way to test this before attempting to deply juju. | 16:06 |
| rkdemon2 | Any help would be seriously awesome!! | 16:06 |
| jhobbs | allenap: done | 16:06 |
| rkdemon2 | anyone ? | 16:12 |
| jhobbs | rkdemon2: https://maas.ubuntu.com/docs/juju-quick-start.html | 16:15 |
| rkdemon2 | jhobbs: I intend to use that link but wanted to know if there's an easy way to tell if the cluster is indeed setup. | 16:16 |
| rkdemon2 | jhobbs: When I "add a node" to the maas server, does the fact that the node get added enough to indicate it is setup ? | 16:17 |
| jhobbs | rkdemon2: you can commission/install it then ssh into it | 16:17 |
| rkdemon2 | to clarify, I added the node as a virsh node. | 16:17 |
| rkdemon2 | i.e specified the mac id of the virsh virtual machine created on another server as a node | 16:18 |
| jhobbs | did you setup power controls for it? | 16:18 |
| rkdemon2 | no I do not know how to .. do I need it ? | 16:19 |
| jhobbs | yeah - http://maas.ubuntu.com/docs/nodes.html | 16:19 |
| rkdemon2 | the vm is up and created etc | 16:19 |
| jhobbs | there is a section on that doc talking about power controls for vm nodes | 16:19 |
| rkdemon2 | ok thanks.. let me read .. thank yo ufor your help | 16:20 |
| jhobbs | np | 16:20 |
| === matsubara-lunch is now known as matsubara | ||
| === CyberJacob|Away is now known as CyberJacob | ||
| === roadmr is now known as roadmr_afk | ||
| === roadmr_afk is now known as roadmr | ||
| d_` | is there any sort of managed login strategy for maas? | 19:46 |
| d_` | each admin has their own key, but we share cluster resources | 19:47 |
| d_` | it _seems_ like it's trying to associate provisioned servers to a single user | 19:51 |
| === roadmr is now known as roadmr_afk | ||
| === vladk is now known as vladk|offline | ||
| === roadmr_afk is now known as roadmr | ||
| dpb1 | Hi -- when you create a container (lxc) on maas through juju, you get a non-critical error: 'sudo: unable to resolve host juju-machine-0-lxc-2' when running sudo commands -- should this be a bug in juju? Maas? | 20:44 |
| === CyberJacob is now known as CyberJacob|Away | ||
| lazyPower | dpb1: thats kind of expected behavior since that hostname is unresolveable. Whats your resulting hostname in /etc/hosts of the lxc container? | 22:07 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!