On Tue, Jun 18, 2013 at 9:08 PM, David Nalley <da...@gnsa.us> wrote: > On Tue, Jun 18, 2013 at 11:33 AM, Sebastien Goasguen <run...@gmail.com> > wrote: > > > > > > > > On 18 Jun 2013, at 17:08, David Nalley <da...@gnsa.us> wrote: > > > >> On Mon, Jun 17, 2013 at 7:00 AM, Prasanna Santhanam <t...@apache.org> > wrote: > >>> On Sun, Jun 09, 2013 at 10:26:43AM -0400, David Nalley wrote: > >>>> On Sun, Jun 9, 2013 at 7:51 AM, Rohit Yadav <bhais...@apache.org> > wrote: > >>>>> Hi, > >>>>> > >>>>> I was about to test CloudStack but the cloudmonkey-4.1.0-0 release > on pypi > >>>>> does not bundle failsafe api cache so when I install it I don't get > any api > >>>>> commands. The autodiscovery using sync is useful but only with the > >>>>> ApiDiscovery plugin which works only for 4.2 and later. For 4.1 and > below I > >>>>> think we should, in that case, bundle the cache for all the apis. Or > maybe > >>>>> just oss components/plugins? > >>>>> > >>>>> I'll wait for Chip and others to comment if we want to ship it as it > is or > >>>>> bundle the cache against 4.1 release? > >>>>> > >>>>> Cheers. > >>>> > >>>> Honestly - this is exactly why I've been suggesting[1] that we break > >>>> CloudMonkey (and Marvin) out of the main repo and giving it it's own > >>>> lifecycle. It's far easier/faster to iterate cloudmonkey than all of > >>>> CloudStack and tying it to the slower lifecycle of ACS will continue > >>>> to trouble it IMO. > >>>> > >>>> --David > >>>> > >>>> [1] http://markmail.org/message/wir5vfawex3y22ot > >>> > >>> I haven't given breaking out the project much thought. But it's > >>> certainly a possibility: > >>> > >>> a) However, there are parts of the codebase (checkin tests) that depend > >>> on marvin. > >>> > >>> b) I need to come up with a easier way to update marvin across > >>> cloudstack providers to enable auto-upating marvin's libraries like > >>> cloudmonkey can. For this I've made a couple enhancements to > >>> apidiscovery but it's not in master yet and I don't have it fully > >>> figured out. > >>> > >>> Need some time to think through this. > >>> > >>> -- > >>> Prasanna., > >>> > >>> ------------------------ > >>> Powered by BigRock.com > >>> > >> > >> > >> OK - are your concerns CM-related? or Marvin only? > >> > >> Any problems I am not seeing with breaking out CloudMonkey? > >> > >> Anyone else have concerns here about breaking out CloudMonkey? > >> > >> --David > > > > Could we talk about it during the hack day and report to the list ? I > for one dont understand how these break out repos would work ...process > wise, release wise, ml wise etc ? > > > Seems like it's something that we def. need to discuss on list. > > Here is my thinking: > > I'd move everything under tools/cli in master to a separate repo - I'd > abandon history (unless someone objects and volunteers to extract all > of that history) > > Releases - they'd be separate, with separate versioning. We'd still > vote on CM releases, but likely at a much faster rate than current > mainline ACS releases. > > I don't envision a different mailing list. > > Things I don't yet have opinions on. Repo name: Should it be > cloudstack-cloudmonkey.git or cloudstack-cli.git or something else? >
+1 break out the repo cloudstack-cloudmonkey.git I can help extract the history out but it's not very necessary. CloudStack cloudmonkey was completely independent of any CloudStack component after I had implemented the API Discovery plugin which made it more maintainable and relevant :) Cheers. > > --David >
