[ovs-dev] [PATCH] ovn: Design and Schema changes for Container integration.

[Russell Bryant]

----- Original Message -----
> >
> > * The Neutron API call here to create a logical port for the container
> > could add a relatively significant amount of time to container creation.
> >  However, an optimization is possible here.  Logical ports could be
> > created in advance and reused by the container system doing container
> > orchestration.  Additional Neutron API calls would only be needed if the
> > port needs to be attached to a different logical
> I spoke to a couple of guys from the Neutron project about how much is
> 'relatively significant amount of time'?
> The answer I get is that it takes less than a second to create a port.
> (On my relatively large internal openstack cloud, my experience with
> creation of a Neutron port has been fast too. Yes, there are times,
> when it looks like it takes time).
> 
> In your experience, on an average, how many seconds does it take to
> create a Neutron port?
> 

I don't have a number to offer. It's more theoretical. In the best case
it's "fast", of course.

I'm assuming that something taking a few seconds has real meaning here
in comparison to container creation and in some cases container runtime.
The API call to create a port for a container has a lot of interactions
between different systems that seem to me could reasonably add up to an
amount of time considered meaningful for containers.

Here's a more detailed view of those interactions.  This is from memory,
so don't hold me to the exact details.  :-)

1) If the container manager has a Keystone token and a copy of the
service catalog, great.  If not, the container manager must issue a REST
API call to the Keystone API to authenticate, get a token, and get a
copy of the service catalog.  It may then make multiple round trips to
backend services, depending on configuration:

1a) Keystone will then hit a SQL server or LDAP service to process
authentication.

1b) Keystone may hit a SQL server to load the service catalog.

1c) Keystone may hit a SQL server to store the token it generates after
successful authentication.

2) Now the container manager can issue the port request to Neutron.
This is a REST API call to the Neutron API service.  This results in:

2a) Depending on the Keystone setup, the Neutron API service may have to
do a REST API call over to Keystone to validate that the token is valid.

2b) Neutron will hit a SQL server to retrieve details about the network
the port is associated with.

2c) Neutron will hit a SQL server to create a new record for the port
being created.

2d) In the OVN driver, it's going to look at the parent port ID and do
another SQL server query to make sure that port is valid and is
accessible by this tenant.

2e) The OVN driver will create the port in the OVN northbound DB.

2f) At this point, the container manager needs to wait for the port to
be marked as 'up'.  There is a mechanism where Neutron will
asynchronously issue a REST API call back to Nova (the VM management
service) to let it know that a port is ready.  In this container
integration case, we'll have to come up with a way for that notification
to go to the container manager, instead.


So, we've got 1 REST API call with a few round-trips to a SQL database
at best.  At worst, it's 3 REST API calls with 6 SQL round trips.  After
all that there's some undefined synchronization method needed with the
container manager to let it know the port is 'up'.  I feel like I may be
forgetting something, but that's the general idea.

The optimization would let the container manager do that process *far*
less often, which seems like a nice win.

-- 
Russell Bryant