Bug 1380728

Leo
I think we should discuss, please ping me on irc and i will set up a BJ session. On ManageIQ I am "bronaghs"

PR for floating IP support in Azure provisioning:
https://github.com/ManageIQ/manageiq/pull/9279

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 ?

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

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.

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.

https://github.com/ManageIQ/manageiq/pull/13042

https://github.com/ManageIQ/manageiq-providers-azure/pull/17

New commit detected on ManageIQ/manageiq-providers-azure/master:
https://github.com/ManageIQ/manageiq-providers-azure/commit/0e30064673b3fed4bfe737ec28fe79279c2a27f0

commit 0e30064673b3fed4bfe737ec28fe79279c2a27f0
Author:     Bronagh Sorota <bsorota>
AuthorDate: Mon Dec 5 11:14:27 2016 -0500
Commit:     Bronagh Sorota <bsorota>
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(-)

https://github.com/ManageIQ/manageiq-providers-azure/pull/25

New commit detected on ManageIQ/manageiq-providers-azure/master:
https://github.com/ManageIQ/manageiq-providers-azure/commit/659a8f86dc668996f4c4e0082d305810092e8a59

commit 659a8f86dc668996f4c4e0082d305810092e8a59
Author:     Bronagh Sorota <bsorota>
AuthorDate: Mon Jan 16 08:32:50 2017 -0500
Commit:     Bronagh Sorota <bsorota>
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(+)

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

Hi Leo,
Can you please point me to an appliance and provide specific instructions for me to reproduce.

thank you
Bronagh

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.

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

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

Bronagh, you were right. adding some delay to the second Vm provision helps
verified  on 5.8.0.4

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