Right now nova-api resides on an internal host (labs-hosts-b) and we have been very cautious about any connectivity between the labs-hosts VLAN and private VLANs. I don't think it's crazy to allow nova-api to respond to queries from private (it's the responses being blocked) but our general agreed on model is to put anything serving cloud and cloud instances in the public VLAN and to use iptables to lock down rather than watering down the restriction between cloud and prod private. In the mid-term nova-api will move to the labcontrol host (or equiv) which is already in the public VLAN as well so let's put labweb in public for now as the most consistent option and revisit later (once nova-api no longer on an internal host)
Currently our wmcs web UI hosts are on public IPs. We're moving all those services to new hosts, labweb1001 and 1002.
The services running on labweb hosts will need to access a variety of openstack endpoints:
| keystone | identity | True | public | http://labcontrol1001.wikimedia.org:5000/v3 |
| glance | image | True | public | http://labcontrol1001.wikimedia.org:9292 |
| designate | dns | True | public | http://labservices1001.wikimedia.org:9001 |
| keystone | identity | True | admin | http://labcontrol1001.wikimedia.org:35357/v3 |
| nova | compute | True | public | http://labnet1001.eqiad.wmnet:8774/v2/$(tenant_id)s |
All of those are simple ferm changes except for the last one -- labnet hosts are on a different private vlan and I'm not clear on how to get access set up between labweb and labnet.
I've been assuming that those hosts would be on private IPs behind misc-web -- that's how they're set up currently. It wouldn't hurt me any to move labweb hosts to public IPs if that's somehow necessary.