[Request]: Avoid changing IP of a container unnecessary on restart

[vsarunas]

Feature or enhancement request details

Currently upon a container stop/start, the IP address will always be incremented, even if there is free IP addresses available. This can sometimes cause issues with other software running inside the container where the IPs are always changing and require reconfiguration/handling.

Even if there is a single container, start and stop will cause the container start will cause a new IP address.

Code of Conduct

• I agree to follow this project's Code of Conduct

[vsarunas]

Fix is in #1740

[jglogan]

@vsarunas Thanks for filing the issue for your PR!

I had started looking at it but we're working on the release this week and also trying to improve our integration testing.

Have you looked at #282 regarding static IP allocation? Your work definitely ties into that. I described the difficulties with static IPs there:

• With vmnet there's no guaranteed way to get the IPv4 subnet you ask for when creating a network. You can either leave ipv4Subnet nil and be guaranteed (unless there are no subnets left) a subnet of its choosing, or you can set ipv4Subnet but fail to get the subnet you want because it's already in use.
• This means we can never guarantee that a fixed static IP address on a container will work across container system restarts. It may work, or it will have the wrong subnet if you have a vmnet-assigned subnet that come up differently, or the network will fail to start in the first place if you assigned the subnet and it's now in use elsewhere.

We expressly chose the rotating IP policy because it's a historical way of reducing the incidence of ARP cache issues when creating and deleting containers. For cloud native development, wiring up configurations with IPs is brittle and that's why container supports local domain name resolution for containers - that a far more robust way of connecting things.

Is yours an application server use case (I need a better term for using container/docker/etc to run packaged applications, as opposed to doing cloud native development)? Would you be better served by being able to ask for a specific IP when you create/run a container?

The reason I ask is that you've done most of the work on the network plugin side for a pragmatic solution to the static IP issue. The way I saw that working is that if added, say, --network default,ip=192.168.64.13 to your container create or container run, the runtime helper would call your register API to try to allocate the IP. The network helper would replace the requested subnet prefix with the current prefix (which would usually be the same but could be different as described above), and use the transformed address in the allocation response.

This would ensure that the container starts with a working network. Of course, anything relying on the original IP will not be able to communicate with the container if the subnet has changed.

[vsarunas]

Background: I'm using container to orchestrate a number of VMs to test/emulate for high availability in stack that has a trading system and few components (Consul/Nomad/Kafka). Generally in my experience is that IP address is usually the same in cloud native if you just do a restart of the system; of course a different if you request a new allocation.

I create a dedicated network and stick the containers on the range that is expected instead of relying on 192.168.6x given out.

Yes I had looked at #282 / #751 ; hence the best attempt sticky solution of not having to deal with all of the edge cases. In a similar fashion where a DHCP server will hand out the same IP address lease if within a certain time window. And I agree that having static IP is cumbersome and has it's own set of issues (a container that is stopped that has a static IP address assigned, but a new container has been requested with the same address needs an XPC call to validate).

Ok I see that also need to save and restore the mac address, as it rotates between restarts and new container comes up with a different one and for some time it is not accessible until arp expires; maybe I can just address that?