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

Russell Bryant rbryant at redhat.com
Fri Mar 6 18:36:16 UTC 2015



----- Original Message -----
> >
> > micro-nit: OpenStack (capitalization here and elsewhere)
> Noted and fixed.
> 
> >> +* A logical port is created in Neutron with a port id that is same as the
> >> +vif-id associated with the virtual network interface (VIF) of VM-A.
> >
> > I get what this is saying.  It's not clear if the wording exactly
> > matches what happens, though.  Here's my attempt at expressing it:
> >
> > * A Neutron port may have been created in advance and passed in to Nova
> > with the request to create a new VM.  If not, Nova will issue a request
> > to Neutron to create a new port.  The ID of the logical port from
> > Neutron will also be used as the vif-id for the virtual network
> > interface (VIF) of VM-A.
> I am not very familiar with Neutron to understand the details. My
> understanding is based mainly on educated assumptions after seeing how
> OVS is eventually configured. So I will use the wordings that you have
> provided as-is. Thank you!

You're welcome!

> >> +* Since VM-A belongs to a logical network, it gets an IP address.  This
> >> IP
> >> +address is used to spawn containers (either manually or through container
> >> +orchestration systems) inside that VM and to monitor their health.
> >
> > This is a very minor clarification, but "their health" read as slightly
> > confusing for me.  It's not obvious if it means the health of the
> > containers specifically or both the containers and the VM.  I suppose
> > either interpretation is fine, but rewording might help.
> I updated the sentence to:
> This IP address is used to spawn containers (either manually or
> through container orchestration systems) inside that VM and to monitor
> the health of the created containers.

Sounds good to me.

> >
> > I figured out what this meant by "container network plugin" eventually,
> > but it wasn't clear at first.  It might be worth a bullet defining what
> > "container network plugin" means.  An attempt based on my understanding
> > so far:
> >
> > * This flow assumes a logical component called a "container network
> > plugin".  Hypothetically, you could envision either a wrapper for docker
> > or a feature of docker itself that understands how to perform part of
> > this flow to get a container connected to a logical network managed by
> > Neutron.  The rest of the flow refers to this logical component that
> > does not yet exist as the "container network plugin".
> I agree. I made slight modifications to your wordings. It now reads:
> 
> * This flow assumes a component called a "container network plugin".
> If you take Docker as an example for containers, you could envision
> the plugin to be either a wrapper around Docker or a feature of Docker itself
> that understands how to perform part of this workflow to get a container
> connected to a logical network managed by Neutron.  The rest of the flow
> refers to this logical component that does not yet exist as the
> "container network plugin".

That helps a lot, thanks!

> >> +* The container network plugin then makes a call to Neutron to create a
> >> +logical port.  In addition to all the inputs that a call to create a port
> >> in
> >> +Neutron is currently needed, it sends the vif-id and the VLAN tag as
> >> inputs.
> >
> > I would change "is currently needed" to "that are currently needed".
> Done.
> 
> >
> > Where would the vif-id and VLAN tag be specified in the request to
> > create a port?  It looks like there's a way to pass completely custom
> > data in the port create request in binding:profile.  Is there anything
> > better?
> >
> > http://developer.openstack.org/api-ref-networking-v2.html#port_binding-ext
> That is something I have consciously not mentioned in this document to leave
> the actual decision making to experts of Neutron.

Sure, that makes sense.  I was hoping some of the other OpenStack folks on the list would help provide input on this point.  It's mostly for my own understanding of how we could put this together.  That seems fine to leave it out of the document.

> >
> > As a higher level comment, if I understand correctly, the current
> > proposal would be to get this going as an OVN specific feature via
> > Neutron.  An alternative would be to create the container interface
> > concept in Neutron itself more officially.  That would certainly take
> > more time and work, so it could just be considered as potential future
> > work.
> Yes. The idea is to demo a workable solution. From Neutron end, if
> people like it, it could be enhanced to make it a native solution.

Sounds good.

Thanks again!

-- 
Russell Bryant



More information about the dev mailing list