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.
> >
>

Reply via email to