@Rohit: I think that the assumption that the API is always backwards compatible is dangerous as we know that in practice it is not always the case.
For example: In ACS 4.6 the `restartVPC` introduced a new parameter called `makeredundant`. Unfortunately, the default value for this parameter (if you don't specify) will be `true`. This means that if you built a script to `restartVPC` when you had ACS 4.4 (when the parameter did not exist) installed, and then you upgrade to say ACS 4.7 (through the correct upgrade path), your script will now break the expected VR functionality. When you attempt to restart your VPCs, because you have not upgraded your script to include the new parameter, it will automatically upgrade your VPCs to be redundant VPCs. This is a single example, but it illustrates the point. We can not assume that the API is always backwards compatible outright or we will run into problems. There has to be a mechanism in which we are able to know which versions of ACS a specific Marvin version supports. Your following alternatives are also interesting and make things much easier from a CI perspective... 1. Along with cloudstack deb/rpm packages, we also bundle/package Marvin library with each CloudStack version/branch/release. This would make it easier for anyone and the CI systems to do a apt/yum install cloudstack-marvin. 2. Presently, CI systems have issue of finding the running integration tests. This can again be solved by bundling the integration tests as a deb/rpm package that may be installed by the CI systems with a apt/yum install cloudstack-tests. The python based integration tests can then be installed and available at a known path and we may further include some helper/test-runner script that fires to run the tests, gather results and upload them back to Jenkins or other CI systems in some known way/format. *Will STEVENS* Lead Developer *CloudOps* *| *Cloud Solutions Experts 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|* tw @CloudOps_ On Tue, Jul 19, 2016 at 1:04 PM, Rohit Yadav <rohit.ya...@shapeblue.com> wrote: > Thanks Syed, you've answered it well. Bharat, what Syed has described > captures the goal behind this effort. > > > I see the pros and cons with keeping Marvin within the repo, and if there > is a hesitation with splitting Marvin -- I propose another alternative: > > > 1. Along with cloudstack deb/rpm packages, we also bundle/package Marvin > library with each CloudStack version/branch/release. This would make it > easier for anyone and the CI systems to do a apt/yum install > cloudstack-marvin. > > > 2. Presently, CI systems have issue of finding the running integration > tests. This can again be solved by bundling the integration tests as a > deb/rpm package that may be installed by the CI systems with a apt/yum > install cloudstack-tests. The python based integration tests can then be > installed and available at a known path and we may further include some > helper/test-runner script that fires to run the tests, gather results and > upload them back to Jenkins or other CI systems in some known way/format. > > > I've presented two ways of reaching our goal to improve testing and ease > of integration with CI systems. Please share your thoughts on above ^^. > Thanks. > > > Regards. > > ________________________________ > From: Syed Ahmed <sah...@cloudops.com> > Sent: 19 July 2016 21:41:44 > To: dev@cloudstack.apache.org > Subject: Re: [VOTE] Split Marvin to its own repository > > I believe it will make CI much smoother. Right now marvin is tied to the > Cloudstack repo which was fine if all the integration tests were running > from Cloudstack build but we are now seeing much better CI approaches with > bubble and Trillian and having marvin in its own repo will facilitate that > even further. I think Rohit can answer this better but this is what I got > as a gist of the motive. > > Does that answer your question Bharat? > > -Syed > > > On Tue, Jul 19, 2016 at 9:14 AM, Bharat Kumar <bharat.ku...@accelerite.com > > > wrote: > > > Hi Rohit, > > > > > > what are we trying to achieve by moving marvin into a separate repo.? > > > > > > --Bharat. > > > > ________________________________ > > From: Raja Pullela <raja.pull...@accelerite.com> > > Sent: Tuesday, July 19, 2016 5:30:20 PM > > To: dev@cloudstack.apache.org > > Subject: Re: [VOTE] Split Marvin to its own repository > > > > Hi Rohit, > > > > same question as Rene has posted, impact on older releases – will have > > issues on older releases. I know that the older releases have marvin > code > > which can be used. Also, this will require changes on the CI side to > pull > > the correct repo for Marvin. > > > > +1, if Bharat can modify CI implementation to take care of this? > > > > best, > > Raja > > Senior Manager, Product Development > > Accelerate, www.accelerite.com,@accelerite<http://www.accelerite.com< > http://www.accelerite.com,@accelerite<http://www.accelerite.com> > > ,@accelerite> > > 2055, Laurelwood Road, Santa Clara, CA 95054, USA > > Phone: 1-408-216-7010 > > > > On 7/18/16, 3:14 PM, "Rohit Yadav" <bhais...@apache.org> wrote: > > All, > > > > Based on a recent discussion thread [1], I want to start a voting thread > to > > gather consensus around splitting Marvin from the CloudStack repository. > > > > On successful voting, we would extract and maintain Marvin as a separate > > library in a separate repository (example repository [2]) and various > > build/test systems such as Travis [3] can install it directly for usage > > with pip+git etc. > > > > Background: During the build process, a commands.xml generated to build > > apidocs is also used to generate CloudStack Cmd and Request classes are > > auto-generated, which is the only dependency why we needed Marvin and > > CloudStack together. The auto-generated cloudstackAPI module can be also > > generated against a live running CloudStack mgmt server which has api > > discovery (listApis) enabled. The integration tests will still be tied > to a > > branch and will remain withing the repository. A PR [3] was sent to show > > that we can still execute tests using this approach, and this would > finally > > allow us to build, release and use Marvin as an independent library. > > > > Vote will be open for 72 hours. > > > > For sanity in tallying the vote, can PMC members please be sure to > indicate > > "(binding)" with their vote? > > > > [ ] +1 approve > > [ ] +0 no opinion > > [ ] -1 disapprove (and reason why) > > > > [1] http://markmail.org/thread/kiezqhjpz44hvrau > > [2] https://github.com/rhtyd/marvin > > [3] https://github.com/apache/cloudstack/pull/1599 > > > > Regards, > > Rohit Yadav > > > > > > > > > > > > DISCLAIMER > > ========== > > This e-mail may contain privileged and confidential information which is > > the property of Accelerite, a Persistent Systems business. It is intended > > only for the use of the individual or entity to which it is addressed. If > > you are not the intended recipient, you are not authorized to read, > retain, > > copy, print, distribute or use this message. If you have received this > > communication in error, please notify the sender and delete all copies of > > this message. Accelerite, a Persistent Systems business does not accept > any > > liability for virus infected mails. > > > > > > > > DISCLAIMER > > ========== > > This e-mail may contain privileged and confidential information which is > > the property of Accelerite, a Persistent Systems business. It is intended > > only for the use of the individual or entity to which it is addressed. If > > you are not the intended recipient, you are not authorized to read, > retain, > > copy, print, distribute or use this message. If you have received this > > communication in error, please notify the sender and delete all copies of > > this message. Accelerite, a Persistent Systems business does not accept > any > > liability for virus infected mails. > > > > rohit.ya...@shapeblue.com > www.shapeblue.com > 53 Chandos Place, Covent Garden, London WC2N 4HSUK > @shapeblue > > > >
