fix: datasource initialization order in stages#6700
fix: datasource initialization order in stages#6700blackboxsw merged 1 commit intocanonical:mainfrom
Conversation
Add a unit test to cover this case.
holmanb
force-pushed
the
holmanb/fix-stages
branch
from
77e04f6 to
f7a05eb
Compare
blackboxsw
left a comment
blackboxsw
left a comment
There was a problem hiding this comment.
Good fix Brett. This code between stages.py and cloudinit.cmd.main is really challenging to follow and catch all cases. This fix will solve both the snap core26 issue #6699 and the MAAS-specific #6695 which both fall through the condition where no datasources were detected in init-local timeframe and cloud-init tries to reference that self.ds attribute before we've setup a discovered datasource in init-network timeframe. +1.
|
|
||
| if hasattr(self.ds, "network_config"): | ||
| available_cfgs[NetworkConfigSource.DS] = self.ds.network_config | ||
| if self.datasource: |
There was a problem hiding this comment.
This check will solve the source of the symptoms filed in issues #6695 and #6699 when no datasource is detected during init-local timeframe and cloud-init still calls init.apply_network_config(...) to write any networking config seen by kernel cmdline or initramfs prior to cloud-init's init-network stage running.
| if hasattr(self.ds, "network_config"): | ||
| available_cfgs[NetworkConfigSource.DS] = self.ds.network_config | ||
| else: | ||
| order = sources.DataSource.network_config_sources |
There was a problem hiding this comment.
Good default back to common parent when no DS detected yet.
|
While I believe this will resolve #6699 issue as well. I want to leave that one open so we can get resolution from core folks on why and what provides that config setup. |
Add a unit test to cover this case. Fixes canonicalGH-6695
Add a unit test to cover this case. Fixes GH-6695
2 participants
Add a unit test to cover this case.