On Tue, Sep 13, 2016 at 11:13 PM, Antoni Segura Puimedon <[email protected] > wrote:
> On Tue, Sep 13, 2016 at 5:05 PM, Hongbin Lu <[email protected]> wrote: > > > > > > On Tue, Sep 13, 2016 at 2:10 AM, Vikas Choudhary > > <[email protected]> wrote: > >> > >> > >> > >> On Mon, Sep 12, 2016 at 9:17 PM, Hongbin Lu <[email protected]> > wrote: > >>> > >>> Ivan, > >>> > >>> Thanks for the proposal. From Magnum's point of view, this proposal > >>> doesn't seem to require to store neutron/rabbitmq credentials in > tenant VMs > >>> which is more desirable. I am looking forward to the PoC. > >> > >> > >> Hogbin, Can you please elaborate on this will not require to store > neutron > >> credentials? > >> For example in libnetwork case, neutron's commands like "show_port" and > >> "update_port" will still need to be invoked from inside VM. > > > > > > In a typical COE cluster, there are master nodes and work (minion/slave) > > nodes. Regarding to credentials, the following is optimal: > > * Avoid storing credentials in work nodes. If credentials have to be > stored, > > move them to master nodes if we can (containers are running in work > nodes so > > credentials stored there have a higher risk). A question for you, > neutron's > > commands like "show_port" and "update_port" need to be invoked from work > > nodes or master nodes? > > * If credentials have to be stored, scope them with least privilege > (Magnum > > uses Keystone trust for this purpose). > > I think that with the ipvlan proposal you probably can do without having > to call > Vikas: To me it looks like 'from where to make neutron calls' part is same in both the approaches(address-pairs and vlan-aware-vms). What neutron api calls are made that will differ(no neutron port creation in ipvlan approach rather port_update) but whether we make those calls from inside worker vm or master vm that is going to be dependent on the choice of 'neutron communication mode' ('rest_driver' or 'rpc_driver') . Please correct me if I understood something wrong. > those two. IIUC the proposal the binding on the VM, taking libnetwork > as an example > would be: > > 1. docker sends a request to kuryr-libnetwork running in container-in-vm > mode. > 2. kuryr-libnetwork forwards the request to a kuryr daemon that has > the necessary > credentials to talk to neutron (it could run either in the master node > or in the compute > node just like there is the dhcp agent, i.e., with one foot on the VM > network and one > on the underlay). > 3. The kuryr daemon does the address pair proposal requests to Neutron > and returns > the result to the kuryr-libnetwork in the VM, at which point the VM > port can already > send and receive data for the container. > 4. kuryr-libnetwork in the VM creates an ipvlan virtual device and > puts it the IP > returned by the kuryr daemon. > > > > >> > >> > >> Overall I liked this approach given its simplicity over vlan-aware-vms. > >> > >> -VikasC > >>> > >>> > >>> Best regards, > >>> Hongbin > >>> > >>> On Mon, Sep 12, 2016 at 7:29 AM, Coughlan, Ivan < > [email protected]> > >>> wrote: > >>>> > >>>> > >>>> > >>>> Overview > >>>> > >>>> Kuryr proposes to address the issues of double encapsulation and > >>>> exposure of containers as neutron entities when containers are running > >>>> within VMs. > >>>> > >>>> As an alternative to the vlan-aware-vms and use of ovs within the VM, > we > >>>> propose to: > >>>> > >>>> - Use allowed-address-pairs configuration for the VM neutron > >>>> port > >>>> > >>>> - Use IPVLAN for wiring the Containers within VM > >>>> > >>>> > >>>> > >>>> In this way: > >>>> > >>>> - Achieve efficient data path to container within VM > >>>> > >>>> - Better leverage OpenStack EPA(Enhanced Platform Awareness) > >>>> features to accelerate the data path (more details below) > >>>> > >>>> - Mitigate the risk of vlan-aware-vms not making neutron in > >>>> time > >>>> > >>>> - Provide a solution that works on existing and previous > >>>> openstack releases > >>>> > >>>> > >>>> > >>>> This work should be done in a way permitting the user to optionally > >>>> select this feature. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Required Changes > >>>> > >>>> The four main changes we have identified in the current kuryr codebase > >>>> are as follows: > >>>> > >>>> · Introduce an option of enabling “IPVLAN in VM” use case. > This > >>>> can be achieved by using a config file option or possibly passing a > command > >>>> line argument. The IPVLAN master interface must also be identified. > >>>> > >>>> · If using “IPVLAN in VM” use case, Kuryr should no longer > >>>> create a new port in Neutron or the associated VEth pairs. Instead, > Kuryr > >>>> will create a new IPVLAN slave interface on top of the VM’s master > interface > >>>> and pass this slave interface to the Container netns. > >>>> > >>>> · If using “IPVLAN in VM” use case, the VM’s port ID needs to > be > >>>> identified so we can associate the additional IPVLAN addresses with > the > >>>> port. This can be achieved by querying Neutron’s show-port function > and > >>>> passing the VMs IP address. > >>>> > >>>> · If using “IPVLAN in VM” use case, Kuryr should associate the > >>>> additional IPVLAN addresses with the VMs port. This can be achieved > using > >>>> Neutron’s allowed-address-pairs flag in the port-update function. We > intend > >>>> to make use of Kuryr’s existing IPAM functionality to request these > IPs from > >>>> Neutron. > >>>> > >>>> > >>>> > >>>> Asks > >>>> > >>>> We wish to discuss the pros and cons. > >>>> > >>>> For example, containers exposure as proper neutron entities and the > >>>> utility of neutron’s allowed-address-pairs is not yet well understood. > >>>> > >>>> > >>>> > >>>> We also wish to understand if this approach is acceptable for kuryr? > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> EPA > >>>> > >>>> The Enhanced Platform Awareness initiative is a continuous program to > >>>> enable fine-tuning of the platform for virtualized network functions. > >>>> > >>>> This is done by exposing the processor and platform capabilities > through > >>>> the management and orchestration layers. > >>>> > >>>> When a virtual network function is instantiated by an Enhanced > Platform > >>>> Awareness enabled orchestrator, the application requirements can be > more > >>>> efficiently matched with the platform capabilities. > >>>> > >>>> > >>>> http://itpeernetwork.intel.com/openstack-kilo-release-is- > shaping-up-to-be-a-milestone-for-enhanced-platform-awareness/ > >>>> > >>>> https://networkbuilders.intel.com/docs/OpenStack_EPA.pdf > >>>> > >>>> > >>>> https://www.brighttalk.com/webcast/12229/181563/epa- > features-in-openstack-kilo > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Regards, > >>>> > >>>> Ivan…. > >>>> > >>>> -------------------------------------------------------------- > >>>> Intel Research and Development Ireland Limited > >>>> Registered in Ireland > >>>> Registered Office: Collinstown Industrial Park, Leixlip, County > Kildare > >>>> Registered Number: 308263 > >>>> > >>>> This e-mail and any attachments may contain confidential material for > >>>> the sole use of the intended recipient(s). Any review or distribution > by > >>>> others is strictly prohibited. If you are not the intended recipient, > please > >>>> contact the sender and delete all copies. > >>>> > >>>> > >>>> > >>>> ____________________________________________________________ > ______________ > >>>> OpenStack Development Mailing List (not for usage questions) > >>>> Unsubscribe: > >>>> [email protected]?subject:unsubscribe > >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >>>> > >>> > >>> > >>> > >>> ____________________________________________________________ > ______________ > >>> OpenStack Development Mailing List (not for usage questions) > >>> Unsubscribe: > >>> [email protected]?subject:unsubscribe > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >>> > >> > >> > >> ____________________________________________________________ > ______________ > >> OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: [email protected]?subject: > unsubscribe > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > > > > > > ____________________________________________________________ > ______________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: [email protected]?subject: > unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
