Release v1.2.0 of Ceph-CSI driver

[humblec]

• Define release process

  • Release doc would be a good start

• Define release deadlines

  • Code Freeze : 05-Aug-2019
  • RC : 10-Aug -2019
  • GA : 15-Aug-2019
  • GA postponed to 30-Aug-2019

• Define/list roadmap for v1.2.0

  • Proposed contents for v1.2.0 release
    -- Metrics support ( RBD, CephFS)
    -- Resize support for Ceph and RBD plugin [Deferred]
    -- Snapshot support for RBD.[Deferred]
    -- Cloning support for RBD.[Deferred]

• Release Team:

• @Madhu-1

• @humblec

• The release blockers (issues/PRs) are labelled with release-1.2.0.
  https://github.com/ceph/ceph-csi/labels/release-1.2.0

• Document features and announce the release.

[ShyamsundarR]

@humblec The dates need a refresh here?

Also, are we using semantic versioning and hence z in this case is a patch release and not a feature release? If so should the next release really be 1.1.1 or should it be 1.2?

I am asking to understand how we will hasten a 1.1.1 release or a refresh to 1.1.0 release for a critical bug fix that is needed by users ASAP.

[humblec]

Also, are we using semantic versioning and hence z in this case is a patch release and not a feature release? If so should the next release really be 1.1.1 or should it be 1.2?>

@ShyamsundarR This is a haunting question for sometime now :), Have to think about this some more , but one thing which we are sure here is, there going to be "features" as mentioned in the description.

Does users have a real concern if we implement features in next "async" release is the question, I dont think thats going to be a big concern.

I am asking to understand how we will hasten a 1.1.1 release or a refresh to 1.1.0 release for a critical bug fix that is needed by users ASAP.

We have almost a month for next release , so whatever we can accomodate in that has to be planned.

[humblec]

As per team discussion, this release will be tracked as 1.2.0 instead of 1.1.1 , the main reason being we will have many new features or enhancements in this release, IOW, its not going to be a bug fix release.

[Madhu-1]

@humblec snapshot/and cloning from the already created snapshot will not be backward compatible and also we can remove legacy volume handing code?
can we consider release as a major release instead of minor release?

[humblec]

@humblec snapshot/and cloning from the already created snapshot will not be backward compatible and also we can remove legacy volume handing code

Can we disallow cloning or snapshotting on already existing ones and allow only delete on those? so that we ensure backward compatibility with previous version ?

[Madhu-1]

as the snapshot and cloning is an alpha feature we don't need to do it. allowing backward compatibility will increase the complexity

[humblec]

as the snapshot and cloning is an alpha feature we don't need to do it. allowing backward compatibility will increase the complexity

True, I was checking whether if its possible with little bit of work we could accommodate the same. One of the enhancement we can do here is, we can have a mark on the PVs or Snapshots about the version of the driver created it. It will come handy when we have to hack between CSI driver versions. For ex: for new snapshot and clone we can mark the metadata with v1.2.0 , so that if we dont see that mark , may be "allow" only "delete" of that ..etc .

[ShyamsundarR]

... and also we can remove legacy volume handing code?

Is this support to mount and delete v1.0.0 volumes? If so, are you suggesting we remove this just one release later? Without any deprecation warning? which is further just ~5-6 weeks from the previous release.

I would say no to that.

[Madhu-1]

as the snapshot and cloning is an alpha feature we don't need to do it. allowing backward compatibility will increase the complexity

True, I was checking whether if its possible with little bit of work we could accommodate the same. One of the enhancement we can do here is, we can have a mark on the PVs or Snapshots about the version of the driver created it. It will come handy when we have to hack between CSI driver versions. For ex: for new snapshot and clone we can mark the metadata with v1.2.0 , so that if we dont see that mark , may be "allow" only "delete" of that ..etc .

@humblec this cannot be done, as we cannot encoding the driver version it's difficult to do it

[Madhu-1]

... and also we can remove legacy volume handing code?

Is this support to mount and delete v1.0.0 volumes? If so, are you suggesting we remove this just one release later? Without any deprecation warning? which is further just ~5-6 weeks from the previous release.

I would say no to that.

