BUILD-264: Refresh-Resources Mode and Configurable Namespaces #46

otaviof · 2021-08-17T10:25:42Z

This pull-request adds two more flags on the operator (controller) part of the CSI Driver. And modifies the test infrastructure to be able to deploy with different arguments.

Flags

Using --refreshresources=false (default's true) flag the operator will only watch Share resources, and will read the actual backing resource object just before mounting the volume. Previously it use to watch over most of the ConfigMap and Secret resources. By using this flag the operator will consume less resources, and won't watch for eventual resources modifications.

Additionally, the list of ignored namespaces can be edited using --ignorenamespace. The original list of ignored namespaces is kept by default.

E2E

A new target is added, test-e2e-no-refreshresources which deploys the operator using this mode and runs the configured test-suite against. For instance:

make test-e2e-no-refreshresources DRIVER_IMAGE="..." NODE_REGISTRAR_IMAGE="..."

gabemontero

Generally looks like I would have expected @otaviof and in the spirit of our 1-1 kick off meeting / code walk through a while back... cool deal !!

A minor naming suggestion or two, otherwise just some in line observations I suspect are already on the path of resolution given you still have the WIP tag on this PR.

And for out of band observations, again with the qualifier that this is still WIP, is that as I'm sure you are already on path for, the unit/e2e stuff will need to be tweaked based on read only vs. read write.

But given your changes so far did not impact the e2e's run are certainly encouraging.

And I am not concerned that a few unit tests failed / need tweaks. Again, not surprising for a WIP PR.

pkg/controller/controller.go

pkg/hostpath/hostpath.go

pkg/hostpath/hpv.go

gabemontero · 2021-08-18T19:02:48Z

FYI ... (re)confirmation that the CI changes from @adambkaplan and I are pulling in the image from this driver built from this PR's code.

From the ci/prow/images job:

2021-08-18T07:15:27.472282690Z Pushing image image-registry.openshift-image-registry.svc:5000/ci-op-4t9mg8y6/pipeline:csi-driver-shared-resource ...
2021-08-18T07:15:27.472944655Z Getting image source signatures
2021-08-18T07:15:27.586030731Z Copying blob sha256:983f1c02b066c17f8c8188228a50cc64976feddb94f2562257ea8f4c9475fe67
2021-08-18T07:15:27.588047974Z Copying blob sha256:296e14ee24149e14d573a1fbf5b5a625c7bb0cc22f5b2a8b180e833258187948
2021-08-18T07:15:27.592182814Z Copying blob sha256:356f18f3a935b2f226093720b65383048249413ed99da72c87d5be58cc46661c
2021-08-18T07:15:27.596988152Z Copying blob sha256:dc1eaa2cd0b85b00e4014fb863457a55b18d741eb2062dfcd3b65ad34c0cf242
2021-08-18T07:15:27.601363055Z Copying blob sha256:7e70cd65b8ce38214c95d786a377472d5c215c43735b8911c5c00c7fdb3bc96e
2021-08-18T07:15:28.914059592Z Copying blob sha256:d14dfac288a514336f4b2caedc4e3a3bdb9ed1ca0b130161084ba026452b8f0c
2021-08-18T07:15:30.437787840Z Copying config sha256:ae369772b70875fefe08f6d64cad9a563f1985a15f896a639e5849a7e5c5d542
2021-08-18T07:15:32.690909003Z Writing manifest to image destination
2021-08-18T07:15:33.009809004Z Storing signatures
2021-08-18T07:15:33.009875104Z Successfully pushed image-registry.openshift-image-registry.svc:5000/ci-op-4t9mg8y6/pipeline@sha256:a0acd20ddff72e106dcab0e7e87ae767d4bf3b2e4b1b12dd7e768c680cdc2929
2021-08-18T07:15:33.045910668Z Push successful

from one of the test e2e's:

Deploying using csi driver registry.build02.ci.openshift.org/ci-op-4t9mg8y6/pipeline@sha256:a0acd20ddff72e106dcab0e7e87ae767d4bf3b2e4b1b12dd7e768c680cdc2929

same SHA for the "pipeline" imagestream

There is an assumption in my statement above that https://github.com/openshift/csi-driver-shared-resource/blob/master/deploy/deploy.sh#L42-L45 worked.

Certainly @otaviof as you move forward with this you are not entirely convinced, I would suggest starting in that deploy.sh file and cat'ing the contents of that csi-hostpath-plugin.yaml, along with temporary dumps of the csi driver pod logs for any new tracing you added.

cmd/main.go

pkg/cache/common.go

coreydaley

Overall I don't think that readonly make sense as the flag name, maybe readonce would be better?

pkg/cache/common.go

pkg/cache/configmaps.go

pkg/cache/secrets.go

otaviof · 2021-08-24T11:51:20Z

/retest

gabemontero · 2021-08-24T12:43:42Z

@otaviof - as part of confirming that your kustomize related changes are doing what we want, please examine the ci/prow/images job log to locate the imagestreamtag image reference for the image built from this PR's code changes, and then go to one of the e2e job run logs on prow, and show where the deploy scripts and test output confirms that the PR test image is being used for the driver's DaemonSet.

I did a similar exercise back in #46 (comment)

Now making another prelim pass at the code changes, still trying to take into account that you have the WIP marker on this PR and you are presumably not done making changes.

Thanks.

gabemontero

Added some prelim, the PR is still WIP, comments @otaviof - thanks

cmd/main.go

pkg/controller/controller.go

otaviof · 2021-08-25T07:01:23Z

@otaviof - as part of confirming that your kustomize related changes are doing what we want, please examine the ci/prow/images job log to locate the imagestreamtag image reference for the image built from this PR's code changes, and then go to one of the e2e job run logs on prow, and show where the deploy scripts and test output confirms that the PR test image is being used for the driver's DaemonSet.

I did a similar exercise back in #46 (comment)

Okay, given the changes in deploy.sh and the introduction of kustomize is only fair to demostrante the new scripting is performing as expected.

As for the image replacement we use to tackle with sed, those are now working as expected by inspecting the deploy.sh script output, i.e.:

$ curl --silent https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/origin-ci-test/pr-logs/pull/openshift_csi-driver-shared-resource/46/pull-ci-openshift-csi-driver-shared-resource-master-e2e-aws-csi-driver/1430137437895528448/artifacts/e2e-aws-csi-driver/test/build-log.txt |grep -i 'patching.*image'

# Patching node-registrar image to use 'registry.build01.ci.openshift.org/ci-op-tv0f2inb/stable@sha256:b8e2d637f14e04658595393df59d99ac12284402c64c18c0a0aeecb29c70b1fb'
# Patching node-csi-driver image to use 'registry.build01.ci.openshift.org/ci-op-tv0f2inb/pipeline@sha256:b6ef81dc8d6b6b1714d0945402ba9e8ab508c6793096f21a21fb99653ac00689'

The same image build by the CI:

$ curl --silent https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/origin-ci-test/pr-logs/pull/openshift_csi-driver-shared-resource/46/pull-ci-openshift-csi-driver-shared-resource-master-e2e-aws-csi-driver/1430137437895528448/artifacts/build-logs/csi-driver-shared-resource.log |grep 'b6ef81dc8d6b6b1714d0945402ba9e8ab508c6793096f21a21fb99653ac00689'

2021-08-24T12:01:42.821921844Z Successfully pushed image-registry.openshift-image-registry.svc:5000/ci-op-tv0f2inb/pipeline@sha256:b6ef81dc8d6b6b1714d0945402ba9e8ab508c6793096f21a21fb99653ac00689

Finally, inspecting the DaemonSets, I can confirm both the desired container image-tag and the correct arguments are informed to the container, as per:

$ curl --silent https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/origin-ci-test/pr-logs/pull/openshift_csi-driver-shared-resource/46/pull-ci-openshift-csi-driver-shared-resource-master-e2e-aws-csi-driver/1430137437895528448/artifacts/e2e-aws-csi-driver/gather-extra/artifacts/daemonsets.json |jq '.items[1].spec.template.spec.containers[1] | .args, .image'
[
  "--drivername=csi.shared-resources.openshift.io",
  "--v=4",
  "--endpoint=$(CSI_ENDPOINT)",
  "--nodeid=$(KUBE_NODE_NAME)",
  "--ignorenamespace=openshift-machine-api",
/*** snip ***/
  "--ignorenamespace=openshift-service-ca-operator"
]
"registry.build01.ci.openshift.org/ci-op-tv0f2inb/pipeline@sha256:b6ef81dc8d6b6b1714d0945402ba9e8ab508c6793096f21a21fb99653ac00689"

Please consider.

otaviof · 2021-08-25T07:14:08Z

/retitle Populate Object Cache on Demand

gabemontero · 2021-08-25T12:52:55Z

@otaviof - as part of confirming that your kustomize related changes are doing what we want, please examine the ci/prow/images job log to locate the imagestreamtag image reference for the image built from this PR's code changes, and then go to one of the e2e job run logs on prow, and show where the deploy scripts and test output confirms that the PR test image is being used for the driver's DaemonSet.
I did a similar exercise back in #46 (comment)

Okay, given the changes in deploy.sh and the introduction of kustomize is only fair to demostrante the new scripting is performing as expected.

As for the image replacement we use to tackle with sed, those are now working as expected by inspecting the deploy.sh script output, i.e.:
$ curl --silent https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/origin-ci-test/pr-logs/pull/openshift_csi-driver-shared-resource/46/pull-ci-openshift-csi-driver-shared-resource-master-e2e-aws-csi-driver/1430137437895528448/artifacts/e2e-aws-csi-driver/test/build-log.txt |grep -i 'patching.*image'

# Patching node-registrar image to use 'registry.build01.ci.openshift.org/ci-op-tv0f2inb/stable@sha256:b8e2d637f14e04658595393df59d99ac12284402c64c18c0a0aeecb29c70b1fb'
# Patching node-csi-driver image to use 'registry.build01.ci.openshift.org/ci-op-tv0f2inb/pipeline@sha256:b6ef81dc8d6b6b1714d0945402ba9e8ab508c6793096f21a21fb99653ac00689'
The same image build by the CI:
$ curl --silent https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/origin-ci-test/pr-logs/pull/openshift_csi-driver-shared-resource/46/pull-ci-openshift-csi-driver-shared-resource-master-e2e-aws-csi-driver/1430137437895528448/artifacts/build-logs/csi-driver-shared-resource.log |grep 'b6ef81dc8d6b6b1714d0945402ba9e8ab508c6793096f21a21fb99653ac00689'

2021-08-24T12:01:42.821921844Z Successfully pushed image-registry.openshift-image-registry.svc:5000/ci-op-tv0f2inb/pipeline@sha256:b6ef81dc8d6b6b1714d0945402ba9e8ab508c6793096f21a21fb99653ac00689
Finally, inspecting the DaemonSets, I can confirm both the desired container image-tag and the correct arguments are informed to the container, as per:
$ curl --silent https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/origin-ci-test/pr-logs/pull/openshift_csi-driver-shared-resource/46/pull-ci-openshift-csi-driver-shared-resource-master-e2e-aws-csi-driver/1430137437895528448/artifacts/e2e-aws-csi-driver/gather-extra/artifacts/daemonsets.json |jq '.items[1].spec.template.spec.containers[1] | .args, .image'
[
  "--drivername=csi.shared-resources.openshift.io",
  "--v=4",
  "--endpoint=$(CSI_ENDPOINT)",
  "--nodeid=$(KUBE_NODE_NAME)",
  "--ignorenamespace=openshift-machine-api",
/*** snip ***/
  "--ignorenamespace=openshift-service-ca-operator"
]
"registry.build01.ci.openshift.org/ci-op-tv0f2inb/pipeline@sha256:b6ef81dc8d6b6b1714d0945402ba9e8ab508c6793096f21a21fb99653ac00689"
Please consider.

Awesome thanks @otaviof looks good

/approve

for now,

between @coreydaley and I we can make the final / more detailed pass through the code and lgtm or post more comments, but seems like we are good to go

adambkaplan · 2021-08-31T18:28:06Z

deploy/deploy.sh

@@ -16,54 +16,122 @@
 set -e
 set -o pipefail

+# when not empty it will run CSI driver on read-only mode
+READ_ONLY_MODE="${1}"


Will probably want to update this based on what we call the flag.

Please consider latest changes.

otaviof · 2021-09-02T06:37:33Z

/retitle BUILD-264: Refresh-Resources Mode and Configurable Namespaces

coreydaley · 2021-09-02T12:29:45Z

Makefile

+# allows overwrite of node registrar image
+NODE_REGISTRAR_IMAGE ?=
+# allows overwite of CSI driver image
+DRIVER_IMAGE ?=
+# non-empty deploy mode will enable read-only mode deployment
+DEPLOY_MODE ?=
+


1.) Should these have a default specified?
2.) These should be at the top of the file so that anyone using it will know right away what options they have

