You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Wei ZHOU <us...@gmail.com> on 2024/09/18 09:37:15 UTC
Removal of unused plugins
Hi all,
There are some plugins in CloudStack which have not been updated for some
years. I think we should remove some of the plugins in the next releases.
For hypervisors, we have a wiki page to maintain the EOL dates:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Hypervisor+and+Management+Server+OS+EOL+Dates
(thanks Rohit)
We lack the information of network plugins.
Anyone (or knows someone else) is using the following plugins in red ?
*- plugins/hypervisors*
* - baremetal- hyperv- kvm- ovm- ovm3- simulator- ucs- vmware- xenserver*
*- plugins/network-elements*
- bigswitch
- cisco-vnmc
- elastic-loadbalancer
- internal-loadbalancer
- netscaler
- nsx
- ovs
- stratosphere-ssp
- vxlan
- brocade-vcs
- dns-notifier
- globodns
- juniper-contrail
- nicira-nvp
- opendaylight
- palo-alto
- tungsten
Thank you !
Kind regards,
Wei
Re: Removal of unused plugins
Posted by Wei ZHOU <us...@gmail.com>.
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 <jo...@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 <br...@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.
> >>
> >>
> >>
>
Re: Removal of unused plugins
Posted by João Jandre <jo...@apache.org>.
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 <br...@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.
>>
>>
>>
Re: Removal of unused plugins
Posted by Bryan Tiang <br...@hotmail.com>.
Hi Wei Zhou,
I can see some updates to the OpenSDN repos recently. Im guessing its just a wait and see then? And for cloudstack community to decide if this is something worth continuing down the line?
Regards,
Bryan
On 26 Sep 2024 at 3:07 AM +0800, Wei ZHOU <us...@gmail.com>, wrote:
> Hi Byran,
>
> They have copied some repos to OpenSDN on github.
> https://github.com/OpenSDN-io
>
> There were already some changes made to some repos.
>
> -Wei
>
>
> On Wednesday, September 25, 2024, Bryan Tiang <br...@hotmail.com>
> wrote:
>
> > Hi Guys,
> >
> > Speaking of Tungsten Plugin, what happened with the OpenSDN integration?
> >
> > Last i heard was that they formed a committee after Tungsten project was
> > closed, but havent heard any news since?
> >
> > Reagrds,
> > Bryan
> > On 18 Sep 2024 at 10:22 PM +0800, Wei ZHOU <us...@gmail.com>, 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 <br...@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.
> > > >
> > > >
> > > >
> >
Re: Removal of unused plugins
Posted by Wei ZHOU <us...@gmail.com>.
Hi Byran,
They have copied some repos to OpenSDN on github.
https://github.com/OpenSDN-io
There were already some changes made to some repos.
-Wei
On Wednesday, September 25, 2024, Bryan Tiang <br...@hotmail.com>
wrote:
> Hi Guys,
>
> Speaking of Tungsten Plugin, what happened with the OpenSDN integration?
>
> Last i heard was that they formed a committee after Tungsten project was
> closed, but havent heard any news since?
>
> Reagrds,
> Bryan
> On 18 Sep 2024 at 10:22 PM +0800, Wei ZHOU <us...@gmail.com>, 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 <br...@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.
> > >
> > >
> > >
>
Re: Removal of unused plugins
Posted by Bryan Tiang <br...@hotmail.com>.
Hi Guys,
Speaking of Tungsten Plugin, what happened with the OpenSDN integration?
Last i heard was that they formed a committee after Tungsten project was closed, but havent heard any news since?
Reagrds,
Bryan
On 18 Sep 2024 at 10:22 PM +0800, Wei ZHOU <us...@gmail.com>, 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 <br...@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.
> >
> >
> >
Re: Removal of unused plugins
Posted by Wei ZHOU <us...@gmail.com>.
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 <br...@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.
>
>
>
Re: Removal of unused plugins
Posted by Wei ZHOU <us...@gmail.com>.
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 <br...@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.
>
>
>
Re: Removal of unused plugins
Posted by Bryan Tiang <br...@hotmail.com>.
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.
Regards,
Bryan
On 18 Sep 2024 at 7:41 PM +0800, Wei ZHOU <us...@gmail.com>, wrote:
> Hi,
>
> It looks like the formatting is lost.
> Below are the plugins in red in my previous email.
>
> - plugins/hypervisors
>
> hyperv
> ovm
> ovm3
> ucs
>
> - plugins/network-elements
>
> bigswitch
> cisco-vnmc
> elastic-loadbalancer
> netscaler
> stratosphere-ssp
> brocade-vcs
> juniper-contrail
> nicira-nvp
> opendaylight
> palo-alto
>
>
>
> Kind regards,
> Wei
>
> On Wed, Sep 18, 2024 at 11:37 AM Wei ZHOU <us...@gmail.com> wrote:
>
> > Hi all,
> >
> > There are some plugins in CloudStack which have not been updated for some
> > years. I think we should remove some of the plugins in the next releases.
> >
> > For hypervisors, we have a wiki page to maintain the EOL dates:
> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Hypervisor+and+Management+Server+OS+EOL+Dates
> > (thanks Rohit)
> >
> > We lack the information of network plugins.
> >
> > Anyone (or knows someone else) is using the following plugins in red ?
> >
> > *- plugins/hypervisors*
> >
> >
> >
> > * - baremetal- hyperv- kvm- ovm- ovm3- simulator- ucs- vmware- xenserver*
> >
> > *- plugins/network-elements*
> >
> >
> > - bigswitch
> > - cisco-vnmc
> > - elastic-loadbalancer
> > - internal-loadbalancer
> > - netscaler
> > - nsx
> > - ovs
> > - stratosphere-ssp
> > - vxlan
> > - brocade-vcs
> > - dns-notifier
> > - globodns
> > - juniper-contrail
> > - nicira-nvp
> > - opendaylight
> > - palo-alto
> > - tungsten
> >
> >
> >
> > Thank you !
> >
> > Kind regards,
> > Wei
> >
> >
> >
> >
> >
> >
Re: Removal of unused plugins
Posted by Wei ZHOU <us...@gmail.com>.
Hi,
It looks like the formatting is lost.
Below are the plugins in red in my previous email.
- plugins/hypervisors
hyperv
ovm
ovm3
ucs
- plugins/network-elements
bigswitch
cisco-vnmc
elastic-loadbalancer
netscaler
stratosphere-ssp
brocade-vcs
juniper-contrail
nicira-nvp
opendaylight
palo-alto
Kind regards,
Wei
On Wed, Sep 18, 2024 at 11:37 AM Wei ZHOU <us...@gmail.com> wrote:
> Hi all,
>
> There are some plugins in CloudStack which have not been updated for some
> years. I think we should remove some of the plugins in the next releases.
>
> For hypervisors, we have a wiki page to maintain the EOL dates:
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Hypervisor+and+Management+Server+OS+EOL+Dates
> (thanks Rohit)
>
> We lack the information of network plugins.
>
> Anyone (or knows someone else) is using the following plugins in red ?
>
> *- plugins/hypervisors*
>
>
>
> * - baremetal- hyperv- kvm- ovm- ovm3- simulator- ucs- vmware- xenserver*
>
> *- plugins/network-elements*
>
>
> - bigswitch
> - cisco-vnmc
> - elastic-loadbalancer
> - internal-loadbalancer
> - netscaler
> - nsx
> - ovs
> - stratosphere-ssp
> - vxlan
> - brocade-vcs
> - dns-notifier
> - globodns
> - juniper-contrail
> - nicira-nvp
> - opendaylight
> - palo-alto
> - tungsten
>
>
>
> Thank you !
>
> Kind regards,
> Wei
>
>
>
>
>
>
Re: Removal of unused plugins
Posted by Wei ZHOU <us...@gmail.com>.
Hi,
It looks like the formatting is lost.
Below are the plugins in red in my previous email.
- plugins/hypervisors
hyperv
ovm
ovm3
ucs
- plugins/network-elements
bigswitch
cisco-vnmc
elastic-loadbalancer
netscaler
stratosphere-ssp
brocade-vcs
juniper-contrail
nicira-nvp
opendaylight
palo-alto
Kind regards,
Wei
On Wed, Sep 18, 2024 at 11:37 AM Wei ZHOU <us...@gmail.com> wrote:
> Hi all,
>
> There are some plugins in CloudStack which have not been updated for some
> years. I think we should remove some of the plugins in the next releases.
>
> For hypervisors, we have a wiki page to maintain the EOL dates:
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Hypervisor+and+Management+Server+OS+EOL+Dates
> (thanks Rohit)
>
> We lack the information of network plugins.
>
> Anyone (or knows someone else) is using the following plugins in red ?
>
> *- plugins/hypervisors*
>
>
>
> * - baremetal- hyperv- kvm- ovm- ovm3- simulator- ucs- vmware- xenserver*
>
> *- plugins/network-elements*
>
>
> - bigswitch
> - cisco-vnmc
> - elastic-loadbalancer
> - internal-loadbalancer
> - netscaler
> - nsx
> - ovs
> - stratosphere-ssp
> - vxlan
> - brocade-vcs
> - dns-notifier
> - globodns
> - juniper-contrail
> - nicira-nvp
> - opendaylight
> - palo-alto
> - tungsten
>
>
>
> Thank you !
>
> Kind regards,
> Wei
>
>
>
>
>
>