incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <>
Subject Re: [DISCUSS] CloudStack Marketplace Update
Date Wed, 12 Dec 2012 21:20:06 GMT
On Wed, Dec 12, 2012 at 2:58 PM, Jie Feng <> wrote:
> Thanks a lot Chip!  My comments inline.

Thanks for the patience as I catch up with you guys.  I'm going to
stick to process comments below, and follow up with feature discussion
points in a later email.

> -----Original Message-----
> From: Chip Childers []
> Sent: Wednesday, December 12, 2012 10:48 AM
> To:
> Subject: Re: [DISCUSS] CloudStack Marketplace Update
> On Wed, Dec 12, 2012 at 12:45 PM, Jie Feng <> wrote:
>> Any inputs from others in the community?  I like to reach some consensus on where
to host the Apache listing repository in the next couple of weeks (since if we go with option
1, we need to give vendors enough time to put listings in source code prior to code freeze
end of Jan).
>> Jie
> Jie,
> Let me start by saying that I didn't (personally) pay enough attention to the original
proposal discussion as I should have.  Sorry for that, but I'm paying allot of attention now.
> I actually need us to back up the discussion quite a bit here, and ask some potentially
obvious questions that are more intention and process centric than specifically addressing
the proposal contents.  Once we get through these, I probably have many more followup questions
about the feature proposal itself and the technical design.  (BTW - I wasn't able to attend
your talk at Collab, so I'm reacting to only the information that has been shared / discussed
on this list)
> Here it goes:
> It appears that your intention is for the marketplace code to be part of CloudStack,
correct?  IMO this isn't a match for CloudStack itself, as much as it's a different project
that might be linked to by a CloudStack deployment.  Does this actually belong as a different
> [Jie] Yes, my intention is for the marketplace code to be part of CloudStack project
and installed along with CloudStack for the following reasons:
> 1. Make it easier for admins and users to use the marketplace and consume products/services
listed in the repository. There is no separate install step and separate database to manage.
It can be turned on/off through CloudStack global setting.
> 2. Give vendors (ISVs/PaaS/SaaS vendors) more incentives to contribute product listings
to the Apache listing repository. I am for having an Apache listing repository because it
is important in achieving one of the key goals of the feature: have a list of products/services
that can be easily consumed by admins/users.  There are many marketplaces out there (AWS,
Azure, etc.). How do we get vendors to be interested in contributing to our listing repository?
Through my discussions with some of them, making it easier for admin/user to consume their
product/service is a key consideration for vendors to contribute.
> However, I'll assume that the answer is yes (to being part of CS) and that it's agreed
that this code belongs in the CloudStack project, and ask some follow up questions:
> You mention wanting to give vendors enough time to put listings in the source code prior
to code freeze in Jan.  Are you talking about our CloudStack 4.1.0 feature freeze?
> [Jie] Yes, 4.1.0 that code freeze in end of Jan.
> Is this actually under development right now?  If so, where is the code?  Who's working
on it?  How can others in the community participate?  Where is the technical design discussion
happening?  Do we have Jira records for tracking the dev work?  Where is the discussion about
QA'ing the software happening?
> [Jie] Yes. I talked about this in the Collab Conference and I am waiting for the video
to be made available, so that I can link to it in wiki. I will open a Jira ticket. Sonny,
Pranav and Brian are working on this. If anyone else wants to contribute, please get in touch
with them. The high level technical discussion happened on the mailing list a few months ago,
and we decided to separate the marketplace source code from the repository. I plan to turn
the current proposal into a design doc and ask for comments once we sort out the listing repository.

Sonny, Pranav and Brian are all committers.  If this is for
CloudStack, shouldn't you guys be developing and pushing to the
cloudstack repo?

> Last two questions (which do tie into the proposal a little bit, but are also high level
enough to have a significant):
> You seem to be proposing that the Apache CloudStack community spend time QA'ing external
vendor virtual appliances.  Am I understanding that right?  I'm very much against this being
an Apache project activity.
> [Jie] No, I am not proposing the community to QA external vendor's virtual appliances.
If we decide as a community that the listing repository to be part of the source code, we
need to test the listings. I don't think we should be testing vendors' products. Vendors'
products will not be stored as part of the listing repository and can change outside of CloudStack.
So we have no control of that.

