cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <bhais...@apache.org>
Subject Re: [DISCUSS] Issue with cloudmonkey-4.1.0-0 on pypi
Date Tue, 18 Jun 2013 18:02:11 GMT
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.
>
> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message