Feature: Resource allocations

[dowlingw]

As an API consumer, I want to be able to request a resource from a named pool and allocate it to myself so that I can automatically allocate resources during service provisioning

Right now, I imagine the allocation request would contain the following items:

• pool name
• any search criteria (attribute based) to filter which candidate resources are selected from the pool

My initial use case is allocating IP addresses and switch ports for L2VPN provisioning, but depending on the design (I haven't had a deep dive into code yet) this might be feasible for any resource type.

If this fits with the goals and designs of nsot I should have no problem contributing :)

[jathanism]

Let's stick with Networks since that is your use-case, and this is something I think could be solved by the current IPAM feature set in NSoT. I am, however, interested in hearing how you think this might apply to other resource types.

I think this can mostly be done right now in roughly 3 steps using a combination of attributes and API methods, which would be:

• Lookup a Network by its attributes. Let's say pool=foo other_lookup=bar. The criteria of this lookup should be something that returns a single Network. Let's say, for example, this is your L2VPN pool. Let's say it returns 192.168.1.0/24.

(I omitted the rest of the fields for illustration)

GET /api/sites/1/networks/query/?query=pool=foo other_lookup=bar
[
    {
        "network_address": "192.168.1.0",
        "prefix_length": 24,
        ...
    }
]

• So now you can use the next_network method to return some IP addresses. Let's say you want 2 /32 host addresses. Let's say it returns 192.168.1.10/32 and 192.168.1.11/32.

GET /api/sites/1/networks/192.168.1.0/24/next_address/?num=2
[
    "192.168.1.10/32",
    "192.168.1.11/32"
]

• Then you could allocate those objects in the database, tagging them with any attribute/values you feel appropriate

POST /api/sites/1/networks/
[
    {
        "cidr": "192.168.1.10/32",
        "attributes": {...}
    },
    {
        "cidr": "192.168.1.11/32",
        "attributes": {...}
    }
]

Sorry if it feels like I'm over-explaining. I'm still working on putting together usage guides and this is kind of a dual purpose exercise for me.

I would also like to see if we could use your request to make this kind of workflow possible within a single API call.

[dowlingw]

One of our services is a internet peering product, so the two big resource allocations here are:

• Find & allocate an unallocated INTERFACE with the right attributes
• Find & allocate an unallocated NETWORK with the right attributes

You're absolutely right though, this is possible right now using attributes.

For me this is something I'll do for multiple resource types, but I think I might be polluting your problems with my own.

I guess this could boil down to the following requirement for nsot itself:

• Ability to use the search for resources without a given attribute (ie: unallocated resources)

Setting attributes by criteria (with num restriction) would definitely help to make consuming this easier, but isn't critical (at the expense of client complexity).

[jathanism]

I like that direction. The concept of an "unallocated resource" is certainly more tangible. In the case of Networks, it means it just doesn't exist in the database.

I think that for Interfaces, "unallocated" could possibly mean "without any addresses assigned to it", but that isn't something easily accessible through the API right now as a filter criteria.

[dowlingw]

Ah ok, for my use case the interface is physical and when allocated it wouldn't have an address assigned (it spans onto L2).

I think I would want to pre-generate both the network and interface resources, so I think I'd want to search for objects with an attribute either without a value (if that's allowed) or just some kind of "NULL" value.

Does that sound sane?