Those are variables previously used on deploy.sh, now also exposed by Makefile as well.

The DEPLOY_MODE is new, and I'm updating the comment to make clear what's its objective. Let me know if it's clear.

the comment update looks good @otaviof

but I agree with @coreydaley that it should be moved toward the top, above all: ....

same with the TEST_SUITE and TEST_TIMEOUT that I think @adambkaplan recently added

thanks

cmd/main.go

pkg/controller/controller.go

otaviof · 2021-09-02T14:46:12Z

/test e2e-aws-csi-driver-disruptive

gabemontero · 2021-09-02T15:23:48Z

docs/content-update-details.md

+cache of `ConfigMap` and `Secret` objects, and as they change the controller will follow the updates.
+When `--refreshresources` is disabled (i.e. `--refreshresources=false`), the controller will read
+the backing-resource (`.spec.backingResource`) just before mounting the volume instead of keeping a
+warm cache.


This looks good with the current implementation, but it reminded me of something. Something not explicitly called out in the Jira as I revisited it, but something I always had in mind when we first created this story.

Namely, if refreshresources is disabled, we force the volume to be read only.

the code check would be around

csi-driver-shared-resource/pkg/hostpath/nodeserver.go

Lines 163 to 165 in 7c62db4

readOnly := req.GetReadonly()

vol, err := ns.hp.createHostpathVolume(req.GetVolumeId(), kubeletTargetPath, readOnly, req.GetVolumeContext(), share, maxStorageCapacity, mountAccess)

I don't see why for the scenarios we are considering we would allow the consuming pod to change the contents we mounted, or add new files to our mount

It defers the need of the atomic writer stuff from k8s/k8s as we would not have to ever coordinate with the pod

remember, we claim to not be a "generic" csi volume provider, so ignoring user options like read only is a legitimate stance

@adambkaplan WDYT ?

I think it's important to highlight that when --refreshresources is disabled, the data on the object-cache is refreshed just before the volume is mounted. Therefore, every time the volume is mounted the cache-key would get in sync with the apiserver again.

we have both "short living" pods like builds and will have "long running" pods which will be comsuming config maps with certs

in those long running cases, the volumes would only be mounted once

but while a good distinction to note @otaviof I think it is still orthogonal to the classic atomic write k8s secret stuff

there are 2 main motivators IMO for this feature's original creation

scaling benefits from not employing a watch

defaulting to read only to avoid atomic write hoopla when we know we won't update content after pod creation

@gabemontero please consider the latest changes. Now on every volume mount when refresh-resources is not enabled, it will be a read-only volume.

gabemontero · 2021-09-02T15:27:31Z

