Puppet::Type::Neutron_floatingip_pool::ProviderNeutron: Neutron API not available. retries forever

please attach full puppet debug log. without it I can't research this issue

Is there any way to reproduce this issue? Can we make a guess why it may happen for some deployments?

I believe this one was caused by the small queuepool size for Neutron, combined with slow keystone token queries.

I have seen this happen while testing https://review.openstack.org/65591 . The problem was a missing dependency from Anchor[haproxy_done] (or Class[openstack::ha::nova] in my branch) to Nova_floating_range<||> in osnailyfacter::cluster_ha.

Nova_floating_range has nothing to do with Neutron API.

On Tue, Feb 4, 2014 at 9:09 PM, Dmitry Borodaenko
<email address hidden>wrote:

> I have seen this happen while testing https://review.openstack.org/65591
> . The problem was a missing dependency from Anchor[haproxy_done] (or
> Class[openstack::ha::nova] in my branch) to Nova_floating_range<||> in
> osnailyfacter::cluster_ha.
>
> --
> You received this bug notification because you are a member of Fuel
> Library Team, which is a bug assignee.
> Matching subscriptions: FUEL Dev subscribe
> https://bugs.launchpad.net/bugs/1272811
>
> Title:
> Puppet::Type::Neutron_floatingip_pool::ProviderNeutron: Neutron API
> not available. retries forever
>
> Status in Fuel: OpenStack installer that works:
> Incomplete
>
> Bug description:
> deployment neutron gre (multi-l3) MOS 4.0
>
> several deployments have seen messages for Neuton API being not
> available and then takes a very long time to continue running puppet
>
>
> notice: Puppet::Type::Neutron_floatingip_pool::ProviderNeutron: Neutron
> API not avalaible. Wait up to 82 sec. debug:
> Puppet::Type::Neutron_floatingip_pool::ProviderNeutron: Executing
> '/usr/bin/neutron --os-tenant-name services --os-username neutron
> --os-password 3wgODmcX --os-auth-url http://10.2.2.14:35357/v2.0floatingip-create --tenant-id 08ef39819c3444f7bec3c98b4904c873 net04_ext'
> debug: Non-fatal error: "Execution of '/usr/bin/neutron --os-tenant-name
> services --os-username neutron --os-password 3wgODmcX --os-auth-url
> http://10.2.2.14:35357/v2.0 floatingip-create --tenant-id
> 08ef39819c3444f7bec3c98b4904c873 net04_ext' returned 1:
> 400-{u'NeutronError': {u'message': u'Unable to find any IP address on
> external network d57086ec-1dc0-4ddf-8b79-2dc29a0d102d.', u'type':
> u'ExternalIpAddressExhausted', u'detail': u''}}
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/fuel/+bug/1272811/+subscriptions
>

--
Yours Faithfully,
Vladimir Kuklin,
Senior Deployment Engineer,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
45bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com <http://www.mirantis.ru/>
www.mirantis.ru
<email address hidden>

You're right, nova_floating_range is a nova-network construct.

For the record, I've seen the following behaviour: if Nova API isn't running yet (or HAProxy doesn't yet listen on port 8774 on the VIP) when ruby-openstack tries to open an HTTP connection, Ruby HTTP module would hang for about an hour before timing out and reporting an error. This isn't exactly the same (no retries), so it might be something else in this case (unless neutron Puppet module has a retry mechanism that nova module lacks).