Comment 2 for bug 1653708

Revision history for this message
John A Meinel (jameinel) wrote :

I do believe there was intent to support dynamic operation. And we had certainly discussed something like RIP. I think what happened in practice is that people noticed that they can configure routes for a space as long as they are careful what subnets they assign to a space.
For example, if you do:
space: internal
  - Rack1:
  - Rack2:
  - Rack3:
  - ...
space: ceph-data
  - Rack1:
  - Rack2:
  - Rack3:
  - ...

Then you can create a "route to internal" as:
 - Rack 1: via via
 - Rack 2: via via
 - Rack 3: via via

And this is 'dynamic enough', because when you add Rack 4:
  internal: via
  ceph-data: via

You don't have to go back an update any of the "static" routes, because they
already allow you the spectrum of 255 racks.

It's a pragmatic solution that does fit in with how humans looking at route
tables would like to see them. You still get "route per space", you just have
to orchestrate your subnets such that they always fit within a larger CIDR.

I think that the way we would want to actually model it would *be* to have
users declare routes for space. (In subnet get to ceph-data space
That would, ultimately, give you more flexibility, as then if you ever grew
large enough that your original CIDR (/16) wasn't big enough, you could grab
any other unused range and the routes would update to follow.