ua fails if any package removed from server
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
ubuntu-advantage-tools (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[Impact]
This bug causes enabling services during a `ua fix` operation to fail.
That means that any user that is attached to a UA contract, but needs a particular service to fix a USN or CVE could run into this bug if they try to use `ua fix` to fix that USN/CVE.
In practice, this probably mostly affects xenial users who are attached to a UA contract, but don't have `esm-infra` enabled. For them, many `ua fix` attempts will fail because they attempt to enable `esm-infra`.
The bug occurred because we are re-using a function to `enable` that has a required argument that isn't checked by mypy. When this new required argument got added to the function, we failed to update this callsite. That happened because the args are currently passed via an argparse Namespace object and so the discrepancy wasn't captured by mypy.
The fix is to pass the required argument.
[Test Plan]
To Reproduce:
```
lxc launch ubuntu-daily:xenial x-1969809
lxc exec x-1969809 -- apt update
lxc exec x-1969809 -- apt upgrade
lxc exec x-1969809 -- apt install apache2
lxc exec x-1969809 -- ua attach --no-auto-enable $YOUR_TOKEN
lxc exec x-1969809 -- ua fix usn-4994-2
# respond with "e" to the prompt
```
You should see "Unexpected error(s) occurred."
To see that release 27.9 of ubuntu-
```
lxc launch ubuntu-daily:xenial x-1969809
lxc exec x-1969809 -- add-apt-repository ppa:ua-
lxc exec x-1969809 -- apt update
lxc exec x-1969809 -- apt upgrade
lxc exec x-1969809 -- apt install apache2
lxc exec x-1969809 -- ua attach --no-auto-enable $YOUR_TOKEN
lxc exec x-1969809 -- ua fix usn-4994-2
# respond with "e" to the prompt
```
You should see "USN-4994-2 is resolved."
[Where problems could occur]
Because the fix just adds the required argument, similar problems could occur in the future if we add a new required argument (or rename an argument, etc) and again forget to update this callsite.
If our fix of passing the required arg is wrong somehow (e.g. mispelled), then this same bug will continue to occur.
If our fix is egregiously wrong (e.g. invalid python), then all `ua fix` attempts could fail, not just those that require a service enabled in the middle.
[Other Info]
In the future, we should move away from re-using the cli action functions with Namespace args for this functionality. Instead we should use functions with mypy-type-checked arguments. We will likely do this soon as a refactor of `ua fix` is on our roadmap for this cycle.
[Original Description]
I'm using the ua tool (version 27.7~16.04.1). I'm unable to enable the esm-infra service because a couple of the packages that I have installed have been completely removed from the launchpad server. Specifically:
deb http://
deb http://
When I remove these package definitions from /etc/apt/
I've attached a log file that includes this stack trace.
Traceback (most recent call last):
File "/usr/lib/
return func(*args, **kwargs)
File "/usr/lib/
return args.action(args, cfg=cfg)
File "/usr/lib/
fix_status = security.
File "/usr/lib/
usn_
File "/usr/lib/
num_pkgs=count,
File "/usr/lib/
cfg, binary_pkgs, pocket
File "/usr/lib/
if not _check_
File "/usr/lib/
if _prompt_
File "/usr/lib/
cfg,
File "/usr/lib/
if cmd_args.format == "json" and not cmd_args.
AttributeError: 'Namespace' object has no attribute 'format'
description: | updated |
Hi cs-huit, thanks for reporting this issue.
Looking at the logs this seems like a real bug on UA regarding the ua fix command.
I will make a PR that address this issue.
However, on the meantime, if you want to keep those packages, please run:
$ ua enable esm-infra
And then run:
$ ua fix USN-4994-2
It should not prompt you anymore for enabling esm-infra and the command should finish without other exceptions.
But please let me know if doing that still cause some issues.