Overview
When creating epairs:
N is limited to 9999. I'd like this number to be larger, ideally, 2^24.
Discussion
Here's my use case:
I've created an application stack on my host and divided the ipv4 network up like this:
I have written automation to create a bunch of jails, and the jails are named: (B)_(C)_(D) like this:
* global_host_lb_10.0.0.2
* dev_bicycle_10.1.2.3
I was hoping to extend my naming scheme to the epairs that are created for the jails, like this:
This would be cool, as I could map ip address directly to the epair id (N) and life would be easy.
However, this isn't supported. From my testing, N must be a number between 0 and 9999.
man.freebsd.org
So in my case, if I squint my eyes, I can compress things a bit:
That's a total of 2^13 bits -> 0 to 8192. So I can just barely squeeze my app stack into the limits here. Note: I'll never create this many epairs... it'll be fairly sparse, so only a few hundred epairs will ever be created on a single host.
But if I want more component types in C, then my input domain expands, and I'll need an output range > 0 to 9999... as mentioned, 2^24 would be ideal.
Hopefully Bjoern A. Zeeb (epair author) will see this.
Alternatively, if someone has a great idea for how I can perform this sort of sparse mapping, I'm all ears.
-ToddG
When creating epairs:
Code:
ifconfig epair[N][a|b] create up
N is limited to 9999. I'd like this number to be larger, ideally, 2^24.
Discussion
Here's my use case:
I've created an application stack on my host and divided the ipv4 network up like this:
Code:
[A].[B].[C].[D]
A: static, always 10
B: a value of either global, dev, stage, or prod
C: a component type (foo, bar, baz, etc.)
D: instance (actual running jail instance)
I have written automation to create a bunch of jails, and the jails are named: (B)_(C)_(D) like this:
* global_host_lb_10.0.0.2
* dev_bicycle_10.1.2.3
I was hoping to extend my naming scheme to the epairs that are created for the jails, like this:
Code:
epair10.1.2.3a and epair10.1.2.3b
This would be cool, as I could map ip address directly to the epair id (N) and life would be easy.
However, this isn't supported. From my testing, N must be a number between 0 and 9999.
epair
So in my case, if I squint my eyes, I can compress things a bit:
Code:
[A].[B].[C].[D]
A: 10, static, requires: zero bits
B: limit environments to 4 values, requires: 2^2 bits
C: limit components to 8 values, requires: 2^3 bits
D: no easy way to limit this, so one of 255 values, requires: 2^8 bits
That's a total of 2^13 bits -> 0 to 8192. So I can just barely squeeze my app stack into the limits here. Note: I'll never create this many epairs... it'll be fairly sparse, so only a few hundred epairs will ever be created on a single host.
But if I want more component types in C, then my input domain expands, and I'll need an output range > 0 to 9999... as mentioned, 2^24 would be ideal.
Hopefully Bjoern A. Zeeb (epair author) will see this.
Alternatively, if someone has a great idea for how I can perform this sort of sparse mapping, I'm all ears.
-ToddG