release 1.1.0 deployments #48
Conversation
node-driver-registrar v1.1.0 works for Kubernetes 1.13. csi-attacher v1.1.1 is the latest bugfix release for Kubernetes 1.14.
This uses the v1.1.0 driver image, which does not exist yet because we first have update the deployment files before we can tag that release. The name of the deployment gets changed because it is no longer for Kubernetes master (although it works there).
k8s-ci-robot
added
release-note
k8s-ci-robot
added
the
size/S
|
/assign @msau42 |
| @@ -63,7 +63,7 @@ spec: | |||
| name: csi-data-dir | |||
|
|
|||
| - name: hostpath | |||
| image: quay.io/k8scsi/hostpathplugin:canary # TODO: replace with v1.1.0 when it is cut | |||
There was a problem hiding this comment.
do we still want a deployment for master?
There was a problem hiding this comment.
No. The CI only uses "kubernetes-x.yy". Using "master" as directory and "kubernetes-1.14" as symlink was an interim solution to indicate to users that the deployment hadn't been finalized yet. That's no longer the case.
I also can't think of another reason right why we might want to have a separate deployment for Kubernetes master. If someone wants to try out the canary images, then they can do that with IMAGE_TAG=canary deploy/kubernetes-latest/deploy-hostpath.sh.
|
Oh one more thing. Can you help prepare a changelog file similar to the sidecars that summarize the important features and fixes for this release? |
|
Michelle Au <[email protected]> writes:
Oh one more thing. Can you help prepare a changelog file similar to
the sidecars that summarize the important features and fixes for this
release?
I had the same thought and actually tried, but the auto-generated
changelog from the release-notes tools is pretty useless for this repo
(just a single entry because most of the PRs don't have release
notes). I then had to stop due to lack of time.
Looking at the commit log I'm not sure which changes need to be
mentioned.
Given that this is a demo driver, perhaps we can simply release 1.1.0
without a changelog and then become more diligent about it for future
releases?
|
|
That's fine. What were the main changes we made? Added raw block support, improved deployment example, added snapshot examples |
|
/remove-kind api-change |
k8s-ci-robot
added
lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: msau42, pohly 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:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
approved
What type of PR is this?
/kind api-change
What this PR does / why we need it:
This is needed because we want the v1.1.0 release of the driver to have the corresponding deployments that use that driver.
Special notes for your reviewer:
The first commit could already be merged now. Let me know if you want to do that and I'll create a separate PR for it. The second commit should be merged only shortly before the actual v1.1.0 release, because merging it will break the deployments and thus the periodic CI testing until the release image becomes available.
Does this PR introduce a user-facing change?: