Portal:Cloud VPS/Admin/notes/Neutron ideal model/meeting-2018-11-29

From Wikitech
Jump to navigation Jump to search

CloudVPS ideal model


  • chase
  • andrew
  • giovanni
  • faidon
  • arzhel
  • arturo


  • 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