Chip ,
Perhaps you missed the earlier conversation happened in the mailing thread
earlier . Attaching the thread here.
[Chip] 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?
[Pranav] - Yes , the basic implementation has just started and myself and Brian
Federle are working on the backend design . The idea is to have the very basic
model up and working and then push the working model to the asf branch so
that if anyone's willing to contribute can do so without any problems. When I
say "basic model" , I am referring to the front end development for the
marketplace within the CloudStack UI and the backend hierarchy for the
directory structure . We had a discussion with Jie and we'll be updating
Jie's proposal with the technical design as soon as possible and sharing it
with the community. The basic structure of the backend design is already there
in the proposal Jie has shared.
[Chip] - 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?
[Pranav] - The static configuration files which you are referring to are not
actually static . The listing of the name of the application a vendor is
willing to host in that file might make you feel that it's static in nature
but it's dynamic in a sense that the config file is being used for listing
will be remotely accessed by the script tags (require.js) .The script tags
would dynamically pick up the appID during the runtime and load the content
which a vendor has provided ( in his application specific config file) in order
to display it on the detail view for his application on the Cloudstack
marketplace .
Hope I managed to answer few of your queries here . Regarding the QAing , I am
not sure how is that supposed to work. For any further clarifications , we can
have a detailed discussion on the backend design. If you suggest , we could
also push the basic working model right now (say in a private asf branch ) for
the community to review it and propose changes , if any.
@Brian - Do you have anything to add here ?
Regards,
Pranav
_______________________________________________________________________________________________________________________________________________________________________
-----Original Message-----
From: Chip Childers [mailto:chip.child...@sungard.com]
Sent: Wednesday, December 12, 2012 10:48 AM
To: cloudstack-dev@incubator.apache.org
Subject: Re: [DISCUSS] CloudStack Marketplace Update
On Wed, Dec 12, 2012 at 12:45 PM, Jie Feng <jie.f...@citrix.com> 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 project?
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?
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?
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.
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?
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.
Thoughts?
-chip
> -----Original Message-----
> From: Jie Feng
> 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 names! You are sure more creative than I am :)
>
> -----Original Message-----
> From: Joe Brockmeier [mailto:j...@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
>> 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 issues.
> [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:
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Mark
> 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 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.
> --
> Joe Brockmeier
> http://dissociatedpress.net/
> Twitter: @jzb
>
--- Begin Message ---
Kelcey ,
I guess you had couple of suggestions to be proposed while we met at the
Conference . Perhaps you could bring them up here as well .
Talking about the marketplace functionality , we are using script tags (
require.js to be specific ) to dynamically load content from remote files
wherein we can pass the App ID /Name provided by the customer and dynamically
render it on the UI . I have kind of started with this work along with Brian
and we'll eventually move the code to the community once the very basic model
is running perfectly . Currently , we are more opened towards any
suggestions/feedbacks for the Marketplace backend design for further
improvements.
Please refer to Jie's proposal link for further details .
Regards,
Pranav
-----Original Message-----
From: Kelcey Damage (BBITS) [mailto:kel...@bbits.ca]
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 proposal.
Very slick!
-kd
-----Original Message-----
From: Jie Feng [mailto:jie.f...@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 names!
You are sure more creative than I am :)
-----Original Message-----
From: Joe Brockmeier [mailto:j...@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
> 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 can distribution like
CloudPlatform 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 issues.
[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:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Marketplac
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
> 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 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.
--
Joe Brockmeier
http://dissociatedpress.net/
Twitter: @jzb
--- End Message ---
