costinm
commented
6 years ago The replication delays are a problem - and some way to identify when 'all' configs have been seen is needed. We are currently depending too much on the debounce.
But I'm not sure how this will work - if we're not deprecating the old rules we'll keep having this problem so we still need to debounce and/or find other ways to deal with eventual consistency. Another problem is that separate resources may work better with RBAC - having the container will mean that we can't have different roles control specific types of configs.
Can we 'group' the configs but still keep them as separate resources ? It wouldn't be hard to add an change-ID to make sure different configs are applied together (as an extra attribute ) - the main problem is knowing how many resources are part of a change, so we wait for all. And the other problem is that we don't want user to manually deal with this. Maybe the CI/CD or UI could add 'change-ID' and 'change-count' as annotations - so we get equivalent grouping ?
Costin
On Tue, Oct 9, 2018 at 9:42 AM Shriram Rajagopalan notifications@github.com wrote:
Decomposing APIs into smaller things (e.g., a separate resource for declaring subsets that decouples it from destination rules, or even the simple VirtualService and DestinationRule split) creates a lot of flexibility. At the same time, eventual consistency makes the implementation complex (atleast in networking) because if one or more pieces arrive late, the system (sidecars) could be in an inconsistent state (e.g., route points to versions, but the associated envoy clusters are not there because the destination rule has not arrived yet). We have been working around this issue by adding a slew of checks, behavioral assumptions/requirements on what the end user needs to do.
I propose that we create a new container API resource, one that can hold multiple types of APIs inside it. This provides us with the necessary collection object where all the related things are in one resource and can be applied without headaches.. At the same time, leaves the door open for flexibility, where people can use individual api objects to tweak stuff.
E.g.,
kind:NetworkingAPIContainerspec:
- type: virtualservice.networking.istio.io/v1alpha3 spec: // virtual service spec
- type: destinationrule.networking.istio.io/v1alpha3 spec: // destination rule spec
The user can stuff any set of resources that need to be applied together. (we can tweak our docs as well). At the same time, users can also supply individual resources, as long as they understand the implications.
I know that networking can benefit from something like this. Not sure if the same is true in Auth/RBAC/Mixer ..
thoughts @geeknoid https://github.com/geeknoid / @louiscryan https://github.com/louiscryan ? or others (too many to name).
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/istio/api/issues/651, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFI6qVMJNJs1hjAUFEwHx5e42EDleakks5ujNH0gaJpZM4XTsN3 .
rshriram
ozevren
mandarjog
kyessenov
ayj
Decomposing APIs into smaller things (e.g., a separate resource for declaring subsets that decouples it from destination rules, or even the simple VirtualService and DestinationRule split) creates a lot of flexibility. At the same time, eventual consistency makes the implementation complex (atleast in networking) because if one or more pieces arrive late, the system (sidecars) could be in an inconsistent state (e.g., route points to versions, but the associated envoy clusters are not there because the destination rule has not arrived yet). We have been working around this issue by adding a slew of checks, behavioral assumptions/requirements on what the end user needs to do.
I propose that we create a new container API resource, one that can hold multiple types of APIs inside it. This provides us with the necessary collection object where all the related things are in one resource and can be applied without headaches.. At the same time, leaves the door open for flexibility, where people can use individual api objects to tweak stuff.
E.g.,
The user can stuff any set of resources that need to be applied together. (we can tweak our docs as well). At the same time, users can also supply individual resources, as long as they understand the implications.
I know that networking can benefit from something like this. Not sure if the same is true in Auth/RBAC/Mixer ..
thoughts @geeknoid / @louiscryan ? or others (too many to name).