The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

CloudVPS ideal model

Attendants:

chase
andrew
giovanni
faidon
arzhel
arturo

topics

transport network renumbering from private to public:
- non-controversial
- non-urgent
- big impact for our users
- idea: adding another interface to our current virtual router with the new transport net
  - add another subnet object using the same network object (same physical network)
- old private and new public addresses use the same VLAN numbers

historical context:
- nova-network to neutron migration enabled many more "cloud-native" features, like AWS and the like
- ideal: hypervisor has a virtual router. But that has other complications, complexity (direct virtual routing)
  - this doesn't prevent from having central router because of floating IPs

neutron complexities when managing virtual router
- we don't have workflows like with juniper routers

ideal model:
- NAT 172 to where and when? (the dmz_cidr mechanisms)
  - what happens when an instance talks to a mediawiki API/endpoint/URL: we see VM addrss in logs
  - should that no longer be the case?
  - What happens in Toolforge?
  - We don't have enough public addressed to it sanely?
  - IPv6 could be a solution
  - what's the difference on having CloudVPS from a NAT? What's the benefit on different addressing?
  - Faidon is pretty sure that not having dmz_cidr is better.
  - actual requirements for dmz_cidr? NFS for sure. Others, will have to be reviewed
  - unmaintainable ACLs because boundaries aren't clear (between Cloud VPS and prod)

- Faidon suggests that separation is a different topic from other ideal features (like IPv6)
- CloudVPS is just like AWS from the production point of view
  - implications in addressing
  - separate routers (cloudnet)
  - border ACLs, BGP, etc: CLoudVPS is The Internet from the prod POV