Bug 1380728 - [RFE] Azure Instance provisioning doesn't reuse Public ip
Summary: [RFE] Azure Instance provisioning doesn't reuse Public ip
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Provisioning
Version: 5.7.0
Hardware: Unspecified
OS: Unspecified
unspecified
urgent
Target Milestone: GA
: 5.8.0
Assignee: Bronagh Sorota
QA Contact: Leo Khomenko
URL:
Whiteboard: provider:azure
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-09-30 12:37 UTC by Leo Khomenko
Modified: 2017-05-31 14:21 UTC (History)
10 users (show)

Fixed In Version: 5.8.0.0
Doc Type: Enhancement
Doc Text:
Clone Of: 1342640
Environment:
Last Closed: 2017-05-31 14:21:53 UTC
Category: ---
Cloudforms Team: Azure
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2017:1367 normal SHIPPED_LIVE Moderate: CFME 5.8.0 security, bug, and enhancement update 2017-05-31 18:16:03 UTC

Comment 2 Bronagh Sorota 2016-09-30 13:38:11 UTC
Leo
I think we should discuss, please ping me on irc and i will set up a BJ session. On ManageIQ I am "bronaghs"

Comment 3 Bronagh Sorota 2016-10-05 15:50:19 UTC
PR for floating IP support in Azure provisioning:
https://github.com/ManageIQ/manageiq/pull/9279

Comment 4 Leo Khomenko 2016-11-17 13:34:31 UTC
during provision in UI we have only public ips which are not associated with any network interface.
so this doesn't meet:
"This PR includes changes to the Environment tab of the provisioning dialogs to provide users with the opportunity to re-use an existing floating IP that is:

-Not already associated with an instance
-Has a network interface associated with it."

but it still works. So maybe some docs and pre-requirements should be updated

Bronagh, could you please confirm ?

Comment 5 Leo Khomenko 2016-11-17 16:30:25 UTC
unfortunately described above is an issue - starting from 5.7.0.10 public IP reuse started showing only Free public IP which are not associated with any networkinterface which gives posibility to select it - but it tries to creates a new public IP. which leads to an issue if we have reached 60ips limit.
2 things to fix:
 - filter public IPs without Network interface
 - bring this functionality back - it was working till 5.7.0.9

Comment 6 Ladislav Smola 2016-11-21 10:53:10 UTC
This change was due to AWS and OpenStack, where having floating IP associated to interface means it's not free. E.g. the Floating Ip can belong to a Load Balancer, or other network device. Those 2 cloud providers also clean up the interfaces when the Vm is deleted.

Does this case apply also for Azure, that a Floating Ip can be used by the different entities than just VM?

For me, it seems like a different RFE, to be able to attach a free NetworkInterface to a VM (where the interface can be associated to other entities). For now, we will probably need a special condition for Azure, that will filter out the 'non used' network interfaces with a Floating Ip.

Comment 7 Bronagh Sorota 2016-12-01 14:57:42 UTC
Ladas, Leo,

In the Azure portal, only floating IPs NOT associated with a NIC are available for reuse during VM or Load Balancer provisioning.
In the Azure ARM API, both floating IPs which ARE associated with an unattached NIC and floating IPs NOT associated with any NIC are available for reuse during VM provisioning. I cannot speak to Load Balancer provisioning through the ARM API yet.

Unlike AWS and OpenStack, when a VM is deleted in Azure (portal or ARM API) the IP and NIC are not cleaned up, this exacerbates the problem of having a 60 IP limit in a subscription/region. To counter this, a change was merged this week to delete the associated resources (including IP and NIC) on a VM during VM retirement:
https://github.com/ManageIQ/manageiq-providers-azure/pull/14

I still think if the ARM API allows us to reuse a floating IP associated with an unattached NIC we should take advantage of that. For this reason, I am going to make the appropriate code change in the Azure VM provisioning code to do this.

Comment 10 CFME Bot 2017-01-16 21:57:03 UTC
New commit detected on ManageIQ/manageiq-providers-azure/master:
https://github.com/ManageIQ/manageiq-providers-azure/commit/0e30064673b3fed4bfe737ec28fe79279c2a27f0

