UDI snap ships the package, thus its data dir is part of the snap
subiquity snap does not.
This tries l-s-c data dir in the base system, outside of the snap
and gives up if the dir does not exits.
The following commmit:
ce146ab28 add .path to Raid so for_client(raid-with-partitions) works
introduced a (read only) path property for Raid objects, returning an
imaginary value to make for_client work with Raid objects. Later on, the
following commit:
8e658998e add "path" attributes to fs model objects that curtin now
provides a path for
introduced a (read/write) path attribute to all filesystem objects. For
Raid however, the property still takes precedence over the new attribute
of the same name, so doing raid.path = x is invalid (no setter) and
results in the following exception:
AttributeError: can't set attribute 'path'
Fixed by using a @property + @setter attribute for path. The getter
returns the actual path if it exists, otherwise returns the same
imaginary value as before.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
When we start supporting source variations we are going to need to set
these up and tear them down a lot more often, trying to keep just one as
app.controllers.Source._handler is going to get difficult. I actually
think this is cleaner overall (at least until we get to downloading
installation sources from the internet...).
In LP: 2009797, an exception of this form happens:
AttributeError: 'FilesystemController' object has no attribute '_start_task'
The installer client, u-d-i, is asking for storage information ASAP
after the socket starts listening, and in this case that happened before
all controllers were started. The sync primitive the probe is waiting
on wasn't created yet.
With one known exception, /meta/status, we really shouldn't be
responding to random API calls, and the startup sequence of the
controllers should be relatively quick (sub 1 second to be sure).
Just delay them, except for the special one.
SingleInstanceTask has distinct steps for creation of the object, and
starting the task. If a different coroutine is waiting on the
SingleInstanceTask, it isn't safe to directly call
SingleInstanceTask.wait() as the task may or may not have been created
yet.
Existing code usage of SingleInstanceTask is in 4 categories, with
reguards to SingleInstanceTask.wait():
1) using SingleInstanceTask without using SingleInstanceTask.wait().
This is unchanged.
2) using SingleInstanceTask.wait without a check on task is not None.
This may be safe now, but is fragile in the face of innocent-looking
refactors around the SingleInstanceTask.
3) using SingleInstanceTask.wait after confirming that the task is not
None. This is fine but a leaky abstraction.
4) directly waiting on the SingleInstanceTask.task. Another leaky
abstraction, but it's solving a cancellation problem. Leaving this
alone.
By enhancing SingleInstanceTask.wait(), cases 2 and 3 are improved. The
code not checking the task today is made safer, and the code checking
the task today can be simplified.
We aren't close to hitting this timeout in unit tests that I can see,
but some of the asyncio tests I'm writing for now risk a hang and I
don't want to get CI stuck.
Dan Bungert