I think your alternatives makes sense. Since we are always merging into and testing 3 different branches (4.7, 4.8, and master in the case of the 4.9 release), we are opening ourselves to headaches IMHO. I don't think we can expect that the same Marvin install will ALWAYS work on all three branches being tested...
We may be able to solve for that, but I do think it is important to highlight this so we know how we will mitigate the risk if we do go this route. *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:18 PM, Rohit Yadav <rohit.ya...@shapeblue.com> wrote: > Hi Will, > > > I understand your concerns, the goal with this initiative is to make sure > that Marvin would remain forward compatible with future versions. As for > the past releases/versions, we cannot guarantee backward compatibility. > > > My main goal was to solve and make it easier for CI systems to configure, > install Marvin and run integration tests. Please see my previous reply > where I present an alternative. > > > Regards. > > ________________________________ > From: williamstev...@gmail.com <williamstev...@gmail.com> on behalf of > Will Stevens <wstev...@cloudops.com> > Sent: 19 July 2016 22:32:26 > To: dev@cloudstack.apache.org > Subject: Re: [VOTE] Split Marvin to its own repository > > So how would the different versions of Marvin be tracked and how would the > versions be associated with the supported ACS versions? > > Because the ACS API changes, a Marvin version will only support a specific > set of ACS versions. We need to understand how that will work because this > is bound to cause some headaches. > > For example, assuming the API changes substantially between 4.8, 4.9 and > 4.10 (new master). Changes can still be merged into 4.8, 4.9 or 4.10 (new > master), so the CI environments have to be aware of which version of ACS is > being run and then install the correct version of Marvin. IMO this is > going to make the setting up and running of CI on multiple versions of ACS > harder. > > Is this the same type of problem others are concerned about? Right now > since it is packaged with ACS, you can always know that the Marvin with the > current code is valid for that code. If we break it out, how do we handle > that? > > *Will STEVENS* > Lead Developer > > *CloudOps* *| *Cloud Solutions Experts > 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 > w cloudops.com *|* tw @CloudOps_ > > > rohit.ya...@shapeblue.com > www.shapeblue.com > 53 Chandos Place, Covent Garden, London WC2N 4HSUK > @shapeblue > > > > On Tue, Jul 19, 2016 at 12:11 PM, Syed Ahmed <sah...@cloudops.com> wrote: > > > 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. > > > > > >
