Open Stack

On Tue, Sep 13, 2016 at 11:13 PM, Antoni Segura Puimedon <celebdor at gmail.com
> wrote:

> On Tue, Sep 13, 2016 at 5:05 PM, Hongbin Lu <hongbin034 at gmail.com> wrote:
> >
> >
> > On Tue, Sep 13, 2016 at 2:10 AM, Vikas Choudhary
> > <choudharyvikas16 at gmail.com> wrote:
> >>
> >>
> >>
> >> On Mon, Sep 12, 2016 at 9:17 PM, Hongbin Lu <hongbin034 at gmail.com>
> 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 <
> ivan.coughlan at intel.com>
> >>> 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:
> >>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>>
> >>>
> >>>
> >>>
> >>> ____________________________________________________________
> ______________
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe:
> >>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>
> >>
> >> ____________________________________________________________
> ______________
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
> unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> > ____________________________________________________________
> ______________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160914/41190e64/attachment-0001.html>