[09:12] <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:19] <allenap> jtv: I think bigjools was falling on the side of making the static range bigger than the dynamic range. 1:3 maybe?
[09:22] <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:23] <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:24] <jtv> So the dynamic range would be unallocated machines and additional unmanaged local services.
[09:25] <jtv> You'd mostly want local services exposed on reliable IPs though, so probably not much of that.
[09:27] <jtv> Hmm... maybe in the future if we found that a bunch of machines only work for other machines on the same network.
[09:28] <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:29] <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:30] <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:31] <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:32] <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:33] <jtv> The initial setup period may be an example of a situation we think of as uncommon: loads of unallocated machines.
[09:34] <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:35] <jtv> Maybe we should describe the problem as “minimising the cost to your network's address range.”
[09:36] <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:37] <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:38] <jtv> It's also OK if we can _reasonably_ ask people to work around a shortage if it appears.
[09:39] <jtv> (We can perhaps ask people to move dynamically-addressed machines to static addresses, but not the other way around.)
[09:42] <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:44] <jtv> We could also treat the dynamic range as nothing more than a loading dock for the static range.
[09:45] <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:46] <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:47] <allenap> jtv: That would be okay. It implies that we need a way to allocate static addresses to containers and BMCs.
[09:48] <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:49] <jtv> Yes...  Horrible unforeseen complications aside I quite liked the idea of link-local addresses myself.
[09:50] <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:51] <jtv> |range| ≥ 2×|nics| + 2
[09:52] <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:53] <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:54] <allenap> Hehe. Or Go. Go solves everything.
[15:11] <jtv> Who's up for a pre-imp about DNS changes for the new DHCP range?
[16:03] <allenap> jtv: I am. Sorry I didn’t see this until now.
[16:03] <allenap> jhobbs: Thanks for testing the lease parsing thing.
[16:04] <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:06] <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:12] <rkdemon2> anyone ?
[16:15] <jhobbs> rkdemon2: https://maas.ubuntu.com/docs/juju-quick-start.html
[16:16] <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:17] <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:18] <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:19] <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:20] <rkdemon2> ok thanks.. let me read .. thank yo ufor your help
[16:20] <jhobbs> np
[19:46] <d_`> is there any sort of managed login strategy for maas?
[19:47] <d_`> each admin has their own key, but we share cluster resources
[19:51] <d_`> it _seems_ like it's trying to associate provisioned servers to a single user
[20:44] <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?
[22:07] <lazyPower> dpb1: thats kind of expected behavior since that hostname is unresolveable. Whats your resulting hostname in /etc/hosts of the lxc container?