DLPX-96420 Troubleshoot cloud-init repo build failure

[tperkins-perforce]

Background

Cloud-init Build upstream was broken due to a few merge conflicts.

Problem

Merge conflict issues with upstream branch for cloud-init repo.

Solution

Resolve merge conflicts (automated) and manually fix lingering merge conflict issues resulting from upstream changes.

Testing Done

git-ab-pre-push: https://selfservice-jenkins.eng-tools-prd.aws.delphixcloud.com/job/linux-pkg/job/develop/job/build-package/job/cloud-init/job/pre-push/104/

[sebroy]

A couple of observations:

1. If we're not making any effort to make sure unit tests pass, then why are we putting effort into maintaining our set of diffs in the unit test code (the code that's mostly responsible for these merge conflicts)?
2. There's a merge conflict in DataSourceOracle.py where we accepted our changes. What was the nature of our change in that file, and is keeping our change as-is the right way to resolve the conflict?

[prakashsurya]

If we're not making any effort to make sure unit tests pass, then why are we putting effort into maintaining our set of diffs in the unit test code (the code that's mostly responsible for these merge conflicts)?

The unit tests that are run as part of the package building process, do pass; if those fail, the package build will fail.

E.g. https://selfservice-jenkins.eng-tools-prd.aws.delphixcloud.com/job/linux-pkg/job/develop/job/build-package/job/cloud-init/job/pre-push/105/consoleFull

...
17:48:39  tests/unittests/distros/test_init.py::TestInstall::test_unknown_package_manager PASSED [ 61%]
17:48:39  tests/unittests/distros/test_init.py::TestInstall::test_non_default_package_manager PASSED [ 61%]
17:48:39  tests/unittests/distros/test_init.py::TestInstall::test_non_default_package_manager_fail PASSED [ 61%]
17:48:39  tests/unittests/distros/test_init.py::TestInstall::test_default_and_specific_package_manager PASSED [ 61%]
17:48:39  tests/unittests/distros/test_init.py::TestInstall::test_specific_package_manager_fail_doesnt_retry PASSED [ 61%]
17:48:39  tests/unittests/distros/test_init.py::TestInstall::test_no_attempt_if_no_package_manager PASSED [ 61%]
17:48:39  tests/unittests/distros/test_init.py::TestInstall::test_failed[debian_no_apt] PASSED [ 61%]
17:48:39  tests/unittests/distros/test_init.py::TestInstall::test_failed[debian_with_apt] PASSED [ 61%]
...

I think the github action tests might have never passed, and I don't think we've ever looked into getting those to pass. Off the top of my head, I don't know what the actions map to (e.g. not sure if it's running the same tests we run as part of the package build process, or something else).

There's a merge conflict in DataSourceOracle.py where we accepted our changes. What was the nature of our change in that file, and is keeping our change as-is the right way to resolve the conflict?

It's difficult to tell from the conflict, but the block of change that we modified, has been removed upstream.. so we're opting to remove that entire block as well..

The conflict was due to how we changed match to match on name, rather than mac_address.. but that entire block has been removed, so we don't have any differences than upstream anymore.

I can zoom with you, it'd be easier to explain that way, if you'd like to. Also, using the non-default diff3 as the conflict style, makes this more clear (IMO).

[sebroy]

The conflict was due to how we changed match to match on name, rather than mac_address.. but that entire block has been removed, so we don't have any differences than upstream anymore.

Ok, was this #23? Indeed, it doesn't feel like the code changes from that PR are relevant anymore given that we create our own netplan yaml with our own matching rules at first boot, and cloud-init is only needed to setup network access during that first boot.

[prakashsurya]

Ok, was this #23?

I believe so, yes.. those changes continually cause us conflicts.