Page MenuHomePhabricator

New network request for CloudVPS CODFW instances transport
Closed, DeclinedPublic


CloudVPS is currently using a locally modified code base to toggle NAT on outbound traffic over the default gateway (cloud-instance-transport1-b-codfw)

We'd like to prototype using Neutron address scopes to eliminate our custom code and make the overall configuration more inline with upstream Neutron. To do this we'll need to create a second network and Neutron interface that will be dedicated to virtual machine traffic to our core services and RFC1918 addresses. Once this is in place, the existing cloud-instances-transport1-b-codfw network will remain in place but only for traffic behind the NAT.

This new network can be an exact mirror of cloud-instance-transport1-b-codfw's configuration on a different CIDR. It will only be used to route traffic between virtual machines and, (with the same ACLs as cloud-instance-transport1-b-codfw)

I've done some local testing and I think this will provide us with the base requirements, in addition to easing the OpenStack configuration upgrade process. If it works well for everyone in CODFW we'll open a new ticket for EQIAD. Also, please note that this work is in parallel to the IPv6 and BGP CloudVPS tasks.

Event Timeline

hey @JHedden, in conversation with @ayounsi on IRC today, he asked me to prioritize this task vs T245495: CloudVPS: IPv6 early PoC. He don't have time to address both.
I decided the IPv6 project should have priority, given has been more time in the queue, and it is explicitly mentioned in our QGoal/OKR, and IPv6 sound like the right next technological movement anyway.

We will need to explicitly schedule time to work on this setup/experiment if we still want to. Probably for the next Q. I'm really sorry, I know you had actual interest on testing this. I had interest too.

For the sake of OKR/QGoal results, my plan is to propose a network refresh that involves IPv6 as a replacement of the dmz_cidr as described on this page: We can explicitly mention that there were other options that weren't explored enough.
I'm thinking if we should carry this OKR/goal for next Q as well, this is something we can discuss in the team, would like to ear your input.

Marking task as declined, is probably the right status for it. We can reopen if required!