Open Stack

We had a call between Andrew (@xarses), Vladimir Kuklin (@aglarendil) and
myself (@mihgen) today to finally sort out Neutron ML2 integration in Fuel.
We didn't have @xenolog on the call, but hopefully he is more or less fine
with all below, and kindly request him to confirm :)
Discussed following topics, with an agreement from all participants:

   1. Risks of merging https://review.openstack.org/#/c/103280 (@xarses,
   upstream puppet module, will further refer as "280") vs
   https://review.openstack.org/#/c/103947 (@xenolog, extending existing
   puppet module with ML2 support, will further refer as "947")
      - We all agree, that 280 is strategically the way to go. It was so by
      design, and 947 was done only as risk mitigation plan in case if
280 is not
      ready in time
      - Both 280 and 947 were manually verified in combinations of
      ubuntu/centos/vlan/gre/ha, 280 needs to be verified with nova-network
      - 947 was ready a week ago and considered to be more stable solution
      - 280 is has much higher risks to introduce regressions, as it is
      basically rearchitecturing of Neutron puppet module in Fuel
      - 947 has backward compatibility support with legacy OVS, while 280
      doesn't have it at the moment
   2. Mellanox & VMWare NSX dependency on ML2 implementation rebase time
      - Rebase itself should not be hard
      - It has to be tested and may take up to next WE to do all
      rebases/testing/fixing
      - As both Mellanox & NSX Neutron pieces are isolated, it can be an
      exception for merging by next TH
   3. Discussed sanitize_network_config [1]
      - @aglarendil points out that we need to verify input params which
      puppet receives in advance, before waiting hours of deploy
      - @mihgen's point of view is that we need to consider each Fuel
      component as module, and verify output of it with certain input
params. So
      there is no point to verify input in puppet, if it's being verified in
      output of Nailgun.
      - @xarses says that we need to verify configuration files created in
      system after module execution, to check if it matches with module input
      params
      - Overall topic has been discussed much more extensively, and it
      needs further follow up. @aglarendil confirms that it is Ok to remove
      sanitize for now, but start writing much more tests to check that 280
      deploys correctly right away

Action plan we've come up with:

   1. Merge 947, as less risky at the moment, also considering the fact
   that 280 doesn't pass CI
      - this will immediately unblock Mellanox & NSX teams so they can
      rebase on ML2 implementation
   2. In parallel, create a test plan for 280 together with QA team
   3. @xenolog to join 280's effort, start fixing issues discovered there,
   including [2]
   4. Build an ISO, based on 280, and start testing it according to the plan
   5. Merge 280 once test plan is executed and issues fixed. Expected on
   Monday.

[1] https://review.openstack.org/#/c/99807/1/specs/5.1/ml2-neutron.rst
[2]
https://fuel-jenkins.mirantis.com/job/master_fuellib_review_systest_ubuntu/1608/

Thanks,


On Wed, Jul 9, 2014 at 10:31 PM, Andrew Woodward <xarses at gmail.com> wrote:

> Teams from MElanox and VMware based their work on current implementation
>> of Neutron
>
> Mlnx appears to not set any neutron settings, so wont be enabled correctly
> with out some more TLC
> (
> https://wiki.openstack.org/wiki/Mellanox-Neutron-Icehouse-Redhat#Neutron_Server_Node
> )
>
> NSX appears to be using legacy OVS, but assumes just whatever the default
> core_plugin is so it will need some TLC too.
>
>
>>    - to merge https://review.openstack.org/#/c/103280 in fuel-5.1
>>
>> Link is wrong should be https://review.openstack.org/#/c/103947
>
>
>>
>>    - To base Neutron implementation for 6.0 get
>>    https://review.openstack.org/#/c/103280/ and start working for adapt
>>    this for Juno Neutron.
>>
>> I still think we should merge it
>
>>
>>    - Also we should discuss how to make HA-wrapper more pluggable.
>>
>> https://review.openstack.org/#/c/103279/ makes it very pluggable, and
> felt like the best start, what else do we need to add in the near term?
> Should we just extend it as we move more components to it?
>
>
> On Wed, Jul 9, 2014 at 9:21 AM, Sergey Vasilenko <svasilenko at mirantis.com>
> wrote:
>
>> After review https://review.openstack.org/#/c/103280/ I have following
>> thoughts. This patch looks fine, but huge and has lot of changes in
>> deployment logic. Parallel teams work (vmware, melanox) depends on current
>> implementation of Neutron in FUEL. I have a some dreads, that they can’t
>> refactor his code in the short time remaining.
>>
>> Implementation https://review.openstack.org/#/c/103280 has considerably
>> less changes in current code of FUEL. Teams from MElanox and VMware based
>> their work on current implementation of Neutron. Also this implementation
>> was already tested in most deployment modes.
>>
>> On this basis, I suggest:
>>
>>    - to merge https://review.openstack.org/#/c/103280 in fuel-5.1
>>    - To base Neutron implementation for 6.0 get
>>    https://review.openstack.org/#/c/103280/ and start working for adapt
>>    this for Juno Neutron.
>>    - Also we should discuss how to make HA-wrapper more pluggable.
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Andrew
> Mirantis
> Ceph community
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Mike Scherbakov
#mihgen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140710/72e8d06a/attachment.html>