Implement ip selection policy mechanism

Bug #1186874 reported by Sergey Lukjanov
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fix Released
Nikita Konovalov

Bug Description

We should implement some ip selection policy mechanism that will allow Savanna to identify correct management ip address.

After an instance is created, it will have an internal ip:
* automatically for Nova Network
* defined by user for Neutron

User may specify an Floating IP Pool name for any Node Group in a Node Group Template, so that instances in specified Node Group will have Floating IPs assigned.

If 'use_floating_ips' option in config is set to True, Savanna will use floating IP of an Instance for management operations. Aslo a validation should be provided not to let user create a Cluster in which there are Node Groups without Floating IP Pool name.

Tags: 0.3
Changed in savanna:
status: New → Triaged
importance: Undecided → High
assignee: nobody → Sergey Lukjanov (slukjanov)
milestone: none → 0.2a1
tags: added: 0.2
summary: - Implement management ip selection policy mechanism
+ Implement ip selection policy mechanism
description: updated
description: updated
Changed in savanna:
milestone: 0.2a1 → 0.2
tags: added: 0.3
removed: 0.2
Changed in savanna:
milestone: 0.2 → 0.3
Revision history for this message
Ruslan Kamaldinov (ruhe) wrote :

Moving this out of scope of v0.3 since we're targeting Neutron support which has higher priority

Changed in savanna:
milestone: 0.3 → none
importance: High → Medium
importance: Medium → Low
Changed in savanna:
assignee: Sergey Lukjanov (slukjanov) → Nikita Konovalov (nkonovalov)
description: updated
description: updated
Changed in savanna:
status: Triaged → Fix Committed
status: Fix Committed → In Progress
Ruslan Kamaldinov (ruhe)
Changed in savanna:
milestone: none → 0.3a1
Ruslan Kamaldinov (ruhe)
tags: added: 0.2.2
Revision history for this message
Matthew Farrellee (mattf) wrote :

IMHO, specific network resources should be assigned at cluster launch, similar to image and keypair selection.

Why did you choose Node Group Template creation over Cluster Template creation and over Cluster Launch?

Revision history for this message
Ruslan Kamaldinov (ruhe) wrote :

I agree that it make more sense to assign network resources at cluster launch.

On the other hand we need an ability to assign network to specific node groups.
In case of cluster of hundreds of nodes it'll be a waste of resources to assign floating IP to all nodes in the cluster. That's why we need to assign network to node groups, not cluster itself.

I guess we can file a bug with requirement to move network specification to cluster launch screen.

Revision history for this message
Matthew Farrellee (mattf) wrote :

It sounds like there are likely three uses cases and one complication in play here -

Given the deployment architectures mostly consist of master nodes and worker nodes,

0) All nodes get floating IPs
1) Only the master nodes gets a floating IP
2) A subset of master and worker nodes get floating IPs

The complication is allowing two nodes to be assigned floating IPs from different Floating IP Pools.


I propose punting the complication unless you have a specific driver for it.

Use case (0) is what is currently implemented.

This feature aims to cover use case (1) and (2).

That's the importance of (2)?

it may be sufficient to cover (0) and (1) with a mechanism that allows just assigning floating IPs to node groups that labeled as requiring floating IP access. This could be done with a flag on the group and assignment during launch, or a tab in the launch dialog that allows assignment of Floating IP Pools to specific groups. The tab option would happen to also address (3) and the complication.

We should continue this discussion on the blueprint for this feature, what's its url?

Revision history for this message
Ruslan Kamaldinov (ruhe) wrote :

I completely agree that only (0) and (1) are important for us. And I don't see any use case for (2) as well.

Revision history for this message
Andrew Lazarev (alazarev) wrote :

>Use case (0) is what is currently implemented.
For now, it works with nova network only. The fix will add support for neutron as well.

>That's the importance of (2)?
Subsets with different floating IP pools (or without pools) could be created separately using different node group templates or with pool parameter redefined. With the fix it can be done if needed.

Revision history for this message
Matthew Farrellee (mattf) wrote :

The more I think about this, the more having this data associated with stored Node Group Templates appears wrong.

For instance, foreign key constraints - we've had issues w/ node groups templates being deleted while they are still in use in cluster templates. Having IP Pools linked to node group templates creates a foreign key on an external service, and will result in more complex code to do validation - validation on creation, validation on deploy. The code to address failed validation on deploy is either complex or manual intensive.

@ruhe where is the bp for this?

tags: removed: 0.2.2
Changed in savanna:
importance: Low → High
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to savanna (master)

Submitter: Jenkins
Branch: master

commit 4083b017426a1954cff6005613f4df097a56dbe7
Author: Nikita Konovalov <email address hidden>
Date: Tue Sep 3 13:09:50 2013 +0400

    Floating ip assignement support

    'floating_ip_pool' field added to Node Groups
    and Node Group Templates.

    'floating_ip_pool' may be Network ID or Floation IP pool name.

    If this field is not None then Savanna will:
    * create a Floating IP for each instance in the Node Group
    * assign it on Cluster start or scaling
    * remove it on Cluster Deletion.

    Validation added for 'floating_ip_pool' field.

    Docs and Sample Configs update

    Co-Authored-By: Andrew Lazarev <email address hidden>

    Fixes bug: #1186874
    Implements blueprint ips-assignment-mechanism

    Change-Id: Id7438b533d140916d683e7ca47424aa00b66a1a0

Changed in savanna:
status: In Progress → Fix Committed
Changed in savanna:
status: Fix Committed → Fix Released
Changed in savanna:
milestone: 0.3a1 → 0.3
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related blueprints