Open Stack

Hi Salvatore,

Thanks for the comments, added some more information.

Gal

On Sun, Jun 14, 2015 at 7:58 PM, Salvatore Orlando <sorlando at nicira.com>
wrote:

> Gal,
>
> thanks for this summery.
> Some additional info inline.
>
> Salvatore
>
> On 12 June 2015 at 19:38, Gal Sagie <gal.sagie at gmail.com> wrote:
>
>> Hello All,
>>
>> I wanted to share some of our next working items and hopefully get more
>> people on board with the project.
>> I personally would mentor any new comer that wants to get familiar with
>> the project and help
>> with any of these items.
>> You can also feel free to approach Russell Bryant (rbryant at redhat.com)
>> which is heading the OVN-Openstack integration.
>>
>> We both are usually active on IRC at #openstack-neutron-ovn (freenode) ,
>> you can drop us a visit if you have any questions.
>>
>> The Neutron sprint in Fort Collins [1] has a work item for OVN, hopefully
>> some work can start
>> there on some of these items (or others).
>> Russell Bryant and myself unfortunately won't be there, but feel free to
>> contact us online or in email.
>>
>> *1. Security Group Implementation*
>> Currently security groups are not being configured to OVN, there is a
>> document written
>> about how to model security groups to OVN northbound ACL's. [2]
>> I suspect getting this right is not going to be trivial, hopefully i
>> might be able to also start tackling
>> this item next week.
>>
>
> From what I recall Miguel was very interested in helping out on this
> front. Have you already reached out to him?
>

   [Gal] I will talk with him about it, thanks for letting me know.

>
>
>>
>> *2. Provider Network support*
>> Russell sent a design proposal to the ovs-dev mailing list [3], need to
>> follow on that
>> and implement in OVN
>>
>
> I think I have replied to that proposal with a few comments, perhaps you
> might have a look at those.
>

   [Gal] haven't read it yet, will probably get to it day after tommorow

>
>
>>
>> *3. Tempest configuration*
>> Russell has a patch for that [4] which needs additional help to make it
>> work.
>>
>
> That patch has merged now. So perhaps Russell does not need help anymore!
>

   [Gal] I synced with Russell before sending this list, the patch is not
merged yet (it depends on another patch)
            even that its reviewed, and i think the tempest job is still
failing, so more tweaking needs to be done.
            I am having a bit of crazy week, but will take it on my self
next week if nothing magical will happen :)

>
>> *4. Unit Tests / Functional Tests *
>> We want to start adding more testing to the project in all fronts
>>
>> *5. Integration with OVS-DPDK*
>> OVS-DPDK has a ML2 mechanism driver [5] to enable userspace DPDK
>> dataplane for OVS,
>> we want to try and see how this can combine with OVN mechanism driver
>> together. (one idea is to
>> use hierarchical port binding for that)
>> Need to design and test it and provide additional working items for this
>> integration
>>
>
> I think this is a rare case where the OVN integration might leverage
> additional mechanism drivers as AFAICT the DPDK driver mainly interacts
> with VIF plugging (operating at the Neutron port bindings level), and does
> not interfere with logical network resource processing.
>
>     [Gal] I agree, the reason why i proposed it here is because DPDK has
many benefits and require tweaking not only
in the VIF plugging but with the whole OVS-DPDK data plane bring up and
huge pages allocations and installation and so on, so
i thought we could get this for free by reusing that mechanism driver.
Of course someone needs to check that this integration actually works and
if not, what needs to be added to make it work.


>
>> *6. L2 Gateway Integration*
>> OVN supports L2 gateway translation between virtual and physical networks.
>> We want to leverage the current L2-Gateway sub project in stack forge [6]
>> and use it
>> to enable configuration of L2 gateways in OVN.
>> I have looked briefly at the project and it seems the API's are good, but
>> currently the
>> implementation relay on RPC and agent implementation (where we would like
>> to
>> configure it using OVSDB) , so this needs to be sorted and tested.
>>
>
> Last time I checked the progress of this project, they were focusing on
> ToR VxLAN offload as a first use case. And, as far as I recall, this is
> what networking-l2gw provides nowaday (Armando and Sukdev might have more
> info).
> Nevertheless, the API is generic enough that in my opinion it might be
> possible for OVN to leverage it. We shall implement a distinct l2gw service
> plugin like [1]; as I have some familiarity with this kind of APIs, let me
> know if I can be of any help.
>
> [1]
> http://git.openstack.org/cgit/openstack/networking-l2gw/tree/networking_l2gw/services/l2gateway/plugin.py
>

