=== 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 [09:12] 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] jtv: I think bigjools was falling on the side of making the static range bigger than the dynamic range. 1:3 maybe? [09:22] 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. === vladk is now known as vladk|offline [09:23] 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. === vladk|offline is now known as vladk [09:24] So the dynamic range would be unallocated machines and additional unmanaged local services. [09:25] You'd mostly want local services exposed on reliable IPs though, so probably not much of that. [09:27] Hmm... maybe in the future if we found that a bunch of machines only work for other machines on the same network. [09:28] 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] jtv: To complicate matters, apparently BMCs are often put on separate networks anyway, and given static addresses by hand. [09:29] Maybe that simplifies things :) [09:30] They should be, yes — unless admins decide that it's a fully controlled network. [09:30] 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] 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] OTOH, "don't do that then." [09:32] jtv: I think it’s only a policy decision by larger customers. Tabletop clusters are probably all single network [09:32] jtv: Indeed it would :-/ [09:33] The initial setup period may be an example of a situation we think of as uncommon: loads of unallocated machines. [09:34] 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] Maybe we should describe the problem as “minimising the cost to your network's address range.” [09:36] 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] 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] It's also OK if we can _reasonably_ ask people to work around a shortage if it appears. [09:39] (We can perhaps ask people to move dynamically-addressed machines to static addresses, but not the other way around.) [09:42] OTOH if we run out of dynamic addresses we can "borrow" from the static range. [09:42] 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] rather than the other way around. [09:42] Yeah. It doesn't suit the steady state very well though. [09:44] We could also treat the dynamic range as nothing more than a loading dock for the static range. [09:45] Where everything that shows up in the dynamic range gets lifted into the static range. [09:45] (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] 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] jtv: That would be okay. It implies that we need a way to allocate static addresses to containers and BMCs. [09:48] Yes, we'd effectively be managing our own DHCP but piggybacking on dhcpd for the protocol niceties. [09:48] 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] Yes... Horrible unforeseen complications aside I quite liked the idea of link-local addresses myself. [09:50] 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] |range| ≥ 2×|nics| + 2 [09:52] (Where the +2 comes from broadcast & base addresses) [09:52] jtv: Sounds good to me. Without a clairvoyant AI in MAAS I doubt we’ll do any better :) [09:53] You don't need a clairvoyant AI. You need a paranoid one. [09:53] Clairvoyance is great for average cases, but paranoid limits worst cases. [09:54] Hehe. Or Go. Go solves everything. === kentb-out is now known as kentb === matsubara is now known as matsubara-lunch [15:11] Who's up for a pre-imp about DNS changes for the new DHCP range? [16:03] jtv: I am. Sorry I didn’t see this until now. [16:03] jhobbs: Thanks for testing the lease parsing thing. [16:04] Hi, [16:04] allenap: np [16:04] jhobbs: One thing: you need to change the verification-needed tag to verification-done. [16:06] 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] I am looking for a way to test this before attempting to deply juju. [16:06] Any help would be seriously awesome!! [16:06] allenap: done [16:12] anyone ? [16:15] rkdemon2: https://maas.ubuntu.com/docs/juju-quick-start.html [16:16] 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] 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] rkdemon2: you can commission/install it then ssh into it [16:17] to clarify, I added the node as a virsh node. [16:18] i.e specified the mac id of the virsh virtual machine created on another server as a node [16:18] did you setup power controls for it? [16:19] no I do not know how to .. do I need it ? [16:19] yeah - http://maas.ubuntu.com/docs/nodes.html [16:19] the vm is up and created etc [16:19] there is a section on that doc talking about power controls for vm nodes [16:20] ok thanks.. let me read .. thank yo ufor your help [16:20] np === 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 [19:46] is there any sort of managed login strategy for maas? [19:47] each admin has their own key, but we share cluster resources [19:51] it _seems_ like it's trying to associate provisioned servers to a single user === roadmr is now known as roadmr_afk === vladk is now known as vladk|offline === roadmr_afk is now known as roadmr [20:44] 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? === CyberJacob is now known as CyberJacob|Away [22:07] dpb1: thats kind of expected behavior since that hostname is unresolveable. Whats your resulting hostname in /etc/hosts of the lxc container?