Re: [DISCUSS] Retirement of midonet plugin
gt; > >> > > > > > > >> > >> Complete removal of the plugin was my solution > to the > > problem > > > > of > > > > >> > the jar > > > > >> > >> file's dependencies. If it's not used or > maintained, > > then it > > > > >> should > > > > >> > be > > > > >> > >> removed, in my opinion. Disabling it in the > build is a > > good > > > > first > > > > >> > step. > > > > >> > >> > > > > >> > >> *Jeff Hair* > > > > >> > >> Technical Lead and Software Developer > > > > >> > >> > > > > >> > >> Tel: (+354) 415 0200 > > > > >> > >> j...@greenqloud.com > > > > >> > >> www.greenqloud.com > > > > >> > >> > > > > >> > >> On Wed, Mar 15, 2017 at 8:18 AM, Rohit Yadav < > > > > >> > rohit.ya...@shapeblue.com> > > > > >> > >> wrote: > > > > >> > >> > > > > >> > >> > +1 as others have noted > > > > >> > >> > > > > > >> > >> > > > > > >> > >> > Disable the plugin from the default build for > next > > few > > > > releases > > > > >> > and > > > > >> > >> > eventually deprecate/remove the plugin from the > > codebase. > > > The > > > > >> > roadmap can > > > > >> > >> > look something like: > > > > >> > >> > > > > > >> > >> > - Announce on the MLs that we're planning to do > > this, send > > > a > > > > PR > > > > >> > and get > > > > >> > >> it > > > > >> > >> > accepted > > > > >> > >> > > > > > >> > >> > - During the release process RM should make > this > > > information > > > > >> > available to > > > > >> > >> > everyone (including voting thread, would be > nice to > > have a > > > > >> > shortlog of > > > > >> > >> > major changes in the voting email?) > > > > >> > >> > > > > > >> > >> > - In the release notes and release > announcement, > > note that > > > > >> > midonet is no > > > > >> > >> > longer included in the default build and is > planned > > to be > > > > >> > deprecated > > > > >> > >> > > > > > >> > >> > - By end of the year, if we've no communication > > received > > > > >> > deprecate and > > > > >> > >> > remove the plugin with an announcement > > > > >> > >> > > > > > >> > >> > > > > > >> > >> > I think this should be done with Midonet and > any > > other > > > > plugins > > > > >> > that are > > > > >> > >> > causing issues and are no longer maintained by > > anyway. > > > > >> > >> > > > > > >> > >> > > > > > >> > >> > Regards. > > > > >> > >> > > > > > >> > >> > > > > > >> > >> > From: Sergey Levitskiy < > > sergey.levits...@autodesk.com> > > > > >> > >> > Sent: 15 March 2017 07:00:51 > > > > >> > >> > To: dev@cloudstack.apache.org > > > > >> > >> > Subject: Re: [DISCUSS] Retirement of midonet > plugin > > > > >> > >> > > > > > >> > >> > I am for: > > > > >> > >> > (i) disable the build for the plugin for the > next 2 > > major > > > > >> release > > > > >> > >> > followed by > > > > >> > >> > (ii) remove everything in ACS 4.12 if no one > express > > > > regrets by > > > > >> > then > > > > >> > >> > > > > > >> > >> > > > > > >> > >> > > > > > >> > >> > > > > > >> > >> > rohit.ya...@shapeblue.com > > > > >> > >> > www.shapeblue.com > > > > >> > >> > 53 Chandos Place, Covent Garden, London WC2N > 4HSUK > > > > >> > >> > @shapeblue > > > > >> > >> > > > > > >> > >> > > > > > >> > >> > > > > > >> > >> > > > > > >> > >> > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > -- > > > > >> > > Rafael Weingärtner > > > > >> > > > > > >> > > > > > >> > > > > > >> > daan.hoogl...@shapeblue.com > > > > >> > www.shapeblue.com > > > > >> > 53 Chandos Place, Covent Garden, London WC2N 4HSUK > > > > >> > @shapeblue > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > > > > > > > > > > > -- > > Rafael Weingärtner > > > > > > > > daan.hoogl...@shapeblue.com > > www.shapeblue.com > > 53 Chandos Place, Covent Garden, London WC2N 4HSUK > > @shapeblue > > > > > > > > > > > -- > Rafael Weingärtner > > > > daan.hoogl...@shapeblue.com > www.shapeblue.com > 53 Chandos Place, Covent Garden, London WC2N 4HSUK > @shapeblue > > > > -- Rafael Weingärtner
Re: [DISCUSS] Retirement of midonet plugin
; how many releases we've rolled out in 6 months. > > > >> > > > > >> > Deprecate in the next (4.11?), remove a few releases later > > > (4.13?). > > > >> > > > > >> > -- > > > >> > Erik > > > >> > > > > >> > On Sat, Mar 18, 2017 at 11:23 PM, Rafael Weingärtner > > > >> > wrote: > > > >> > > Sorry the delay guys, I have been swapped these last > days. > > > >> > > > > > >> > > In summary, everybody that spoke is in favor of the > plugin > > > >> > retirement. I am > > > >> > > assuming that people who did not present their opinion > agree > > > with > > > >> > the ones > > > >> > > presented here. > > > >> > > > > > >> > > The process to retire this plugin would be the > following: > > > >> > > > > > >> > >1. Announce in our mailing lists the road map of > > retirement, > > > a > > > >> > data for > > > >> > >the final removal should be defined and presented in > this > > > road > > > >> > map; > > > >> > >2. Create a Jira ticket to execute the plugin > disabling (is > > > this > > > >> > >expression right?!), and of course, a PR to disable > the > > build > > > >> > until final > > > >> > >deletion; > > > >> > >3. Create a Jira ticket to execute the final removal > of the > > > >> > plugin. The > > > >> > >removal should only happen when the defined date > comes by; > > > >> > >4. Wait patiently while time goes by…. > > > >> > >5. When the time comes, create the PR and execute the > > plugin > > > >> > removal. > > > >> > > > > > >> > > > > > >> > > What date would you guys prefer to execute the plugin > removal? > > > 3, > > > >> 6, > > > >> > or 12 > > > >> > > months from now? > > > >> > > What do you think of this process? Am I missing > something > > else? > > > >> > > > > > >> > > > > > >> > > > > > >> > > On Wed, Mar 15, 2017 at 9:13 AM, Jeff Hair < > > j...@greenqloud.com > > > > > > > >> > wrote: > > > >> > > > > > >> > >> Complete removal of the plugin was my solution to the > problem > > > of > > > >> > the jar > > > >> > >> file's dependencies. If it's not used or maintained, > then it > > > >> should > > > >> > be > > > >> > >> removed, in my opinion. Disabling it in the build is a > good > > > first > > > >> > step. > > > >> > >> > > > >> > >> *Jeff Hair* > > > >> > >> Technical Lead and Software Developer > > > >> > >> > > > >> > >> Tel: (+354) 415 0200 > > > >> > >> j...@greenqloud.com > > > >> > >> www.greenqloud.com > > > >> > >> > > > >> > >> On Wed, Mar 15, 2017 at 8:18 AM, Rohit Yadav < > > > >> > rohit.ya...@shapeblue.com> > > > >> > >> wrote: > > > >> > >> > > > >> > >> &g
Re: [DISCUSS] Retirement of midonet plugin
Looks good to me.
Re: [DISCUSS] Retirement of midonet plugin
tirement. I am > > > >> > > assuming that people who did not present their opinion > agree > > > with > > > >> > the ones > > > >> > > presented here. > > > >> > > > > > >> > > The process to retire this plugin would be the > following: > > > >> > > > > > >> > >1. Announce in our mailing lists the road map of > > retirement, > > > a > > > >> > data for > > > >> > >the final removal should be defined and presented in > this > > > road > > > >> > map; > > > >> > >2. Create a Jira ticket to execute the plugin > disabling (is > > > this > > > >> > >expression right?!), and of course, a PR to disable > the > > build > > > >> > until final > > > >> > >deletion; > > > >> > >3. Create a Jira ticket to execute the final removal > of the > > > >> > plugin. The > > > >> > >removal should only happen when the defined date > comes by; > > > >> > >4. Wait patiently while time goes by…. > > > >> > >5. When the time comes, create the PR and execute the > > plugin > > > >> > removal. > > > >> > > > > > >> > > > > > >> > > What date would you guys prefer to execute the plugin > removal? > > > 3, > > > >> 6, > > > >> > or 12 > > > >> > > months from now? > > > >> > > What do you think of this process? Am I missing > something > > else? > > > >> > > > > > >> > > > > > >> > > > > > >> > > On Wed, Mar 15, 2017 at 9:13 AM, Jeff Hair < > > j...@greenqloud.com > > > > > > > >> > wrote: > > > >> > > > > > >> > >> Complete removal of the plugin was my solution to the > problem > > > of > > > >> > the jar > > > >> > >> file's dependencies. If it's not used or maintained, > then it > > > >> should > > > >> > be > > > >> > >> removed, in my opinion. Disabling it in the build is a > good > > > first > > > >> > step. > > > >> > >> > > > >> > >> *Jeff Hair* > > > >> > >> Technical Lead and Software Developer > > > >> > >> > > > >> > >> Tel: (+354) 415 0200 > > > >> > >> j...@greenqloud.com > > > >> > >> www.greenqloud.com > > > >> > >> > > > >> > >> On Wed, Mar 15, 2017 at 8:18 AM, Rohit Yadav < > > > >> > rohit.ya...@shapeblue.com> > > > >> > >> wrote: > > > >> > >> > > > >> > >> > +1 as others have noted > > > >> > >> > > > > >> > >> > > > > >> > >> > Disable the plugin from the default build for next > few > > > releases > > > >> > and > > > >> > >> > eventually deprecate/remove the plugin from the > codebase. > > The > > > >> > roadmap can > > > >> > >> > look something like: > > > >> > >> > > > > >> > >> > - Announce on the MLs that we're planning to do > this, send > > a > > > PR > > > >> > and get > > > >> > >> it > > > >> > >> > accepted > > > >> > >> > > > > >> > >> > - During the release process RM should make this > > information > > > >> > available to > > > >> > >> > everyone (including voting thread, would be nice to > have a > > > >> > shortlog of > > > >> > >> > major changes in the voting email?) > > > >> > >> > > > > >> > >> > - In the release notes and release announcement, > note that > > > >> > midonet is no > > > >> > >> > longer included in the default build and is planned > to be > > > >> > deprecated > > > >> > >> > > > > >> > >> > - By end of the year, if we've no communication > received > > > >> > deprecate and > > > >> > >> > remove the plugin with an announcement > > > >> > >> > > > > >> > >> > > > > >> > >> > I think this should be done with Midonet and any > other > > > plugins > > > >> > that are > > > >> > >> > causing issues and are no longer maintained by > anyway. > > > >> > >> > > > > >> > >> > > > > >> > >> > Regards. > > > >> > >> > > > > >> > >> > > > > >> > >> > From: Sergey Levitskiy < > sergey.levits...@autodesk.com> > > > >> > >> > Sent: 15 March 2017 07:00:51 > > > >> > >> > To: dev@cloudstack.apache.org > > > >> > >> > Subject: Re: [DISCUSS] Retirement of midonet plugin > > > >> > >> > > > > >> > >> > I am for: > > > >> > >> > (i) disable the build for the plugin for the next 2 > major > > > >> release > > > >> > >> > followed by > > > >> > >> > (ii) remove everything in ACS 4.12 if no one express > > > regrets by > > > >> > then > > > >> > >> > > > > >> > >> > > > > >> > >> > > > > >> > >> > > > > >> > >> > rohit.ya...@shapeblue.com > > > >> > >> > www.shapeblue.com > > > >> > >> > 53 Chandos Place, Covent Garden, London WC2N 4HSUK > > > >> > >> > @shapeblue > > > >> > >> > > > > >> > >> > > > > >> > >> > > > > >> > >> > > > > >> > >> > > > >> > > > > > >> > > > > > >> > > > > > >> > > -- > > > >> > > Rafael Weingärtner > > > >> > > > > >> > > > > >> > > > > >> > daan.hoogl...@shapeblue.com > > > >> > www.shapeblue.com > > > >> > 53 Chandos Place, Covent Garden, London WC2N 4HSUK > > > >> > @shapeblue > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > > > > > > -- > Rafael Weingärtner > > > > daan.hoogl...@shapeblue.com > www.shapeblue.com > 53 Chandos Place, Covent Garden, London WC2N 4HSUK > @shapeblue > > > > -- Rafael Weingärtner
Re: [DISCUSS] Retirement of midonet plugin
t;expression right?!), and of course, a PR to disable the > build > > >> > until final > > >> > >deletion; > > >> > >3. Create a Jira ticket to execute the final removal of the > > >> > plugin. The > > >> > >removal should only happen when the defined date comes by; > > >> > >4. Wait patiently while time goes by…. > > >> > >5. When the time comes, create the PR and execute the > plugin > > >> > removal. > > >> > > > > >> > > > > >> > > What date would you guys prefer to execute the plugin removal? > > 3, > > >> 6, > > >> > or 12 > > >> > > months from now? > > >> > > What do you think of this process? Am I missing something > else? > > >> > > > > >> > > > > >> > > > > >> > > On Wed, Mar 15, 2017 at 9:13 AM, Jeff Hair < > j...@greenqloud.com > > > > > >> > wrote: > > >> > > > > >> > >> Complete removal of the plugin was my solution to the problem > > of > > >> > the jar > > >> > >> file's dependencies. If it's not used or maintained, then it > > >> should > > >> > be > > >> > >> removed, in my opinion. Disabling it in the build is a good > > first > > >> > step. > > >> > >> > > >> > >> *Jeff Hair* > > >> > >> Technical Lead and Software Developer > > >> > >> > > >> > >> Tel: (+354) 415 0200 > > >> > >> j...@greenqloud.com > > >> > >> www.greenqloud.com > > >> > >> > > >> > >> On Wed, Mar 15, 2017 at 8:18 AM, Rohit Yadav < > > >> > rohit.ya...@shapeblue.com> > > >> > >> wrote: > > >> > >> > > >> > >> > +1 as others have noted > > >> > >> > > > >> > >> > > > >> > >> > Disable the plugin from the default build for next few > > releases > > >> > and > > >> > >> > eventually deprecate/remove the plugin from the codebase. > The > > >> > roadmap can > > >> > >> > look something like: > > >> > >> > > > >> > >> > - Announce on the MLs that we're planning to do this, send > a > > PR > > >> > and get > > >> > >> it > > >> > >> > accepted > > >> > >> > > > >> > >> > - During the release process RM should make this > information > > >> > available to > > >> > >> > everyone (including voting thread, would be nice to have a > > >> > shortlog of > > >> > >> > major changes in the voting email?) > > >> > >> > > > >> > >> > - In the release notes and release announcement, note that > > >> > midonet is no > > >> > >> > longer included in the default build and is planned to be > > >> > deprecated > > >> > >> > > > >> > >> > - By end of the year, if we've no communication received > > >> > deprecate and > > >> > >> > remove the plugin with an announcement > > >> > >> > > > >> > >> > > > >> > >> > I think this should be done with Midonet and any other > > plugins > > >> > that are > > >> > >> > causing issues and are no longer maintained by anyway. > > >> > >> > > > >> > >> > > > >> > >> > Regards. > > >> > >> > > > >> > >> > > > >> > >> > From: Sergey Levitskiy > > >> > >> > Sent: 15 March 2017 07:00:51 > > >> > >> > To: dev@cloudstack.apache.org > > >> > >> > Subject: Re: [DISCUSS] Retirement of midonet plugin > > >> > >> > > > >> > >> > I am for: > > >> > >> > (i) disable the build for the plugin for the next 2 major > > >> release > > >> > >> > followed by > > >> > >> > (ii) remove everything in ACS 4.12 if no one express > > regrets by > > >> > then > > >> > >> > > > >> > >> > > > >> > >> > > > >> > >> > > > >> > >> > rohit.ya...@shapeblue.com > > >> > >> > www.shapeblue.com > > >> > >> > 53 Chandos Place, Covent Garden, London WC2N 4HSUK > > >> > >> > @shapeblue > > >> > >> > > > >> > >> > > > >> > >> > > > >> > >> > > > >> > >> > > >> > > > > >> > > > > >> > > > > >> > > -- > > >> > > Rafael Weingärtner > > >> > > > >> > > > >> > > > >> > daan.hoogl...@shapeblue.com > > >> > www.shapeblue.com > > >> > 53 Chandos Place, Covent Garden, London WC2N 4HSUK > > >> > @shapeblue > > >> > > > >> > > > >> > > > >> > > > >> > > > -- Rafael Weingärtner daan.hoogl...@shapeblue.com www.shapeblue.com 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue
Re: [DISCUSS] Retirement of midonet plugin
>> > > months from now? > > >> > > What do you think of this process? Am I missing something > else? > > >> > > > > >> > > > > >> > > > > >> > > On Wed, Mar 15, 2017 at 9:13 AM, Jeff Hair < > j...@greenqloud.com > > > > > >> > wrote: > > >> > > > > >> > >> Complete removal of the plugin was my solution to the problem > > of > > >> > the jar > > >> > >> file's dependencies. If it's not used or maintained, then it > > >> should > > >> > be > > >> > >> removed, in my opinion. Disabling it in the build is a good > > first > > >> > step. > > >> > >> > > >> > >> *Jeff Hair* > > >> > >> Technical Lead and Software Developer > > >> > >> > > >> > >> Tel: (+354) 415 0200 > > >> > >> j...@greenqloud.com > > >> > >> www.greenqloud.com > > >> > >> > > >> > >> On Wed, Mar 15, 2017 at 8:18 AM, Rohit Yadav < > > >> > rohit.ya...@shapeblue.com> > > >> > >> wrote: > > >> > >> > > >> > >> > +1 as others have noted > > >> > >> > > > >> > >> > > > >> > >> > Disable the plugin from the default build for next few > > releases > > >> > and > > >> > >> > eventually deprecate/remove the plugin from the codebase. > The > > >> > roadmap can > > >> > >> > look something like: > > >> > >> > > > >> > >> > - Announce on the MLs that we're planning to do this, send > a > > PR > > >> > and get > > >> > >> it > > >> > >> > accepted > > >> > >> > > > >> > >> > - During the release process RM should make this > information > > >> > available to > > >> > >> > everyone (including voting thread, would be nice to have a > > >> > shortlog of > > >> > >> > major changes in the voting email?) > > >> > >> > > > >> > >> > - In the release notes and release announcement, note that > > >> > midonet is no > > >> > >> > longer included in the default build and is planned to be > > >> > deprecated > > >> > >> > > > >> > >> > - By end of the year, if we've no communication received > > >> > deprecate and > > >> > >> > remove the plugin with an announcement > > >> > >> > > > >> > >> > > > >> > >> > I think this should be done with Midonet and any other > > plugins > > >> > that are > > >> > >> > causing issues and are no longer maintained by anyway. > > >> > >> > > > >> > >> > > > >> > >> > Regards. > > >> > >> > > > >> > >> > > > >> > >> > From: Sergey Levitskiy > > >> > >> > Sent: 15 March 2017 07:00:51 > > >> > >> > To: dev@cloudstack.apache.org > > >> > >> > Subject: Re: [DISCUSS] Retirement of midonet plugin > > >> > >> > > > >> > >> > I am for: > > >> > >> > (i) disable the build for the plugin for the next 2 major > > >> release > > >> > >> > followed by > > >> > >> > (ii) remove everything in ACS 4.12 if no one express > > regrets by > > >> > then > > >> > >> > > > >> > >> > > > >> > >> > > > >> > >> > > > >> > >> > rohit.ya...@shapeblue.com > > >> > >> > www.shapeblue.com > > >> > >> > 53 Chandos Place, Covent Garden, London WC2N 4HSUK > > >> > >> > @shapeblue > > >> > >> > > > >> > >> > > > >> > >> > > > >> > >> > > > >> > >> > > >> > > > > >> > > > > >> > > > > >> > > -- > > >> > > Rafael Weingärtner > > >> > > > >> > > > >> > > > >> > daan.hoogl...@shapeblue.com > > >> > www.shapeblue.com > > >> > 53 Chandos Place, Covent Garden, London WC2N 4HSUK > > >> > @shapeblue > > >> > > > >> > > > >> > > > >> > > > >> > > > -- Rafael Weingärtner
Re: [DISCUSS] Retirement of midonet plugin
r > >> > >> > >> > >> Tel: (+354) 415 0200 > >> > >> j...@greenqloud.com > >> > >> www.greenqloud.com > >> > >> > >> > >> On Wed, Mar 15, 2017 at 8:18 AM, Rohit Yadav < > >> > rohit.ya...@shapeblue.com> > >> > >> wrote: > >> > >> > >> > >> > +1 as others have noted > >> > >> > > >> > >> > > >> > >> > Disable the plugin from the default build for next few > releases > >> > and > >> > >> > eventually deprecate/remove the plugin from the codebase. The > >> > roadmap can > >> > >> > look something like: > >> > >> > > >> > >> > - Announce on the MLs that we're planning to do this, send a > PR > >> > and get > >> > >> it > >> > >> > accepted > >> > >> > > >> > >> > - During the release process RM should make this information > >> > available to > >> > >> > everyone (including voting thread, would be nice to have a > >> > shortlog of > >> > >> > major changes in the voting email?) > >> > >> > > >> > >> > - In the release notes and release announcement, note that > >> > midonet is no > >> > >> > longer included in the default build and is planned to be > >> > deprecated > >> > >> > > >> > >> > - By end of the year, if we've no communication received > >> > deprecate and > >> > >> > remove the plugin with an announcement > >> > >> > > >> > >> > > >> > >> > I think this should be done with Midonet and any other > plugins > >> > that are > >> > >> > causing issues and are no longer maintained by anyway. > >> > >> > > >> > >> > > >> > >> > Regards. > >> > >> > > >> > >> > > >> > >> > From: Sergey Levitskiy > >> > >> > Sent: 15 March 2017 07:00:51 > >> > >> > To: dev@cloudstack.apache.org > >> > >> > Subject: Re: [DISCUSS] Retirement of midonet plugin > >> > >> > > >> > >> > I am for: > >> > >> > (i) disable the build for the plugin for the next 2 major > >> release > >> > >> > followed by > >> > >> > (ii) remove everything in ACS 4.12 if no one express > regrets by > >> > then > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > rohit.ya...@shapeblue.com > >> > >> > www.shapeblue.com > >> > >> > 53 Chandos Place, Covent Garden, London WC2N 4HSUK > >> > >> > @shapeblue > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > >> > > > >> > > > >> > > > >> > > -- > >> > > Rafael Weingärtner > >> > > >> > > >> > > >> > daan.hoogl...@shapeblue.com > >> > www.shapeblue.com > >> > 53 Chandos Place, Covent Garden, London WC2N 4HSUK > >> > @shapeblue > >> > > >> > > >> > > >> > > >> >
Re: [DISCUSS] Retirement of midonet plugin
es >> > and >> > >> > eventually deprecate/remove the plugin from the codebase. The >> > roadmap can >> > >> > look something like: >> > >> > >> > >> > - Announce on the MLs that we're planning to do this, send a PR >> > and get >> > >> it >> > >> > accepted >> > >> > >> > >> > - During the release process RM should make this information >> > available to >> > >> > everyone (including voting thread, would be nice to have a >> > shortlog of >> > >> > major changes in the voting email?) >> > >> > >> > >> > - In the release notes and release announcement, note that >> > midonet is no >> > >> > longer included in the default build and is planned to be >> > deprecated >> > >> > >> > >> > - By end of the year, if we've no communication received >> > deprecate and >> > >> > remove the plugin with an announcement >> > >> > >> > >> > >> > >> > I think this should be done with Midonet and any other plugins >> > that are >> > >> > causing issues and are no longer maintained by anyway. >> > >> > >> > >> > >> > >> > Regards. >> > >> > >> > >> > >> > >> > From: Sergey Levitskiy >> > >> > Sent: 15 March 2017 07:00:51 >> > >> > To: dev@cloudstack.apache.org >> > >> > Subject: Re: [DISCUSS] Retirement of midonet plugin >> > >> > >> > >> > I am for: >> > >> > (i) disable the build for the plugin for the next 2 major >> release >> > >> > followed by >> > >> > (ii) remove everything in ACS 4.12 if no one express regrets by >> > then >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > rohit.ya...@shapeblue.com >> > >> > www.shapeblue.com >> > >> > 53 Chandos Place, Covent Garden, London WC2N 4HSUK >> > >> > @shapeblue >> > >> > >> > >> > >> > >> > >> > >> > >> > >> >> > > >> > > >> > > >> > > -- >> > > Rafael Weingärtner >> > >> > >> > >> > daan.hoogl...@shapeblue.com >> > www.shapeblue.com >> > 53 Chandos Place, Covent Garden, London WC2N 4HSUK >> > @shapeblue >> > >> > >> > >> > >>
Re: [DISCUSS] Retirement of midonet plugin
Sounds good :-) Erik man. 27. mar. 2017 kl. 18.03 skrev Will Stevens : > I think we are planning to do something like "at least 6 months" because of > the irregularity of releases. This gives us a date (from when the > announcement was release becomes available) till the PR to remove gets > merged. That PR will then be included in the next release whenever it is. > So if the "time" is 6 months, it could actually be closer to 9 months > before it actually gets removes since the release may not be ready to be > cut at 6 months. > > Does this make sense? It gives us a way to have a date alert when a PR > should be merged rather than trying to track which releases each > decommissioned item is targeted for, which could mess up timing if there is > some long release cycles as well as short ones... > > *Will STEVENS* > Lead Developer > > <https://goo.gl/NYZ8KK> > > On Mon, Mar 27, 2017 at 9:46 AM, Daan Hoogland < > daan.hoogl...@shapeblue.com> > wrote: > > > I am against that > > Strain on the community is not in releases but in time. We already > > guarantee it is at least one minor > > > > On 27/03/17 15:24, "Erik Weber" wrote: > > > > Personally I would be in favour of using releases rather than months > > as time unit. > > Our release schedule is very unpredictable, and it's hard to foresee > > how many releases we've rolled out in 6 months. > > > > Deprecate in the next (4.11?), remove a few releases later (4.13?). > > > > -- > > Erik > > > > On Sat, Mar 18, 2017 at 11:23 PM, Rafael Weingärtner > > wrote: > > > Sorry the delay guys, I have been swapped these last days. > > > > > > In summary, everybody that spoke is in favor of the plugin > > retirement. I am > > > assuming that people who did not present their opinion agree with > > the ones > > > presented here. > > > > > > The process to retire this plugin would be the following: > > > > > >1. Announce in our mailing lists the road map of retirement, a > > data for > > >the final removal should be defined and presented in this road > > map; > > >2. Create a Jira ticket to execute the plugin disabling (is this > > >expression right?!), and of course, a PR to disable the build > > until final > > >deletion; > > >3. Create a Jira ticket to execute the final removal of the > > plugin. The > > >removal should only happen when the defined date comes by; > > >4. Wait patiently while time goes by…. > > >5. When the time comes, create the PR and execute the plugin > > removal. > > > > > > > > > What date would you guys prefer to execute the plugin removal? 3, > 6, > > or 12 > > > months from now? > > > What do you think of this process? Am I missing something else? > > > > > > > > > > > > On Wed, Mar 15, 2017 at 9:13 AM, Jeff Hair > > wrote: > > > > > >> Complete removal of the plugin was my solution to the problem of > > the jar > > >> file's dependencies. If it's not used or maintained, then it > should > > be > > >> removed, in my opinion. Disabling it in the build is a good first > > step. > > >> > > >> *Jeff Hair* > > >> Technical Lead and Software Developer > > >> > > >> Tel: (+354) 415 0200 > > >> j...@greenqloud.com > > >> www.greenqloud.com > > >> > > >> On Wed, Mar 15, 2017 at 8:18 AM, Rohit Yadav < > > rohit.ya...@shapeblue.com> > > >> wrote: > > >> > > >> > +1 as others have noted > > >> > > > >> > > > >> > Disable the plugin from the default build for next few releases > > and > > >> > eventually deprecate/remove the plugin from the codebase. The > > roadmap can > > >> > look something like: > > >> > > > >> > - Announce on the MLs that we're planning to do this, send a PR > > and get > > >> it > > >> > accepted > > >> > > > >> > - During the release process RM should make this information > > available to > >
Re: [DISCUSS] Retirement of midonet plugin
>> > - Announce on the MLs that we're planning to do this, send a PR > > and get > > >> it > > >> > accepted > > >> > > > >> > - During the release process RM should make this information > > available to > > >> > everyone (including voting thread, would be nice to have a > > shortlog of > > >> > major changes in the voting email?) > > >> > > > >> > - In the release notes and release announcement, note that > > midonet is no > > >> > longer included in the default build and is planned to be > > deprecated > > >> > > > >> > - By end of the year, if we've no communication received > > deprecate and > > >> > remove the plugin with an announcement > > >> > > > >> > > > >> > I think this should be done with Midonet and any other plugins > > that are > > >> > causing issues and are no longer maintained by anyway. > > >> > > > >> > > > >> > Regards. > > >> > > > >> > > > >> > From: Sergey Levitskiy > > >> > Sent: 15 March 2017 07:00:51 > > >> > To: dev@cloudstack.apache.org > > >> > Subject: Re: [DISCUSS] Retirement of midonet plugin > > >> > > > >> > I am for: > > >> > (i) disable the build for the plugin for the next 2 major > release > > >> > followed by > > >> > (ii) remove everything in ACS 4.12 if no one express regrets by > > then > > >> > > > >> > > > >> > > > >> > > > >> > rohit.ya...@shapeblue.com > > >> > www.shapeblue.com > > >> > 53 Chandos Place, Covent Garden, London WC2N 4HSUK > > >> > @shapeblue > > >> > > > >> > > > >> > > > >> > > > >> > > > > > > > > > > > > -- > > > Rafael Weingärtner > > > > > > > > daan.hoogl...@shapeblue.com > > www.shapeblue.com > > 53 Chandos Place, Covent Garden, London WC2N 4HSUK > > @shapeblue > > > > > > > > > -- Rafael Weingärtner
Re: [DISCUSS] Retirement of midonet plugin
I think we are planning to do something like "at least 6 months" because of the irregularity of releases. This gives us a date (from when the announcement was release becomes available) till the PR to remove gets merged. That PR will then be included in the next release whenever it is. So if the "time" is 6 months, it could actually be closer to 9 months before it actually gets removes since the release may not be ready to be cut at 6 months. Does this make sense? It gives us a way to have a date alert when a PR should be merged rather than trying to track which releases each decommissioned item is targeted for, which could mess up timing if there is some long release cycles as well as short ones... *Will STEVENS* Lead Developer <https://goo.gl/NYZ8KK> On Mon, Mar 27, 2017 at 9:46 AM, Daan Hoogland wrote: > I am against that > Strain on the community is not in releases but in time. We already > guarantee it is at least one minor > > On 27/03/17 15:24, "Erik Weber" wrote: > > Personally I would be in favour of using releases rather than months > as time unit. > Our release schedule is very unpredictable, and it's hard to foresee > how many releases we've rolled out in 6 months. > > Deprecate in the next (4.11?), remove a few releases later (4.13?). > > -- > Erik > > On Sat, Mar 18, 2017 at 11:23 PM, Rafael Weingärtner > wrote: > > Sorry the delay guys, I have been swapped these last days. > > > > In summary, everybody that spoke is in favor of the plugin > retirement. I am > > assuming that people who did not present their opinion agree with > the ones > > presented here. > > > > The process to retire this plugin would be the following: > > > >1. Announce in our mailing lists the road map of retirement, a > data for > >the final removal should be defined and presented in this road > map; > >2. Create a Jira ticket to execute the plugin disabling (is this > >expression right?!), and of course, a PR to disable the build > until final > >deletion; > >3. Create a Jira ticket to execute the final removal of the > plugin. The > >removal should only happen when the defined date comes by; > >4. Wait patiently while time goes by…. > >5. When the time comes, create the PR and execute the plugin > removal. > > > > > > What date would you guys prefer to execute the plugin removal? 3, 6, > or 12 > > months from now? > > What do you think of this process? Am I missing something else? > > > > > > > > On Wed, Mar 15, 2017 at 9:13 AM, Jeff Hair > wrote: > > > >> Complete removal of the plugin was my solution to the problem of > the jar > >> file's dependencies. If it's not used or maintained, then it should > be > >> removed, in my opinion. Disabling it in the build is a good first > step. > >> > >> *Jeff Hair* > >> Technical Lead and Software Developer > >> > >> Tel: (+354) 415 0200 > >> j...@greenqloud.com > >> www.greenqloud.com > >> > >> On Wed, Mar 15, 2017 at 8:18 AM, Rohit Yadav < > rohit.ya...@shapeblue.com> > >> wrote: > >> > >> > +1 as others have noted > >> > > >> > > >> > Disable the plugin from the default build for next few releases > and > >> > eventually deprecate/remove the plugin from the codebase. The > roadmap can > >> > look something like: > >> > > >> > - Announce on the MLs that we're planning to do this, send a PR > and get > >> it > >> > accepted > >> > > >> > - During the release process RM should make this information > available to > >> > everyone (including voting thread, would be nice to have a > shortlog of > >> > major changes in the voting email?) > >> > > >> > - In the release notes and release announcement, note that > midonet is no > >> > longer included in the default build and is planned to be > deprecated > >> > > >> > - By end of the year, if we've no communication received > deprecate and > >> > remove the plugin with an announcement > >> > > >> > > >> > I think this should be done with Midonet and any other
Re: [DISCUSS] Retirement of midonet plugin
I am against that
Strain on the community is not in releases but in time. We already guarantee it
is at least one minor
On 27/03/17 15:24, "Erik Weber" wrote:
Personally I would be in favour of using releases rather than months
as time unit.
Our release schedule is very unpredictable, and it's hard to foresee
how many releases we've rolled out in 6 months.
Deprecate in the next (4.11?), remove a few releases later (4.13?).
--
Erik
On Sat, Mar 18, 2017 at 11:23 PM, Rafael Weingärtner
wrote:
> Sorry the delay guys, I have been swapped these last days.
>
> In summary, everybody that spoke is in favor of the plugin retirement. I
am
> assuming that people who did not present their opinion agree with the ones
> presented here.
>
> The process to retire this plugin would be the following:
>
>1. Announce in our mailing lists the road map of retirement, a data for
>the final removal should be defined and presented in this road map;
>2. Create a Jira ticket to execute the plugin disabling (is this
>expression right?!), and of course, a PR to disable the build until
final
>deletion;
>3. Create a Jira ticket to execute the final removal of the plugin. The
>removal should only happen when the defined date comes by;
>4. Wait patiently while time goes by….
>5. When the time comes, create the PR and execute the plugin removal.
>
>
> What date would you guys prefer to execute the plugin removal? 3, 6, or 12
> months from now?
> What do you think of this process? Am I missing something else?
>
>
>
> On Wed, Mar 15, 2017 at 9:13 AM, Jeff Hair wrote:
>
>> Complete removal of the plugin was my solution to the problem of the jar
>> file's dependencies. If it's not used or maintained, then it should be
>> removed, in my opinion. Disabling it in the build is a good first step.
>>
>> *Jeff Hair*
>> Technical Lead and Software Developer
>>
>> Tel: (+354) 415 0200
>> j...@greenqloud.com
>> www.greenqloud.com
>>
>> On Wed, Mar 15, 2017 at 8:18 AM, Rohit Yadav
>> wrote:
>>
>> > +1 as others have noted
>> >
>> >
>> > Disable the plugin from the default build for next few releases and
>> > eventually deprecate/remove the plugin from the codebase. The roadmap
can
>> > look something like:
>> >
>> > - Announce on the MLs that we're planning to do this, send a PR and get
>> it
>> > accepted
>> >
>> > - During the release process RM should make this information available
to
>> > everyone (including voting thread, would be nice to have a shortlog of
>> > major changes in the voting email?)
>> >
>> > - In the release notes and release announcement, note that midonet is
no
>> > longer included in the default build and is planned to be deprecated
>> >
>> > - By end of the year, if we've no communication received deprecate and
>> > remove the plugin with an announcement
>> >
>> >
>> > I think this should be done with Midonet and any other plugins that are
>> > causing issues and are no longer maintained by anyway.
>> >
>> >
>> > Regards.
>> >
>> >
>> > From: Sergey Levitskiy
>> > Sent: 15 March 2017 07:00:51
>> > To: dev@cloudstack.apache.org
>> > Subject: Re: [DISCUSS] Retirement of midonet plugin
>> >
>> > I am for:
>> > (i) disable the build for the plugin for the next 2 major release
>> > followed by
>> > (ii) remove everything in ACS 4.12 if no one express regrets by then
>> >
>> >
>> >
>> >
>> > rohit.ya...@shapeblue.com
>> > www.shapeblue.com
>> > 53 Chandos Place, Covent Garden, London WC2N 4HSUK
>> > @shapeblue
>> >
>> >
>> >
>> >
>>
>
>
>
> --
> Rafael Weingärtner
daan.hoogl...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue
Re: [DISCUSS] Retirement of midonet plugin
Personally I would be in favour of using releases rather than months as time unit. Our release schedule is very unpredictable, and it's hard to foresee how many releases we've rolled out in 6 months. Deprecate in the next (4.11?), remove a few releases later (4.13?). -- Erik On Sat, Mar 18, 2017 at 11:23 PM, Rafael Weingärtner wrote: > Sorry the delay guys, I have been swapped these last days. > > In summary, everybody that spoke is in favor of the plugin retirement. I am > assuming that people who did not present their opinion agree with the ones > presented here. > > The process to retire this plugin would be the following: > >1. Announce in our mailing lists the road map of retirement, a data for >the final removal should be defined and presented in this road map; >2. Create a Jira ticket to execute the plugin disabling (is this >expression right?!), and of course, a PR to disable the build until final >deletion; >3. Create a Jira ticket to execute the final removal of the plugin. The >removal should only happen when the defined date comes by; >4. Wait patiently while time goes by…. >5. When the time comes, create the PR and execute the plugin removal. > > > What date would you guys prefer to execute the plugin removal? 3, 6, or 12 > months from now? > What do you think of this process? Am I missing something else? > > > > On Wed, Mar 15, 2017 at 9:13 AM, Jeff Hair wrote: > >> Complete removal of the plugin was my solution to the problem of the jar >> file's dependencies. If it's not used or maintained, then it should be >> removed, in my opinion. Disabling it in the build is a good first step. >> >> *Jeff Hair* >> Technical Lead and Software Developer >> >> Tel: (+354) 415 0200 >> j...@greenqloud.com >> www.greenqloud.com >> >> On Wed, Mar 15, 2017 at 8:18 AM, Rohit Yadav >> wrote: >> >> > +1 as others have noted >> > >> > >> > Disable the plugin from the default build for next few releases and >> > eventually deprecate/remove the plugin from the codebase. The roadmap can >> > look something like: >> > >> > - Announce on the MLs that we're planning to do this, send a PR and get >> it >> > accepted >> > >> > - During the release process RM should make this information available to >> > everyone (including voting thread, would be nice to have a shortlog of >> > major changes in the voting email?) >> > >> > - In the release notes and release announcement, note that midonet is no >> > longer included in the default build and is planned to be deprecated >> > >> > - By end of the year, if we've no communication received deprecate and >> > remove the plugin with an announcement >> > >> > >> > I think this should be done with Midonet and any other plugins that are >> > causing issues and are no longer maintained by anyway. >> > >> > >> > Regards. >> > >> > >> > From: Sergey Levitskiy >> > Sent: 15 March 2017 07:00:51 >> > To: dev@cloudstack.apache.org >> > Subject: Re: [DISCUSS] Retirement of midonet plugin >> > >> > I am for: >> > (i) disable the build for the plugin for the next 2 major release >> > followed by >> > (ii) remove everything in ACS 4.12 if no one express regrets by then >> > >> > >> > >> > >> > rohit.ya...@shapeblue.com >> > www.shapeblue.com >> > 53 Chandos Place, Covent Garden, London WC2N 4HSUK >> > @shapeblue >> > >> > >> > >> > >> > > > > -- > Rafael Weingärtner
Re: [DISCUSS] Retirement of midonet plugin
Sorry for the delay guys. I have been a little busy lately. I will write down a wiki page detailing the code retirement steps. Then, I will proceed and kick off the Midonet plugin retirement process. On Mon, Mar 20, 2017 at 3:39 AM, Daan Hoogland wrote: > Don’t worry Marty, non-committers/-coders will be heard here as well. > > Good point @swill I think we have enough wording to call this a policy > now… As so far, no objections of any kind have been raised I also think it > is now official unless someone now starts shouting. Here is a semi-formal > definition of the procedure. > > Code that is not maintained and breaks the build will be phased out > according to the following retirement procedure: > > 1. An announce in our mailing lists the road map of retirement, a data for > the final removal should be defined and presented in this road map; This > will be in terms of “The firsts release after /mm/dd” > 2. If no objection arises or no one volunteers to maintain the code, a > Jira ticket to disable of the code is created. > 3. A patch to disable the code in the build will be created. > 4. The patch is applied and released with the next x.y.0 release. > 5. A Jira ticket to execute the final removal of the code is created. > 6. A patch for the definite removal of the code is created. > 7. The patch will be applied 6 months after the x.y.0 release is announced > and thus be release with x.(y+n).0 (n probably being 1 but could be higher) > > > On 19/03/17 18:53, "Marty Godsey" wrote: > > I know that I am not a committer (I am a systems, networking guy, I > don’t "code") but I agree with Will. Giving the community at large some > time to yell if they are using is good. > > Regards, > Marty Godsey > Principal Engineer > nSource Solutions, LLC > > -Original Message- > From: Will Stevens [mailto:williamstev...@gmail.com] > Sent: Sunday, March 19, 2017 7:39 AM > To: dev@cloudstack.apache.org > Subject: Re: [DISCUSS] Retirement of midonet plugin > > I think there needs to be at least 6 months between the disable code > being released and the delete PR being merged. I feel like the clock has to > start only when the disable code is generally available in a stable release > (not when it is merged). > > On Mar 19, 2017 6:47 AM, "Daan Hoogland" > wrote: > > > You are spot on. We can add a due date for the final removal I think. > > Let’s not add a target version, I’d say. > > > > On 18/03/17 23:23, "Rafael Weingärtner" > > > wrote: > > > > Sorry the delay guys, I have been swapped these last days. > > > > In summary, everybody that spoke is in favor of the plugin > retirement. > > I am > > assuming that people who did not present their opinion agree with > > the ones > > presented here. > > > > The process to retire this plugin would be the following: > > > >1. Announce in our mailing lists the road map of retirement, a > > data for > >the final removal should be defined and presented in this > road map; > >2. Create a Jira ticket to execute the plugin disabling (is > this > >expression right?!), and of course, a PR to disable the build > > until final > >deletion; > >3. Create a Jira ticket to execute the final removal of the > plugin. > > The > >removal should only happen when the defined date comes by; > >4. Wait patiently while time goes by…. > >5. When the time comes, create the PR and execute the plugin > > removal. > > > > > > What date would you guys prefer to execute the plugin removal? 3, > > 6, or 12 > > months from now? > > What do you think of this process? Am I missing something else? > > > > > > > > On Wed, Mar 15, 2017 at 9:13 AM, Jeff Hair > > wrote: > > > > > Complete removal of the plugin was my solution to the problem > of > > the jar > > > file's dependencies. If it's not used or maintained, then it > > should be > > > removed, in my opinion. Disabling it in the build is a good > > first step. > > > > > > *Jeff Hair* > > > Technical Lead and Software Developer > > > > > > Tel: (+354) 415 0200 > > > j...@greenqloud.com >
Re: [DISCUSS] Retirement of midonet plugin
Don’t worry Marty, non-committers/-coders will be heard here as well. Good point @swill I think we have enough wording to call this a policy now… As so far, no objections of any kind have been raised I also think it is now official unless someone now starts shouting. Here is a semi-formal definition of the procedure. Code that is not maintained and breaks the build will be phased out according to the following retirement procedure: 1. An announce in our mailing lists the road map of retirement, a data for the final removal should be defined and presented in this road map; This will be in terms of “The firsts release after /mm/dd” 2. If no objection arises or no one volunteers to maintain the code, a Jira ticket to disable of the code is created. 3. A patch to disable the code in the build will be created. 4. The patch is applied and released with the next x.y.0 release. 5. A Jira ticket to execute the final removal of the code is created. 6. A patch for the definite removal of the code is created. 7. The patch will be applied 6 months after the x.y.0 release is announced and thus be release with x.(y+n).0 (n probably being 1 but could be higher) On 19/03/17 18:53, "Marty Godsey" wrote: I know that I am not a committer (I am a systems, networking guy, I don’t "code") but I agree with Will. Giving the community at large some time to yell if they are using is good. Regards, Marty Godsey Principal Engineer nSource Solutions, LLC -Original Message- From: Will Stevens [mailto:williamstev...@gmail.com] Sent: Sunday, March 19, 2017 7:39 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Retirement of midonet plugin I think there needs to be at least 6 months between the disable code being released and the delete PR being merged. I feel like the clock has to start only when the disable code is generally available in a stable release (not when it is merged). On Mar 19, 2017 6:47 AM, "Daan Hoogland" wrote: > You are spot on. We can add a due date for the final removal I think. > Let’s not add a target version, I’d say. > > On 18/03/17 23:23, "Rafael Weingärtner" > wrote: > > Sorry the delay guys, I have been swapped these last days. > > In summary, everybody that spoke is in favor of the plugin retirement. > I am > assuming that people who did not present their opinion agree with > the ones > presented here. > > The process to retire this plugin would be the following: > >1. Announce in our mailing lists the road map of retirement, a > data for >the final removal should be defined and presented in this road map; >2. Create a Jira ticket to execute the plugin disabling (is this >expression right?!), and of course, a PR to disable the build > until final >deletion; >3. Create a Jira ticket to execute the final removal of the plugin. > The >removal should only happen when the defined date comes by; >4. Wait patiently while time goes by…. >5. When the time comes, create the PR and execute the plugin > removal. > > > What date would you guys prefer to execute the plugin removal? 3, > 6, or 12 > months from now? > What do you think of this process? Am I missing something else? > > > > On Wed, Mar 15, 2017 at 9:13 AM, Jeff Hair > wrote: > > > Complete removal of the plugin was my solution to the problem of > the jar > > file's dependencies. If it's not used or maintained, then it > should be > > removed, in my opinion. Disabling it in the build is a good > first step. > > > > *Jeff Hair* > > Technical Lead and Software Developer > > > > Tel: (+354) 415 0200 > > j...@greenqloud.com > > www.greenqloud.com > > > > On Wed, Mar 15, 2017 at 8:18 AM, Rohit Yadav < > rohit.ya...@shapeblue.com> > > wrote: > > > > > +1 as others have noted > > > > > > > > > Disable the plugin from the default build for next few releases and > > > eventually deprecate/remove the plugin from the codebase. The > roadmap can > > > look something like: > > > > > > - Announce on the MLs that we're planning to do this, send a > PR and get > > it > > > accepted > > >
RE: [DISCUSS] Retirement of midonet plugin
I know that I am not a committer (I am a systems, networking guy, I don’t "code") but I agree with Will. Giving the community at large some time to yell if they are using is good. Regards, Marty Godsey Principal Engineer nSource Solutions, LLC -Original Message- From: Will Stevens [mailto:williamstev...@gmail.com] Sent: Sunday, March 19, 2017 7:39 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Retirement of midonet plugin I think there needs to be at least 6 months between the disable code being released and the delete PR being merged. I feel like the clock has to start only when the disable code is generally available in a stable release (not when it is merged). On Mar 19, 2017 6:47 AM, "Daan Hoogland" wrote: > You are spot on. We can add a due date for the final removal I think. > Let’s not add a target version, I’d say. > > On 18/03/17 23:23, "Rafael Weingärtner" > wrote: > > Sorry the delay guys, I have been swapped these last days. > > In summary, everybody that spoke is in favor of the plugin retirement. > I am > assuming that people who did not present their opinion agree with > the ones > presented here. > > The process to retire this plugin would be the following: > >1. Announce in our mailing lists the road map of retirement, a > data for >the final removal should be defined and presented in this road map; >2. Create a Jira ticket to execute the plugin disabling (is this >expression right?!), and of course, a PR to disable the build > until final >deletion; >3. Create a Jira ticket to execute the final removal of the plugin. > The >removal should only happen when the defined date comes by; >4. Wait patiently while time goes by…. >5. When the time comes, create the PR and execute the plugin > removal. > > > What date would you guys prefer to execute the plugin removal? 3, > 6, or 12 > months from now? > What do you think of this process? Am I missing something else? > > > > On Wed, Mar 15, 2017 at 9:13 AM, Jeff Hair > wrote: > > > Complete removal of the plugin was my solution to the problem of > the jar > > file's dependencies. If it's not used or maintained, then it > should be > > removed, in my opinion. Disabling it in the build is a good > first step. > > > > *Jeff Hair* > > Technical Lead and Software Developer > > > > Tel: (+354) 415 0200 > > j...@greenqloud.com > > www.greenqloud.com > > > > On Wed, Mar 15, 2017 at 8:18 AM, Rohit Yadav < > rohit.ya...@shapeblue.com> > > wrote: > > > > > +1 as others have noted > > > > > > > > > Disable the plugin from the default build for next few releases and > > > eventually deprecate/remove the plugin from the codebase. The > roadmap can > > > look something like: > > > > > > - Announce on the MLs that we're planning to do this, send a > PR and get > > it > > > accepted > > > > > > - During the release process RM should make this information > available to > > > everyone (including voting thread, would be nice to have a > shortlog of > > > major changes in the voting email?) > > > > > > - In the release notes and release announcement, note that > midonet is no > > > longer included in the default build and is planned to be > deprecated > > > > > > - By end of the year, if we've no communication received > deprecate and > > > remove the plugin with an announcement > > > > > > > > > I think this should be done with Midonet and any other plugins > that are > > > causing issues and are no longer maintained by anyway. > > > > > > > > > Regards. > > > > > > > > > From: Sergey Levitskiy > > > Sent: 15 March 2017 07:00:51 > > > To: dev@cloudstack.apache.org > > > Subject: Re: [DISCUSS] Retirement of midonet plugin > > > > > > I am for: > > > (i) disable the build for the plugin for the next 2 major release > > > followed by > > > (ii) remove everything in ACS 4.12 if no one express regrets > by then > > > > > > > > > > > > > > > rohit.ya...@shapeblue.com > > > www.shapeblue.com > > > 53 Chandos Place, Covent Garden, London WC2N 4HSUK > > > @shapeblue > > > > > > > > > > > > > > > > > > -- > Rafael Weingärtner > > > > daan.hoogl...@shapeblue.com > www.shapeblue.com > 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue > > > >
Re: [DISCUSS] Retirement of midonet plugin
I think there needs to be at least 6 months between the disable code being released and the delete PR being merged. I feel like the clock has to start only when the disable code is generally available in a stable release (not when it is merged). On Mar 19, 2017 6:47 AM, "Daan Hoogland" wrote: > You are spot on. We can add a due date for the final removal I think. > Let’s not add a target version, I’d say. > > On 18/03/17 23:23, "Rafael Weingärtner" > wrote: > > Sorry the delay guys, I have been swapped these last days. > > In summary, everybody that spoke is in favor of the plugin retirement. > I am > assuming that people who did not present their opinion agree with the > ones > presented here. > > The process to retire this plugin would be the following: > >1. Announce in our mailing lists the road map of retirement, a data > for >the final removal should be defined and presented in this road map; >2. Create a Jira ticket to execute the plugin disabling (is this >expression right?!), and of course, a PR to disable the build until > final >deletion; >3. Create a Jira ticket to execute the final removal of the plugin. > The >removal should only happen when the defined date comes by; >4. Wait patiently while time goes by…. >5. When the time comes, create the PR and execute the plugin > removal. > > > What date would you guys prefer to execute the plugin removal? 3, 6, > or 12 > months from now? > What do you think of this process? Am I missing something else? > > > > On Wed, Mar 15, 2017 at 9:13 AM, Jeff Hair > wrote: > > > Complete removal of the plugin was my solution to the problem of the > jar > > file's dependencies. If it's not used or maintained, then it should > be > > removed, in my opinion. Disabling it in the build is a good first > step. > > > > *Jeff Hair* > > Technical Lead and Software Developer > > > > Tel: (+354) 415 0200 > > j...@greenqloud.com > > www.greenqloud.com > > > > On Wed, Mar 15, 2017 at 8:18 AM, Rohit Yadav < > rohit.ya...@shapeblue.com> > > wrote: > > > > > +1 as others have noted > > > > > > > > > Disable the plugin from the default build for next few releases and > > > eventually deprecate/remove the plugin from the codebase. The > roadmap can > > > look something like: > > > > > > - Announce on the MLs that we're planning to do this, send a PR > and get > > it > > > accepted > > > > > > - During the release process RM should make this information > available to > > > everyone (including voting thread, would be nice to have a > shortlog of > > > major changes in the voting email?) > > > > > > - In the release notes and release announcement, note that midonet > is no > > > longer included in the default build and is planned to be > deprecated > > > > > > - By end of the year, if we've no communication received deprecate > and > > > remove the plugin with an announcement > > > > > > > > > I think this should be done with Midonet and any other plugins > that are > > > causing issues and are no longer maintained by anyway. > > > > > > > > > Regards. > > > > > > > > > From: Sergey Levitskiy > > > Sent: 15 March 2017 07:00:51 > > > To: dev@cloudstack.apache.org > > > Subject: Re: [DISCUSS] Retirement of midonet plugin > > > > > > I am for: > > > (i) disable the build for the plugin for the next 2 major release > > > followed by > > > (ii) remove everything in ACS 4.12 if no one express regrets by > then > > > > > > > > > > > > > > > rohit.ya...@shapeblue.com > > > www.shapeblue.com > > > 53 Chandos Place, Covent Garden, London WC2N 4HSUK > > > @shapeblue > > > > > > > > > > > > > > > > > > -- > Rafael Weingärtner > > > > daan.hoogl...@shapeblue.com > www.shapeblue.com > 53 Chandos Place, Covent Garden, London WC2N 4HSUK > @shapeblue > > > >
Re: [DISCUSS] Retirement of midonet plugin
And I forgot to mention that I an +1 on this process... On Mar 19, 2017 7:39 AM, "Will Stevens" wrote: > I think there needs to be at least 6 months between the disable code being > released and the delete PR being merged. I feel like the clock has to start > only when the disable code is generally available in a stable release (not > when it is merged). > > On Mar 19, 2017 6:47 AM, "Daan Hoogland" > wrote: > >> You are spot on. We can add a due date for the final removal I think. >> Let’s not add a target version, I’d say. >> >> On 18/03/17 23:23, "Rafael Weingärtner" >> wrote: >> >> Sorry the delay guys, I have been swapped these last days. >> >> In summary, everybody that spoke is in favor of the plugin >> retirement. I am >> assuming that people who did not present their opinion agree with the >> ones >> presented here. >> >> The process to retire this plugin would be the following: >> >>1. Announce in our mailing lists the road map of retirement, a >> data for >>the final removal should be defined and presented in this road map; >>2. Create a Jira ticket to execute the plugin disabling (is this >>expression right?!), and of course, a PR to disable the build >> until final >>deletion; >>3. Create a Jira ticket to execute the final removal of the >> plugin. The >>removal should only happen when the defined date comes by; >>4. Wait patiently while time goes by…. >>5. When the time comes, create the PR and execute the plugin >> removal. >> >> >> What date would you guys prefer to execute the plugin removal? 3, 6, >> or 12 >> months from now? >> What do you think of this process? Am I missing something else? >> >> >> >> On Wed, Mar 15, 2017 at 9:13 AM, Jeff Hair >> wrote: >> >> > Complete removal of the plugin was my solution to the problem of >> the jar >> > file's dependencies. If it's not used or maintained, then it should >> be >> > removed, in my opinion. Disabling it in the build is a good first >> step. >> > >> > *Jeff Hair* >> > Technical Lead and Software Developer >> > >> > Tel: (+354) 415 0200 >> > j...@greenqloud.com >> > www.greenqloud.com >> > >> > On Wed, Mar 15, 2017 at 8:18 AM, Rohit Yadav < >> rohit.ya...@shapeblue.com> >> > wrote: >> > >> > > +1 as others have noted >> > > >> > > >> > > Disable the plugin from the default build for next few releases >> and >> > > eventually deprecate/remove the plugin from the codebase. The >> roadmap can >> > > look something like: >> > > >> > > - Announce on the MLs that we're planning to do this, send a PR >> and get >> > it >> > > accepted >> > > >> > > - During the release process RM should make this information >> available to >> > > everyone (including voting thread, would be nice to have a >> shortlog of >> > > major changes in the voting email?) >> > > >> > > - In the release notes and release announcement, note that >> midonet is no >> > > longer included in the default build and is planned to be >> deprecated >> > > >> > > - By end of the year, if we've no communication received >> deprecate and >> > > remove the plugin with an announcement >> > > >> > > >> > > I think this should be done with Midonet and any other plugins >> that are >> > > causing issues and are no longer maintained by anyway. >> > > >> > > >> > > Regards. >> > > >> > > >> > > From: Sergey Levitskiy >> > > Sent: 15 March 2017 07:00:51 >> > > To: dev@cloudstack.apache.org >> > > Subject: Re: [DISCUSS] Retirement of midonet plugin >> > > >> > > I am for: >> > > (i) disable the build for the plugin for the next 2 major release >> > > followed by >> > > (ii) remove everything in ACS 4.12 if no one express regrets by >> then >> > > >> > > >> > > >> > > >> > > rohit.ya...@shapeblue.com >> > > www.shapeblue.com >> > > 53 Chandos Place, Covent Garden, London WC2N 4HSUK >> > > @shapeblue >> > > >> > > >> > > >> > > >> > >> >> >> >> -- >> Rafael Weingärtner >> >> >> >> daan.hoogl...@shapeblue.com >> www.shapeblue.com >> 53 Chandos Place, Covent Garden, London WC2N 4HSUK >> @shapeblue >> >> >> >>
Re: [DISCUSS] Retirement of midonet plugin
You are spot on. We can add a due date for the final removal I think. Let’s not
add a target version, I’d say.
On 18/03/17 23:23, "Rafael Weingärtner" wrote:
Sorry the delay guys, I have been swapped these last days.
In summary, everybody that spoke is in favor of the plugin retirement. I am
assuming that people who did not present their opinion agree with the ones
presented here.
The process to retire this plugin would be the following:
1. Announce in our mailing lists the road map of retirement, a data for
the final removal should be defined and presented in this road map;
2. Create a Jira ticket to execute the plugin disabling (is this
expression right?!), and of course, a PR to disable the build until final
deletion;
3. Create a Jira ticket to execute the final removal of the plugin. The
removal should only happen when the defined date comes by;
4. Wait patiently while time goes by….
5. When the time comes, create the PR and execute the plugin removal.
What date would you guys prefer to execute the plugin removal? 3, 6, or 12
months from now?
What do you think of this process? Am I missing something else?
On Wed, Mar 15, 2017 at 9:13 AM, Jeff Hair wrote:
> Complete removal of the plugin was my solution to the problem of the jar
> file's dependencies. If it's not used or maintained, then it should be
> removed, in my opinion. Disabling it in the build is a good first step.
>
> *Jeff Hair*
> Technical Lead and Software Developer
>
> Tel: (+354) 415 0200
> j...@greenqloud.com
> www.greenqloud.com
>
> On Wed, Mar 15, 2017 at 8:18 AM, Rohit Yadav
> wrote:
>
> > +1 as others have noted
> >
> >
> > Disable the plugin from the default build for next few releases and
> > eventually deprecate/remove the plugin from the codebase. The roadmap
can
> > look something like:
> >
> > - Announce on the MLs that we're planning to do this, send a PR and get
> it
> > accepted
> >
> > - During the release process RM should make this information available
to
> > everyone (including voting thread, would be nice to have a shortlog of
> > major changes in the voting email?)
> >
> > - In the release notes and release announcement, note that midonet is no
> > longer included in the default build and is planned to be deprecated
> >
> > - By end of the year, if we've no communication received deprecate and
> > remove the plugin with an announcement
> >
> >
> > I think this should be done with Midonet and any other plugins that are
> > causing issues and are no longer maintained by anyway.
> >
> >
> > Regards.
> >
> >
> > From: Sergey Levitskiy
> > Sent: 15 March 2017 07:00:51
> > To: dev@cloudstack.apache.org
> > Subject: Re: [DISCUSS] Retirement of midonet plugin
> >
> > I am for:
> > (i) disable the build for the plugin for the next 2 major release
> > followed by
> > (ii) remove everything in ACS 4.12 if no one express regrets by then
> >
> >
> >
> >
> > rohit.ya...@shapeblue.com
> > www.shapeblue.com
> > 53 Chandos Place, Covent Garden, London WC2N 4HSUK
> > @shapeblue
> >
> >
> >
> >
>
--
Rafael Weingärtner
daan.hoogl...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue
Re: [DISCUSS] Retirement of midonet plugin
Sorry the delay guys, I have been swapped these last days. In summary, everybody that spoke is in favor of the plugin retirement. I am assuming that people who did not present their opinion agree with the ones presented here. The process to retire this plugin would be the following: 1. Announce in our mailing lists the road map of retirement, a data for the final removal should be defined and presented in this road map; 2. Create a Jira ticket to execute the plugin disabling (is this expression right?!), and of course, a PR to disable the build until final deletion; 3. Create a Jira ticket to execute the final removal of the plugin. The removal should only happen when the defined date comes by; 4. Wait patiently while time goes by…. 5. When the time comes, create the PR and execute the plugin removal. What date would you guys prefer to execute the plugin removal? 3, 6, or 12 months from now? What do you think of this process? Am I missing something else? On Wed, Mar 15, 2017 at 9:13 AM, Jeff Hair wrote: > Complete removal of the plugin was my solution to the problem of the jar > file's dependencies. If it's not used or maintained, then it should be > removed, in my opinion. Disabling it in the build is a good first step. > > *Jeff Hair* > Technical Lead and Software Developer > > Tel: (+354) 415 0200 > j...@greenqloud.com > www.greenqloud.com > > On Wed, Mar 15, 2017 at 8:18 AM, Rohit Yadav > wrote: > > > +1 as others have noted > > > > > > Disable the plugin from the default build for next few releases and > > eventually deprecate/remove the plugin from the codebase. The roadmap can > > look something like: > > > > - Announce on the MLs that we're planning to do this, send a PR and get > it > > accepted > > > > - During the release process RM should make this information available to > > everyone (including voting thread, would be nice to have a shortlog of > > major changes in the voting email?) > > > > - In the release notes and release announcement, note that midonet is no > > longer included in the default build and is planned to be deprecated > > > > - By end of the year, if we've no communication received deprecate and > > remove the plugin with an announcement > > > > > > I think this should be done with Midonet and any other plugins that are > > causing issues and are no longer maintained by anyway. > > > > > > Regards. > > > > > > From: Sergey Levitskiy > > Sent: 15 March 2017 07:00:51 > > To: dev@cloudstack.apache.org > > Subject: Re: [DISCUSS] Retirement of midonet plugin > > > > I am for: > > (i) disable the build for the plugin for the next 2 major release > > followed by > > (ii) remove everything in ACS 4.12 if no one express regrets by then > > > > > > > > > > rohit.ya...@shapeblue.com > > www.shapeblue.com > > 53 Chandos Place, Covent Garden, London WC2N 4HSUK > > @shapeblue > > > > > > > > > -- Rafael Weingärtner
Re: [DISCUSS] Retirement of midonet plugin
Complete removal of the plugin was my solution to the problem of the jar file's dependencies. If it's not used or maintained, then it should be removed, in my opinion. Disabling it in the build is a good first step. *Jeff Hair* Technical Lead and Software Developer Tel: (+354) 415 0200 j...@greenqloud.com www.greenqloud.com On Wed, Mar 15, 2017 at 8:18 AM, Rohit Yadav wrote: > +1 as others have noted > > > Disable the plugin from the default build for next few releases and > eventually deprecate/remove the plugin from the codebase. The roadmap can > look something like: > > - Announce on the MLs that we're planning to do this, send a PR and get it > accepted > > - During the release process RM should make this information available to > everyone (including voting thread, would be nice to have a shortlog of > major changes in the voting email?) > > - In the release notes and release announcement, note that midonet is no > longer included in the default build and is planned to be deprecated > > - By end of the year, if we've no communication received deprecate and > remove the plugin with an announcement > > > I think this should be done with Midonet and any other plugins that are > causing issues and are no longer maintained by anyway. > > > Regards. > > > From: Sergey Levitskiy > Sent: 15 March 2017 07:00:51 > To: dev@cloudstack.apache.org > Subject: Re: [DISCUSS] Retirement of midonet plugin > > I am for: > (i) disable the build for the plugin for the next 2 major release > followed by > (ii) remove everything in ACS 4.12 if no one express regrets by then > > > > > rohit.ya...@shapeblue.com > www.shapeblue.com > 53 Chandos Place, Covent Garden, London WC2N 4HSUK > @shapeblue > > > >
Re: [DISCUSS] Retirement of midonet plugin
+1 as others have noted Disable the plugin from the default build for next few releases and eventually deprecate/remove the plugin from the codebase. The roadmap can look something like: - Announce on the MLs that we're planning to do this, send a PR and get it accepted - During the release process RM should make this information available to everyone (including voting thread, would be nice to have a shortlog of major changes in the voting email?) - In the release notes and release announcement, note that midonet is no longer included in the default build and is planned to be deprecated - By end of the year, if we've no communication received deprecate and remove the plugin with an announcement I think this should be done with Midonet and any other plugins that are causing issues and are no longer maintained by anyway. Regards. From: Sergey Levitskiy Sent: 15 March 2017 07:00:51 To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Retirement of midonet plugin I am for: (i) disable the build for the plugin for the next 2 major release followed by (ii) remove everything in ACS 4.12 if no one express regrets by then rohit.ya...@shapeblue.com www.shapeblue.com 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue
Re: [DISCUSS] Retirement of midonet plugin
Disable with a maven profile to enable? mvn –P withThisOrThat
Delete but only after a time span. A number of releases is not any kind of
promise in our case.
On 15/03/17 04:40, "Tutkowski, Mike" wrote:
Disable, then delete works for me, too.
On 3/14/17, 7:49 PM, "Simon Weller" wrote:
I agree with Sergey and Will. Let's disable it first.
Simon Weller/615-312-6068
-Original Message-
From: Rafael Weingärtner [rafaelweingart...@gmail.com]
Received: Tuesday, 14 Mar 2017, 9:10PM
To: dev@cloudstack.apache.org [dev@cloudstack.apache.org]
Subject: [DISCUSS] Retirement of midonet plugin
Dear ACS fellows,
Recently there have been two threads asking and discussing the “midonet”
integration with Apache CloudStack (ACS) [1-2].
After quite some discussions, we noticed that despite having some people
willing to use it, the plugin has never been fully developed by its
vendor
(Midokura). Further, nobody else has put the effort on fully testing and
finishing its implementation. It seems that the plugin was incorporated
into our code base without being fully finished. Moreover, I have asked
around at the Midonet community, and the java client they use has
changed
quite a bit from the one we use.
It begs the question, if it does not work, why do we advertise such
integration? [3]. In my opinion, it would be great if we had such
integration; however, we as a community of individuals cannot bear the
burden with the cost of such task by ourselves.
It seems we have three options; (i) disable the build for the plugin and
let the code create its own mystic throughout time in ACS code base;
(ii)
remove everything; or (iii) someone that may benefit from this plugin
jumps
in and concludes the integration with Midonet using their new client.
There maybe other solutions that I am not seeing. So, @Devs yours
thoughts
and comments are welcome ;)
[1]
http://cloudstack.markmail.org/thread/qyedle5jb2c34gsc#query:+page:1+mid:xn2zq2v3eim5vl2q+state:results
[2]
http://cloudstack.markmail.org/message/rewzk4v7dgzpsxkm?q=midonet+order:date-backward&page=1#query:midonet%20order%3Adate-backward+page:1+mid:i563khxlginf6smg+state:results
[3] http://docs.cloudstack.apache.org/en/latest/networking/midonet.html
--
Rafael Weingärtner
daan.hoogl...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue
Re: [DISCUSS] Retirement of midonet plugin
Disable, then delete works for me, too. On 3/14/17, 7:49 PM, "Simon Weller" wrote: I agree with Sergey and Will. Let's disable it first. Simon Weller/615-312-6068 -Original Message- From: Rafael Weingärtner [rafaelweingart...@gmail.com] Received: Tuesday, 14 Mar 2017, 9:10PM To: dev@cloudstack.apache.org [dev@cloudstack.apache.org] Subject: [DISCUSS] Retirement of midonet plugin Dear ACS fellows, Recently there have been two threads asking and discussing the “midonet” integration with Apache CloudStack (ACS) [1-2]. After quite some discussions, we noticed that despite having some people willing to use it, the plugin has never been fully developed by its vendor (Midokura). Further, nobody else has put the effort on fully testing and finishing its implementation. It seems that the plugin was incorporated into our code base without being fully finished. Moreover, I have asked around at the Midonet community, and the java client they use has changed quite a bit from the one we use. It begs the question, if it does not work, why do we advertise such integration? [3]. In my opinion, it would be great if we had such integration; however, we as a community of individuals cannot bear the burden with the cost of such task by ourselves. It seems we have three options; (i) disable the build for the plugin and let the code create its own mystic throughout time in ACS code base; (ii) remove everything; or (iii) someone that may benefit from this plugin jumps in and concludes the integration with Midonet using their new client. There maybe other solutions that I am not seeing. So, @Devs yours thoughts and comments are welcome ;) [1] http://cloudstack.markmail.org/thread/qyedle5jb2c34gsc#query:+page:1+mid:xn2zq2v3eim5vl2q+state:results [2] http://cloudstack.markmail.org/message/rewzk4v7dgzpsxkm?q=midonet+order:date-backward&page=1#query:midonet%20order%3Adate-backward+page:1+mid:i563khxlginf6smg+state:results [3] http://docs.cloudstack.apache.org/en/latest/networking/midonet.html -- Rafael Weingärtner
RE: [DISCUSS] Retirement of midonet plugin
I agree with Sergey and Will. Let's disable it first. Simon Weller/615-312-6068 -Original Message- From: Rafael Weingärtner [rafaelweingart...@gmail.com] Received: Tuesday, 14 Mar 2017, 9:10PM To: dev@cloudstack.apache.org [dev@cloudstack.apache.org] Subject: [DISCUSS] Retirement of midonet plugin Dear ACS fellows, Recently there have been two threads asking and discussing the “midonet” integration with Apache CloudStack (ACS) [1-2]. After quite some discussions, we noticed that despite having some people willing to use it, the plugin has never been fully developed by its vendor (Midokura). Further, nobody else has put the effort on fully testing and finishing its implementation. It seems that the plugin was incorporated into our code base without being fully finished. Moreover, I have asked around at the Midonet community, and the java client they use has changed quite a bit from the one we use. It begs the question, if it does not work, why do we advertise such integration? [3]. In my opinion, it would be great if we had such integration; however, we as a community of individuals cannot bear the burden with the cost of such task by ourselves. It seems we have three options; (i) disable the build for the plugin and let the code create its own mystic throughout time in ACS code base; (ii) remove everything; or (iii) someone that may benefit from this plugin jumps in and concludes the integration with Midonet using their new client. There maybe other solutions that I am not seeing. So, @Devs yours thoughts and comments are welcome ;) [1] http://cloudstack.markmail.org/thread/qyedle5jb2c34gsc#query:+page:1+mid:xn2zq2v3eim5vl2q+state:results [2] http://cloudstack.markmail.org/message/rewzk4v7dgzpsxkm?q=midonet+order:date-backward&page=1#query:midonet%20order%3Adate-backward+page:1+mid:i563khxlginf6smg+state:results [3] http://docs.cloudstack.apache.org/en/latest/networking/midonet.html -- Rafael Weingärtner
Re: [DISCUSS] Retirement of midonet plugin
I think we approach these with a disable, then delete approach. Disable for one or two releases and if no one steps in to revive it in that period, we delete it. On Mar 14, 2017 9:10 PM, "Rafael Weingärtner" wrote: Dear ACS fellows, Recently there have been two threads asking and discussing the “midonet” integration with Apache CloudStack (ACS) [1-2]. After quite some discussions, we noticed that despite having some people willing to use it, the plugin has never been fully developed by its vendor (Midokura). Further, nobody else has put the effort on fully testing and finishing its implementation. It seems that the plugin was incorporated into our code base without being fully finished. Moreover, I have asked around at the Midonet community, and the java client they use has changed quite a bit from the one we use. It begs the question, if it does not work, why do we advertise such integration? [3]. In my opinion, it would be great if we had such integration; however, we as a community of individuals cannot bear the burden with the cost of such task by ourselves. It seems we have three options; (i) disable the build for the plugin and let the code create its own mystic throughout time in ACS code base; (ii) remove everything; or (iii) someone that may benefit from this plugin jumps in and concludes the integration with Midonet using their new client. There maybe other solutions that I am not seeing. So, @Devs yours thoughts and comments are welcome ;) [1] http://cloudstack.markmail.org/thread/qyedle5jb2c34gsc#query:+page:1+mid: xn2zq2v3eim5vl2q+state:results [2] http://cloudstack.markmail.org/message/rewzk4v7dgzpsxkm? q=midonet+order:date-backward&page=1#query:midonet%20order% 3Adate-backward+page:1+mid:i563khxlginf6smg+state:results [3] http://docs.cloudstack.apache.org/en/latest/networking/midonet.html -- Rafael Weingärtner
Re: [DISCUSS] Retirement of midonet plugin
I am for: (i) disable the build for the plugin for the next 2 major release followed by (ii) remove everything in ACS 4.12 if no one express regrets by then
[DISCUSS] Retirement of midonet plugin
Dear ACS fellows, Recently there have been two threads asking and discussing the “midonet” integration with Apache CloudStack (ACS) [1-2]. After quite some discussions, we noticed that despite having some people willing to use it, the plugin has never been fully developed by its vendor (Midokura). Further, nobody else has put the effort on fully testing and finishing its implementation. It seems that the plugin was incorporated into our code base without being fully finished. Moreover, I have asked around at the Midonet community, and the java client they use has changed quite a bit from the one we use. It begs the question, if it does not work, why do we advertise such integration? [3]. In my opinion, it would be great if we had such integration; however, we as a community of individuals cannot bear the burden with the cost of such task by ourselves. It seems we have three options; (i) disable the build for the plugin and let the code create its own mystic throughout time in ACS code base; (ii) remove everything; or (iii) someone that may benefit from this plugin jumps in and concludes the integration with Midonet using their new client. There maybe other solutions that I am not seeing. So, @Devs yours thoughts and comments are welcome ;) [1] http://cloudstack.markmail.org/thread/qyedle5jb2c34gsc#query:+page:1+mid:xn2zq2v3eim5vl2q+state:results [2] http://cloudstack.markmail.org/message/rewzk4v7dgzpsxkm?q=midonet+order:date-backward&page=1#query:midonet%20order%3Adate-backward+page:1+mid:i563khxlginf6smg+state:results [3] http://docs.cloudstack.apache.org/en/latest/networking/midonet.html -- Rafael Weingärtner
