cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <da...@gnsa.us>
Subject Re: [DISCUSS] Issue with cloudmonkey-4.1.0-0 on pypi
Date Sun, 23 Jun 2013 20:50:07 GMT
I've created this repo based on Rohit's work to preserve history.

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

--David

On Wed, Jun 19, 2013 at 10:27 PM, David Nalley <david@gnsa.us> wrote:
> On Tue, Jun 18, 2013 at 2:24 PM, Rohit Yadav <bhaisaab@apache.org> wrote:
>> On Tue, Jun 18, 2013 at 9:08 PM, David Nalley <david@gnsa.us> wrote:
>>
>>> On Tue, Jun 18, 2013 at 11:33 AM, Sebastien Goasguen <runseb@gmail.com>
>>> wrote:
>>> >
>>> >
>>> >
>>> > On 18 Jun 2013, at 17:08, David Nalley <david@gnsa.us> wrote:
>>> >
>>> >> On Mon, Jun 17, 2013 at 7:00 AM, Prasanna Santhanam <tsp@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 <bhaisaab@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

Mime
View raw message