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
See the discussion for complete context and commentary.
Originally posted by brianehlert July 11, 2023
There are many customers that like the master-minion patter of the Ingress Resource.
Specifically the ability to define the Master that represents the hostname and core attributes such as TLS and then allow Minions to be defined that modify the behavior of that hostname by defining paths or other behavior modifiers.
This is also called "mergeable ingress".
Four years ago this project introduced its CRDs as an answer to problems that customers had identified with the Ingress resource, specifically the ability to provide safety guarantees around different portions to the configuration. The K8s RBAC allowed an easy way to secure the different objects as a way to provide that safety.
One point of feedback that has come back repeatedly is that the similarity of the VirtualServer and VirtualServerRoute pattern, while powerful, does not offer the simplicity of the mergeable ingress pattern.
The limitation being that a VirtualServerRoute cannot simply and easily extend a VirtualServer object.
The core problem being that the VirtualServer object must be modified whenever a VirtualServerRoute is added. Thus creating both a two step process that is difficult to automate, but also requiring that the person that adds the VSR also have access to the VS (thus breaking the safety boundary) or that two people in different groups have to orchestrate change with each other.
The end result is that it creates a core piece of friction that limits adoption of the VirtualServer/VirtualServerRoute and related CRD objects - which have already proven themselves more powerful and capable than Ingress with its mergeable and annotation pattern.
I am starting this discussion to explore ideas around how we can address this friction point between VS and VSR and still meet the core intention of creating an RBAC boundary and separation of responsibility that promotes configuration safety for those customers that continue to need that.
The content you are editing has changed. Please copy your edits and refresh the page.
shaun-nx
changed the title
Epic - Make it easier to "attach" a VirtualServerRoute to a VirtualServer without requiring that the VirtualServer be modified
Make it easier to "attach" a VirtualServerRoute to a VirtualServer without requiring that the VirtualServer be modified
Jun 28, 2024
shaun-nx
changed the title
Make it easier to "attach" a VirtualServerRoute to a VirtualServer without requiring that the VirtualServer be modified
Decouple updates to VirtualServerRoute from VirtualServer resource
Sep 24, 2024
Discussed in #4092
See the discussion for complete context and commentary.
Originally posted by brianehlert July 11, 2023
There are many customers that like the master-minion patter of the Ingress Resource.
Specifically the ability to define the Master that represents the hostname and core attributes such as TLS and then allow Minions to be defined that modify the behavior of that hostname by defining paths or other behavior modifiers.
This is also called "mergeable ingress".
Four years ago this project introduced its CRDs as an answer to problems that customers had identified with the Ingress resource, specifically the ability to provide safety guarantees around different portions to the configuration. The K8s RBAC allowed an easy way to secure the different objects as a way to provide that safety.
One point of feedback that has come back repeatedly is that the similarity of the VirtualServer and VirtualServerRoute pattern, while powerful, does not offer the simplicity of the mergeable ingress pattern.
The limitation being that a VirtualServerRoute cannot simply and easily extend a VirtualServer object.
The core problem being that the VirtualServer object must be modified whenever a VirtualServerRoute is added. Thus creating both a two step process that is difficult to automate, but also requiring that the person that adds the VSR also have access to the VS (thus breaking the safety boundary) or that two people in different groups have to orchestrate change with each other.
The end result is that it creates a core piece of friction that limits adoption of the VirtualServer/VirtualServerRoute and related CRD objects - which have already proven themselves more powerful and capable than Ingress with its mergeable and annotation pattern.
I am starting this discussion to explore ideas around how we can address this friction point between VS and VSR and still meet the core intention of creating an RBAC boundary and separation of responsibility that promotes configuration safety for those customers that continue to need that.
Tasks
The text was updated successfully, but these errors were encountered: