Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Workload webhook should update the pod spec on the pod, not the workload definition #41

Closed
4 tasks
hessjcg opened this issue Oct 10, 2022 · 0 comments · Fixed by #119
Closed
4 tasks
Assignees
Labels
priority: p0 Highest priority. Critical issue. P0 implies highest priority. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.

Comments

@hessjcg
Copy link
Collaborator

hessjcg commented Oct 10, 2022

When applying the proxy container to an existing workload, the container should be applied to the PodSpec on the Pod owned by a workload (Deployment, StatefulSet, etc.) As implemented now, the container gets applied to the PodSpec of the workload.

This feature will be complete when

  • the workload webhook updates the pod for a pod owned by a workload
  • unit tests properly check the webhook method
  • e2e tests properly check the pod
  • integration tests checking the current behavior are modified
@hessjcg hessjcg added type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design. priority: p0 labels Oct 10, 2022
@hessjcg hessjcg removed their assignment Oct 10, 2022
@hessjcg hessjcg added this to the v0.5 public preview milestone Oct 10, 2022
@hessjcg hessjcg self-assigned this Oct 10, 2022
@hessjcg hessjcg added priority: p0 Highest priority. Critical issue. P0 implies highest priority. and removed priority: p0 labels Oct 28, 2022
hessjcg added a commit that referenced this issue Dec 2, 2022
…p 1) (#112)

Begin to inline test cases that are no longer common between integration and e2e tests.
Refactor tests and test helpers so that they are more in alignment with go style.
Make TestCaseClient more like a single-responsibility thing.
hessjcg added a commit that referenced this issue Dec 2, 2022
…#113)

TestModifiesNewDeployment and TestModifiesExistingDeployment test case implementation
was shared between e2e and integration tests. That will no longer work.
hessjcg added a commit that referenced this issue Dec 5, 2022
…step 2.5) (#123)

Conventionally, context.Context must be a parameter instead of a member of a struct.
This updates uses of TestCaseClient to bring it into alignment with convention.
hessjcg added a commit that referenced this issue Dec 5, 2022
…p 3) (#114)

Convert e2e tests to table test for all workload types.
Remove unused test helpers and clean up imports.
hessjcg added a commit that referenced this issue Dec 5, 2022
Remove the "workloads" webhook add the Kubernetes boilerplate for a new
webhook that modifies pods.
hessjcg added a commit that referenced this issue Dec 5, 2022
…tep 6) (#117)

This change removes all the old logic that modified the PodTemplateSpec of an existing workload.

Also it adjusts the state logic in the reconcile controller to so that it only reads, does not update
Workloads created by customers. The reconcile loop will only update the status on the AuthProxyWorkload
so that the status includes all listed deployments. 

And adds support for ReplicaSet workloads, so that our operator can better traverse the 
ownership hierarchy of a pod.
hessjcg added a commit that referenced this issue Dec 6, 2022
…tep 7) (#118)

The proxy configuration is now only applied when a pod is created. The old algorithm allowed updates to the PodSpec
to apply changes after the pod was created. This PR simplifies the logic that applies the proxy configuration to a
PodSpec, mainly removing the code that would update the pod spec multiple times.
hessjcg added a commit that referenced this issue Dec 7, 2022
…tep 8) (#119)

Implement the new algorithm in the AuthProxyWorkload reconcile controller, as well as in the
pod webhook.

Fixes #41
This was referenced Dec 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority: p0 Highest priority. Critical issue. P0 implies highest priority. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.
Projects
None yet
1 participant