27 lines
1.4 KiB
Org Mode
27 lines
1.4 KiB
Org Mode
Ok, so I met with Sangeetha and Bob from MCNS and I think I have an
|
|
idea of what needs to happen for our integrated network for us to
|
|
build things like MCNS and VMaaS.
|
|
|
|
First, you just need two things to be able to integrate at the
|
|
boundaries of Metal and Fabric, you need a VNI and you need a USE
|
|
port. Metal already has a service which allocates VNIs, so I was
|
|
wondering why Jarrod might not have told MCNS about it. Since VNIs and
|
|
USE ports are both shared resources that we want a single bookkeeper
|
|
over, there's only one logical point to do that today, and that's the
|
|
Metal API.
|
|
|
|
In a perfect world though, the Metal API doesn't orchestrate our
|
|
internal network state so specifically, at least I think. It'd be nice
|
|
if we could rip out the USE port management from the API and push that
|
|
down a layer away from the customer facing API. The end result is we
|
|
have internal services Metal API, MCNs, VMaaS all building on our
|
|
integrated network, but we still just have a single source of truth
|
|
for allocating the shared resources.
|
|
|
|
Sangeetha got a slice of VNIs and (eventually will have) USE ports for
|
|
them to build the initial MCNS product, but eventually we'll want to
|
|
bring those VNIs and ports under control of a single service, so we
|
|
don't have multiple bookkeeping spots for the same resources.
|
|
Jarrod's initial plan was to just build that in to the Metal API, but
|
|
if we can,
|