In 13fe234b3927bd05 we broke a model test:
This breaks one of the model tests: test_example_model. Previously
all the MachineModels were instantiated during resolve_networking.
They are still instantiated, but instantiated through the
ResolvableModel keys.
The test tries to instantiate samba.evil.com in a non-async context.
That used to work because samba.evil.com doesn't have an async_ready
and because the link through the red enclave (evil.com) was collapsed
during resolve_networking.
However, the red enclave is not instantiated to ready in
resolve_networking (either in old or new code). Since the link
through red enclave is collapsed in the new code only for
ResolvableModel but not for MachineModel, when the tests tries to
instantiate samba.evil.com, it finds red enclave in a not-ready state.
The test code is instantiating ready=True non-asynchronously and so
it correctly gets an error.
The test could be changed to resolve in an asynchronous context.
Alternatively it might be possible to get the container propagation
code to always prefer the transclusion key for the inner key, and
convince dependency_injection.XrefMarker's metaclass to hash
XrefMarker classes with the same target_key and ikey to the same
value. That would alias the providers at the InjectableModel layer
and cause all the links to collapse at the same time, allowing the
existing test to work.
For now, the test is marked xfail.
In 13fe234b3927bd05 we broke a model test: This breaks one of the model tests: test_example_model. Previously all the MachineModels were instantiated during resolve_networking. They are still instantiated, but instantiated through the ResolvableModel keys. The test tries to instantiate samba.evil.com in a non-async context. That used to work because samba.evil.com doesn't have an async_ready and because the link through the red enclave (evil.com) was collapsed during resolve_networking.