Makefile

+# allows overwrite of node registrar image
+NODE_REGISTRAR_IMAGE ?=
+# allows overwite of CSI driver image
+DRIVER_IMAGE ?=
+# non-empty deploy mode will enable read-only mode deployment
+DEPLOY_MODE ?=
+


the comment update looks good @otaviof

but I agree with @coreydaley that it should be moved toward the top, above all: ....

same with the TEST_SUITE and TEST_TIMEOUT that I think @adambkaplan recently added

thanks

gabemontero

One minor ask, one suggested change that admittedly needs to be discussed, where I could see us going either way @otaviof and we need to discuss either here on or video conf with @adambkaplan

Also, I see the e2e commit for when refresh resources is disabled, and I see the unit test changes, but I was expecting e2e test changes in the go files where minimally the e2e tests that changed the share when refresh resources was disabled were not executed when we did test-e2e-no-refreshresources per your Makefile update, as well as making sure content was not updated

i.e. a new TEST_SUITE

Were you planning those in a subsequent PR?

gabemontero · 2021-09-02T15:52:00Z

not sure why it removed approved .... some git intergration we don't have elsewhere

/approve

coreydaley · 2021-09-02T16:03:18Z

deploy/csi-hostpath-plugin.yaml

+            - --ignorenamespace=openshift-machine-api
+            - --ignorenamespace=openshift-kube-apiserver
+            - --ignorenamespace=openshift-kube-apiserver-operator
+            - --ignorenamespace=openshift-kube-scheduler
+            - --ignorenamespace=openshift-kube-controller-manager
+            - --ignorenamespace=openshift-kube-controller-manager-operator
+            - --ignorenamespace=openshift-kube-scheduler-operator
+            - --ignorenamespace=openshift-console-operator
+            - --ignorenamespace=openshift-controller-manager
+            - --ignorenamespace=openshift-controller-manager-operator
+            - --ignorenamespace=openshift-cloud-credential-operator
+            - --ignorenamespace=openshift-authentication-operator
+            - --ignorenamespace=openshift-service-ca
+            - --ignorenamespace=openshift-kube-storage-version-migrator-operator
+            - --ignorenamespace=openshift-config-operator
+            - --ignorenamespace=openshift-etcd-operator
+            - --ignorenamespace=openshift-apiserver-operator
+            - --ignorenamespace=openshift-cluster-csi-drivers
+            - --ignorenamespace=openshift-cluster-storage-operator
+            - --ignorenamespace=openshift-cluster-version
+            - --ignorenamespace=openshift-image-registry
+            - --ignorenamespace=openshift-machine-config-operator
+            - --ignorenamespace=openshift-sdn
+            - --ignorenamespace=openshift-service-ca-operator


