maas-devel team mailing list archive

[Dean Henrichsmeyer <dean@xxxxxxxxxxxxx>]

I think the CIDR format would be fine. That's currently how users define
networks in OpenStack and that seems to be the most reliable way of
identifying the right network. I think dealing with interfaces and/or names
or labels could lead to confusion. It seems it would be fairly portable too
since it should work for ipv6 as well.

-Dean


On Fri, Jun 27, 2014 at 10:18 AM, Andres Rodriguez <
andres.rodriguez@xxxxxxxxxxxxx> wrote:

> Dean,
>
> Would this fit Landscape's need for the address reservation API?
>
> Thanks
>
>
> On Wed, Jun 25, 2014 at 3:03 AM, Julian Edwards <
> julian.edwards@xxxxxxxxxxxxx> wrote:
>
>> We need to add some API support for obtaining new IPs, in the following
>> scenarios:
>>
>>  * Unmanaged devices - To claim a static IP for a particular MAC
>> address; writes a DHCP map.
>>
>>  * Extra node IP - To claim an additional static IP for another MAC (or
>> NIC alias) on a node; writes a DHCP map.
>>
>>  * User reservation - To claim an IP on a network for use outside MAAS;
>> no DHCP map required, it just stops MAAS from using it
>>
>> I am currently trying to work out where best to place API endpoints for
>> these operations.  I think the "extra node IP" is easy, that will sit as
>> an operation on the node endpoint.
>>
>> But the others are not so straightforward.  To help understand, here's
>> what parameters and return values are needed for each:
>>
>> Operation             Parameters                    Returns
>> ---------             ----------                    -------
>>
>> New Unmanaged Device  MAC, cluster interface        IP Address
>>    (admin only)
>>
>> New Reserved IP       MAC, cluster interface, user  IP Address
>>
>> (We also need to have list, read and delete operations, not listed here
>> for brevity)
>>
>> Each of the "cluster interface" parameters are required so we know on
>> which network the IP must be allocated.  We have a few different ways to
>> identify a cluster interface, some of which may be more or less
>> appropriate depending on what the caller already knows:
>>
>>  - the network details, e.g. N.N.N.N/bits (or ipv6 equivalent)
>>  - the cluster ID plus one of its NIC names (won't work for IPv6 I am
>> told by jtv, he can explain)
>>  - the cluster ID plus some new surrogate identifier
>>  - invent our own new syntax
>>
>> None of these are particularly palatable.
>>
>> Depending on how we solve this identification issue will dictate the API
>> endpoint.  All comments welcome here!
>>
>> J
>>
>> --
>> Mailing list: https://launchpad.net/~maas-devel
>> Post to     : maas-devel@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~maas-devel
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
>
> --
> Andres Rodriguez
> Engineering Manager, HWE Team
> Canonical USA, Inc.
>