DLPX-67375 [Backport of Issue DLPX-67281 to 6.0.0.0] Network configuration not migrated because of multiple netplan files #160
Conversation
…ation not migrated because of multiple netplan files The root-cause of this issue is that the service that generates the default netplan file for cloud-init (named cloud-init-local) can run at the same time as delphix-migration which writes our own custom netplan file on-disk (and potentially deletes the default one if the timing is right). Unfortunately, timing is not always right and due to the above raace between the two services we end up with two netplan files that can have conflicting info. This change ensures that the migration service runs after cloud-init-local so the default netplan file is always generated before ouyr custom one takes its place. Note again that this is a migration-only issue that can happen on first boot. We disable the cloud-init-local service from regenerating its netplan file for subsequent boots.
|
PR for original issue can be found here -> #159 |
| [Unit] | ||
| Description=Delphix OS Migration Service | ||
| PartOf=delphix.target | ||
| DefaultDependencies=no | ||
| After=systemd-udev-settle.service | ||
| After=cloud-init-local.service |
There was a problem hiding this comment.
Out of curiosity, do we have to worry about running before any other cloud-init services? In other words, does this also need a Before=cloud-init.service?
There was a problem hiding this comment.
That's a great question. In term of anything that we manage by netplan there should be nothing to worry about. Outside of that though, one could bring up the question of resolv.conf. Looking at the logs in our machines and the source code of cloud-init it is not obvious to me which service handles the creation of that file by default. If it is indeed cloud-init and not cloud-init-local then we should probably do what you suggest. I can open an issue about this so it is tracked somewhere as this is a backport and I wouldn't like to introduce any differences between this and its original commit on master.
There was a problem hiding this comment.
The root-cause of this issue is that the service that generates the
default netplan file for cloud-init (named cloud-init-local) can run
at the same time as delphix-migration which writes our own custom
netplan file on-disk (and potentially deletes the default one if the
timing is right). Unfortunately, timing is not always right and due
to the above raace between the two services we end up with two
netplan files that can have conflicting info.
This change ensures that the migration service runs after cloud-init-local
so the default netplan file is always generated before ouyr custom one
takes its place.
Note again that this is a migration-only issue that can happen on
first boot. We disable the cloud-init-local service from regenerating
its netplan file for subsequent boots.