Open dowlingw opened 8 years ago
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:
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,
...
}
]
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"
]
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.
One of our services is a internet peering product, so the two big resource allocations here are:
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:
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).
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.
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?
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:
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 :)