IMO, a listing repository shouldn't be part of the source tree or
released by ASF.  This ties us to having to test that URLs are working
at the time we release, and dealing with changes that might happen
after a release.  I think we have process issues doing it this way,
including bugs being filed and / or user issues to resolve when there
is an unsupported version of CloudStack who's listing includes
recently invalidated URLs.

> There is mention of static configuration files being used to store the product listings,
and storing them as part of the CloudStack source code repository.  This doesn't make any
sense to me on a number of fronts.  Why would a product catalog be embedded in the source
code of the store front?  Wouldn't a better design be to allow *whomever* is hosting this
software to use runtime config changes to create and manage their product listings?
> [Jie] That's a good point. If we package the Apache listing repository with CloudStack
source code or if admin creates its own listing repository, admin can modify the config.js
file to decide which listing shows up. If we host the Apache listing repository outside of
CloudStack, then there are two ways we can allow admin to decide which listing to enable for
its user: 1. Have a "enable service" property for each listing (which we are planning on doing
today with SaaS/PaaS apps, but can be extended to the templates/ISOs). 2. Have admin download
a copy of the config.js file into its CS environment and modify it.
> I actually think that Maven is a reasonable analogy to the marketplace, in that maven
central is a site that complements the Apache Maven project's code.  Is this analogy something
you think holds?  If so, notice that maven central isn't hosted by ASF.  The Apache Maven
community focuses on maven itself, and the hosting of repos is delegated to whomever wants
to host it.
> [Jie] For Maven Central, do they have people actively managing and governing what is
being submitted?  How can we find people and compute resources to do that (it seems similar
to option 2 in my proposal)?  I proposed option 1 (putting listing repository in source code)
for the first release of the marketplace feature because it does not require additional process
and compute resources. For the future releases, I agree that we should take time to work out
a process similar to Maven Central.  Thoughts?

More information on maven central's upload process can be found on
their "Guide to uploading artifacts to the Central Repository" page


> Thoughts?
> -chip
>> -----Original Message-----
>> From: Jie Feng
>> Sent: Monday, December 10, 2012 4:14 PM
>> To:
>> Subject: RE: CloudStack Marketplace Update
>> Thanks Joe for the inputs! My comments inline. Chiradeep, thanks for
>> the names!  You are sure more creative than I am :)
>> -----Original Message-----
>> From: Joe Brockmeier []
>> Sent: Monday, December 10, 2012 3:51 PM
>> To:
>> Subject: Re: CloudStack Marketplace Update
>> 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.
>> [Jie] I am thinking to turning this on by default in ACS so that it is visible immediately
to CloudStack admins after installation. This is really a way to make sure admins actually
know about the new feature. There will be a global configuration that admin can turn this
feature off entirely.
>>> =========================================
>>> 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.?
>> [Jie] Yes.
>>>  *         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.
>> [Jie] I think we only need to test the listing, but not the actual templates. Otherwise,
I agree it will be too much work. How do we test vendor plugins today?
>>>  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.
>> [Jie] Can you clarify more for the CLA?  I thought that anyone contributing anything
to CloudStack source code tree needs to sign CLA?  Is that true?  If we package the listing
repository in the source code tree and ship with CloudStack distribution, I assume vendors
who puts the listings there needs to sign the CLA.
>> 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
>> [Jie] Yes, for templates/ISOs, vendor will provide a pointer to image hosted elsewhere.
We will not host it in Apache.
>>>  *         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?
>> [Jie] That's my question also. Where can we host it if not in the
>> source code tree? Apache CloudStack website? See wiki for format:
>> etplace+Proposal
>>>  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?
>> [Jie] For option 1, we will test the listing itself as part of the Apache CloudStack
governance process we use for the source code, so that we don't need to create a separate
governance process. We can only go as far as testing the listing does not include virus. We
cannot test the templates/ISOs (too time consuming). Should this be similar to vendor plugins?
 In the case of vendor plugins, we can only test the plugins. Vendors' products can evolve
outside of CloudStack and if they put some virus in, there is no way we can govern that.
>>>  *         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.
>> [Jie] You are correct that there is configuration item that lets you point to one
(or more) marketplace repositories. My proposal is to turn the feature on by default as explained
>>> 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
>> Twitter: @jzb

View raw message