Hi João, Thanks for the reply.
I agree that the deprecation/removal of plugins should only happen in major releases. Kind regards, Wei On Thu, Sep 19, 2024 at 1:56 PM João Jandre <j...@apache.org> wrote: > Hello all, Wei > > I think that's a great initiative, we should definitely trim the > codebase of old and unused integration/features. However, I think we > should not do this in a minor release. We could decide on what plugins > should be removed and announce/deprecate them in the next release. > However, the removal of features should only happen in major releases. > > I would like to once again bring back the recent discussions on > versioning: > https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87, > https://lists.apache.org/thread/4zs8d15ghvvwwro46ry5zjf8fn8x0t88, > https://lists.apache.org/thread/o6o9h3qp8gqrpq4v7o81tl6vp51tkjhg, and > https://github.com/apache/cloudstack/discussions/8970. I think we should > really sit down and discuss the direction that we want to bring the > project. We should build a consensus on a versioning schema that will > come with the proper mechanisms of deprecating/removing features, as > well as introducing breaking changes. > > Looking at those discussions and Daniel's topics of discussions (see > > https://github.com/apache/cloudstack/discussions/8970#discussioncomment-9754199) > > here would be my new proposal: > > 1. **Looking at our history, what would be the ideal cadence of major > releases for our context and why?** On average, we take 9 months to > release a new minor version. Considering that our 'minor' versions are > where our major changes happen, we could take this cadence of minor > versions and transfer it into major ones. Furthermore, as we will have > mechanisms to introduce breaking changes (and those tend to take time), > we should add some padding on those 9 months and make it 1 year. We also > do not need to decide on a specific month to release the version, we > could have a quarter (Q1/Q2/Q3/Q4) that is when the version is scheduled > to release. That way, we will have some predictability on when the > release is out, but also some flexibility. > 2. **How and when should we define the RM for each major?** For the > 'how', I like the current system of someone volunteering and the > community voting on them; I don't see any reason to change this. As for > the 'when', the week following a new release, we should already have a > new RM to guide the next one. This way, we avoid having an aimless > project for too long. > 3. **How should we introduce disruptive changes and remove > compatibility?** For our first major release, I think we should announce > these changes as soon as the discussions about versioning are over and > introduce these changes on that release. But for the future, the better > method would be: on one major release, we announce the disruptive > changes and deprecate the necessary code; on the next one we introduce > the changes. > 4. **What are the community's common goals?** From our discussions, it > seems like a part of the community wants to keep the project as is and > not introduce too many breaking changes. However, we also have another > part of the community that wants to evolve the project and try to make > it even better. As always with a community we should strive to build a > consensus on changes, if they should or not happen. We could have an > annual discussion planned to map what are the next year's goals, as well > as decide on things that should not change (at least at the time). This > discussion could be held at the start of a new major release cycle so > that the RM has a north to follow and steer the community efforts. I > think that one common goal that we should try to achieve is the creation > of an automated release process. We could create a pipeline that does > most (or all) the release process so that we only have to approve it > (and tweak it if needed) before releasing. > 5. **Regarding minor releases, should we flexibilize it more or be more > rigid?** I think we should concentrate our big and new features on the > major versions; while tweaks and bug fixes would go on the minor > releases. This way, we can have more stable minor releases that do not > introduce too much stuff at a time. Focusing on the major releases for > new features will allow us to better test them and do better quality > control. > > If there is further interest in continuing the discussion on the release > process/versioning, please create a new thread so we can discuss it and > hammer it down. > > Best regards, > > João Jandre > > On 9/18/24 11:19, Wei ZHOU wrote: > > Thanks Byran. > > > > I think we will definitely keep the following the plugins > > - kvm, vmware, xenserver, simulator > > - ovs, vxlan, nsx, tungsten, internal-lb > > > > hyperv is not well-maintained, but I prefer to keep it. ovm/ovm3/ucs > > support could be dropped. > > > > for the network plugins, I do not have preferences. good to know that > Palo > > alto is interested. > > in ACS 4.21 or 4.22, you might see some more VNF improvements (e.g. a > > provider framework and an implementation) > > > > > > Kind regards, > > Wei > > > > > > On Wed, Sep 18, 2024 at 3:25 PM Bryan Tiang <bryantian...@hotmail.com> > > wrote: > > > >> Hi Wei Zhou, > >> > >> We dont use any of the plugins listed, but some do stand out: > >> > >> # HyperV # We dont use it right now, but would definitely use it if it > was > >> more mature. Some enterprise-ey applications we use require HyperV > (other > >> than Vmware) for some reason (Eg. Oneidentity Privilege Access Mgmt > >> System), so we maintain a small cluster of HyperV outside of cloudstack. > >> But if there's no intention to enhance these, id suggest to remove it. > With > >> people moving out of Vmware and looking for alternatives, Cloudstack > docs > >> should show the fairly supported items. Its just better on optics and CS > >> adoption. > >> > >> # Palo Alto # I believe this was built by CloudOps by Aptum in 2014? We > >> were researching this extensively cause we wanted to implement some NGFW > >> capabilities in our setup, but it seems the project wasn't maintained > over > >> the years. Im not sure whos using it, but it's sad there wasn't much > >> uptake. Probably because Palo Alto is really expensive now. If there > was a > >> fortinet plugin, we'd be very interested. But right now, we settled on > >> using VNF + L2 Networks. > >> > >> Note: Please dont remove VXLAN plugin... will self destruct. > >> > >> > >> >