why not if we release 2.0.0? as can mention no direct upgrade from 1.0.0 to 2.0.0?
better to upgrade 1.0.0 to 1.1.0 and 1.1.0 to 2.0.0

@humblec can you please update readme for supported upgrade versions.

[ShyamsundarR]

as the snapshot and cloning is an alpha feature we don't need to do it. allowing backward compatibility will increase the complexity

True, I was checking whether if its possible with little bit of work we could accommodate the same. One of the enhancement we can do here is, we can have a mark on the PVs or Snapshots about the version of the driver created it. It will come handy when we have to hack between CSI driver versions. For ex: for new snapshot and clone we can mark the metadata with v1.2.0 , so that if we dont see that mark , may be "allow" only "delete" of that ..etc .

@humblec this cannot be done, as we cannot encoding the driver version it's difficult to do it

We can always use the VolumeID version field and up that to 2 for the newly created volumes and snapshots that exhibit appropriate support levels. This was one of the reasons to have that in there.

[ShyamsundarR]

... and also we can remove legacy volume handing code?

Is this support to mount and delete v1.0.0 volumes? If so, are you suggesting we remove this just one release later? Without any deprecation warning? which is further just ~5-6 weeks from the previous release.
I would say no to that.

why not if we release 2.0.0? as can mention no direct upgrade from 1.0.0 to 2.0.0?
better to upgrade 1.0.0 to 1.1.0 and 1.1.0 to 2.0.0

My point is,

• We would hence be supporting the backward compatibility for exactly 1 release, which looks too short
• Also, what is the reason to do this? The code is there and restricted in its scope, so I do not see a need to remove it in a hurry
• I would go with a deprecation announcement in the next release, and then one or two releases later, deprecate the feature (we possibly can make this a process of deprecation for other future needs as well)

[humblec]

Release Call update:

This release will be **v2.0.0** considering the features we are bringing here and also because the new snapshot implementation in this release. The issue and other references are updated with **v2.0.0**.

@Madhu-1 Did I miss anything to add here ?

[novakoki]

Will resize support still be in this release? I can't find related code but it should be in RC stage now according to the plan. @humblec

[humblec]

Will resize support still be in this release? I can't find related code but it should be in RC stage now according to the plan. @humblec

Due to other bug fixes or critical things to solve, resize is not yet in this release. Apologies for the same. We are also thinking to call this as a minor release and prepare one more release at mid of sept with resize support . Does it help ?

[humblec]

[Release call update]

As this release is mainly on bug fixes, we plan to call this as 1.2.0 instead of 2.0.0. The features like resize , snapshot and cloning has been taken out from this release due to the fact that, it was difficult to get it in due to other fixes which were touching the same area of the code. The deferred features are moved to v2.0.0 which is planned around 3rd week of sep.

At present, we are facing some issues with CI and good number of PRs are in merge queue for v1.2.0 . Due to the same reason new GA date has been moved to 21-Aug-2019.

@Madhu-1 anything else to add ?

[humblec]

[Status update]
Out of 40 issues/PRs tagged for release-1.2.0 , 36 are closed and 4 more is still open. We are postponing the GA to 30-Aug-2019 for the same reason.

[HaveFun83]

Hi how is the status here?

[humblec]

Hi how is the status here?

Pretty much there, got a small delay due to CI issues + holiday yesterday. Waiting for CI to pass on couple of important PRs which @poornimag working on. Once its done, we will cut the release, targetting tomorrow for the release.

[HaveFun83]

Hi how is the status here?

Pretty much there, got a small delay due to CI issues + holiday yesterday. Waiting for CI to pass on couple of important PRs which @poornimag working on. Once its done, we will cut the release, targetting tomorrow for the release.

Thanks for the info

[humblec]

[Pending PRs]
https://github.com/ceph/ceph-csi/pulls?q=is%3Apr+is%3Aopen+label%3Arelease-1.2.0

[Madhu-1]

closing this as we have released v1.2.0

[humblec]

Finally the release v1.2.0 is out !! Thanks all ! ceph-csi++

[humblec]

docker pull quay.io/cephcsi/cephcsi:v1.2.0 is the release container image! @HaveFun83

[HaveFun83]

docker pull quay.io/cephcsi/cephcsi:v1.2.0 is the release container image! @HaveFun83

Thanks a lot