curiosity: how stupid (or even possible) of an idea is it to use pulumi's state to manage a simple IPAM setup? i know e.g. AWS has an IPAM pool, but afaik that extends only down to the VPC level; once a pulumi stack has created and owned a VPC, i would like to subdivide the ip space within that VPC; i currently have a stateful reducer-style function that takes in some previous ip pool state, any new requests/changes for addresses, and produces a new ip pool state. i looked briefly at dynamic resources and stashes but i'm not sure either of them solve this… a dynamic resource per ip allocation i don't think works (the state is the culmination of all allocations, so a single allocation itself doesn't really have any way to communicate with other requested allocations afaik)… but it feels like this is something that should technically be possible for pulumi to do, at least at the stack level? afaik, when performing actions, the entire stack is locked and the stack state transitions atomically from state

S

to

S'

after some operation (e.g.

up

) so… my intuition says if there was some way to a) get the current ip pool from

S

, b) determine ALL the desired ip allocation resource changes during the operation, and c) provide the new ip pool to

S'

, then such a system would be possible within pulumi itself and not having to rely on an additional external system.

I don't know if IPAM in this question is an actual AWS service (never heard of it), but if you just mean contiguous CIDRs, then you could look at Pulumi's AWSX package. The VPC wrapper that it provides has this built in. https://www.pulumi.com/registry/packages/awsx/api-docs/ec2/vpc/

thanks @little-cartoon-10569 🙂 from reading this code it looks like the intent is that when this vpc resource is allocated it knowingly "owns" or controls the entire vpc cidr space? any subdivisions within the vpc are made once, at the time this vpc resource is created? there is no proviso here that i see that could allow consumers of this vpc resource to dynamically request or release a slice of the vpc ip space?

The VPC and the CIDRs are owned by the account, so there is no difference, from AWS' point of view. If you wanted to allow a group of resources to have exclusive access to a subset of the CIDR, the usual solution is to define subnets for that purpose. While you could add additional management on top of what's normally provided (is that the IPAM pool functionality that you mentioned?), the easy solution (in my mind) would be to define up front as many subnets as you think you might ever need, then hand them out on demand.

> the usual solution is to define subnets for that purpose. [...] the easy solution (in my mind) would be to define up front as many subnets as you think you might ever need, then hand them out on demand. yes i was kind of hoping to avoid this "ahead-of-time" slicing if it were possible but maybe it's not. it is certainly easier. was hoping for pulumi resources to be able to say "i need a pool of at least N addresses" and have my allocator hand out a provisioned slice of the VPC that lives and is fixed as long as the resource is alive (and will also not be taken away during the resource lifetime), and then that slice is freed when the resource dies and available to other resources (akin to like a memory allocator or a dhcp server in some ways i guess). > is that the IPAM pool functionality that you mentioned i think so; IPAM = IP address management, which is kind of an umbrella term for managing ownership of IP spaces; AWS has a service for this but it only extends to the VPC level afaik

yes i was kind of hoping to avoid this "ahead-of-time" slicing if it were possible but maybe it's not

You could do it as a service, implemented via automation-api. You can also do it with regular component resources, but it is "ahead of time" in that you need to run

pulumi up

every time to change it.

> You could do it as a service, implemented via automation-api. is there… very rough pseudo-code or skeleton about what the shape of that might look like? i have never used automation-api before

Yea I think the docs are quite good, and there's example code in GitHub. Onesec I'll grab the links.

It's kind of how subnetting works (especially with VPCs) - if you don't preplan it things get tricky, as Subnet CIDRs are not mutable. So if you need more IPs you have to migrate all your workloads.

thanks for all the info, i will have a look! 🙂

i think is a great idea. Worth a try...

I tried to do this previously, although it never got beyond POC... The way I approached it was similar to your reducer approach. I defined a singleton that contained a reference to the last allocation, which I used as a synchronization point. Each time a new allocation was requested it would depend on the previous one so they would be created sequentially. Allocations remained stable by using something similar to the stash resource. I kept track of the current set of allocations in the singleton for determining the next slice, and I initialized the set by listing the subnets in the vpc to account for existing allocations. So essentially: • For the initial stack update, each allocation chains onto the previous one so they don't clobber each other • For the next stack update, we don't re-allocate existing allocations due to their state being stashed, but the IPAM singleton is still aware of them because it lists the subnets in its VPC during init This only works within the context of a single stack though

super interesting, thanks @hallowed-baker-22997; seems like i am at least not alone in my idea 😅 very clever to effectively make kind of a "block-chain"-esque sequence of state updates/storage