Allow user to explicitly specify service name for pod about pilot HOT 4 CLOSED

I wouldn't call it a bug, we haven't implemented source-based filtering. I would rule against env variables since those cannot be changed without a pod restart. You're folding service definition into pod definition, which is an OK practice, but not the common case.

Regarding eventual consistency - isn't that inherent to the distributed proxy mesh? All operations are asynchronous and we need feedback loops for good usability, where the remote agent reports back on the success or failure of the operation.

Regarding source-based filtering - so is the basic problem how do we enforce that "only service a v1 can talk to service b v1"? This is impossible with the current defaulting rule "a can talk to b". We need to revoke the default rule to begin with.

from pilot.

Let's say you want to apply that rule at the client-side by overriding the default rule. Each proxy instance carries a list of instances it belongs to (including service versions). Then it can match the source field against the list of instances and apply only if it matches. The missing piece is enumerating all service versions from the rules (since those are declared dynamically by rules) so we can attach the list of service versions to each proxy instance.

from pilot.

pr #225

from pilot.

Can I close this?

from pilot.