Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of Sonny.Chhen@citrix.com
 designates 66.165.176.63 as permitted sender)
From: Sonny Chhen <Sonny.Chhen@citrix.com>
To: "cloudstack-dev@incubator.apache.org"
	<cloudstack-dev@incubator.apache.org>, "kelcey@bbits.ca" <kelcey@bbits.ca>
Date: Mon, 10 Dec 2012 16:38:46 -0800
Subject: RE: CloudStack Marketplace Update
Thread-Topic: CloudStack Marketplace Update
Thread-Index: AQHyKFm8K/mdMPbUQ+x2zU+mQvjx2wF/IAXTApwMwucCer0HMpeVbiZwgAABEVA=
Message-ID: 
 <7914B38A4445B34AA16EB9F1352942F1012F13CC8117@SJCPMAILBOX01.citrite.net>
References: 
 <7A92FF96DF135843B4B608FB576BFC3E012DA27F3E84@SJCPMAILBOX01.citrite.net>
 <7A92FF96DF135843B4B608FB576BFC3E012DA27F3E93@SJCPMAILBOX01.citrite.net>
 <20121210235048.GA2063@localhost.localdomain>
 <7A92FF96DF135843B4B608FB576BFC3E012DA27F3ECE@SJCPMAILBOX01.citrite.net>
 <042301cdd737$3b3ed8c0$b1bc8a40$@bbits.ca>
In-Reply-To: <042301cdd737$3b3ed8c0$b1bc8a40$@bbits.ca>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hey Kelcey,

I tweeted out a ui concept for CloudStack that the marketplace is based off=
 of a while ago. Check it out here.

https://pbs.twimg.com/media/A5gvfLlCMAAzmd8.jpg:large

Wait to you see what I have in mind for mobile ;)

Thanks You and Best Regards,

Sonny H. Chhen
Manager of User Interface & User Experience | Citrix Systems - CloudPlatfor=
m
4988 Great America Parkway, Santa Clara, CA=A0 95054, USA=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=20


-----Original Message-----
From: Kelcey Damage (BBITS) [mailto:kelcey@bbits.ca]=20
Sent: Monday, December 10, 2012 4:34 PM
To: cloudstack-dev@incubator.apache.org
Subject: RE: CloudStack Marketplace Update


I'll say this.. I wish the CloudStack UI looked like the marketplace propos=
al. Very slick!

-kd

-----Original Message-----
From: Jie Feng [mailto:Jie.Feng@citrix.com]
Sent: Monday, December 10, 2012 4:14 PM
To: cloudstack-dev@incubator.apache.org
Subject: RE: CloudStack Marketplace Update

Thanks Joe for the inputs! My comments inline. Chiradeep, thanks for the na=
mes!  You are sure more creative than I am :)

-----Original Message-----
From: Joe Brockmeier [mailto:jzb@zonker.net]
Sent: Monday, December 10, 2012 3:51 PM
To: cloudstack-dev@incubator.apache.org
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=20
> included text info instead. Sorry about the spam.

Probably just as well, some of us aren't using gui mail clients. ;-)=20

> We had some early discussions in the mailing list regarding where to=20
> host the Apache CloudStack listing repository and what to name this=20
> feature. I included various options in the wiki (also see below), my=20
> proposal for v1.0, and feedbacks I got from the Collaboration=20
> Conference attendees. Comments, suggestions, flames?

The feature itself - having a way to list a "marketplace" of templates/imag=
es for CloudStack users - sounds great.=20

Companies like Citrix that ship a CloudStack can distribution like CloudPla=
tform populate a marketplace with templates, etc. from their partners. Prov=
iders like Contegix could populate the marketplace with their own offerings=
, etc.=20

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 visi=
ble immediately to CloudStack admins after installation. This is really a w=
ay to make sure admins actually know about the new feature. There will be a=
 global configuration that admin can turn this feature off entirely.

> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Here are the Design Choices:
>=20
> Where to host Apache Listing Repository?
>=20
> There have been some discussions on the cloudstack-dev mailing list on=20
> where to host the Apache Listing Repository a few months ago. Given=20
> that additional resources will be required to create a separate=20
> governance body for a community managed listing repository, hosting=20
> 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=20
> pros and cons for each option. This was presented at the CloudStack=20
> Collaboration Conference and feedback was that as long as the actual=20
> vendor software is not open source, and vendor can continue to update=20
> 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 vo=
lunteers from the committers/PPMC, etc.?=20
[Jie] Yes.

>  *         Option 1. CloudStack Source Code Tree (part of CloudStack
>  distribution)  -- proposed for v1.0
>=20
>  o   Pros: Governed by the same Apache project process; listings are
>  tested and verified to work with each CloudStack version (just like=20
> vendor plugins)

I think we have our hands full testing Apache CloudStack. Trying to test th=
ird party templates that would run on CloudStack seems like a *lot* of work=
.=20
[Jie] I think we only need to test the listing, but not the actual template=
s. Otherwise, I agree it will be too much work. How do we test vendor plugi=
ns today?=20

>  o   Cons: Vendors need to sign Apache contributor license agreement
>  (CLA); vendors cannot make changes to listing files off CloudStack=20
> release cycle; new vendors and products have to wait for the next=20
> 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 imag=
es, etc. hosted elsewhere? Obviously, we would not be able to host the imag=
es themselves given licensing/space issues.=20
[Jie] Yes, for templates/ISOs, vendor will provide a pointer to image hoste=
d 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?=20
[Jie] That's my question also. Where can we host it if not in the source co=
de tree? Apache CloudStack website? See wiki for format:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Marketpla=
c
e+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=20
> 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=20
> to create a whole new process and need people

This would also be true of Option 1, yes?=20
[Jie] For option 1, we will test the listing itself as part of the Apache C=
loudStack governance process we use for the source code, so that we don't n=
eed to create a separate governance process. We can only go as far as testi=
ng the listing does not include virus. We cannot test the templates/ISOs (t=
oo 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 vir=
us in, there is no way we can govern that.

>  *         No Apache listing repository

This has my vote so far.=20

If I understand the feature correctly, I would say the marketplace should b=
e 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 wan=
ts to manage a marketplace, they can publish the URL it can be found at and=
 users can flip the switch to get that.=20
[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 featu=
re on by default as explained above.

> 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.=20
--
Joe Brockmeier
http://dissociatedpress.net/
Twitter: @jzb