You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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).
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.
#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.
Activity
rshriram commentedon Jan 12, 2018
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 commentedon Jan 12, 2018
A couple of thoughts.
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).
Regardless of whether there is one or many of the resources allowed, I think the name is bad. My suggestion is to rename
ForeignServicesto something likeEgressSpecification(or something like that - not plural) and rename the embeddedServicetoForeignService, since that's what it actually is.rshriram commentedon Jan 12, 2018
#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 commentedon Jun 13, 2018
Is this still relevant? Can we close the issue?
transcoding: Handle RequestStatus error (istio#305)
andraxylia commentedon Jun 14, 2018
ServiceEntry fixes these problems.
Make retention policy configurable (istio#305)