Open Stack

Derek Higgins <derekh at redhat.com> writes:

> On 30/11/15 14:56, Derek Higgins wrote:
>> Hi all,
>>
>>      I've been asking about this on irc but given the holidays last week
>> the problem is still persisting, now since freenode  unavailable maybe
>> an email might be better.
>>
>> tripleo ci jobs havn't run sense Thursday morning about (0700 UTC), it
>> looks to me like nodepool is constantly spinning up VMs and deleting
>> them again with no attempt to allocated the VM a IP address. yolanda
>> tells me nodepool is trying to ssh to a 10.2.x.x address (which isn't
>> the correct address)
>>
>>  From the looks of it, this patch
>> https://review.openstack.org/#/c/249351/1
>>
>> has caused nodepool to start treating the internal IPs as external and
>> it no longer attempting to allocate an floating IP.
>>
>> How can we best go about getting things running again? One possibility
>> is the patch below I think this will make nodepool avoid the new
>> codepath for the tripleo cloud and at least work around the problem
>> https://review.openstack.org/251404
>
> I've also proposed a revert of the nodepool commit as it may not be
> only the tripleo cloud that is effected.
> https://review.openstack.org/#/c/251438/

Hi,

Sorry about this.

The fundamental issue is that OpenStack has no standard way of
indicating to a user that a network can route to the Internet.

There is *nearly* such a way in the "router:external" flag in neutron --
except that doesn't *just* mean "this network routes externally" it also
means "this network is shared across tenants".  Those things are of
course *entirely* orthogonal, but neutron has confused them.

To accommodate this, os-client-config and shade are growing the ability
to define per-region behaviors in config files[1].  This will let occ
indicate that the external network on some clouds will be found by
constructing a network name out of some other configuration fields.
In my view, this marks a significant (but necessary) change in shade to
accommodate not only per-cloud configuration settings, but now,
per-cloud-region deployment topology information.

Once we switch nodepool to use shade, we should consume that
automatically.  In the mean time, I think the best solution for
current-nodepool is to revert the change to net-name and more-or-less
mirror the shade behavior change by adding a new config attribute to
nodepool providers, 'external-net-name', which will indicate to nodepool
which network is external.  Or alternatively, add an 'external: True'
attribute to the net-name list.  I will work on that today.

-Jim

[1] https://review.openstack.org/24848