On Mon, Dec 10, 2012 at 03:24:18PM -0800, Jie Feng wrote: > It seems the image got stripped out by the Apache mail server. So I > included text info instead. Sorry about the spam.
Probably just as well, some of us aren't using gui mail clients. ;-) > We had some early discussions in the mailing list regarding where to > host the Apache CloudStack listing repository and what to name this > feature. I included various options in the wiki (also see below), my > proposal for v1.0, and feedbacks I got from the Collaboration Conference > attendees. Comments, suggestions, flames? The feature itself - having a way to list a "marketplace" of templates/images for CloudStack users - sounds great. Companies like Citrix that ship a CloudStack distribution like CloudPlatform can populate a marketplace with templates, etc. from their partners. Providers like Contegix could populate the marketplace with their own offerings, etc. I'm not so sure about turning this feature on by default in ACS, though. > ========================================= > Here are the Design Choices: > > Where to host Apache Listing Repository? > > There have been some discussions on the cloudstack-dev mailing list on > where to host the Apache Listing Repository a few months ago. Given that > additional resources will be required to create a separate governance > body for a community managed listing repository, hosting the Apache > Listing Repository within CloudStack source code tree for v1.0 seems to > be a more viable option. The following is an analysis of pros and cons > for each option. This was presented at the CloudStack Collaboration > Conference and feedback was that as long as the actual vendor software > is not open source, and vendor can continue to update the image template > off release cycle, option 1 (CloudStack source code tree) is fine. Separate governance body? I'm guessing what you mean here is a subset of volunteers from the committers/PPMC, etc.? > * Option 1. CloudStack Source Code Tree (part of CloudStack > distribution) -- proposed for v1.0 > > o Pros: Governed by the same Apache project process; listings are > tested and verified to work with each CloudStack version (just like > vendor plugins) I think we have our hands full testing Apache CloudStack. Trying to test third party templates that would run on CloudStack seems like a *lot* of work. > o Cons: Vendors need to sign Apache contributor license agreement > (CLA); vendors cannot make changes to listing files off CloudStack > release cycle; new vendors and products have to wait for the next > CloudStack release cycle to be added I'm not sure about whether vendors would need to sign the CLA, but I'm not entirely clear on *what* it is that we'd be providing, exactly. If I understand correctly, we'd be providing a pointer of some kind to images, etc. hosted elsewhere? Obviously, we would not be able to host the images themselves given licensing/space issues. > * Option 2. A separate listing repository hosted by the Apache > CloudStack community Hosted where? How? What format is the listing going to be in? What kind of technical requirements are we talking about? > o Pros: Vendors do not need to sign Apache CLA; vendors can add/update > listing any time with changes propagated to each Cloudstack instance > with Marketplace enabled > > o Cons: What about governance? If no governance, the listing might > not work or can even contain virus. To provide governance requires us > to create a whole new process and need people This would also be true of Option 1, yes? > * No Apache listing repository This has my vote so far. If I understand the feature correctly, I would say the marketplace should be an optional feature that can be turned on at compile time - perhaps with a configuration that lets you point to one (or more) managed marketplaces provided by third parties. That way if a company or group wants to manage a marketplace, they can publish the URL it can be found at and users can flip the switch to get that. > What should be the name of this new component? Marketplace seems fine to me, seems descriptive enough and doesn't overlap with other names currently. -- Joe Brockmeier http://dissociatedpress.net/ Twitter: @jzb
