Derek Higgins <[email protected]> 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 _______________________________________________ OpenStack-Infra mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
