-
Notifications
You must be signed in to change notification settings - Fork 858
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Removing MAAS preseed broke oracular deployments #5685
Comments
We need to reconstitute both handle_preseed_maas and handle_preseed_local_cloud_config because maas provides key config in db settings for maas-metadata-url maas-metadata-credentials and local-cloud-config |
Commit cf13fd1 removed support for MAAS preseed functions from debian/cloud-init.postinst which is the only operation which allows MAAS to send preseed config to cloud-init. Fixes canonicalGH-5685
Yes, we can't break oracular this late. However, this also reveals an ownership problem. MAAS is broken by cloud-init, yet cloud-init behaves correctly. Long term this code should move into a codebase that MAAS owns and can maintain, rather than relying on image build behaviors that are built into cloud-init's packaging scripts. I'll submit a PR to fix this and file an issue against MAAS so that we can track eventually removing this from cloud-init. |
I think this may be a misunderstanding of how MAAS interacts with cloud-init during commisioning/provisioning. I believe MAAS still calls either debconf or dpkg-reconfigure cloud-init providing debconf selections during commissioning based on preseed config settings to setup MAAS URLs for communication back to maas of all cloud-init logs, this triggers a call to I haven't looked through MAAS commisioning/provisioning code in quite a while so maybe @alexsander-souza can point us to/confirm how maas is using preseed debconf config in various boot stages. |
I believe the debconf setup is invoked early by curtin in curthooks.py but that may be grasping at straws. |
you are correct, Curtin drives this process
relevant bits:
(I know, it's suspiciously redundant, I'm going to check this)
|
the |
we need to talk to Curtin folks to understand why this is done differently for Ubuntu, at first glance it looks like we could use the same mechanism |
Added a followup issue #5688 to at least get integration test coverage for cloud-init MAAS preseed file creation by postinst to ensure that functionality is better documented and avoids regression in cloud-init tests. |
What makes you say that? Please clarify what you think the misunderstanding is.
This is what I expected.
This functionality needs to exist somewhere - I don't object to that. I just don't think that this has to exist in cloud-init's Ubuntu packaging. The current implementation makes MAAS's implementation distro-specific without a specific benefit to Ubuntu. Using debconf was an implementation choice - one that ties this implementation tightly to debian distros.
This behavior has to exist for other distros as well for MAAS, so why should preseed be funneled through debconf? Just because one can use debconf to configure an Ubuntu package doesn't mean that one should. And in this case since this is functionality that is owned by MAAS and needs to be distro-agnostic, I think that there is sufficient reason to say that this shouldn't be implemented using debian packaging scripts and that this shouldn't be implemented in cloud-init's postinst. MAAS seems like the rightful owner of this functionality, whether that is implemented with curtin or some other method. |
@alexsander-souza thanks for digging that up. I'm happy to assist with crafting a more distro-agnostic solution, which I think would benefit both MAAS and cloud-init. |
Hello! Would there happen to be any workarounds for this issue until a fix is deployed? |
The fix is already available in the Oracular archive, so I expect that it will be included in the next image built, probably tomorrow |
Fixed per #5686 and published to oracular yesterday as cloud-init version |
Bug report
Removing MAAS preseed (#5487) broke all MAAS deployments.
Steps to reproduce the problem
Without the preseed code, cloud-init will set
datasource_list
to[ MAAS ]
but won't create/etc/cloud/cloud.cfg.d/90_dpkg_maas.cfg
with the required parameters.Environment details
cloud-init logs
The text was updated successfully, but these errors were encountered: