While creating the VM/Instances, we can not add these instances to second subnet of a Network. It always attached to first subnet.

Bug #1324452 reported by Mahesh Bachche
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Dashboard (Horizon)
New
Wishlist
Unassigned
neutron
Invalid
Undecided
Unassigned

Bug Description

This scenario is checked in icehouse release.

Build used:
===========
neutron-common : 1:2014.1-0ubuntu1~cloud0
neutron-dhcp-agent : 1:2014.1-0ubuntu1~cloud0
neutron-l3-agent : 1:2014.1-0ubuntu1~cloud0
neutron-metadata-agent :1:2014.1-0ubuntu1~cloud0
neutron-plugin-ml2 :1:2014.1-0ubuntu1~cloud0
neutron-plugin-nicira : 1:2014.1-0ubuntu1~cloud0
neutron-plugin-vmware : 1:2014.1-0ubuntu1~cloud0
neutron-server: 1:2014.1-0ubuntu1~cloud0
python-neutron: 1:2014.1-0ubuntu1~cloud0
python-neutronclient : 2:2.3.4.46.g07bcee8+git201404070301~trusty-0ubuntu1

Steps performed:
================
1. Through network horizon, create one network with one subnet. name of this subnet is "subnet1" and his network address is 85.85.85.0/24
2. attached this subnet to router's interface.
3. Through horizon or nova command create 2 to 3 VMs/instances
 All these Vm are correctly created and connected to subnet1. They are getting correct IP address from subnet1.

4. Now through horizon, create second subnet. His name is "subnet2" and his network address is 95.95.95.0/24.

5. Through horizon or nova command create 2 VMs/instances and check they are connecting to which subnet networks.

Observed behavior:
=================
1. While creating the VM, we can not add these VM to second subnet of network.
2. It will always add to first subnet only.
3. there is no option for this in both openstack horizon and nova command. If there are multiple subsets for same networks then there is no option to specify particular subnet while creating a instance.
4. All created VMs are automatically attached to first subnet only.

Tags: neutron
information type: Private Security → Public
Revision history for this message
Armando Migliaccio (armando-migliaccio) wrote :

Using the Nova CLI you can pre-create the port with a specific Fixed IP and then use the port uuid in the nova boot command. That said, it always baffled me the use case where a tenant network (that models a single L2 broadcast domain) needs to be mapped by two logical IP network subnets.

Revision history for this message
Eugene Nikanorov (enikanorov) wrote :

I think it's not neutron's bug. Marking as Invalid for neutron.

Changed in neutron:
status: New → Invalid
Revision history for this message
Armando Migliaccio (armando-migliaccio) wrote :

Eugene, I would agree :) But wouldn't be fair to provide a justification when marking a bug as invalid?

Revision history for this message
Eugene Nikanorov (enikanorov) wrote :

Yes, I think your comment above justifies it: there's nothing neutron can do because it already provides everything necessary to attach VM to subnets, so I've left it as valid in Horizon.

Revision history for this message
Akihiro Motoki (amotoki) wrote :

As Armando and Eugene commented, it can be done by creating a port with a specific IP address and providing port UUID to nova boot CLI.

On the other hand, Horizon does not provide a way to specify an IP address for a network when launching an instance. If this feature is implemented, this bug will be addressed. It is in a wish list for a long time and it would be nice if someone contributes it :-)

tags: added: neutron
Changed in horizon:
importance: Undecided → Wishlist
status: New → Confirmed
milestone: none → next
Changed in horizon:
assignee: nobody → Sam Stoelinga (sammiestoel)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to horizon (master)

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

Changed in horizon:
status: Confirmed → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on horizon (master)

Change abandoned by David Lyle (<email address hidden>) on branch: master
Review: https://review.openstack.org/174211
Reason: This review is > 4 weeks without comment, and failed Jenkins the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

Changed in horizon:
assignee: Sam Stoelinga (sammiestoel) → nobody
Revision history for this message
Ivan Kolodyazhny (e0ne) wrote :

We need to verify if it's still actual.

Changed in horizon:
status: In Progress → New
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.