> > 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! >> +* 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. > > 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". >> +* 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. > > 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. > > -- > Russell Bryant _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
