Comments (20)
/help
/good-first-issue
from csi-driver-host-path.
@msau42:
This request has been marked as suitable for new contributors.
Please ensure the request meets the requirements listed here.
If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-good-first-issue
command.
In response to this:
/help
/good-first-issue
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
from csi-driver-host-path.
I don't see a reason why provisioner, resizer, snapshotter can't all be in the same Pod as the driver
One reason for separate pods is that we test the RBAC rules for each sidecar separately. For example, if resizer and provisioner both need access to the same resource, but only the RBAC rules for provisioner list that, then resizer will work fine when deployed in the same pod as provisioner, but will fail when deployed separately.
from csi-driver-host-path.
Hm that's a good point. I guess it depends on how much we want to balance testing for rbac breakages vs providing a best practices example to the community. I think having all the individual pods:
- is very confusing to someone new to CSI
- isn't something that we recommend in a real production CSI driver
- doesn't follow security best practices since all the controller pieces need to use hostpath to share the socket
- requires each driver to consume a Pod resource per sidecar, which limits the amount of parallel testing we can do in k/k since there's a maximum 110 pods per node, and also could land us in strange scenarios where the driver is only partially able to be deployed on a node.
from csi-driver-host-path.
IMHO the main purpose of the csi-hostpath-driver is to facilitate testing. Providing a good example of how to write and deploy a CSI driver is secondary.
is very confusing to someone new to CSI
isn't something that we recommend in a real production CSI driver
doesn't follow security best practices since all the controller pieces need to use hostpath to share the socket
This could be addressed by adding comments and explanations why it is done this way here and what should be done instead. Perhaps link to a "real" CSI driver that does it properly?
requires each driver to consume a Pod resource per sidecar, which limits the amount of parallel testing we can do in k/k since there's a maximum 110 pods per node, and also could land us in strange scenarios where the driver is only partially able to be deployed on a node.
This is more relevant because it affects testing. But is that really an issue in practice? Have there been test failures because of a partially deployed driver?
from csi-driver-host-path.
I was wondering how important RBAC testing really is: if every CSI driver uses all sidecars and thus all RBAC rules, then buggy individual RBAC rules don't matter as long as we also test with all of them combined. But there are valid reasons for CSI driver developers to not use certain sidecars (skip attach -> no external-attacher, no resize support -> no external-resizer), so I think it is important to test the RBAC rule set for each sidecar in isolation.
from csi-driver-host-path.
Are there other ways we can check for rbac updates, like doing a file diff? Or test via mock driver, which is definitely a testing-only driver? We don't have good coverage with csi hostpath already. For example, the primary attacher path is completely untested and our tests did not catch any of the rbac changes needed with the latest attacher.
This is more relevant because it affects testing. But is that really an issue in practice? Have there been test failures because of a partially deployed driver?
I haven't seen specifically a test failure because of this, however, I have seen symptoms of e2e jobs hitting the max pods per node limits, such as kubernetes/kubernetes#87855 (comment). I think being able to reduce every hostpath and mock test case to only deploy 1 pod instead of 5 would help. We have 80+ test cases running in k/k so that's a 300+ pod count reduction
from csi-driver-host-path.
Are there other ways we can check for rbac updates, like doing a file diff?
The problem is that the a missing RBAC rule only shows up when the sidecar actually tries to do some operation that is forbidden. Code reviews may be able to find new operations, but I suspect that it's very easy to miss - it has slipped through in the past.
Or test via mock driver, which is definitely a testing-only driver? We don't have good coverage with csi hostpath already.
I suspect we cover even less code paths with the mock driver compared to the hostpath driver.
For example, the primary attacher path is completely untested and our tests did not catch any of the rbac changes needed with the latest attacher.
But is that observation a reason to extend RBAC testing (i.e. implement attach in the host path driver) or reduce it (i.e. merge into a pod and try to do something else for RBAC)? I really don't know.
from csi-driver-host-path.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
from csi-driver-host-path.
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten
.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close
.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
from csi-driver-host-path.
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen
.
Mark the issue as fresh with /remove-lifecycle rotten
.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close
from csi-driver-host-path.
@fejta-bot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity.
Reopen the issue with/reopen
.
Mark the issue as fresh with/remove-lifecycle rotten
.Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
from csi-driver-host-path.
/reopen
/lifecycle-frozen
from csi-driver-host-path.
@msau42: Reopened this issue.
In response to this:
/reopen
/lifecycle-frozen
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
from csi-driver-host-path.
I think we should seriously consider having an option to deploy all the sidecars into one Pod. k/k kind testing is very flaky and I think being able to reduce load from our tests by a few 100 pods would definitely improve the situation.
from csi-driver-host-path.
Sounds reasonable. But then we should still have one alternative deployment with one pod per sidecar and some minimal testing to cover the correctness of our RBAC rules.
from csi-driver-host-path.
Agree, unless we can think of another way to test rbacs, we'll want both methods. For our kubernetes-csi testing, we can still use the current method, but for k/k, we can use the consolidated way.
from csi-driver-host-path.
For our kubernetes-csi testing, we can still use the current method, but for k/k, we can use the consolidated way.
Agreed, that should give us good coverage of both approaches. I was struggling a bit with identifying "minimal testing" because it's not immediately obvious which tests go through all code paths that depend on RBAC - running all of them avoids having to make that choice.
from csi-driver-host-path.
/assign
from csi-driver-host-path.
I think we should have additional jobs for the csi-driver-host-path repo to cover all deployment flavors. If we only test the deployments with separate pods, then it could happen that we accidentally break the deployments meant for testing in Kubernetes and only notice when trying to use a new release in Kubernetes.
from csi-driver-host-path.
Related Issues (20)
- Missing a piece of the URL, for the CRD installation HOT 11
- Need to locate the correct path of `csi-hostpath-plugin.yaml`
- Broken link of `contributor cheatsheet` Need to fix HOT 4
- SELinuxMountReadWriteOncePod tests are failing in CI HOT 4
- Implement support for SINGLE_NODE_SINGLE_WRITER enforcement in NodePublishVolume
- Host Path PV Encryption HOT 5
- Switch from k8s.gcr.io to registry.k8s.io HOT 5
- [enable discussion]
- [changing the pod's node == migrate the volume ?] HOT 1
- Inconsistent namespace in deployment templates HOT 3
- failed to provision volume with StorageClass "csi-hostpath-sc": error getting handle for DataSource Type PersistentVolumeClaim by Name pvc-claim-1: claim in dataSource not bound or invalid HOT 5
- Test config needs to disable new snapshot restore tests
- Are high vulnerabilities being addressed? HOT 10
- Sample implementation in CSI hostpath mock driver
- Remove dependencies on docker-hosted images HOT 5
- [discussion]is this line mean the directory created by hostpath csi driver with file mode 777? HOT 4
- Update the mentions of testgrid dashboard URL from k8s-testgrid.appspot.com to testgrid.k8s.io HOT 1
- Unix sock file is not removed after the server stop HOT 4
- State file not updated after stage/publish action
- 1.29 - [KEP-3751] VAC Hostpath Driver Implementation HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from csi-driver-host-path.