Is this list going to have to get updated every time a new openshift-* namespace comes along? Couldn't we exclude all openshift-* namespaces with a regexp in the code somewhere if that is what needs to be done?

For the rotating cert scenario we may need to watch certain openshift
namespaces

I at least am fine with deferring more sophisticated regex / other means of
expression in a separate PR

I also think we should take this in a standalone pull-request, I would like discuss this requirement further.

coreydaley · 2021-09-02T16:20:12Z

pkg/controller/controller.go

@@ -63,37 +68,11 @@ func NewController(shareRelist time.Duration) (*Controller, error) {
 	// informers.NewSharedInformerFactoryWithOptions, but we restrict OpenShift
 	// "system" namespaces with chatty configmaps like the leaderelection related ones
 	// that are updated every few seconds
-	//TODO make this list externally configurable


tweakListOptions := internalinterfaces.TweakListOptionsFunc(func(options *metav1.ListOptions) { ignored := []string{} for _, ns := range ignoredNamespaces { klog.V(4).Infof("namespace '%s' is being ignored", ns) ignored = append(ignored, fmt.Sprintf("metadata.namespace!=%s", ns)) } options.FieldSelector = strings.Join(ignored, ",") })

This would be cleaner than all the appending strings stuff.

true ... technically a tech debt item given @otaviof did not change that existing bit

I'm fine if he want to take that on now, or somebody does this as a follow up PR

Thanks for the heads up, @coreydaley, it's more readable this way. However, I would argue this change should be tackled in a subsequent PR, would be "a good first issue" by the way.

@coreydaley I'm bringing that up on #60, thanks for the suggestion!

otaviof · 2021-09-03T10:45:27Z

Also, I see the e2e commit for when refresh resources is disabled, and I see the unit test changes, but I was expecting e2e test changes in the go files where minimally the e2e tests that changed the share when refresh resources was disabled were not executed when we did test-e2e-no-refreshresources per your Makefile update, as well as making sure content was not updated

@gabemontero, in my view the --refreshresources=false is orthogonal to the TEST_SUITE. So, as a follow up step I was about to update the CI configuration to also run the normal test-suite with this flag enabled. Would you second this move?

I've tested this mode against all test suites successfuly. And on this PR we have unit-testing to assert the HostPathDriver works as expected when a client is informed: https://github.com/otaviof/csi-driver-shared-resource/blob/1406188d39046dc4de5a92c131682cadefcc7390/pkg/hostpath/hostpath_test.go#L544-L645

gabemontero · 2021-09-03T12:42:51Z

Also, I see the e2e commit for when refresh resources is disabled, and I see the unit test changes, but I was expecting e2e test changes in the go files where minimally the e2e tests that changed the share when refresh resources was disabled were not executed when we did test-e2e-no-refreshresources per your Makefile update, as well as making sure content was not updated

@gabemontero, in my view the --refreshresources=false is orthogonal to the TEST_SUITE. So, as a follow up step I was about to update the CI configuration to also run the normal test-suite with this flag enabled. Would you second this move?

I'm not sure I agree it is orthogonal @otaviof , but I'll defer "officially" declaring that objection until I see more precisely what your openshift/release change is

If I see something equivalent to both

running normal with --refreshresources=false
running normal with --refreshresources=true

I'll be satisfied. I did refresh my memory, and normal only deals with deletion of shares, so I agree its tests as is should work regardless of the refreshresources setting.

I've tested this mode against all test suites successfuly. And on this PR we have unit-testing to assert the HostPathDriver works as expected when a client is informed: https://github.com/otaviof/csi-driver-shared-resource/blob/1406188d39046dc4de5a92c131682cadefcc7390/pkg/hostpath/hostpath_test.go#L544-L645

Yes I realize the tests are currently passing.

Creating an additional flag (`--refreshresources`), so when disabled, the object-cache is updated just before mounting the volume. It allows the controller to only watch OpenShift's `Share`. Namespaces can now be configured with `--ignorenamespace` flag. Co-authored-by: Corey Daley <cdaley@redhat.com>

Adapting deploy.sh script with a flag to add an "refreshresources=false" mode, and introducing kustomize to edit the resources before rolling out in the cluster. Tweaking end-to-end test to wait for a configurable amount of pods produced by the `DeamonSet`, so it can run in smaller testing clusters.

gabemontero

/lgtm

openshift-ci · 2021-09-03T16:28:22Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: gabemontero, otaviof

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

~~OWNERS~~ [gabemontero]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

openshift-ci bot added do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. labels Aug 17, 2021

openshift-ci bot requested review from adambkaplan and coreydaley August 17, 2021 10:26

otaviof force-pushed the BUILD-264 branch from b992fdf to bc99e2e Compare August 18, 2021 07:11

openshift-ci bot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Aug 18, 2021

gabemontero reviewed Aug 18, 2021

View reviewed changes

pkg/controller/controller.go Outdated Show resolved Hide resolved

pkg/controller/controller.go Outdated Show resolved Hide resolved

pkg/hostpath/hostpath.go Show resolved Hide resolved

pkg/hostpath/hpv.go Outdated Show resolved Hide resolved

otaviof force-pushed the BUILD-264 branch 2 times, most recently from 6a947e3 to 4716365 Compare August 21, 2021 09:44

coreydaley reviewed Aug 23, 2021

View reviewed changes

cmd/main.go Outdated Show resolved Hide resolved

coreydaley reviewed Aug 23, 2021

View reviewed changes

cmd/main.go Outdated Show resolved Hide resolved

coreydaley reviewed Aug 23, 2021

View reviewed changes

cmd/main.go Outdated Show resolved Hide resolved

coreydaley reviewed Aug 23, 2021

View reviewed changes

pkg/cache/common.go Outdated Show resolved Hide resolved

coreydaley requested changes Aug 23, 2021

View reviewed changes

pkg/cache/common.go Outdated Show resolved Hide resolved

pkg/cache/configmaps.go Outdated Show resolved Hide resolved

pkg/cache/secrets.go Outdated Show resolved Hide resolved

openshift-ci bot assigned coreydaley Aug 23, 2021

otaviof force-pushed the BUILD-264 branch 5 times, most recently from 3b4acea to c1838db Compare August 24, 2021 11:51

otaviof force-pushed the BUILD-264 branch from c1838db to f0a1aab Compare August 24, 2021 11:56

gabemontero reviewed Aug 24, 2021

View reviewed changes

cmd/main.go Outdated Show resolved Hide resolved

pkg/controller/controller.go Show resolved Hide resolved

otaviof changed the title ~~[WIP] Read Only Mode~~ Populate Object Cache on Demand Aug 25, 2021

openshift-ci bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Aug 25, 2021

adambkaplan reviewed Aug 31, 2021

View reviewed changes

otaviof force-pushed the BUILD-264 branch from f0a1aab to 156bd6c Compare September 2, 2021 06:36

openshift-ci bot changed the title ~~BUILD-264: Populate Object Cache on Demand~~ BUILD-264: Refresh-Resources Mode and Configurable Namespaces Sep 2, 2021

otaviof requested review from coreydaley, gabemontero and adambkaplan September 2, 2021 06:39

coreydaley reviewed Sep 2, 2021

View reviewed changes

otaviof force-pushed the BUILD-264 branch 2 times, most recently from fd0ad3e to 1406188 Compare September 2, 2021 13:25

gabemontero reviewed Sep 2, 2021

View reviewed changes

gabemontero suggested changes Sep 2, 2021

View reviewed changes

openshift-ci bot assigned gabemontero Sep 2, 2021

openshift-ci bot removed the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Sep 2, 2021

openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Sep 2, 2021

coreydaley reviewed Sep 2, 2021

View reviewed changes

otaviof force-pushed the BUILD-264 branch from 1406188 to 249a9a5 Compare September 3, 2021 10:45

otaviof force-pushed the BUILD-264 branch from 249a9a5 to 16080b7 Compare September 3, 2021 15:30

otaviof and others added 2 commits September 3, 2021 17:34

otaviof force-pushed the BUILD-264 branch from 16080b7 to b1fc7c2 Compare September 3, 2021 15:34

gabemontero approved these changes Sep 3, 2021

View reviewed changes

openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Sep 3, 2021

openshift-merge-robot merged commit 76288b4 into openshift:master Sep 3, 2021

	readOnly := req.GetReadonly()

	vol, err := ns.hp.createHostpathVolume(req.GetVolumeId(), kubeletTargetPath, readOnly, req.GetVolumeContext(), share, maxStorageCapacity, mountAccess)

BUILD-264: Refresh-Resources Mode and Configurable Namespaces #46

BUILD-264: Refresh-Resources Mode and Configurable Namespaces #46

Conversation

otaviof commented Aug 17, 2021 • edited

Flags

E2E

gabemontero left a comment • edited

Choose a reason for hiding this comment

gabemontero commented Aug 18, 2021

coreydaley left a comment

Choose a reason for hiding this comment

otaviof commented Aug 24, 2021

gabemontero commented Aug 24, 2021

gabemontero left a comment

Choose a reason for hiding this comment

otaviof commented Aug 25, 2021 • edited

otaviof commented Aug 25, 2021

gabemontero commented Aug 25, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

otaviof commented Sep 2, 2021 • edited by openshift-ci bot

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

otaviof commented Sep 2, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gabemontero left a comment

Choose a reason for hiding this comment

gabemontero commented Sep 2, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

coreydaley Sep 2, 2021 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

otaviof commented Sep 3, 2021

gabemontero commented Sep 3, 2021

gabemontero left a comment

Choose a reason for hiding this comment

openshift-ci bot commented Sep 3, 2021

otaviof commented Aug 17, 2021 •

edited

gabemontero left a comment •

edited

otaviof commented Aug 25, 2021 •

edited

otaviof commented Sep 2, 2021 •

edited by openshift-ci bot

coreydaley Sep 2, 2021 •

edited