Flocker storage plugin removed from k8s codebase.
Flocker, an early external storage plugin in k8s,
has not been in maintenance and their business is
down. As far as I know, the plugin is not being
used anymore.
This PR removes the whole flocker dependency and
codebase from core k8s to reduce potential security
risks and reduce maintenance work from the sig-storage community.
Currently, there are some unit tests that are failing on Windows due to
various reasons:
- volume mounting is a bit different on Windows: Mount will create the
parent dirs and mklink at the volume path later (otherwise mklink will
raise an error).
- os.Chmod is not working as intended on Windows.
- path.Dir() will always return "." on Windows, and filepath.Dir()
should be used instead (which works correctly).
- on Windows, you can't typically run binaries without extensions. If
the file C:\\foo.bat exists, we can still run C:\\foo because Windows
will append one of the supported file extensions ($env:PATHEXT) to it
and run it.
- Windows file permissions do not work the same way as the Linux ones.
- /tmp directory being used, which might not exist on Windows. Instead,
the OS-specific Temp directory should be used.
Fixes a few other issues:
- rbd.go: Return error in a case in which an error is encountered. This
will prevent "rbd: failed to setup" and "rbd: successfully setup" log
messages to be logged at the same time.
GlusterFS is one of the first dynamic provisioner which made into
Kubernetes release v1.4.
https://github.com/kubernetes/kubernetes/pull/30888
When CSI plugins/drivers to start appear, glusterfs' CSI driver
came into existence, however this project is not maintianed at
present and the last release happened few years back.
https://github.com/gluster/gluster-csi-driver/releases/tag/v0.0.9
The possibilities of migration to compatible CSI driver was also
discussed https://github.com/kubernetes/kubernetes/issues/100897
and consensus was to start the deprecation in v1.25.
This commit start the deprecation process of glusterfs plugin from
in-tree drivers.
Signed-off-by: Humble Chirammal <hchiramm@redhat.com>
- Run hack/update-codegen.sh
- Run hack/update-generated-device-plugin.sh
- Run hack/update-generated-protobuf.sh
- Run hack/update-generated-runtime.sh
- Run hack/update-generated-swagger-docs.sh
- Run hack/update-openapi-spec.sh
- Run hack/update-gofmt.sh
Signed-off-by: Davanum Srinivas <davanum@gmail.com>
For example, we have two filesystems, one is embedded into another:
/a/test # first filesystem with a directory "/a/test/b2"
/a/test/b2 # not auto mounted yet second filesystem, notice "/a/test/b2" is
# a new directory on this filesystem after this filesystem is mounted
For subpath mount "/a/test/b2", `openat("/a/test", "b2")` gets directory "b2" on the first
filesystem, then "mount -c" will use this wrong directory as source directory.
`fstatat("/a/test", "b2/")` forces triggering auto mount of second filesystem, so
`openat("/a/test", "b2")` gets correct source directory for "mount -c".
This fixes issue https://github.com/kubernetes/kubernetes/issues/110818#issuecomment-1175736550
References:
1. https://man7.org/linux/man-pages/man2/openat.2.html
If pathname refers to an automount point that has not yet
been triggered, so no other filesystem is mounted on it,
then the call returns a file descriptor referring to the
automount directory without triggering a mount.
2. https://man7.org/linux/man-pages/man2/open_by_handle_at.2.html
name_to_handle_at() does not trigger a mount when the final
component of the pathname is an automount point. When a
filesystem supports both file handles and automount points, a
name_to_handle_at() call on an automount point will return with
error EOVERFLOW without having increased handle_bytes. This can
happen since Linux 4.13 with NFS when accessing a directory which
is on a separate filesystem on the server. In this case, the
automount can be triggered by adding a "/" to the end of the
pathname.
Before:
findDisk()
fcPathExp := "^(pci-.*-fc|fc)-0x" + wwn + "-lun-" + lun
After:
findDisk()
fcPathExp := "^(pci-.*-fc|fc)-0x" + wwn + "-lun-" + lun + "$"
fc path may have the same wwns but different luns.for example:
pci-0000:41:00.0-fc-0x500a0981891b8dc5-lun-1
pci-0000:41:00.0-fc-0x500a0981891b8dc5-lun-12
Function findDisk() may mismatch the fc path, return the wrong device and wrong associated devicemapper parent.
This may cause a disater that pods attach wrong disks. Accutally it happended in my testing environment before.
Addresses in the Kubernetes API objects (PV, Pod) have `[]` around IPv6
addresses, while addresses in /dev/ and /sys/ have addresses without them.
Add/remove `[]` as needed.
This resolves a couple of issues for CSI volume reconstruction.
1. IsLikelyNotMountPoint is known not to work for bind mounts and was
causing problems for subpaths and hostpath volumes.
2. Inline volumes were failing reconstruction due to calling
GetVolumeName, which only works when there is a PV spec.
v1.43.0 marked grpc.WithInsecure() deprecated so this commit moves to use
what is the recommended replacement:
grpc.WithTransportCredentials(insecure.NewCredentials())
Signed-off-by: Mikko Ylinen <mikko.ylinen@intel.com>
On IPv6 clusters, one of the most frequent problems I encounter is
assumptions that one can build a URL with a host and port simply by
using Sprintf, like this:
```go
fmt.Sprintf("http://%s:%d/foo", host, port)
```
When `host` is an IPv6 address, this produces an invalid URL as it must
be bracketed, like this:
```
http://[2001:4860:4860::8888]:9443
```
This change fixes the occurences of joining a host and port with the
purpose built `net.JoinHostPort` function.
I encounter this problem often enough that I started to [write a linter
for it](https://github.com/stbenjam/go-sprintf-host-port). I don't
think the linter is quite ready for wide use yet, but I did run it
against the Kube codebase and found these. While the host portion in
some of these changes may always be an FQDN or IPv4 IP today, it's an
easy thing that can break later on.
CSI spec 1.5 enhanced the spec to add optional secrets field to
NodeExpandVolumeRequest. This commit adds NodeExpandSecret to the
CSI PV source and also derive the expansion secret in csiclient to
send it out as part of the nodeexpand request.
Signed-off-by: Humble Chirammal <hchiramm@redhat.com>
Signed-off-by: zhucan <zhucan.k8s@gmail.com>
