Multiple ranges are not available for any networks but Public and Floating

[Dmitriy Novakovskiy]

In 5.0 we've got support for multiple network ranges to be for logical OpenStack networks - blue "plus" button (http://goo.gl/h9uNxG).

Actual behavior: As of now (fuel 5.0) it is available only for Public and Floating networks.
Expected behavior: Multiple network ranges should be available for all logical OpenStack networks (Management, Internal, etc)

[Aleksey Kasatkin (alekseyk-ru)]

This is to be resolved within https://blueprints.launchpad.net/fuel/+spec/advanced-networking BP.

[Dmitriy Novakovskiy (dnovakovskiy)]

Привет!

А почему won't fix?

---
Regards,
Dmitriy

On Wed, Jul 16, 2014 at 5:49 PM, Aleksey Kasatkin <email address hidden>
wrote:

> ** Changed in: fuel
> Status: Confirmed => Won't Fix
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1341026
>
> Title:
> Multiple ranges are not available for any networks but Public and
> Floating
>
> Status in Fuel: OpenStack installer that works:
> Won't Fix
>
> Bug description:
> In 5.0 we've got support for multiple network ranges to be for logical
> OpenStack networks - blue "plus" button (http://goo.gl/h9uNxG).
>
> Actual behavior: As of now (fuel 5.0) it is available only for Public
> and Floating networks.
> Expected behavior: Multiple network ranges should be available for all
> logical OpenStack networks (Management, Internal, etc)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/fuel/+bug/1341026/+subscriptions
>

[Aleksey Kasatkin (alekseyk-ru)]

It will be fixed with implementation of "advanced networking" feature (please look at comment #1). We now close bugs which request architecture changes etc. and don't require immediate fix. We make BPs instead. That BP was created already.

[Andrew Woodward (xarses)]

The design document for advanced networking does not cover this. Neither is this an architecture change, all of the networks support network ranges, they are just not shown on the UI.

This could be absorbed into advanced networking, but it would have to be described on the spec prior to marking this as wont fix.

[Aleksey Kasatkin (alekseyk-ru)]

Okey. It was discussed on design sessions. I clarified that in design doc now.
Yes, it's not so big change. I suppose it requires only fixture changes. UI should reflect them properly. But I'm not sure about manifests.

[Dmitriy Novakovskiy (dnovakovskiy)]

A follow-up item to this bug - looks like multiple ranges for Public network (and, in turn, Floating IPs) can be defined only within single CIDR and VLAN.

This is a significant constraint which needs solution. In real world, if admin is provisioning a number of Floating IP pools from company's bank of routable IPv4 addresses, they are likely to be within different subnets.

[Aleksey Kasatkin (alekseyk-ru)]

Yes, every network can have single CIDR, VLAN and gateway in present model.
Floating IP ranges can now be placed in different CIDRs in case of nova-network. AFAIR, there was a ticket on providing the same behaviour in case of Neutron. There is no separate floating network object now but a list of IP ranges is defined for a cluster.
It's required to figure out what networks (network roles in terms of "advanced networking") can have several CIDRs etc.
I'd propose the following options to solve single-cidr problem within "advanced networking" concept:
1. Allow M:M network-roles-to-networks mapping so every network role (e.g. 'public') can be mapped to a number of networks.
2. Allow multi-CIDR (multi-gateway etc.) for every network while keeping network-roles-to-networks mapping M:1. It seems that this will require the introduction of CIDR-to-IP_range mapping, CIDR-to-gateway mapping etc. inside the network.

I like first option more as it uses existing entities and introduses less additional complexity.
Either option will require UI redesign and may be changes in library part.

[Aleksey Kasatkin (alekseyk-ru)]

Results of our yesterday's discussion:
this is a feature request, it will be covered with the following BPs:
https://blueprints.launchpad.net/fuel/+spec/advanced-networking
https://blueprints.launchpad.net/fuel/+spec/multiple-cluster-networks
The BPs are linked to this ticket.

[Mike Scherbakov (mihgen)]

New bp name: https://blueprints.launchpad.net/fuel/+spec/granular-network-functions

[Mike Scherbakov (mihgen)]

According to the discussion with product management (Nathan, Craig P.), we believe that this is pretty important, thus changing priority to High for 7.0.

[Aleksey Kasatkin (alekseyk-ru)]

This is fully covered by https://blueprints.launchpad.net/fuel/+spec/granular-network-functions itself. Each network will be able to have all possible parameters as network definition is separated from network role.

[Andrew Woodward (xarses)]

The fixture can be changed to ranges, but ranges cause serialization errors. This must be fixed in 7.0 and back ported to 6.1. No real network doesn't need ranged and requires hacking into the database to fix this.

The only way to work around this is to leave the fixtures as they are and manipulate the values in the serializer.

[Andrew Woodward (xarses)]

Which bp is this covered by? its still wrong in the UI and must be fixed with https://bugs.launchpad.net/fuel/+bug/1469328

[Ihor Kalnytskyi (ikalnytskyi)]

It should be fixed, for sure, after this one - https://bugs.launchpad.net/fuel/+bug/1365368 Let's do not start until then.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/211464

[OpenStack Infra (hudson-openstack)]

Change abandoned by Ivan Kliuk (<email address hidden>) on branch: master
Review: https://review.openstack.org/211464
Reason: It was resolved not to change default 'notation' values.

[Mike Scherbakov (mihgen)]

Is not this bug a duplicate of Bug #1365368 ?

[Ihor Kalnytskyi (ikalnytskyi)]

@Mike, they are similar but a bit different. Actually, the fix of this bug will include the fix for the bug #1365368.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/209892
Committed: https://git.openstack.org/cgit/stackforge/fuel-web/commit/?id=fb684c7c6e1ef3b9719a9c2559da0a31fb9131bb
Submitter: Jenkins
Branch: master

commit fb684c7c6e1ef3b9719a9c2559da0a31fb9131bb
Author: Ivan Kliuk <email address hidden>
Date: Sat Aug 1 11:15:00 2015 +0300

    Allow modification of NetworkGroup.meta

    * Additional validation logic for network configuration update.
    * Network configuration is validated using JSON-schema.
    * Unit tests for new validation logic and JSON-schema.
    * Additional helper methods in 'BaseValidatorTest'.
    * Minor cosmetic changes of 'test_network_template_validator.py'.

    Change-Id: Ibc4e7091eed299f513d850d7aa44453be14b9f40
    Closes-bug: #1365368
    Closes-bug: #1341026
    Closes-bug: #1469328

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/213347

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/213347
Committed: https://git.openstack.org/cgit/stackforge/fuel-web/commit/?id=2f75e217185cfeb64b8f43be87418dcf29684be6
Submitter: Jenkins
Branch: master

commit 2f75e217185cfeb64b8f43be87418dcf29684be6
Author: Ivan Kliuk <email address hidden>
Date: Fri Aug 14 20:48:40 2015 +0300

    [Tech debt] Networking validation schema change

    * Removed redundant 'network_group.NETWORK_GROUP' JSON-schema.
    * Added 'networks.NETWORK_CONFIGURATION', 'networks.NETWORK_GROUP' and
      'networks.NETWORK_GROUPS' JSON-schemas.
    * Network parameters are validated with corresponding JSON-schema.
    * Improved testing of validation process.

    Change-Id: Id86c1543ddd437f15242b384034d72e29a7e4ebc
    Partial-bug: #1365368
    Partial-bug: #1341026
    Partial-bug: #1469328

[Vitaly Sedelnik (vsedelnik)]

Won't Fix for 6.1-updates because of high risk of regression (~900 LOC) and no separate change addressing this specific problem (2 CRs addressing 6 bugs).

[IK (ivankliuk)]

Support for multiple network ranges is implemented only in Fuel CLI.

[IK (ivankliuk)]

The bug has been verified on ISO#290.

[Nikita Marchenko (nmarchenko)]

To add ranges for the networks, follow the steps below using Fuel CLI:
Download the network configuration for your environment:

fuel network --env <env-id> -d

Edit the downloaded configuration file:
find proper network and change ip_ranges and meta.notation.

Sample:
- cidr: 192.168.0.0/24
 gateway: null
 group_id: 1
 id: 3
 ip_ranges: <-- add a list of IPip network ranges
 - - 192.168.0.1
   - 192.168.0.90
 - - 192.168.0.100
   - 192.168.0.254
 meta:
   cidr: 192.168.0.0/24
   configurable: true
   map_priority: 2
   name: management
   notation: ip_ranges <-- change the notation from cidr to ip_ranges
   render_addr_mask: internal
   render_type: cidr
   use_gateway: false
   vips:
   - haproxy
   - vrouter
   vlan_start: 101
 name: management
 vlan_start: 101

Upload the configuration file to Fuel:

fuel network --env <env-id> -u

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/227215
Committed: https://git.openstack.org/cgit/stackforge/fuel-docs/commit/?id=3e222293b74ea5f82c0de71054cff60f27b55fe8
Submitter: Jenkins
Branch: master

commit 3e222293b74ea5f82c0de71054cff60f27b55fe8
Author: evkonstantinov <email address hidden>
Date: Thu Sep 24 13:34:39 2015 +0300

    Add network ranges resolved issue to relnotes 7.0

    Also add instructions on how to do that through CLI
    to UG

    Related-Bug:#1341026
    Change-Id: Ib0b84c55b71eabf7fddea12e5975399d44421912