change targetpath permission to allow non-root access

[Madhu-1]

change targetpath permission to allow non-root access
Signed-off-by: Madhu Rajanna madhupr007@gmail.com

[Madhu-1]

@humblec @ShyamsundarR can we get this PR in for csiv1.0?

[humblec]

@Madhu-1 can u check why the CI fail?

[Madhu-1]

@humblec its a know issue with CI https://travis-ci.org/ceph/ceph-csi/jobs/545193245#L562

[ShyamsundarR]

@humblec @ShyamsundarR can we get this PR in for csiv1.0?

We should get it in for v1.0, but version would be v1.0.1 when we decide to update the images in quay, right? The whole point of creating the final v1.0.0 was to retain it unchanging and provide the next .z version with the fixes, I would hence state we retain that premise.

[Madhu-1]

if we update it to v1.0.1 we need to update it in rook also.
if we fix this in 1.0.0 people already using this will get the update

planning to update rook for v1.1.0

[ShyamsundarR]

if we update it to v1.0.1 we need to update it in rook also.
if we fix this in 1.0.0 people already using this will get the update

planning to update rook for v1.1.0

I understand the rook integration position, but as we have stated we will retain the 1.0.0 image as is, I would still push for 1.0.1 and update rook as well to the same.

[Madhu-1]

if we update it to v1.0.1 we need to update it in rook also.
if we fix this in 1.0.0 people already using this will get the update
planning to update rook for v1.1.0

I understand the rook integration position, but as we have stated we will retain the 1.0.0 image as is, I would still push for 1.0.1 and update rook as well to the same.

@humblec what's your thought on this?

[Madhu-1]

if we update it to v1.0.1 we need to update it in rook also.
if we fix this in 1.0.0 people already using this will get the update
planning to update rook for v1.1.0

I understand the rook integration position, but as we have stated we will retain the 1.0.0 image as is, I would still push for 1.0.1 and update rook as well to the same.

@ShyamsundarR without making release should we push v1.0.1 images?

[humblec]

@ShyamsundarR as @Madhu-1 mentioned, this fix is important and the customer should get it without the changes in the tag. So, lets put it on 1.0.0 and we have to avoid any extra tagging or should not complicate the things.

[humblec]

@ShyamsundarR @poornimag can you please approve this PR as this is needed urgently for some testing ?

[ShyamsundarR]

@ShyamsundarR as @Madhu-1 mentioned this fix is important and the customer should get it without the changes in the tag. So, lets put it on 1.0.0 and we have to avoid any extra tagging or should not complicate the things.

This breaks what we have committed to users with the 1.0.0 image versions, so what is special that the one customer cannot use a new image version? or test the 1.0-canary?

If you just need the vote, then I will give it, but reasoning is missing.

[ShyamsundarR]

@ShyamsundarR as @Madhu-1 mentioned this fix is important and the customer should get it without the changes in the tag. So, lets put it on 1.0.0 and we have to avoid any extra tagging or should not complicate the things.

This breaks what we have committed to users with the 1.0.0 image versions, so what is special that the one customer cannot use a new image version? or test the 1.0-canary?

If you just need the vote, then I will give it, but reasoning is missing.

Is it because the image versions are baked into the manifests carried by Rook and that it would need a further PR for the user to use the updated image?

[ShyamsundarR]

Barring the version discussion code changes are fine.

[humblec]

This breaks what we have committed to users with the 1.0.0 image versions,

@ShyamsundarR can you point me the readme or document where we mentioned this ?

[ShyamsundarR]

This breaks what we have committed to users with the 1.0.0 image versions,

@ShyamsundarR can you point me the readme or document where we mentioned this ?

#345 is a start.

<< Humble's edit below>>
Well, first of all there is no release till date for v1.0, so no clear decision have been made or confirmed with above. We tagged v1.0 for the reasons like our default branch and other preparations for v1.1.0. Updating rook templates , backporting and making a release on Rook v1.0 and user updating to that release is required for a user to get this change. more or less, the changes in ceph-csi may not be the "one and only" thing coming in rook for a clear tracking from user pov. My point is that, the new users are getting this change without any hiccups or immediately if we update the existing tag, so I would vote for bringing the change as mentioned by @Madhu-1 . The existing deployments are NOT going to be disturbed as the image pull policy is NOT PRESENT. So, it should not be a concern.