commit 0e30064673b3fed4bfe737ec28fe79279c2a27f0
Author:     Bronagh Sorota <bsorota@redhat.com>
AuthorDate: Mon Dec 5 11:14:27 2016 -0500
Commit:     Bronagh Sorota <bsorota@redhat.com>
CommitDate: Mon Jan 16 16:44:40 2017 -0500

    Azure LoadBalancer networking
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1380728

 .../manageiq/providers/azure/network_manager.rb    |    2 +
 .../providers/azure/network_manager/floating_ip.rb |    3 +
 .../azure/network_manager/refresh_parser.rb        |   60 +-
 .../azure/cloud_manager/provision_workflow_spec.rb |   23 +
 .../azure/cloud_manager/refresher_spec.rb          |   25 +-
 .../providers/azure/cloud_manager/refresher.yml    | 1972 +++++++++++---------
 6 files changed, 1130 insertions(+), 955 deletions(-)

Comment 12 CFME Bot 2017-01-17 17:07:42 UTC
New commit detected on ManageIQ/manageiq-providers-azure/master:
https://github.com/ManageIQ/manageiq-providers-azure/commit/659a8f86dc668996f4c4e0082d305810092e8a59

commit 659a8f86dc668996f4c4e0082d305810092e8a59
Author:     Bronagh Sorota <bsorota@redhat.com>
AuthorDate: Mon Jan 16 08:32:50 2017 -0500
Commit:     Bronagh Sorota <bsorota@redhat.com>
CommitDate: Tue Jan 17 06:53:51 2017 -0500

    Modifies the available method to be azure specific
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1380728

 .../manageiq/providers/azure/network_manager.rb    |  3 +++
 .../providers/azure/network_manager/floating_ip.rb |  3 +++
 .../azure/cloud_manager/provision_workflow_spec.rb | 28 ++++++++++++++++++++++
 3 files changed, 34 insertions(+)

Comment 15 Leo Khomenko 2017-02-28 16:20:24 UTC
CFME now shows both public_ips - which have NIC or not. But provisioning using any of those creates a new pair NIC+public_ip. this happened on 5.8.0.2

Comment 16 Bronagh Sorota 2017-03-01 17:18:38 UTC
Hi Leo,
Can you please point me to an appliance and provide specific instructions for me to reproduce.

thank you
Bronagh

Comment 17 Leo Khomenko 2017-03-01 19:36:15 UTC
Try any env with Azure.
1.Create provision Request with public IP.
2.Create another provision request after and select same public IP - as it is available. or check on azure your first VM details - it has public ip named - <vm_name>-public-ip - this is a new created public IP.

Comment 18 Bronagh Sorota 2017-03-15 13:14:40 UTC
Leo,

I followed the steps above and could not reproduce this bug, it worked as expected for me. Step 2 above was unclear so here is exactly what I did:

1) I provisioned a new VM using a floating IP that was displayed in the Environment/Public IP address drop down.
2) I observed this VM was created successfully in the Azure portal with the public IP I selected in 1) above.
3)I started to create a second VM in the CF UI. When I got to the Environment/Public IP address drop down, the Public IP address I chose in 1) was not listed and therefore I could not select it.

I also tested, on the rails console, the method that returns the list of available floating IPs and it worked perfectly in every scenario, it returned:
- any Public IPs not associated to a network port or a load balancer
- any Public IPs associated to a network port which are not attached to a VM

Please retest this, thanks.

Bronagh

Comment 19 Bronagh Sorota 2017-03-16 15:43:05 UTC
Leo
I dug into this some more and might have come up with a theory around why you are seeing this. After the first VM has been provisioned, an event is fired from Azure which is captured by CF and triggers an EMS refresh. This EMS refresh will update the list of available floating IPs in the database.
Maybe you provisioned the second VM before this EMS refresh had a chance to finish and update the list of available floating IPs. 
In my testing, the EMS refresh did complete before I provisioned the second VM.

Can you run the test again but delay the provisioning of the second Vm until the EMS refresh has finished. A targeted (VM) refresh is being actively worked on which is much quicker than a full EMS refresh.

HTH
Bronagh

Comment 20 Leo Khomenko 2017-03-21 16:50:01 UTC
Bronagh, you were right. adding some delay to the second Vm provision helps
verified  on 5.8.0.4

Comment 22 errata-xmlrpc 2017-05-31 14:21:53 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:1367


Note You need to log in before you can comment on or make changes to this bug.