Thanks John for the feedback. I looked at OpenNebula marketplace (thanks Sebastien for contributing the link), which is a marketplace of virtual appliance metadata hosted by OpenNebula. In that scenario, admin needs to go to this marketplace website to import virtual appliances into its cloud. The only type of product supported is virtual appliance. I proposed to have the marketplace source code being part of an add-on feature admin can install with CloudStack (instead of a global hosting service) for two reasons:
1. Simplify the experience for admins so that they don't need to go to another place to get the listings 2. Enable admin to offer its own marketplace with support for both templates and SaaS/PaaS The marketplace functionality source code will be in the CloudStack source code tree. As for the listings, for simplicity, I was thinking to create a folder in the source code tree to store seller listings, just like how plugins are stored. For templates, the listing will only store metadata, but not the actual binary of the templates. Listing might include source code seller provides to do something after user click on "acquire service" (Is this necessary?). John's idea about a separate repository and feed is also interesting. I like to explore more on the voting process. How is it going to work and who will be voting? Can we follow the same process to qualify CloudStack plugins for this marketplace listing? Jie -----Original Message----- From: John Kinsella [mailto:j...@stratosec.co] Sent: Tuesday, July 10, 2012 10:46 AM To: <cloudstack-dev@incubator.apache.org> Subject: Re: CloudStack Marketplace - need feedback I'm wondering if you would want that code running on each CS installation, or maybe have just a link/iframe out to a marketplace running somewhere else? That would allow much easier management of the content - one scenario that comes to mind is if a seller's product is compromised or determined to be malicious, you'd want to pull it from the marketplace ASAP. Maybe a compromise between the two - centrally serve an xml/binary feed that the CS install can grab/use, something like a yum/apt/etc repository. (note - I'm not suggesting add dependency functionality :) ) I don't think you want each potential seller contributing xml/graphics/code, or checking this into the source tree? I'd think what you want in the src tree is code for the client side, and maybe a web portal (I wouldn't want us to spend a ton of time coding this up unless this is a core feature moving forward): * Have a web UI where sellers can register/login and define/modify their products * Before products are listed in the feed, there's some sort of voting process (maybe moderate each seller until they've "proven" themselves over a release or two?) * Daily cron process generates the feed, places it somewhere accessible via http John On Jul 9, 2012, at 10:32 AM, Jie Feng wrote: > I would love to get folks' feedback on proposing a subproject under Apache > CloudStack, called MarketPlace. There are many ISVs, SaaS/PaaS vendors > providing value-added products and services on IaaS clouds. The goal is to > make their products more visible and easier to consume by anyone who deploys > CloudStack. It would also allow cloud admins to offer their own marketplace > to their users to get access to a variety of products and services that can > be used with CloudStack. > > Here is the idea: > * The subproject (let's call it MarketPlace for now) will consist > of source code for the CloudStack Marketplace user UI main page; a > product/service listing template; an admin portal; and a repository of > listing. Both the source code and listings will be part of the CloudStack > Marketplace distribution. > * Each listing will contain information about the > product/service, the user action needed to use the product/service, and > instructions for the admin to set up the product/service. Listings are > contributed by sellers (i.e. ISVs, SaaS/PaaS vendors). To include a listing > in the CloudStack MarketPlace distribution, the seller needs to place its XML > files, graphics and code in the designated folder within the subproject. > * When CloudStack is installed, the admin will have a choice to > install MarketPlace including all the pre-packaged listings. The admin can > then choose which listings to enable for the users to see. The admin may need > to follow seller instructions to get products/services set up. > * This is not a global marketplace for every CloudStack user. > Each CloudStack instance will have its own marketplace if the admin chooses > to install it. After CloudStack is installed, the admin should have the > capability to add, delete, enable, disable, and update the listings. If a > seller wants to add or update it listing for a specific CloudStack instance, > s/he needs to go through the admin. > > To keep it simple in the first phase, I propose to support two types of > listings only: SaaS/PaaS services and free image templates. Even though the > image template is free, the seller can still enforce licensing and charge a > fee within the application itself. To minimize product/service set up effort, > in the case of image template, seller should provide a publicly accessible > URL from which the image template can be downloaded. > > Future phases could include functions such as a seller listing publishing > portal, listing approval workflow, and usage reporting, etc. > > Jie
