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
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
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 > > > >
[GitHub] cloudstack issue #1582: CLOUDSTACK-9408 for the move away from download.clou...
Github user karuturi commented on the issue: https://github.com/apache/cloudstack/pull/1582 I want this to be updated to use download.cloudstack.org instead of cloudstack.apt-get.eu. I will send a PR with URL changes to this PR. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] cloudstack issue #1994: CLOUDSTACK-9827: Storage tags stored in multiple pla...
Github user karuturi commented on the issue: https://github.com/apache/cloudstack/pull/1994 Thanks @nvazquez Waiting for LGTMs --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: Welcoming Wido as the new ACS VP
Thank you Will and all! I'll be present at CCC in Miami this year for a 'official' initiation as VP of the CloudStack project :) Wido > Op 16 maart 2017 om 18:00 schreef Will Stevens : > > > Hello Everyone, > It has been a pleasure working with you as the ACS VP over the past year. > I would like to say Thank You to everyone who has supported me in this role > and have supported the project as a whole. > > It is my pleasure to announce that Wido den Hollander has been voted in to > replace me as the Apache Cloudstack VP in our annual VP rotation. Wido has > a long history with the project and we are happy welcome him into this new > role. > > Be sure to join us at CCC in Miami [1] so we can initiate him correctly > over many beers. :) > > Cheers, > > *Will Stevens* > > [1] http://us.cloudstackcollab.org/
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: Welcoming Wido as the new ACS VP
Great to hear Wido, congrats and see you in Miami! On Sun, Mar 19, 2017 at 1:45 PM Wido den Hollander wrote: > Thank you Will and all! > > I'll be present at CCC in Miami this year for a 'official' initiation as > VP of the CloudStack project :) > > Wido > > > Op 16 maart 2017 om 18:00 schreef Will Stevens : > > > > > > Hello Everyone, > > It has been a pleasure working with you as the ACS VP over the past year. > > I would like to say Thank You to everyone who has supported me in this > role > > and have supported the project as a whole. > > > > It is my pleasure to announce that Wido den Hollander has been voted in > to > > replace me as the Apache Cloudstack VP in our annual VP rotation. Wido > has > > a long history with the project and we are happy welcome him into this > new > > role. > > > > Be sure to join us at CCC in Miami [1] so we can initiate him correctly > > over many beers. :) > > > > Cheers, > > > > *Will Stevens* > > > > [1] http://us.cloudstackcollab.org/ > -- Ian Rae CEO | PDG c: 514.944.4008 CloudOps | Cloud Infrastructure and Networking Solutions www.cloudops.com | 420 rue Guy | Montreal | Canada | H3J 1S6
[GitHub] cloudstack issue #1582: CLOUDSTACK-9408 for the move away from download.clou...
Github user karuturi commented on the issue: https://github.com/apache/cloudstack/pull/1582 I see that its already using download.cloudstack.org. Its merge ready. Will merge once I do some tests. Thanks @DaanHoogland --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] cloudstack issue #1582: CLOUDSTACK-9408 for the move away from download.clou...
Github user karuturi commented on the issue: https://github.com/apache/cloudstack/pull/1582 @borisstoyanov Can you run @blueorangutan tests on this please? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] cloudstack issue #1853: CLOUDSTACK-9696: Fixed Virtual Router deployment fai...
Github user koushik-das commented on the issue: https://github.com/apache/cloudstack/pull/1853 Code change LGTM. @anshul1886 Please make sure Travis is green. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] cloudstack pull request #1853: CLOUDSTACK-9696: Fixed Virtual Router deploym...
Github user anshul1886 closed the pull request at: https://github.com/apache/cloudstack/pull/1853 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] cloudstack pull request #1853: CLOUDSTACK-9696: Fixed Virtual Router deploym...
GitHub user anshul1886 reopened a pull request: https://github.com/apache/cloudstack/pull/1853 CLOUDSTACK-9696: Fixed Virtual Router deployment failing if there are⦠⦠no shared resources available and has access to resources through parent domain heirarachy You can merge this pull request into a Git repository by running: $ git pull https://github.com/anshul1886/cloudstack-1 CLOUDSTACK-9696 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/1853.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1853 commit 0024dfc62266cc52380b7977860f667414d36e42 Author: Anshul Gangwar Date: 2016-12-22T06:17:03Z CLOUDSTACK-9696: Fixed Virtual Router deployment failing if there are no shared resources available and has access to resources through parent domain heirarachy --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] cloudstack issue #1859: CLOUDSTACK-8672 : NCC Integration with CloudStack
Github user priyankparihar commented on the issue: https://github.com/apache/cloudstack/pull/1859 Hi @rhtyd, >From my experience RM-ing for 4.3, 4.5, 4.9 -- the git history is pretty messed-up and it becomes far too difficult to track changes. I think everything has its own + and -. Multiple commits provide more insight and clarity on history. Could you please provide some more advantages of squashing with proper proof. >From my experience This statement seems very loose. I think it needs some improvement. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] cloudstack pull request #2011: CLOUDSTACK-9811: fix duplicated nics on VR ca...
GitHub user ustcweizhou opened a pull request: https://github.com/apache/cloudstack/pull/2011 CLOUDSTACK-9811: fix duplicated nics on VR caused by nic name pp You can merge this pull request into a Git repository by running: $ git pull https://github.com/ustcweizhou/cloudstack fix-issue-p55p1 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/2011.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2011 commit cf442b459ae79ff7828c0ae868c4e1af9c078f01 Author: Wei Zhou Date: 2017-03-16T10:48:35Z CLOUDSTACK-9811: fix duplicated nics on VR caused by nic name pp --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
