ElasticIP operation is harmful when there's no free public ip

Bug #768815 reported by wat
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Eucalyptus
New
Undecided
chris grzegorczyk

Bug Description

Following operations make a 'dead' ElasticIP which anyone cannot use there after.

In the condition that all the public addresses allocated or associated,
disassociating and releasing an address change its state 'nobody'.
However it seems to be still associated with the instance by euca-describe-instances.
In this state I cannot connect to the instance by the address.

Next, I allocate the address, which I released in the above again, and associate it to another instance.
I cannot connect to another too.
After these operations, there's an error message, "Found 2 vms with the same address", in cloud-debug.log.

In euca-disassociate-address, the user ,'eucalyptus', cannot associate substitute one due to
lack of free addresses and create a dead ElasticIP as a result.
I think euca-disassociate-address should not do anything but returning an error when there's no free address.

Thanks.

system:
Eucalyptus : 2.0.2
Host : CentOS5.5
Installed : binary(eucalyptus-2.0.2-centos-x86_64.tar.gz)
Hypervisor : kvm
VNET_MODE : MANAGED
VNET_PUBLICIPS="10.21.67.159 10.21.67.160 10.21.67.161"

1)
# euca-describe-addresses
ADDRESS 10.21.67.159 i-45EC08B4 (eucalyptus)
ADDRESS 10.21.67.161 available (admin)
ADDRESS 10.21.67.160 i-3AAD079D (admin)
# euca-describe-instances
RESERVATION r-437F07DA admin default
INSTANCE i-3AAD079D emi-280B11DF 10.21.67.160 192.168.50.179 running privatekey 0 c1.medium 2010-11-04T02:06:32.126Z cluster1 eki-6F3112C8 eri-A31E13A1

-----------
2)
# euca-disassociate-address 10.21.67.160
# euca-release-address 10.21.67.160
# euca-describe-addresses
ADDRESS 10.21.67.159 i-45EC08B4 (eucalyptus)
ADDRESS 10.21.67.161 available (admin)
ADDRESS 10.21.67.160 nobody
# euca-describe-instances
RESERVATION r-437F07DA admin default
INSTANCE i-3AAD079D emi-280B11DF 10.21.67.160 192.168.50.179 running privatekey 0 c1.medium 2010-11-04T02:06:32.126Z cluster1 eki-6F3112C8 eri-A31E13A1

[--> cannot connect i-3AAD079D by 10.21.67.160]
[cloud-debug.log]
10:51:24 WARN [Addresses:New I/O client worker #2-14] No addresses are available to provide a system address for: [VmInstance...

-----------
3) change to 'sample_user'
# euca-allocate-address
ADDRESS 10.21.67.160
# euca-associate-address -i i-4CDC0954 10.21.67.160
# euca-describe-addresses
ADDRESS 10.21.67.159 i-45EC08B4 (eucalyptus)
ADDRESS 10.21.67.161 available (admin)
ADDRESS 10.21.67.160 i-4CDC0954 (sample_user)
# euca-describe-instances
RESERVATION r-437F07DA admin default
INSTANCE i-3AAD079D emi-280B11DF 10.21.67.160 192.168.50.179 running privatekey 0 c1.medium 2010-11-04T02:06:32.126Z cluster1 eki-6F3112C8 eri-A31E13A1
RESERVATION r-532A08FD sample_user default
INSTANCE i-4CDC0954 emi-280B11DF 10.21.67.160 192.168.50.180 running mykey 0 c1.medium 2010-11-04T02:16:07.874Z cluster1 eki-6F3112C8 eri-A31E13A1

[--> cannot connect i-4CDC0954 by 10.21.67.160]
[cloud-debug.log]
11:08:00 ERROR [AbstractSystemAddressManager:New I/O client worker #2-1] Found 2 vms with the same address: ClusterAddressInfo 10.21.67.160 192.168.50.179 orphanCount=0 -> i-3AAD079D(RUNNING) i-4CDC0954(RUNNING)

-----------

Daniel Nurmi (nurmi)
Changed in eucalyptus:
assignee: nobody → chris grzegorczyk (chris-grze)
Revision history for this message
Andy Grimm (agrimm) wrote :

This issue is now being tracked upstream at http://eucalyptus.atlassian.net/browse/EUCA-2766

Please watch that issue for further updates.

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.