Apps in co-located container does not have all interfaces required by spaces

As I understand it, these are not subordinates; they are just co-located by placement.

At bundle parsing time, this is hard to validate deterministically, because we haven't yet applied any constraints/bindings to *potential* target machines. Depending on the machines available in the substrate, it might even work circumstantially.

Possible work-arounds are:
- To lay down the designate-bind charm (most-constrained) first and then to place the memcached units (less constrained) on those machines.
- Declare the machines separately using space constraints and target both sets of units to those.

I suspect the bundle is ultimately parsed as designate-bind units having a placement directive, which overrides any selection based on available interfaces.

That's correct Joseph. So you presented the 2nd workaround, which really fine.

Yet.I think there should be warning/error while parsing, when you collect from 2 units the spaces
and the unit that will laydown on the same machine as the primary one will have more interfaces it should call exception that it is not a correct setup with proposed solution, either seperate container/machine or applying charm containing more interfaces first.

So maybe that's a core issue, we should also collect interfaces/binding while parsing.