| 2024-04-08 17:46:42 |
Lucas Albuquerque Medeiros de Moura |
bug |
|
|
added bug |
| 2024-04-08 18:31:50 |
Lucas Albuquerque Medeiros de Moura |
description |
As Trusty is reaching EOL of ESM support, we are now creating a new service called esm-infra-legacy to extend that support for more time |
[Impact]
As Trusty is reaching EOL of ESM support, we are now creating a new service called esm-infra-legacy to extend ESM support for more time.
Users who are entitled to that service, will need to run both of these commands to enable the service in their machine:
$ ua refresh
$ ua enable esm-infra-legacy
The first command will update the contract definitions on the machine, making it aware of the esm-infra-legacy service, and the second command enables it on the
machine.
Additionally, we can see that esm-infra-legacy will be a standalone service, meaning that users won't need to have esm-infra already enabled before enabling that service. This also means that both esm-infra and esm-infra-legacy are completely independent of one another, in the sense that changes on esm-infra should not affect esm-infra-legacy and vice versa. However, there is one situation where esm-infra will impact esm-infra-legacy. We will better discuss that on the discussion section.
Finally, users should now see esm-infra-legacy output on status from now on, when attached and unattached. Users will also see that service on the output of ua help as well.
[Test cases]
The Trusty version of the client only has a subset of the integration tests we have on the other releases that support the client. Due to that, we will need to perform several manual tests to guarantee that the support for esm-infra-legacy is working and we are not affecting existing customers.
Therefore, besides running the current test for the Trusty package, we will run the following tests:
* Enabling esm-infra-legacy
- User is attached to a subscription that is entitled to esm-infra-legacy
- User can see esm-infra-legacy on ua help
- User can enable esm-infra-legacy through ua enable esm-infra-legacy
- User see esm-infra-legacy as enabled on the output of ua status
- User can see esm-infra-legacy enabled on the output of apt-cache policy
- User can disable esm-infra-legacy
- User can see that esm-infra-legacy is disabled on the machine
- User enables esm-infra-legacy again
- User can detach with esm-infra-legacy enabled on the machine
* Interactions with esm-infra
- User is attached to a subscription that is entitled to both esm-infra and esm-infra-legacy
- User has esm-infra enabled
- User can enable esm-infra-legacy
- User can see both esm-infra and esm-infra-legacy as enabled on status
- User can disable esm-infra-legacy and not affect esm-infra
* User that is not entitled to esm-infra-legacy
- User is attached to a subscription
- User cannot enable esm-infra-legacy
- User can see the service on status, which will show the service as not entitled
* User that buys access to esm-infra-legacy
- User is already attached to a subscription
- User runs ua refresh
- User enable esm-infra-legacy
- User can see that the service is enabled on ua status
* User that is attaching a new subscription
- User subscription can be either entitled or not to esm-infra-legacy
- In both situations, when the user runs ua attach, they will verify that:
- esm-infra will be enabled by default
- esm-infra-legacy should not be enabled by default
* Upgrade scenarios:
- User on Trusty running version <= 19.6
- User is attached to a subscription
- User has esm-infra enabled
- User upgrades to new Trusty package
- User is still attached and sees esm-infra as enabled
- User can enable esm-infra-legacy
- User on Trusty running version <= 19.6
- User is attached to a subscription
- User upgrades to new Trusty package
- User enables esm-infra-legacy
- User runs a do-release-upgrade
- User will see that it is still attached
- User still has esm-infra service enabled
- User cannot see any indication of esm-infra-legacy on ua status and ua help
- Users on other Ubuntu releases
- Users should never see any mention of esm-infra-legacy service
[Discussions]
There are main aspects of the esm-infra-legacy service that need to be discussed here: The interaction between esm-infra-legacy and esm-infra and the disable strategy used for esm-infra-legacy.
Regarding the first aspect, the services should be independent of one another, however there is one situation where that doesn't happen. If the user disables esm-infra it will also disable esm-infra-legacy. That is because the esm-infra service in Trusty is disabled by performing the following steps:
* removing the service line from /etc/apt/auth.conf.d
* Create a preference file on /etc/apt/preferences.d with the following content:
Package: *
Pin: release o=UbuntuESM, n=trusty
Pin-Priority: never
This pin file is also disabling esm-infra-legacy because both services share the same origin, UbuntuESM. By fixing that, we would need to touch the logic related to disabling esm-infra, due to the extra risk tied to that change, we have discussed this with Product and we have concluded that we can proceed with the release even with this issue, that is because:
1) We believe it is highly unlikely that an user will disable esm-infra on Trusty today
2) When documenting about the esm-infra-legacy support, we can tell users what will happen when disabling the esm-infra service.
The second point is that we are disabling esm-infra-legacy differently then what we do for esm-infra. As we have mentioned, when disabling esm-infra we perform the two steps above, that is because we want users to still see the esm-infra packages on APT, even if the service is disabled. However, if we used the same estrategy for esm-infra-legacy, disabling esm-infra-legacy would also disable esm-infra, because of the preference file we already discussed. Because of that, when an user disables esm-infra-legacy, we will remove the source file on /etc/apt/sources.list.d/ to only affect the esm-infra-legacy service.
[Regression Potential]
We are adding a new service to the Trusty package. Since this is a new service and we will perform several tests already outlined to see how that service will appear in ua status and how it will interact with other services, we believe the regression potential here should be low. |
|
| 2024-04-08 18:43:44 |
Lucas Albuquerque Medeiros de Moura |
nominated for series |
|
Ubuntu Trusty |
|
| 2024-04-08 18:43:44 |
Lucas Albuquerque Medeiros de Moura |
bug task added |
|
ubuntu-advantage-tools (Ubuntu Trusty) |
|
| 2024-04-08 19:42:44 |
Andreas Hasenack |
description |
[Impact]
As Trusty is reaching EOL of ESM support, we are now creating a new service called esm-infra-legacy to extend ESM support for more time.
Users who are entitled to that service, will need to run both of these commands to enable the service in their machine:
$ ua refresh
$ ua enable esm-infra-legacy
The first command will update the contract definitions on the machine, making it aware of the esm-infra-legacy service, and the second command enables it on the
machine.
Additionally, we can see that esm-infra-legacy will be a standalone service, meaning that users won't need to have esm-infra already enabled before enabling that service. This also means that both esm-infra and esm-infra-legacy are completely independent of one another, in the sense that changes on esm-infra should not affect esm-infra-legacy and vice versa. However, there is one situation where esm-infra will impact esm-infra-legacy. We will better discuss that on the discussion section.
Finally, users should now see esm-infra-legacy output on status from now on, when attached and unattached. Users will also see that service on the output of ua help as well.
[Test cases]
The Trusty version of the client only has a subset of the integration tests we have on the other releases that support the client. Due to that, we will need to perform several manual tests to guarantee that the support for esm-infra-legacy is working and we are not affecting existing customers.
Therefore, besides running the current test for the Trusty package, we will run the following tests:
* Enabling esm-infra-legacy
- User is attached to a subscription that is entitled to esm-infra-legacy
- User can see esm-infra-legacy on ua help
- User can enable esm-infra-legacy through ua enable esm-infra-legacy
- User see esm-infra-legacy as enabled on the output of ua status
- User can see esm-infra-legacy enabled on the output of apt-cache policy
- User can disable esm-infra-legacy
- User can see that esm-infra-legacy is disabled on the machine
- User enables esm-infra-legacy again
- User can detach with esm-infra-legacy enabled on the machine
* Interactions with esm-infra
- User is attached to a subscription that is entitled to both esm-infra and esm-infra-legacy
- User has esm-infra enabled
- User can enable esm-infra-legacy
- User can see both esm-infra and esm-infra-legacy as enabled on status
- User can disable esm-infra-legacy and not affect esm-infra
* User that is not entitled to esm-infra-legacy
- User is attached to a subscription
- User cannot enable esm-infra-legacy
- User can see the service on status, which will show the service as not entitled
* User that buys access to esm-infra-legacy
- User is already attached to a subscription
- User runs ua refresh
- User enable esm-infra-legacy
- User can see that the service is enabled on ua status
* User that is attaching a new subscription
- User subscription can be either entitled or not to esm-infra-legacy
- In both situations, when the user runs ua attach, they will verify that:
- esm-infra will be enabled by default
- esm-infra-legacy should not be enabled by default
* Upgrade scenarios:
- User on Trusty running version <= 19.6
- User is attached to a subscription
- User has esm-infra enabled
- User upgrades to new Trusty package
- User is still attached and sees esm-infra as enabled
- User can enable esm-infra-legacy
- User on Trusty running version <= 19.6
- User is attached to a subscription
- User upgrades to new Trusty package
- User enables esm-infra-legacy
- User runs a do-release-upgrade
- User will see that it is still attached
- User still has esm-infra service enabled
- User cannot see any indication of esm-infra-legacy on ua status and ua help
- Users on other Ubuntu releases
- Users should never see any mention of esm-infra-legacy service
[Discussions]
There are main aspects of the esm-infra-legacy service that need to be discussed here: The interaction between esm-infra-legacy and esm-infra and the disable strategy used for esm-infra-legacy.
Regarding the first aspect, the services should be independent of one another, however there is one situation where that doesn't happen. If the user disables esm-infra it will also disable esm-infra-legacy. That is because the esm-infra service in Trusty is disabled by performing the following steps:
* removing the service line from /etc/apt/auth.conf.d
* Create a preference file on /etc/apt/preferences.d with the following content:
Package: *
Pin: release o=UbuntuESM, n=trusty
Pin-Priority: never
This pin file is also disabling esm-infra-legacy because both services share the same origin, UbuntuESM. By fixing that, we would need to touch the logic related to disabling esm-infra, due to the extra risk tied to that change, we have discussed this with Product and we have concluded that we can proceed with the release even with this issue, that is because:
1) We believe it is highly unlikely that an user will disable esm-infra on Trusty today
2) When documenting about the esm-infra-legacy support, we can tell users what will happen when disabling the esm-infra service.
The second point is that we are disabling esm-infra-legacy differently then what we do for esm-infra. As we have mentioned, when disabling esm-infra we perform the two steps above, that is because we want users to still see the esm-infra packages on APT, even if the service is disabled. However, if we used the same estrategy for esm-infra-legacy, disabling esm-infra-legacy would also disable esm-infra, because of the preference file we already discussed. Because of that, when an user disables esm-infra-legacy, we will remove the source file on /etc/apt/sources.list.d/ to only affect the esm-infra-legacy service.
[Regression Potential]
We are adding a new service to the Trusty package. Since this is a new service and we will perform several tests already outlined to see how that service will appear in ua status and how it will interact with other services, we believe the regression potential here should be low. |
[Impact]
As Trusty is reaching EOL of ESM support, we are now creating a new service called esm-infra-legacy to extend ESM support for more time.
Users who are entitled to that service, will need to run both of these commands to enable the service in their machine:
$ ua refresh
$ ua enable esm-infra-legacy
The first command will update the contract definitions on the machine, making it aware of the esm-infra-legacy service, and the second command enables it on the machine.
Additionally, we can see that esm-infra-legacy will be a standalone service, meaning that users won't need to have esm-infra already enabled before enabling that service. This also means that both esm-infra and esm-infra-legacy are completely independent of one another, in the sense that changes on esm-infra should not affect esm-infra-legacy and vice versa. However, there is one situation where esm-infra will impact esm-infra-legacy. We will better discuss that on the discussion section.
Finally, users should now see esm-infra-legacy output on status from now on, when attached and unattached. Users will also see that service on the output of ua help as well.
[Test cases]
The Trusty version of the client only has a subset of the integration tests we have on the other releases that support the client. Due to that, we will need to perform several manual tests to guarantee that the support for esm-infra-legacy is working and we are not affecting existing customers.
Therefore, besides running the current test for the Trusty package, we will run the following tests:
* Enabling esm-infra-legacy
- User is attached to a subscription that is entitled to esm-infra-legacy
- User can see esm-infra-legacy on ua help
- User can enable esm-infra-legacy through ua enable esm-infra-legacy
- User see esm-infra-legacy as enabled on the output of ua status
- User can see esm-infra-legacy enabled on the output of apt-cache policy
- User can disable esm-infra-legacy
- User can see that esm-infra-legacy is disabled on the machine
- User enables esm-infra-legacy again
- User can detach with esm-infra-legacy enabled on the machine
* Interactions with esm-infra
- User is attached to a subscription that is entitled to both esm-infra and esm-infra-legacy
- User has esm-infra enabled
- User can enable esm-infra-legacy
- User can see both esm-infra and esm-infra-legacy as enabled on status
- User can disable esm-infra-legacy and not affect esm-infra
* User that is not entitled to esm-infra-legacy
- User is attached to a subscription
- User cannot enable esm-infra-legacy
- User can see the service on status, which will show the service as not entitled
* User that buys access to esm-infra-legacy
- User is already attached to a subscription
- User runs ua refresh
- User enable esm-infra-legacy
- User can see that the service is enabled on ua status
* User that is attaching a new subscription
- User subscription can be either entitled or not to esm-infra-legacy
- In both situations, when the user runs ua attach, they will verify that:
- esm-infra will be enabled by default
- esm-infra-legacy should not be enabled by default
* Upgrade scenarios:
- User on Trusty running version <= 19.6
- User is attached to a subscription
- User has esm-infra enabled
- User upgrades to new Trusty package
- User is still attached and sees esm-infra as enabled
- User can enable esm-infra-legacy
- User on Trusty running version <= 19.6
- User is attached to a subscription
- User upgrades to new Trusty package
- User enables esm-infra-legacy
- User runs a do-release-upgrade
- User will see that it is still attached
- User still has esm-infra service enabled
- User cannot see any indication of esm-infra-legacy on ua status and ua help
- Users on other Ubuntu releases
- Users should never see any mention of esm-infra-legacy service
[Discussions]
There are main aspects of the esm-infra-legacy service that need to be discussed here: The interaction between esm-infra-legacy and esm-infra and the disable strategy used for esm-infra-legacy.
Regarding the first aspect, the services should be independent of one another, however there is one situation where that doesn't happen. If the user disables esm-infra it will also disable esm-infra-legacy. That is because the esm-infra service in Trusty is disabled by performing the following steps:
* removing the service line from /etc/apt/auth.conf.d
* Create a preference file on /etc/apt/preferences.d with the following content:
Package: *
Pin: release o=UbuntuESM, n=trusty
Pin-Priority: never
This pin file is also disabling esm-infra-legacy because both services share the same origin, UbuntuESM. By fixing that, we would need to touch the logic related to disabling esm-infra, due to the extra risk tied to that change, we have discussed this with Product and we have concluded that we can proceed with the release even with this issue, that is because:
1) We believe it is highly unlikely that an user will disable esm-infra on Trusty today
2) When documenting about the esm-infra-legacy support, we can tell users what will happen when disabling the esm-infra service.
The second point is that we are disabling esm-infra-legacy differently then what we do for esm-infra. As we have mentioned, when disabling esm-infra we perform the two steps above, that is because we want users to still see the esm-infra packages on APT, even if the service is disabled. However, if we used the same estrategy for esm-infra-legacy, disabling esm-infra-legacy would also disable esm-infra, because of the preference file we already discussed. Because of that, when an user disables esm-infra-legacy, we will remove the source file on /etc/apt/sources.list.d/ to only affect the esm-infra-legacy service.
[Regression Potential]
We are adding a new service to the Trusty package. Since this is a new service and we will perform several tests already outlined to see how that service will appear in ua status and how it will interact with other services, we believe the regression potential here should be low. |
|
| 2024-04-08 20:17:16 |
Lucas Albuquerque Medeiros de Moura |
description |
[Impact]
As Trusty is reaching EOL of ESM support, we are now creating a new service called esm-infra-legacy to extend ESM support for more time.
Users who are entitled to that service, will need to run both of these commands to enable the service in their machine:
$ ua refresh
$ ua enable esm-infra-legacy
The first command will update the contract definitions on the machine, making it aware of the esm-infra-legacy service, and the second command enables it on the machine.
Additionally, we can see that esm-infra-legacy will be a standalone service, meaning that users won't need to have esm-infra already enabled before enabling that service. This also means that both esm-infra and esm-infra-legacy are completely independent of one another, in the sense that changes on esm-infra should not affect esm-infra-legacy and vice versa. However, there is one situation where esm-infra will impact esm-infra-legacy. We will better discuss that on the discussion section.
Finally, users should now see esm-infra-legacy output on status from now on, when attached and unattached. Users will also see that service on the output of ua help as well.
[Test cases]
The Trusty version of the client only has a subset of the integration tests we have on the other releases that support the client. Due to that, we will need to perform several manual tests to guarantee that the support for esm-infra-legacy is working and we are not affecting existing customers.
Therefore, besides running the current test for the Trusty package, we will run the following tests:
* Enabling esm-infra-legacy
- User is attached to a subscription that is entitled to esm-infra-legacy
- User can see esm-infra-legacy on ua help
- User can enable esm-infra-legacy through ua enable esm-infra-legacy
- User see esm-infra-legacy as enabled on the output of ua status
- User can see esm-infra-legacy enabled on the output of apt-cache policy
- User can disable esm-infra-legacy
- User can see that esm-infra-legacy is disabled on the machine
- User enables esm-infra-legacy again
- User can detach with esm-infra-legacy enabled on the machine
* Interactions with esm-infra
- User is attached to a subscription that is entitled to both esm-infra and esm-infra-legacy
- User has esm-infra enabled
- User can enable esm-infra-legacy
- User can see both esm-infra and esm-infra-legacy as enabled on status
- User can disable esm-infra-legacy and not affect esm-infra
* User that is not entitled to esm-infra-legacy
- User is attached to a subscription
- User cannot enable esm-infra-legacy
- User can see the service on status, which will show the service as not entitled
* User that buys access to esm-infra-legacy
- User is already attached to a subscription
- User runs ua refresh
- User enable esm-infra-legacy
- User can see that the service is enabled on ua status
* User that is attaching a new subscription
- User subscription can be either entitled or not to esm-infra-legacy
- In both situations, when the user runs ua attach, they will verify that:
- esm-infra will be enabled by default
- esm-infra-legacy should not be enabled by default
* Upgrade scenarios:
- User on Trusty running version <= 19.6
- User is attached to a subscription
- User has esm-infra enabled
- User upgrades to new Trusty package
- User is still attached and sees esm-infra as enabled
- User can enable esm-infra-legacy
- User on Trusty running version <= 19.6
- User is attached to a subscription
- User upgrades to new Trusty package
- User enables esm-infra-legacy
- User runs a do-release-upgrade
- User will see that it is still attached
- User still has esm-infra service enabled
- User cannot see any indication of esm-infra-legacy on ua status and ua help
- Users on other Ubuntu releases
- Users should never see any mention of esm-infra-legacy service
[Discussions]
There are main aspects of the esm-infra-legacy service that need to be discussed here: The interaction between esm-infra-legacy and esm-infra and the disable strategy used for esm-infra-legacy.
Regarding the first aspect, the services should be independent of one another, however there is one situation where that doesn't happen. If the user disables esm-infra it will also disable esm-infra-legacy. That is because the esm-infra service in Trusty is disabled by performing the following steps:
* removing the service line from /etc/apt/auth.conf.d
* Create a preference file on /etc/apt/preferences.d with the following content:
Package: *
Pin: release o=UbuntuESM, n=trusty
Pin-Priority: never
This pin file is also disabling esm-infra-legacy because both services share the same origin, UbuntuESM. By fixing that, we would need to touch the logic related to disabling esm-infra, due to the extra risk tied to that change, we have discussed this with Product and we have concluded that we can proceed with the release even with this issue, that is because:
1) We believe it is highly unlikely that an user will disable esm-infra on Trusty today
2) When documenting about the esm-infra-legacy support, we can tell users what will happen when disabling the esm-infra service.
The second point is that we are disabling esm-infra-legacy differently then what we do for esm-infra. As we have mentioned, when disabling esm-infra we perform the two steps above, that is because we want users to still see the esm-infra packages on APT, even if the service is disabled. However, if we used the same estrategy for esm-infra-legacy, disabling esm-infra-legacy would also disable esm-infra, because of the preference file we already discussed. Because of that, when an user disables esm-infra-legacy, we will remove the source file on /etc/apt/sources.list.d/ to only affect the esm-infra-legacy service.
[Regression Potential]
We are adding a new service to the Trusty package. Since this is a new service and we will perform several tests already outlined to see how that service will appear in ua status and how it will interact with other services, we believe the regression potential here should be low. |
[Impact]
As Trusty is reaching EOL of ESM support, we are now creating a new service called esm-infra-legacy to extend ESM support for more time.
This service will only be available and visible on Trusty and users who are entitled to that service, will need to run both of these commands to enable the service in their machine:
$ ua refresh
$ ua enable esm-infra-legacy
The first command will update the contract definitions on the machine, making it aware of the esm-infra-legacy service, and the second command enables it on the
machine.
Additionally, we can see that esm-infra-legacy will be a standalone service, meaning that users won't need to have esm-infra already enabled before enabling that service. This also means that both esm-infra and esm-infra-legacy are completely independent of one another, in the sense that changes on esm-infra should not affect esm-infra-legacy and vice versa. However, there is one situation where esm-infra will impact esm-infra-legacy. We will better discuss that on the discussion section.
Finally, users should now see esm-infra-legacy output on status from now on, when attached and unattached. Users will also see that service on the output of ua help as well.
[Test cases]
The Trusty version of the client only has a subset of the integration tests we have on the other releases that support the client. Due to that, we will need to perform several manual tests to guarantee that the support for esm-infra-legacy is working and we are not affecting existing customers.
Therefore, besides running the current test for the Trusty package, we will run the following tests:
* Enabling esm-infra-legacy
- User is attached to a subscription that is entitled to esm-infra-legacy
- User can see esm-infra-legacy on ua help
- User can enable esm-infra-legacy through ua enable esm-infra-legacy
- User see esm-infra-legacy as enabled on the output of ua status
- User can see esm-infra-legacy enabled on the output of apt-cache policy
- User can disable esm-infra-legacy
- User can see that esm-infra-legacy is disabled on the machine
- User enables esm-infra-legacy again
- User can detach with esm-infra-legacy enabled on the machine
* Interactions with esm-infra
- User is attached to a subscription that is entitled to both esm-infra and esm-infra-legacy
- User has esm-infra enabled
- User can enable esm-infra-legacy
- User can see both esm-infra and esm-infra-legacy as enabled on status
- User can disable esm-infra-legacy and not affect esm-infra
* User that is not entitled to esm-infra-legacy
- User is attached to a subscription
- User cannot enable esm-infra-legacy
- User can see the service on status, which will show the service as not entitled
* User that buys access to esm-infra-legacy
- User is already attached to a subscription
- User runs ua refresh
- User enable esm-infra-legacy
- User can see that the service is enabled on ua status
* User that is attaching a new subscription
- User subscription can be either entitled or not to esm-infra-legacy
- In both situations, when the user runs ua attach, they will verify that:
- esm-infra will be enabled by default
- esm-infra-legacy should not be enabled by default
* Upgrade scenarios:
- User on Trusty running version <= 19.6
- User is attached to a subscription
- User has esm-infra enabled
- User upgrades to new Trusty package
- User is still attached and sees esm-infra as enabled
- User can enable esm-infra-legacy
- User on Trusty running version <= 19.6
- User is attached to a subscription
- User upgrades to new Trusty package
- User enables esm-infra-legacy
- User runs a do-release-upgrade
- User will see that it is still attached
- User still has esm-infra service enabled
- User cannot see any indication of esm-infra-legacy on ua status and ua help
- Users on other Ubuntu releases
- Users should never see any mention of esm-infra-legacy service
[Discussions]
There are main aspects of the esm-infra-legacy service that need to be discussed here: The interaction between esm-infra-legacy and esm-infra and the disable strategy used for esm-infra-legacy.
Regarding the first aspect, the services should be independent of one another, however there is one situation where that doesn't happen. If the user disables esm-infra it will also disable esm-infra-legacy. That is because the esm-infra service in Trusty is disabled by performing the following steps:
* removing the service line from /etc/apt/auth.conf.d
* Create a preference file on /etc/apt/preferences.d with the following content:
Package: *
Pin: release o=UbuntuESM, n=trusty
Pin-Priority: never
This pin file is also disabling esm-infra-legacy because both services share the same origin, UbuntuESM. By fixing that, we would need to touch the logic related to disabling esm-infra, due to the extra risk tied to that change, we have discussed this with Product and we have concluded that we can proceed with the release even with this issue, that is because:
1) We believe it is highly unlikely that an user will disable esm-infra on Trusty today
2) When documenting about the esm-infra-legacy support, we can tell users what will happen when disabling the esm-infra service.
The second point is that we are disabling esm-infra-legacy differently then what we do for esm-infra. As we have mentioned, when disabling esm-infra we perform the two steps above, that is because we want users to still see the esm-infra packages on APT, even if the service is disabled. However, if we used the same estrategy for esm-infra-legacy, disabling esm-infra-legacy would also disable esm-infra, because of the preference file we already discussed. Because of that, when an user disables esm-infra-legacy, we will remove the source file on /etc/apt/sources.list.d/ to only affect the esm-infra-legacy service.
[Regression Potential]
We are adding a new service to the Trusty package. Since this is a new service and we will perform several tests already outlined to see how that service will appear in ua status and how it will interact with other services, we believe the regression potential here should be low. |
|
| 2024-04-18 17:57:19 |
Andreas Hasenack |
description |
[Impact]
As Trusty is reaching EOL of ESM support, we are now creating a new service called esm-infra-legacy to extend ESM support for more time.
This service will only be available and visible on Trusty and users who are entitled to that service, will need to run both of these commands to enable the service in their machine:
$ ua refresh
$ ua enable esm-infra-legacy
The first command will update the contract definitions on the machine, making it aware of the esm-infra-legacy service, and the second command enables it on the
machine.
Additionally, we can see that esm-infra-legacy will be a standalone service, meaning that users won't need to have esm-infra already enabled before enabling that service. This also means that both esm-infra and esm-infra-legacy are completely independent of one another, in the sense that changes on esm-infra should not affect esm-infra-legacy and vice versa. However, there is one situation where esm-infra will impact esm-infra-legacy. We will better discuss that on the discussion section.
Finally, users should now see esm-infra-legacy output on status from now on, when attached and unattached. Users will also see that service on the output of ua help as well.
[Test cases]
The Trusty version of the client only has a subset of the integration tests we have on the other releases that support the client. Due to that, we will need to perform several manual tests to guarantee that the support for esm-infra-legacy is working and we are not affecting existing customers.
Therefore, besides running the current test for the Trusty package, we will run the following tests:
* Enabling esm-infra-legacy
- User is attached to a subscription that is entitled to esm-infra-legacy
- User can see esm-infra-legacy on ua help
- User can enable esm-infra-legacy through ua enable esm-infra-legacy
- User see esm-infra-legacy as enabled on the output of ua status
- User can see esm-infra-legacy enabled on the output of apt-cache policy
- User can disable esm-infra-legacy
- User can see that esm-infra-legacy is disabled on the machine
- User enables esm-infra-legacy again
- User can detach with esm-infra-legacy enabled on the machine
* Interactions with esm-infra
- User is attached to a subscription that is entitled to both esm-infra and esm-infra-legacy
- User has esm-infra enabled
- User can enable esm-infra-legacy
- User can see both esm-infra and esm-infra-legacy as enabled on status
- User can disable esm-infra-legacy and not affect esm-infra
* User that is not entitled to esm-infra-legacy
- User is attached to a subscription
- User cannot enable esm-infra-legacy
- User can see the service on status, which will show the service as not entitled
* User that buys access to esm-infra-legacy
- User is already attached to a subscription
- User runs ua refresh
- User enable esm-infra-legacy
- User can see that the service is enabled on ua status
* User that is attaching a new subscription
- User subscription can be either entitled or not to esm-infra-legacy
- In both situations, when the user runs ua attach, they will verify that:
- esm-infra will be enabled by default
- esm-infra-legacy should not be enabled by default
* Upgrade scenarios:
- User on Trusty running version <= 19.6
- User is attached to a subscription
- User has esm-infra enabled
- User upgrades to new Trusty package
- User is still attached and sees esm-infra as enabled
- User can enable esm-infra-legacy
- User on Trusty running version <= 19.6
- User is attached to a subscription
- User upgrades to new Trusty package
- User enables esm-infra-legacy
- User runs a do-release-upgrade
- User will see that it is still attached
- User still has esm-infra service enabled
- User cannot see any indication of esm-infra-legacy on ua status and ua help
- Users on other Ubuntu releases
- Users should never see any mention of esm-infra-legacy service
[Discussions]
There are main aspects of the esm-infra-legacy service that need to be discussed here: The interaction between esm-infra-legacy and esm-infra and the disable strategy used for esm-infra-legacy.
Regarding the first aspect, the services should be independent of one another, however there is one situation where that doesn't happen. If the user disables esm-infra it will also disable esm-infra-legacy. That is because the esm-infra service in Trusty is disabled by performing the following steps:
* removing the service line from /etc/apt/auth.conf.d
* Create a preference file on /etc/apt/preferences.d with the following content:
Package: *
Pin: release o=UbuntuESM, n=trusty
Pin-Priority: never
This pin file is also disabling esm-infra-legacy because both services share the same origin, UbuntuESM. By fixing that, we would need to touch the logic related to disabling esm-infra, due to the extra risk tied to that change, we have discussed this with Product and we have concluded that we can proceed with the release even with this issue, that is because:
1) We believe it is highly unlikely that an user will disable esm-infra on Trusty today
2) When documenting about the esm-infra-legacy support, we can tell users what will happen when disabling the esm-infra service.
The second point is that we are disabling esm-infra-legacy differently then what we do for esm-infra. As we have mentioned, when disabling esm-infra we perform the two steps above, that is because we want users to still see the esm-infra packages on APT, even if the service is disabled. However, if we used the same estrategy for esm-infra-legacy, disabling esm-infra-legacy would also disable esm-infra, because of the preference file we already discussed. Because of that, when an user disables esm-infra-legacy, we will remove the source file on /etc/apt/sources.list.d/ to only affect the esm-infra-legacy service.
[Regression Potential]
We are adding a new service to the Trusty package. Since this is a new service and we will perform several tests already outlined to see how that service will appear in ua status and how it will interact with other services, we believe the regression potential here should be low. |
[Impact]
As Trusty is reaching EOL of ESM support, we are now creating a new service called esm-infra-legacy to extend ESM support for more time.
This service will only be available and visible on Trusty, and users who are entitled to that service will need to run both of these commands to enable the service in their machine:
$ ua refresh
$ ua enable esm-infra-legacy
The first command will update the contract definitions on the machine, making it aware of the esm-infra-legacy service, and the second command enables it on the
machine.
Additionally, we can see that esm-infra-legacy will be a standalone service, meaning that users won't need to have esm-infra already enabled before enabling that service. This also means that both esm-infra and esm-infra-legacy are completely independent of one another, in the sense that changes on esm-infra should not affect esm-infra-legacy and vice versa. However, there is one situation where esm-infra will impact esm-infra-legacy. We will better discuss that on the discussion section.
Finally, users should now see esm-infra-legacy output on status from now on, when attached and unattached. Users will also see that service on the output of ua help as well.
[Test cases]
The Trusty version of the client only has a subset of the integration tests we have on the other releases that support the client. Due to that, we will need to perform several manual tests to guarantee that the support for esm-infra-legacy is working and we are not affecting existing customers.
Therefore, besides running the current test for the Trusty package, we will run the following tests:
* Enabling esm-infra-legacy
- User is attached to a subscription that is entitled to esm-infra-legacy
- User can see esm-infra-legacy on ua help
- User can enable esm-infra-legacy through ua enable esm-infra-legacy
- User see esm-infra-legacy as enabled on the output of ua status
- User can see esm-infra-legacy enabled on the output of apt-cache policy
- User can disable esm-infra-legacy
- User can see that esm-infra-legacy is disabled on the machine
- User enables esm-infra-legacy again
- User can detach with esm-infra-legacy enabled on the machine
* Interactions with esm-infra
- User is attached to a subscription that is entitled to both esm-infra and esm-infra-legacy
- User has esm-infra enabled
- User can enable esm-infra-legacy
- User can see both esm-infra and esm-infra-legacy as enabled on status
- User can disable esm-infra-legacy and not affect esm-infra
* User that is not entitled to esm-infra-legacy
- User is attached to a subscription
- User cannot enable esm-infra-legacy
- User can see the service on status, which will show the service as not entitled
* User that buys access to esm-infra-legacy
- User is already attached to a subscription
- User runs ua refresh
- User enable esm-infra-legacy
- User can see that the service is enabled on ua status
* User that is attaching a new subscription
- User subscription can be either entitled or not to esm-infra-legacy
- In both situations, when the user runs ua attach, they will verify that:
- esm-infra will be enabled by default
- esm-infra-legacy should not be enabled by default
* Upgrade scenarios:
- User on Trusty running version <= 19.6
- User is attached to a subscription
- User has esm-infra enabled
- User upgrades to new Trusty package
- User is still attached and sees esm-infra as enabled
- User can enable esm-infra-legacy
- User on Trusty running version <= 19.6
- User is attached to a subscription
- User upgrades to new Trusty package
- User enables esm-infra-legacy
- User runs a do-release-upgrade
- User will see that it is still attached
- User still has esm-infra service enabled
- User cannot see any indication of esm-infra-legacy on ua status and ua help
- Users on other Ubuntu releases
- Users should never see any mention of esm-infra-legacy service
[Discussions]
There are main aspects of the esm-infra-legacy service that need to be discussed here: The interaction between esm-infra-legacy and esm-infra and the disable strategy used for esm-infra-legacy.
Regarding the first aspect, the services should be independent of one another, however there is one situation where that doesn't happen. If the user disables esm-infra it will also disable esm-infra-legacy. That is because the esm-infra service in Trusty is disabled by performing the following steps:
* removing the service line from /etc/apt/auth.conf.d
* Create a preference file on /etc/apt/preferences.d with the following content:
Package: *
Pin: release o=UbuntuESM, n=trusty
Pin-Priority: never
This pin file is also disabling esm-infra-legacy because both services share the same origin, UbuntuESM. By fixing that, we would need to touch the logic related to disabling esm-infra, due to the extra risk tied to that change, we have discussed this with Product and we have concluded that we can proceed with the release even with this issue, that is because:
1) We believe it is highly unlikely that an user will disable esm-infra on Trusty today
2) When documenting about the esm-infra-legacy support, we can tell users what will happen when disabling the esm-infra service.
The second point is that we are disabling esm-infra-legacy differently then what we do for esm-infra. As we have mentioned, when disabling esm-infra we perform the two steps above, that is because we want users to still see the esm-infra packages on APT, even if the service is disabled. However, if we used the same estrategy for esm-infra-legacy, disabling esm-infra-legacy would also disable esm-infra, because of the preference file we already discussed. Because of that, when an user disables esm-infra-legacy, we will remove the source file on /etc/apt/sources.list.d/ to only affect the esm-infra-legacy service.
[Regression Potential]
We are adding a new service to the Trusty package. Since this is a new service and we will perform several tests already outlined to see how that service will appear in ua status and how it will interact with other services, we believe the regression potential here should be low. |
|
| 2024-04-18 17:57:37 |
Andreas Hasenack |
description |
[Impact]
As Trusty is reaching EOL of ESM support, we are now creating a new service called esm-infra-legacy to extend ESM support for more time.
This service will only be available and visible on Trusty, and users who are entitled to that service will need to run both of these commands to enable the service in their machine:
$ ua refresh
$ ua enable esm-infra-legacy
The first command will update the contract definitions on the machine, making it aware of the esm-infra-legacy service, and the second command enables it on the
machine.
Additionally, we can see that esm-infra-legacy will be a standalone service, meaning that users won't need to have esm-infra already enabled before enabling that service. This also means that both esm-infra and esm-infra-legacy are completely independent of one another, in the sense that changes on esm-infra should not affect esm-infra-legacy and vice versa. However, there is one situation where esm-infra will impact esm-infra-legacy. We will better discuss that on the discussion section.
Finally, users should now see esm-infra-legacy output on status from now on, when attached and unattached. Users will also see that service on the output of ua help as well.
[Test cases]
The Trusty version of the client only has a subset of the integration tests we have on the other releases that support the client. Due to that, we will need to perform several manual tests to guarantee that the support for esm-infra-legacy is working and we are not affecting existing customers.
Therefore, besides running the current test for the Trusty package, we will run the following tests:
* Enabling esm-infra-legacy
- User is attached to a subscription that is entitled to esm-infra-legacy
- User can see esm-infra-legacy on ua help
- User can enable esm-infra-legacy through ua enable esm-infra-legacy
- User see esm-infra-legacy as enabled on the output of ua status
- User can see esm-infra-legacy enabled on the output of apt-cache policy
- User can disable esm-infra-legacy
- User can see that esm-infra-legacy is disabled on the machine
- User enables esm-infra-legacy again
- User can detach with esm-infra-legacy enabled on the machine
* Interactions with esm-infra
- User is attached to a subscription that is entitled to both esm-infra and esm-infra-legacy
- User has esm-infra enabled
- User can enable esm-infra-legacy
- User can see both esm-infra and esm-infra-legacy as enabled on status
- User can disable esm-infra-legacy and not affect esm-infra
* User that is not entitled to esm-infra-legacy
- User is attached to a subscription
- User cannot enable esm-infra-legacy
- User can see the service on status, which will show the service as not entitled
* User that buys access to esm-infra-legacy
- User is already attached to a subscription
- User runs ua refresh
- User enable esm-infra-legacy
- User can see that the service is enabled on ua status
* User that is attaching a new subscription
- User subscription can be either entitled or not to esm-infra-legacy
- In both situations, when the user runs ua attach, they will verify that:
- esm-infra will be enabled by default
- esm-infra-legacy should not be enabled by default
* Upgrade scenarios:
- User on Trusty running version <= 19.6
- User is attached to a subscription
- User has esm-infra enabled
- User upgrades to new Trusty package
- User is still attached and sees esm-infra as enabled
- User can enable esm-infra-legacy
- User on Trusty running version <= 19.6
- User is attached to a subscription
- User upgrades to new Trusty package
- User enables esm-infra-legacy
- User runs a do-release-upgrade
- User will see that it is still attached
- User still has esm-infra service enabled
- User cannot see any indication of esm-infra-legacy on ua status and ua help
- Users on other Ubuntu releases
- Users should never see any mention of esm-infra-legacy service
[Discussions]
There are main aspects of the esm-infra-legacy service that need to be discussed here: The interaction between esm-infra-legacy and esm-infra and the disable strategy used for esm-infra-legacy.
Regarding the first aspect, the services should be independent of one another, however there is one situation where that doesn't happen. If the user disables esm-infra it will also disable esm-infra-legacy. That is because the esm-infra service in Trusty is disabled by performing the following steps:
* removing the service line from /etc/apt/auth.conf.d
* Create a preference file on /etc/apt/preferences.d with the following content:
Package: *
Pin: release o=UbuntuESM, n=trusty
Pin-Priority: never
This pin file is also disabling esm-infra-legacy because both services share the same origin, UbuntuESM. By fixing that, we would need to touch the logic related to disabling esm-infra, due to the extra risk tied to that change, we have discussed this with Product and we have concluded that we can proceed with the release even with this issue, that is because:
1) We believe it is highly unlikely that an user will disable esm-infra on Trusty today
2) When documenting about the esm-infra-legacy support, we can tell users what will happen when disabling the esm-infra service.
The second point is that we are disabling esm-infra-legacy differently then what we do for esm-infra. As we have mentioned, when disabling esm-infra we perform the two steps above, that is because we want users to still see the esm-infra packages on APT, even if the service is disabled. However, if we used the same estrategy for esm-infra-legacy, disabling esm-infra-legacy would also disable esm-infra, because of the preference file we already discussed. Because of that, when an user disables esm-infra-legacy, we will remove the source file on /etc/apt/sources.list.d/ to only affect the esm-infra-legacy service.
[Regression Potential]
We are adding a new service to the Trusty package. Since this is a new service and we will perform several tests already outlined to see how that service will appear in ua status and how it will interact with other services, we believe the regression potential here should be low. |
[Impact]
As Trusty is reaching EOL of ESM support, we are now creating a new service called esm-infra-legacy to extend ESM support for more time.
This service will only be available and visible on Trusty, and users who are entitled to that service will need to run both of these commands to enable the service in their machine:
$ ua refresh
$ ua enable esm-infra-legacy
The first command will update the contract definitions on the machine, making it aware of the esm-infra-legacy service, and the second command enables it on the machine.
Additionally, we can see that esm-infra-legacy will be a standalone service, meaning that users won't need to have esm-infra already enabled before enabling that service. This also means that both esm-infra and esm-infra-legacy are completely independent of one another, in the sense that changes on esm-infra should not affect esm-infra-legacy and vice versa. However, there is one situation where esm-infra will impact esm-infra-legacy. We will better discuss that on the discussion section.
Finally, users should now see esm-infra-legacy output on status from now on, when attached and unattached. Users will also see that service on the output of ua help as well.
[Test cases]
The Trusty version of the client only has a subset of the integration tests we have on the other releases that support the client. Due to that, we will need to perform several manual tests to guarantee that the support for esm-infra-legacy is working and we are not affecting existing customers.
Therefore, besides running the current test for the Trusty package, we will run the following tests:
* Enabling esm-infra-legacy
- User is attached to a subscription that is entitled to esm-infra-legacy
- User can see esm-infra-legacy on ua help
- User can enable esm-infra-legacy through ua enable esm-infra-legacy
- User see esm-infra-legacy as enabled on the output of ua status
- User can see esm-infra-legacy enabled on the output of apt-cache policy
- User can disable esm-infra-legacy
- User can see that esm-infra-legacy is disabled on the machine
- User enables esm-infra-legacy again
- User can detach with esm-infra-legacy enabled on the machine
* Interactions with esm-infra
- User is attached to a subscription that is entitled to both esm-infra and esm-infra-legacy
- User has esm-infra enabled
- User can enable esm-infra-legacy
- User can see both esm-infra and esm-infra-legacy as enabled on status
- User can disable esm-infra-legacy and not affect esm-infra
* User that is not entitled to esm-infra-legacy
- User is attached to a subscription
- User cannot enable esm-infra-legacy
- User can see the service on status, which will show the service as not entitled
* User that buys access to esm-infra-legacy
- User is already attached to a subscription
- User runs ua refresh
- User enable esm-infra-legacy
- User can see that the service is enabled on ua status
* User that is attaching a new subscription
- User subscription can be either entitled or not to esm-infra-legacy
- In both situations, when the user runs ua attach, they will verify that:
- esm-infra will be enabled by default
- esm-infra-legacy should not be enabled by default
* Upgrade scenarios:
- User on Trusty running version <= 19.6
- User is attached to a subscription
- User has esm-infra enabled
- User upgrades to new Trusty package
- User is still attached and sees esm-infra as enabled
- User can enable esm-infra-legacy
- User on Trusty running version <= 19.6
- User is attached to a subscription
- User upgrades to new Trusty package
- User enables esm-infra-legacy
- User runs a do-release-upgrade
- User will see that it is still attached
- User still has esm-infra service enabled
- User cannot see any indication of esm-infra-legacy on ua status and ua help
- Users on other Ubuntu releases
- Users should never see any mention of esm-infra-legacy service
[Discussions]
There are main aspects of the esm-infra-legacy service that need to be discussed here: The interaction between esm-infra-legacy and esm-infra and the disable strategy used for esm-infra-legacy.
Regarding the first aspect, the services should be independent of one another, however there is one situation where that doesn't happen. If the user disables esm-infra it will also disable esm-infra-legacy. That is because the esm-infra service in Trusty is disabled by performing the following steps:
* removing the service line from /etc/apt/auth.conf.d
* Create a preference file on /etc/apt/preferences.d with the following content:
Package: *
Pin: release o=UbuntuESM, n=trusty
Pin-Priority: never
This pin file is also disabling esm-infra-legacy because both services share the same origin, UbuntuESM. By fixing that, we would need to touch the logic related to disabling esm-infra, due to the extra risk tied to that change, we have discussed this with Product and we have concluded that we can proceed with the release even with this issue, that is because:
1) We believe it is highly unlikely that an user will disable esm-infra on Trusty today
2) When documenting about the esm-infra-legacy support, we can tell users what will happen when disabling the esm-infra service.
The second point is that we are disabling esm-infra-legacy differently then what we do for esm-infra. As we have mentioned, when disabling esm-infra we perform the two steps above, that is because we want users to still see the esm-infra packages on APT, even if the service is disabled. However, if we used the same estrategy for esm-infra-legacy, disabling esm-infra-legacy would also disable esm-infra, because of the preference file we already discussed. Because of that, when an user disables esm-infra-legacy, we will remove the source file on /etc/apt/sources.list.d/ to only affect the esm-infra-legacy service.
[Regression Potential]
We are adding a new service to the Trusty package. Since this is a new service and we will perform several tests already outlined to see how that service will appear in ua status and how it will interact with other services, we believe the regression potential here should be low. |
|
| 2024-04-18 18:02:48 |
Andreas Hasenack |
ubuntu-advantage-tools (Ubuntu Trusty): status |
New |
Fix Committed |
|
| 2024-04-18 18:02:49 |
Andreas Hasenack |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2024-04-18 18:02:52 |
Andreas Hasenack |
bug |
|
|
added subscriber SRU Verification |
| 2024-04-18 18:02:55 |
Andreas Hasenack |
tags |
|
verification-needed verification-needed-trusty |
|
| 2024-04-23 16:28:39 |
Lucas Albuquerque Medeiros de Moura |
attachment added |
|
trusty-test-results.tar.xz https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/2060566/+attachment/5769753/+files/trusty-test-results.tar.xz |
|
| 2024-04-23 17:34:31 |
Andreas Hasenack |
tags |
verification-needed verification-needed-trusty |
block-proposed-trusty verification-needed verification-needed-trusty |
|
| 2024-04-30 12:32:53 |
Lucas Albuquerque Medeiros de Moura |
tags |
block-proposed-trusty verification-needed verification-needed-trusty |
block-proposed-trusty verification-done verification-done-trusty |
|
| 2024-04-30 12:49:05 |
Andreas Hasenack |
tags |
block-proposed-trusty verification-done verification-done-trusty |
verification-done verification-done-trusty |
|
| 2024-04-30 16:53:44 |
Launchpad Janitor |
ubuntu-advantage-tools (Ubuntu Trusty): status |
Fix Committed |
Fix Released |
|
| 2024-04-30 16:53:47 |
Andreas Hasenack |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2024-04-30 17:22:38 |
Andreas Hasenack |
ubuntu-advantage-tools (Ubuntu): status |
New |
Invalid |
|
