| 2024-04-01 15:38:44 |
Lucas Albuquerque Medeiros de Moura |
bug |
|
|
added bug |
| 2024-04-02 13:45:45 |
Lucas Albuquerque Medeiros de Moura |
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. |
[ 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.
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.
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.
[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.
[ 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. |
|
| 2024-04-02 13:46:39 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~lamoura/ubuntu/+source/ubuntu-advantage-tools/+git/ubuntu-advantage-tools/+merge/463510 |
|
| 2024-04-02 15:47:49 |
Lucas Albuquerque Medeiros de Moura |
description |
[ 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.
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.
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.
[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.
[ 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. |
[ Impact ]
Currently, the Pro client support a daemon named ubuntu-advantage.service that
performs two actions:
* 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
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.
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. |
|
| 2024-04-02 16:48:25 |
Lucas Albuquerque Medeiros de Moura |
description |
[ Impact ]
Currently, the Pro client support a daemon named ubuntu-advantage.service that
performs two actions:
* 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
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.
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. |
[ Impact ]
Currently, the Pro client support a daemon named ubuntu-advantage.service that
performs two actions:
* 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
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 no 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.
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. |
|
| 2024-04-02 16:55:12 |
Lucas Albuquerque Medeiros de Moura |
description |
[ Impact ]
Currently, the Pro client support a daemon named ubuntu-advantage.service that
performs two actions:
* 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
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 no 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.
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. |
[ Impact ]
Currently, the Pro client support a daemon named ubuntu-advantage.service that
performs two actions:
* 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
Therefore, this daemon is only being activated on generic 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 no 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.
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. |
|
| 2024-04-03 12:44:57 |
Renan Rodrigo |
ubuntu-advantage-tools (Ubuntu): status |
New |
In Progress |
|
| 2024-04-04 21:40:17 |
Andreas Hasenack |
description |
[ Impact ]
Currently, the Pro client support a daemon named ubuntu-advantage.service that
performs two actions:
* 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
Therefore, this daemon is only being activated on generic 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 no 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.
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. |
[ Impact ]
Currently, the Pro client support a daemon named ubuntu-advantage.service that
performs two actions:
* 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
Therefore, this daemon is only being activated on generic 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 no services to be enabled, but still want to attach to the Pro license.
2) Our daemon starts running before cloud-config 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.
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. |
|
| 2024-04-04 21:41:14 |
Andreas Hasenack |
description |
[ Impact ]
Currently, the Pro client support a daemon named ubuntu-advantage.service that
performs two actions:
* 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
Therefore, this daemon is only being activated on generic 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 no services to be enabled, but still want to attach to the Pro license.
2) Our daemon starts running before cloud-config 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.
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. |
[ Impact ]
Currently, the Pro client support a daemon named ubuntu-advantage.service that
performs two actions:
* 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
Therefore, this daemon is only being activated on generic 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 no services to be enabled, but still want to attach to the Pro license.
2) Our daemon starts running before cloud-config.service 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.
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. |
|
| 2024-04-07 07:08:59 |
Launchpad Janitor |
ubuntu-advantage-tools (Ubuntu): status |
In Progress |
Fix Released |
|
| 2024-04-08 12:41:43 |
Catherine Redfield |
bug |
|
|
added subscriber Catherine Redfield |
| 2024-04-16 17:42:06 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Focal |
|
| 2024-04-16 17:42:06 |
Andreas Hasenack |
bug task added |
|
ubuntu-advantage-tools (Ubuntu Focal) |
|
| 2024-04-16 17:42:06 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Bionic |
|
| 2024-04-16 17:42:06 |
Andreas Hasenack |
bug task added |
|
ubuntu-advantage-tools (Ubuntu Bionic) |
|
| 2024-04-16 17:42:06 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Xenial |
|
| 2024-04-16 17:42:06 |
Andreas Hasenack |
bug task added |
|
ubuntu-advantage-tools (Ubuntu Xenial) |
|
| 2024-04-16 17:42:06 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Mantic |
|
| 2024-04-16 17:42:06 |
Andreas Hasenack |
bug task added |
|
ubuntu-advantage-tools (Ubuntu Mantic) |
|
| 2024-04-16 17:42:06 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Jammy |
|
| 2024-04-16 17:42:06 |
Andreas Hasenack |
bug task added |
|
ubuntu-advantage-tools (Ubuntu Jammy) |
|
| 2024-04-16 17:43:27 |
Andreas Hasenack |
ubuntu-advantage-tools (Ubuntu Mantic): status |
New |
Fix Committed |
|
| 2024-04-16 17:43:28 |
Andreas Hasenack |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2024-04-16 17:43:30 |
Andreas Hasenack |
bug |
|
|
added subscriber SRU Verification |
| 2024-04-16 17:43:38 |
Andreas Hasenack |
tags |
|
verification-needed verification-needed-mantic |
|
| 2024-04-16 17:44:18 |
Andreas Hasenack |
ubuntu-advantage-tools (Ubuntu Jammy): status |
New |
Fix Committed |
|
| 2024-04-16 17:44:24 |
Andreas Hasenack |
tags |
verification-needed verification-needed-mantic |
verification-needed verification-needed-jammy verification-needed-mantic |
|
| 2024-04-16 17:44:51 |
Andreas Hasenack |
ubuntu-advantage-tools (Ubuntu Focal): status |
New |
Fix Committed |
|
| 2024-04-16 17:44:56 |
Andreas Hasenack |
tags |
verification-needed verification-needed-jammy verification-needed-mantic |
verification-needed verification-needed-focal verification-needed-jammy verification-needed-mantic |
|
| 2024-04-16 17:45:25 |
Andreas Hasenack |
ubuntu-advantage-tools (Ubuntu Bionic): status |
New |
Fix Committed |
|
| 2024-04-16 17:45:31 |
Andreas Hasenack |
tags |
verification-needed verification-needed-focal verification-needed-jammy verification-needed-mantic |
verification-needed verification-needed-bionic verification-needed-focal verification-needed-jammy verification-needed-mantic |
|
| 2024-04-16 17:45:58 |
Andreas Hasenack |
ubuntu-advantage-tools (Ubuntu Xenial): status |
New |
Fix Committed |
|
| 2024-04-16 17:46:04 |
Andreas Hasenack |
tags |
verification-needed verification-needed-bionic verification-needed-focal verification-needed-jammy verification-needed-mantic |
verification-needed verification-needed-bionic verification-needed-focal verification-needed-jammy verification-needed-mantic verification-needed-xenial |
|
| 2024-04-16 19:16:31 |
Catherine Redfield |
description |
[ Impact ]
Currently, the Pro client support a daemon named ubuntu-advantage.service that
performs two actions:
* 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
Therefore, this daemon is only being activated on generic 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 no services to be enabled, but still want to attach to the Pro license.
2) Our daemon starts running before cloud-config.service 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.
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. |
[ Impact ]
Currently, the Pro client support a daemon named ubuntu-advantage.service that
performs two actions:
* 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
Therefore, this daemon is only being activated on generic 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 no services to be enabled, but still want to attach to the Pro license.
2) Our daemon starts running before cloud-config.service 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.
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.
Build image that pulls pro from -proposed but otherwise follows the standard pro image build hook. Upload and register the image with the cloud for testing.
#Set cloud-init userdata that disables all pro services
$ cat userdata.yaml
#cloud-config
ubuntu_advantage:
enable: []
#Instantiate VM (GCP)
$ gcloud compute instances create pro-order-bug-mantic --image [IMAGE_NAME] --image-project ubuntu-catred --metadata-from-file=user-data=userdata.yaml --zone us-central1-a
#Instantiate VM (Azure)
[TODO]
#On VM, validate version of pro and bugfix (services disable, no cloud-init warnings in log)
$ apt-cache policy ubuntu-pro-client
ubuntu-pro-client:
Installed: 31.2.3~[RELEASE]
Candidate: 31.2.3~[RELEASE]
$ cat /var/log/cloud-init.log | grep 'WARNING'
$ pro status
SERVICE AVAILABLE DESCRIPTION
anbox-cloud yes Scalable Android in the cloud
esm-apps yes Expanded Security Maintenance for Applications
esm-infra yes Expanded Security Maintenance for Infrastructure
landscape yes Management and administration tool for Ubuntu
livepatch yes Current kernel is not supported
For a list of all Ubuntu Pro services, run 'pro status --all'
This machine is not attached to an Ubuntu Pro subscription.
See https://ubuntu.com/pro
Supported livepatch kernels are listed here: https://ubuntu.com/security/livepatch/docs/kernels
If the bug is still present, there will be a WARNING in the cloud-init log and pro status will return something similar to:
SERVICE ENTITLED STATUS DESCRIPTION
anbox-cloud yes disabled Scalable Android in the cloud
esm-apps yes enabled Expanded Security Maintenance for Applications
esm-infra yes enabled Expanded Security Maintenance for Infrastructure
fips-preview yes disabled Preview of FIPS crypto packages undergoing certification with NIST
fips-updates yes disabled FIPS compliant crypto packages with stable security updates
livepatch yes enabled Canonical Livepatch service
usg yes disabled Security compliance and audit tools
For a list of all Ubuntu Pro services, run 'pro status --all'
Enable services with: pro enable <service>
Account: ubuntu-catred
Subscription: ubuntu-catred
Valid until: Fri Dec 31 00:00:00 9999 UTC
Technical support level: essential
[ 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. |
|
| 2024-05-02 17:47:40 |
Catherine Redfield |
tags |
verification-needed verification-needed-bionic verification-needed-focal verification-needed-jammy verification-needed-mantic verification-needed-xenial |
|
|
| 2024-05-02 17:48:38 |
Catherine Redfield |
tags |
|
verification-done-bionic verification-done-focal verification-done-jammy |
|
| 2024-05-06 14:46:15 |
Andreas Hasenack |
tags |
verification-done-bionic verification-done-focal verification-done-jammy |
verification-done-bionic verification-done-focal verification-done-jammy verification-done-xenial |
|
| 2024-05-06 14:53:06 |
Andreas Hasenack |
tags |
verification-done-bionic verification-done-focal verification-done-jammy verification-done-xenial |
verification-done-bionic verification-done-focal verification-done-jammy verification-needed-xenial |
|
| 2024-05-06 19:38:13 |
Andreas Hasenack |
bug |
|
|
added subscriber Andreas Hasenack |
| 2024-05-06 19:43:21 |
Andreas Hasenack |
ubuntu-advantage-tools (Ubuntu Xenial): status |
Fix Committed |
Invalid |
|
| 2024-05-06 19:43:41 |
Andreas Hasenack |
tags |
verification-done-bionic verification-done-focal verification-done-jammy verification-needed-xenial |
verification-done-bionic verification-done-focal verification-done-jammy verification-failed-xenial |
|
| 2024-05-07 13:14:31 |
Lucas Albuquerque Medeiros de Moura |
attachment added |
|
mantic-test-results.tar.xz https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/2059952/+attachment/5775924/+files/mantic-test-results.tar.xz |
|
| 2024-05-07 13:19:57 |
Andreas Hasenack |
tags |
verification-done-bionic verification-done-focal verification-done-jammy verification-failed-xenial |
verification-done-bionic verification-done-focal verification-done-jammy verification-done-mantic verification-failed-xenial |
|
| 2024-05-07 13:22:20 |
Launchpad Janitor |
ubuntu-advantage-tools (Ubuntu Mantic): status |
Fix Committed |
Fix Released |
|
| 2024-05-07 13:22:24 |
Andreas Hasenack |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2024-05-07 13:22:38 |
Launchpad Janitor |
ubuntu-advantage-tools (Ubuntu Jammy): status |
Fix Committed |
Fix Released |
|
| 2024-05-07 13:22:51 |
Launchpad Janitor |
ubuntu-advantage-tools (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
| 2024-05-07 13:23:26 |
Launchpad Janitor |
ubuntu-advantage-tools (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
