cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <>
Subject RE: [DISCUSS] cloudmonkey releases along with CloudStack releases
Date Fri, 11 Jan 2013 09:43:27 GMT
Hey Hugo!

Yes, we should follow the ASF process and to make sure cloudmonkey won't be affected by CloudStack's
long release cycles I created a (totally independent) plugin which helps discover api for
a user role.
Using this plugin, cloudmonkey or any client would be able to discover new apis or changes
in available apis and won't need much development and it could be done with CloudStack's long
release cycles. (on the fly better online apidocs, and autocompletion for params coming too;
if this works as planned our cli is pretty much done and there won't be any maintenance problem
we can do official long term releases on pypi)

My concern was pypi is not asf infra and I considered it as an external place of distribution.

Long story short:
Previous proposal: stable, tested, voted cloudmonkey releases alongwith ACS releases on asf
infra; and stable snapshots on pypi maintained by community.
New proposal: let's do it as the official asf way on both asf/pypi alongwith CloudStack's
release cycles.

PPMC/committers pl. give me your pypi id, I'll add you as owner/admin and remove myself. We
can keep that account for official releases and I'll create another one for snapshots of cloudmonkey
under some different name which would have frequent releases based off master.

PS. Frankly, I don't care where you host it and how you release it as long as the code is
good, maintainable, works and is reachable to the users.
PPS. For me the bigger problem is working with the code, fixing things, technical discussions,
reviewing code and making it fast and better (design, quality, data structure and tool wise).
PPPS. I want to avoid email m**terbat**n, the IP/legal/trademark/laws/release crap; we've
better people for that, I would reads their views and go with their decisions.
PPPPS. These are my personal views, at the lowest levels of the food chain my opinions should
not matter or this line it's got four Ps.

From: Hugo Trippaers []
Sent: Friday, January 11, 2013 2:27 PM
Subject: RE: [DISCUSS] cloudmonkey releases along with CloudStack releases

Heya Rohit,

I like the proposal a lot, however I'm not sure if we should deviate from the ASF process
while we are still in the incubator. The ASF has a very detailed release process which includes
votes, code signing etc. This process covers everything that is in the Apache CloudStack project.
If we decide that cloudmonkey is the official CLI (+1 for that) we should take care to follow
the release process. If we think that the current release process does not work we should
apply for a separate apache project or take it out of the code.

Of course we can have multiple builds of cloudmonkey, just like we have multiple builds of
CloudStack, but the source is fixed as it is released. That means that cloudmonkey 4.0.1 is
based on the cloudmonkey sources in the apache repo as they are when release 4.0.1 will be
tagged. If the release on pypi is our official release, then it should follow the ASF process,
otherwise we should have a separate place where we release Apache CloudStack Cloudmonkey and
leave pypi to others, making sure that it is clear that that particular release is not an
official release from the Apache CloudStack.

I hope I'm making sense here..

Any mentors that want to chip in?



> -----Original Message-----
> From: Musayev, Ilya []
> Sent: Tuesday, January 08, 2013 12:56 AM
> To:
> Subject: RE: [DISCUSS] cloudmonkey releases along with CloudStack releases
> +1
> I am all for it :)
> -----Original Message-----
> From: Rohit Yadav []
> Sent: Monday, January 07, 2013 6:10 PM
> To:
> Subject: [DISCUSS] cloudmonkey releases along with CloudStack releases
> Hi everyone,
> Right now cloudmonkey, a command line interface and interactive shell [0]
> for CloudStack (in tools/cli) is being released independently on cheese shop
> [1]. This is a proposal of how we can release it. Let me start by giving some
> background;
> I started writing cloudmonkey because I wanted a cli and due to a jira issue
> [2]. It was written in Python because instead of starting from complete
> scratch I based it top of marvin which was written in Python and some text
> book functional programming tricks that generates closures or handlers for
> the shell on the fly used for autocompletion for 300+ apis etc. It has a build
> dependency on marvin (which depends on apidoc, which depends on
> cloudstack build targets => indirectly cloudmonkey depends on CloudStack
> codebase) therefore I did not develop this in a separate repo but within the
> codebase.
> Why we should not separate cloudmonkey: CloudStack itself is collection of a
> lot of plugins (hypervisor, acl, network), tools/extras (apidoc, cli, devcloud,
> marvin etc.) and add ons (though tightly coupled now, ex. ssvm, cpvm,
> router-vm etc.). If all these things are decided by the community to be
> separated out of the codebase as separate git repos, then we should
> separate out cloudmonkey as well.
> Proposal to release cloudmonkey:
> - Make cloudmonkey as the official CLI [2] as there is no other known and
> working CLI.
> - The version on cloudmonkey release should reflect the version of
> CloudStack for which it was released or found to work with. Proposed name-
> version syntax is:
>    cloudmonkey-<CloudStack version>-<cloudmonkey counter, a build
> number starting 0>
>    For example for 4.1.0 it would be, cloudmonkey-4.1.0-0.
> - The counter starts at 0 which would be the release that started with a
> CloudStack release, the increments of which would be hosted on pypi. Think
> this way, the official tar ball is available from but users installs
> from community maintained distribution place which is pypi for our case, just
> like we distribute  source tarballs from but we've apt/yum repos
> as well which are community maintained (someone in the community
> maintains that).
> - The release cycles for cloudmonkey may be frequent, in that case it does
> not make sense to release it along with CloudStack only. So, the proposal is
> to release the 0 (gold) version (cloudmonkey-4.1.0-0 for ex.) along with
> CloudStack and host src on both pypi and and keep doing
> community releases on pypi i.e. voted and approved by community with a
> very fast release cycle and small voting window (say only 24 hours)
> - Who can release? Any committer, PMC member is welcome to join the pypi
> project as an admin/owner. On it would be the PMC members at
> the time of CloudStack releases.
> Suggestions, comments welcome.
> Regards.
> [0]
> dmonkey+CLI
> [1]
> [2]

View raw message