On Mon, Jun 24, 2013 at 2:20 AM, David Nalley <da...@gnsa.us> wrote: > I've created this repo based on Rohit's work to preserve history. > > Great, thanks David. Maybe fix the repo description to "Apache CloudStack CLI" etc.
> The repo is currently read only. I'd like several reviews of this repo > before I open it up for writes. > > https://git-wip-us.apache.org/repos/asf/cloudstack-cloudmonkey.git +1 review license, docs, any other thing that needs to be fixed. Cheers. > > > --David > > On Wed, Jun 19, 2013 at 10:27 PM, David Nalley <da...@gnsa.us> wrote: > > 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 >