[ShyamsundarR]

This breaks what we have committed to users with the 1.0.0 image versions,

@ShyamsundarR can you point me the readme or document where we mentioned this ?

#345 is a start.

<< Humble's edit below>>
Well, first of all there is no release till date for v1.0, so no clear decision have been made or confirmed with above. We tagged v1.0 for the reasons like our default branch and other preparations for v1.1.0. Updating rook templates , backporting and making a release on Rook v1.0 and user updating to that release is required for a user to get this change. more or less, the changes in ceph-csi may not be the "one and only" thing coming in rook for a clear tracking from user pov. My point is that, the new users are getting this change without any hiccups or immediately if we update the existing tag, so I would vote for bringing the change as mentioned by @Madhu-1 . The existing deployments are NOT going to be disturbed as the image pull policy is NOT PRESENT. So, it should not be a concern.

Rook has the following means of mentioning which CSI image versions to use, that should come in handy, rather than having the push a PR to Rook IMO,

• https://github.com/rook/rook/blob/2d73d024d4d11341dc2cbb3996825ccdd3ac4090/cluster/examples/kubernetes/ceph/operator-openshift-with-csi.yaml#L130
• https://github.com/rook/rook/blob/2d73d024d4d11341dc2cbb3996825ccdd3ac4090/cluster/examples/kubernetes/ceph/operator-openshift-with-csi.yaml#L130

Also, when a pod changes nodes, or is restarted on another node, it would pull the latest image, if it was never pulled before, so the statement "deployments NOT going to be disturbed" is not true.

[humblec]

Also, when a pod changes nodes, or is restarted on another node, it would pull the latest image, if it was never pulled before, so the statement "deployments NOT going to be disturbed" is not true.

Node plugin is a deamonset. That means image is present on EVERY NODE!! so, no question/confusion on "pod changes nodes or is restarted on another node ....".

In short that statement is correct :).

The only possibility is when you scale up the cluster itself, not when pod is rescheduled.

[ShyamsundarR]

Also, when a pod changes nodes, or is restarted on another node, it would pull the latest image, if it was never pulled before, so the statement "deployments NOT going to be disturbed" is not true.

Node plugin is a deamonset. That means image is present on EVERY NODE!! so, no question/confusion on "pod changes nodes or is restarted on another node ....".

In short that statement is correct :).

Agreed, I stand corrected.

The only possibility is when you scale up the cluster itself, not when pod is rescheduled.

But the above is a possibility, so still needs to be tackled, no?

[Madhu-1]

@humblec @ShyamsundarR ping

[ShyamsundarR]

The only last option, in terms of simplicity till we close out how we release updates, I want to provide is as follows,

• Get the PR to build and push a 1.0.1 image
• Follow up with another PR that changes it back to 1.0-canary
• The rook YAMLs allow the image name selection, that the user can use to
  use the 1.0.1 image instead of the default 1.0.0 in Rook
  • https://github.com/rook/rook/blob/2d73d024d4d11341dc2cbb3996825ccdd3ac4090/cluster/examples/kubernetes/ceph/operator-openshift-with-csi.yaml#L130
  • https://github.com/rook/rook/blob/2d73d024d4d11341dc2cbb3996825ccdd3ac4090/cluster/examples/kubernetes/ceph/operator-openshift-with-csi.yaml#L130

The pod manifests if they change is what gets us in trouble as these are
packaged into the rook image and hence needs a rook image rebuild. That
does not seem to be the case at present, so gives us an opportunity to
go ahead and roll out 1.0.1.

@humblec @Madhu-1 If this is still not acceptable, please roll out 1.0.0 by taking a
decision as the release owners, because any further back and forth on this is not going to get us anywhere IMO.

[ekuric]

@ShyamsundarR @humblec @Madhu-1 I wonder, when we can expect to have new images
per last @ShyamsundarR comment, I mean quay.io/cephcsi/cephfsplugin:v1.0.1 and quay.io/cephcsi/rbdplugin:v1.0.0 which are supposed to fix / workaround this problem. I would like to update cluster and test with usual suspects mongdb/postgresql.

[Madhu-1]

closing this one. this as been fixed in new release v1.1.0