** Description changed: [ Impact ] - If the user has specified custom setup for the Pro client through cloud-init, there is a high chance that this setup will be ignored. + Currently, the Pro client support a daemon named ubuntu-advantage.service that + performs two actions: - This happened due to a recent change made on the Pro client. We - identified a race condition when our daemon waited for the cloud-config - service to be finished. We have removed that condition, by manually - checking the cloud-config service state in the daemon itself and only - proceeding if it has already finished. + * Actively look for Pro licenses on Azure and GCP images to perform an auto-attach + * Retry auto-attach on Pro images if that command fails on boot - However, there is a situation where the cloud-init service has not even - started yet, which would generate a inactive state for the cloud-config - service, allowing our daemon to proceed, causing the problem. + Therefore, this daemon is only being activated on Azure and GCP images + and all Pro cloud images. + + This daemon was originally setup to run after the cloud-config.service. However, + due to a race condition, this is no longer happening. Right now, we manually + check in the daemon code to see if the cloud-config service has finished. + + Unfortunately, this new logic now breaks the current Pro setup through + cloud-init userdata in both GCP and Azure Pro cloud images. That is + because our daemon is now running before cloud-init has even started + running. This means that the daemon will perform the attach and not + cloud-init itself. This will be clearer, in the following example: + + Let's imagine this situation where a user is launching a Pro GCP image: + + 1) User provides the following cloud-init userdata to the cloud image + before booting it: + + #cloud-config + + ubuntu_advantage: + enable: [] + + This means that the user wants to services to be enabled, but still want + to attach to the Pro license. + + 2) Our daemon starts running before cloud-init has even started + 3) Our daemon see the cloud-config.service as inactive and proceeds normally + 4) Our daemon identifies that the user is running on a GCP instance and there is a valid Pro license for it. + 5) Due to that, our daemon auto-attach the machine completely ignoring the cloud-init directives. + + Therefore, to fix that issue we need to guarantee that we will only + execute the daemon, if and only if, cloud-init has already started. That + is because, on this situation, the cloud-config.service will already + perform the attach operation following the user directives. When the + daemon starts running, it will see that the image is already attached + and do nothing. + + Finally, given this scenario, this bug is only affecting GCP/Azure Pro + images, as these are the only ones that will be able to reach the flow + described here. [Discussion] To address that issue, we are now also checking if the cloud-init service has already started if we detect that cloud-config service is inactive. If it isn't, the daemon will sleep for an specific amount of time before trying again. [ Test Plan ] Since this is a first boot issue, we will need to create a custom image with the package in proposed. Then, we need to guarantee that Pro configuration delivered through cloud-init is being honored when we launch the image. - CPC is already aware of this issue and will help us creating the test - plan here. + Additionally, it is worth noting that we cannot reproduce this issue on + a VM easily. That is because, we would need "mock" the VM to pass as one + of the affected clouds and also add a valid Pro license to it. + + However, CPC is already aware of this issue and will help us creating + the test plan here. [ Where problems could occur ] We are updating the cloud-init wait logic on the daemon. This could potentially make our daemon to not start. However, since we are just now waiting on the base cloud-init.service to start and we have already tested this solution in a custom image, we believe this is a low risk for this fix. [ Original Description ] We have recently updated the Pro to not strictly run after cloud-config.service. If cloud-config.service has not been started when pro runs, it can complete before cloud-config.service begins and thus the user-specificed pro configuration will be ignored since the instance is already attached. When cloud-config.service has yet to run, ubuntu-advantage.service should wait until it's finished before running.
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2059952 Title: pro sometimes runs before cloud-config.service To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/2059952/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
