ForeignServices cardinality issues

[louiscryan]

@frankbu @wora @rshriram

Currently ForegnServices has the following properties

• There can only be one resource of this type in the whole API
• It defines a plural

The alternatives would be to (a) allow there to be many and (b) allow one per domain

[rshriram]

Thanks for following up on this.. Parroting back what I told @frankbu

The idea is that you have only one such thing that requires admin access to add. Per @nmnellis (Weather.com), this seems like a nice thing.

The more technical problem is that we no longer do anything with namespaces in the rules. Even in routing rules, we infer the namespace for short names based on the calling pod's namespace, instead of the rule's namespace. The rationale behind this was that most people tend to put all Istio artifacts in the istio-system namespace, for easier management.

From a cross platform support perspective, this alienation of namespaces works well, because namespace is just a folder where you put your rules. It is not an isolation/protection/enforcement domain.

So, if you look at foreign services from this perspective, its simpler to do any RBAC if need be, based on the fact that there is only one foreign services resource to track. Having per namespace means that the underlying system assigns the endpoints to unique namespaces - a property that only kubernetes has. Any bespoke system using internal service registry on a bunch of containers/vms/baremetals or using Consul or using CloudFoundry will not have this abstraction.

The same argument can be applied to RouteRules and DestinationRules as well. It remains to be sorted out.

cc @ZackButcher / @ijsnellf / @GregHanson as well, since you would probably have encountered this.

[frankbu]

A couple of thoughts.

1. Does this need to be one or the other? If the resource contains a list of multiple foreign services, but it was not specified that there can only be one, then users would have the choice to put all the foreign services in a single resource (@nmnellis's preference), one foreign resource per resource (extreme opposite), or anything in between. The compete list of foreign services is the union of services from all the resources (no namespaces involved).

2. Regardless of whether there is one or many of the resources allowed, I think the name is bad. My suggestion is to rename ForeignServices to something like EgressSpecification (or something like that - not plural) and rename the embedded Service to ForeignService, since that's what it actually is.

[rshriram]

#307 fixes the cardinality issue. I am not sold on the term EgressRule, as there is no action associated with that rule. EgressSpecification is fine, but if the current PR #307 suffices, then all should be good.

[geeknoid]

Is this still relevant? Can we close the issue?

[andraxylia]

ServiceEntry fixes these problems.