Open Stack

On Fri, Feb 2, 2018 at 3:28 AM, Harald Jensås <hjensas at redhat.com> wrote:

> Requesting:
>   Feuture Freeze Exception request for Routed Spine and Leaf Deployment
>
> Blueprints:
> https://blueprints.launchpad.net/tripleo/+spec/tripleo-routed-networks-
> ironic-inspector
> https://blueprints.launchpad.net/tripleo/+spec/tripleo-routed-networks-
> deployment
>
> All external dependencies for Routed Spine and Leaf Deployement have
> finally landed. (Except puppet module changes.)
>
>
> Pros
> ====
>
> This delivers a feature that has been requested since the Kilo release.
> It makes TripleO more viable in large deployments as well as in edge
> use cases where openstack services are not deployed in one datacenter.
>
> The core piece in this is the neutron segments service_plugin. This has
> been around since newton. Most of the instack-undercloud patches were
> first proposed during ocata.
>
> The major change is in the undercloud. In tripleo-heat-templates we
> need just a small change to ensure we get ip addresses allocated from
> neutron when segments service plug-in is enabled in neutron. The
> overcloud configuration stays the same, we already do have users
> deploying routed networks in the isolated networks using composable
> networks so we know it works.
>
>
> Risks
> =====
>
> I see little risk introducing a regression to current functionality
> with these changes. The major part of the undercloud patches has been
> around for a long time and passing CI.
>
> The format of undercloud.conf is changed, options are deprecated and
> new options are added to enable multiple control plane subnets/l2-
> segments to be defined. All options are properly deprectated, so
> using a configuration file from pike will still work.
>
>
>
> =====================================
> The list of patches that need to land
> =====================================
>
> instack-undercloud
> ------------------
>
> * Tripleo routed networks ironic inspector, and Undercloud
>   https://review.openstack.org/#/c/437544/
> * Move ctlplane network/subnet setup to python
>   https://review.openstack.org/533364
> * Update config to use per network groups
>   https://review.openstack.org/533365
> * Update validations to validate all subnets
>   https://review.openstack.org/533366
> * Add support for multiple inspection subnets
>   https://review.openstack.org/533367
> * Create static routes for remote subnets
>   https://review.openstack.org/533368
> * Add per subnet network cidr nat rules
>   https://review.openstack.org/533369
> * Add per subnet masquerading
>   https://review.openstack.org/533370
> * Install and enable neutron baremetal mech plugin
>   https://review.openstack.org/537830
>
> tripleo-heat-templates
> ----------------------
>
> * Add subnet property to ctlplane network for server resources
>   https://review.openstack.org/473817
>
> tripleo-docs
> ------------
>
> * Documentation - TripleO routed-spine-and-leaf
>   https://review.openstack.org/#/c/539939/
>
> puppet-neutron
> --------------
>
> * Add networking-baremetal ml2 plug-in
>   https://review.openstack.org/537826
> * Add networking-baremetal - ironic-neutron-agent
>   https://review.openstack.org/539405
>
>
I'm a bit concerned by the delay of this request. Feature freeze request
deadline was 10 days ago:
https://releases.openstack.org/queens/schedule.html#q-ff

We're now in the process on producing a release candidate. The amount of
code that needs to land to have the feature completed isn't small but it
looks like well tested and you seems pretty confident.
I'm not sure what to vote on this one tbh because yeah the use-case is
super important, and we know how Queens release is important to us. But at
the same time there is a risk to introduce problems, and delay the
potentially delay the release and after the delivery of other features...

I guess I'm ok as long as all patches pass ALL CI jobs without exception
and are carefully tested and reviewed.

Thanks,
-- 
Emilien Macchi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180204/c2fbce8b/attachment.html>