[Gal] Would love if you could help with this, from what i briefly saw the
API's seems generic enough, but as stated below we first need
        to see what is the correct way to configure it to OVN and thats
something that first needs to be resolved in OVN side i believe


>
>
>> Another issue is related to OVN it self which doesn't have L2 Gateway
>> awareness
>> in the Northbound DB (which is the DB that neutron configure) but only
>> has the API
>> in the Southbound DB
>>
>
> Yeah, this could be some sort of a problem... I don't think Neutron should
> interact with SB DB. OVN architecture has not been conceived to work this
> way.
>
>
>>
>> *7. QoS Support*
>> We want to be able to support the new QoS API that is being implemented
>> in Liberty [7]
>> Need to see how we can leverage the work that will implement this for OVS
>> in the
>> reference implementation and what additions need to be made for OVN case.
>>
>
> Do you already have anything in mind?
>

   [Gal] No, but i am participating in the QoS implementation effort in OVS
(will attend the sprint in Israel), i will try to see how we can
           implement this in such a way that OVN can leverage as well.
           The main problem here is that this implementation relies on an
agent :( , and even if we could do it all in OVSDB
           Still its something the ovn-controller will need to be aware of,
so thats another API support that is needed in OVN side.
           In general i think that a more generic approach should be
considered for the NB interface, since its basically in the end
           a subset of the Neutron API (i understand that its done this way
to support other CMS..)

>
>>
>
>> *8. L3 Implementation*
>> L3 is not yet implemented in OVN, need to follow up on the design and add
>> the L3 service plugin
>> and implementation.
>>
>
> If I can be of any help on this front, I'd be glad to offer my assistance
> (which may of no use for you, but that's another story!)
> By the way, is there a reason for which native OVN DHCP/metadata access
> support are not in this todo list?
>
>>
    [Gal] I think everyone agrees that your help is always useful , and i
appreciate any help.
            The problem here is that i feel i have less visibility on the
actual design decisions for the L3 implementation in OVN.
            As such i have no real idea what and how they plan to implement
it (and what will be the obvious scale problems).
            (For example, i think the correct way to handle this is to
share the thoughts in an email to the mailing list, or even in the scheduled
             IRC meeting, so feedback can be given before the design is
closed)

            If you can internally help with this that would be great.
            Once we know the design, we can implement it in the Neutron
integration and you are more then welcome to work
            on it, or we can work on this together that will be great as
well.

            Regarding the DHCP/metadata access, thats some good points, i
will make sure to add these to the list
            so we can track them (we currently track these with bugs in ovn
launchpad)


>
>>
>
>> *9. VLAN Aware VM's*
>> This is not directly related to OVN, but we need to see that OVN use case
>> of configuring parent
>> ports (for the use case of Containers inside a VM) is being addressed,
>> and if the implementation
>> is finished, to align the API for OVN as well.
>>
>
> I reckon the proposed API (master/child ports) or the alternative concept
> of trunk ports both map fairly well on the data structures so far
> implemented in OVN NB Database.
> From what I gather that mechanism, even if conceived for containers
> running in VMs, can also be used for NFV enabling through OVN, assuming
> that is even something OVN needs to care about.
>
>
>
>>
>> As i mentioned above, if you are interested in working on any of these
>> items please email me
>> or Russell back and we can get you started!
>>
>> Thanks
>> Gal.
>>
>> [1] https://etherpad.openstack.org/p/neutron-liberty-mid-cycle
>> [2]
>> https://github.com/stackforge/networking-ovn/blob/master/doc/source/design/data_model.rst
>> [3] http://openvswitch.org/pipermail/dev/2015-June/056212.html
>> [4] https://review.openstack.org/#/c/186894/
>> [5] https://github.com/stackforge/networking-ovs-dpdk
>> [6] https://github.com/stackforge/networking-l2gw
>> [7] https://review.openstack.org/#/c/182349/
>>
>> __________________________________________________________________________
>> 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
>
>


-- 
Best Regards ,

The G.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150614/3f20b8f3/attachment.html>