On Tue, Jun 18, 2013 at 2:24 PM, Rohit Yadav <bhais...@apache.org> wrote: > 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. >> >> > Hey David, let's do that. Separate versioning makes sense as cloudmonkey no > longer really depends on CloudStack or marvin with its api discovery, > though we can keep a failsafe precache or have instructions on how to build > one using one's synced cache (which is in ~/.cloudmonkey/cache). > > I've separated out cloudmonkey in a separate git repo retaining its history > using my git-fu; https://github.com/bhaisaab/cloudmonkey > > It's same as latest master plus some commit on adding the license file from > CloudStack's root directory, a README.md file, a Makefile and a .gitignore > file. > > Cheers. >
AWESOME - thanks for the work on this. I'll stand up a RO git repo clone in the next day or so for review. --David
