maas-devel team mailing list archive

[Gavin Panella <gavin.panella@xxxxxxxxxxxxx>]

On 29 May 2014 17:31, Dean Henrichsmeyer <dean@xxxxxxxxxxxxx> wrote:
> On Thu, May 29, 2014 at 4:26 AM, Mark Shuttleworth <mark@xxxxxxxxxx> wrote:
>>
>> On 27/05/14 16:02, Dean Henrichsmeyer wrote:
>> >  We're fine with such
>> > use being explicit - meaning you allocate explicitly by asking MAAS for
>> > it
>> > and you deallocate it explicitly by telling MAAS you don't need it
>> > anymore.
>>
>> That's what you'll get, yes. Not sure about the MAC for those IPs
>> though; do you prefer it as a new generated MAC for the host? Or an
>> additional IP for the existing NIC MAC?
>
>
> Actually neither. It's an IP that will be used as a service endpoint in
> OpenStack. There will be different hosts loosely associated with those
> virtual IPs at any given time so the IPs in question really shouldn't be
> tied to any known piece of hardware in MAAS.
>
> Explicit deallocation seems to be the most straightforward but there are
> other options. An IP could be "associated" with multiple nodes and remain
> allocated so long as *any* node is still associated with the IP. The
> downside of that would be as machines are added/removed from the pool that
> association would have to be managed.
>
> The main difference here is that the allocation of an IP for this purpose is
> distinctly independent from hardware resources in MAAS.

Fwiw, I favour allocating these addresses to users, and not associating
with hardware. Admins ought to then have access to an overview of where
IP addresses are going so they can deal with leaks.

There will then be at least three classes of address that MAAS can
manage:

1. A statically assigned address for a node's first NIC, associated with
   its MAC address.

   Any NIC can request an address from DHCP, but only one will get the
   statically assigned address that every node gets as part of being
   provisioned.

   This address is assigned when the node is provisioned, and will be
   reused for use with other hardware when the machine is deprovisioned.
   -- OR --
   This address is assigned by an admin and made "sticky". This means
   that it will always remain associated with the specific hardware,
   until that hardware is removed from MAAS.

   This is a special-case of #2.

2. Additional statically assigned addresses for a node's other NICs.

   These NICs can be hardware or virtual, e.g. for containers. The
   difference, as far as MAAS is concerned, is that the latter disappear
   when the machine is deprovisioned, and the former stay around.

   Addresses must be requested explicitly via MAAS's API.

   The NIC's MAC address must be associated with the node. MAAS may
   already be aware of the MAC address from hardware discovery, or may
   have to be told in the case of a virtual NIC.

   The address will then be associated with the MAC.

   The address will be garbage-collected automatically when
   deprovisioning the node, and will be reused for use with other
   hardware. MAC addresses from virtual NICs will also be forgotten
   during deprovisioning.

   DHCP requests from registered MAC addresses will yield the
   corresponding statically assigned address.

   The agent that requested the addresses, e.g. Juju, can optionally
   arrange for NIC configuration itself instead of deferring to DHCP.

   Implementation node: addresses obtained in this way from MAAS need to
   be in the DHCP config before the API call completes, so that the NIC
   can be brought up without delay (or getting into a race).

3. Additional statically assigned "floating" addresses.

   These addresses must be requested explicitly via MAAS's API.

   These addresses can only be unassigned by an explicit request via
   MAAS's API.

   These are not associated with hardware, they are only associated with
   a user.

   The DHCP server will never hand out these addresses; they are
   reserved. The agent that requested the addresses, e.g. Juju, must
   arrange for NIC configuration itself.