Weighing in late here as well… First guys, appreciate the contribution. All these awesome ideas, we appreciate the work.
That said, work *has* to happen in The Apache Way. Now, some comments: I would strongly recommend separation of code and data. Build Marketplace into ACS, allow it to be easily enabled/disabled at both the global and account/user levels. Regarding data, I think the model you should follow here is that of Eclipse, not maven - as we have a UI, 3rd parties can provide links to repositories that users can add by pasting the link into a wizard in the UI. After submission, the repo sends it's public key to ACS, which stores it for later use. Once a repo is enabled in an ACS install, offerings are browsable/selectable through the admin console, with any commerce/tracking/whatever happening outside our application. When a user selects to download a widget, the repo sends a URL with a mime type that ACS recognizes means it's for it's own consumption. The downloaded package contains the widget and a cryptographic signature - ACS then verifies that signature on the widget via the public key previously downloaded. By default, ACS should ship with a basic "marketplace" that contains the SSVM image and a sample base OS. From a security POV, you better have a metric ton of certainty that what you're providing me is a clean innocent widget. Another reason for this to happen outside the sphere of ACS. If there's an issue, I don't really want that affecting the Apache or CloudStack brand because our vetting of said widget missed something and now some cloud is running 500 copies of a malicious VM. I don't like that type of front-page coverage. The UI looks nice, but it's not maintaining a standard look/feel with the rest of the app. I think as part of accepting the project, we should consider enforcing a standardized look/feel, otherwise our baby will turn into a beast with many arms sticking out of it's head. John On Dec 12, 2012, at 1:40 PM, Pranav Saxena <pranav.sax...@citrix.com> wrote: > [Chip] - I would suggest that committers in particular use feature branches > within the asf repo. I assume that the term "asf branch" you use above is > because you guys have your local git repo configured with multiple remotes. > That's perfectly fine, but shouldn't you be coordinating code collaboration > through the project repo? > > [Pranav] - Yes , you are right Chip . > > [chip] - Not sure what you mean by a "private asf branch", but I think you > might mean a "feature branch" in the project's git repo. Correct? > Can you create a feature branch and push each of your changes as each of you > make significant ones? We had previously agreed as a community that larger > development, particularly done by committers, would be done in feature > branches that are public. Does this work for you guys? > > [Pranav] - Yeah , apologize for the wrong terminology. I am referring to a > feature branch here . I'll definitely do it today and push my code changes > there. And yes , we would share the detailed underlying technical design > for the marketplace for a clear understanding of how the implementation is > being done. > > Thanks & Regards, > Pranav > > -----Original Message----- > From: Chip Childers [mailto:chip.child...@sungard.com] > Sent: Wednesday, December 12, 2012 1:29 PM > To: Pranav Saxena > Cc: cloudstack-dev@incubator.apache.org; Brian Federle > Subject: Re: [DISCUSS] CloudStack Marketplace Update > > On Wed, Dec 12, 2012 at 3:13 PM, Pranav Saxena <pranav.sax...@citrix.com> > wrote: >> Chip , >> >> Perhaps you missed the earlier conversation happened in the mailing thread >> earlier . Attaching the thread here. > > Thanks... I didn't miss it, because this is the same thread. But I do > appreciate you re-sharing the content in case I did miss it. ;-) > >> [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. >> > > I would suggest that committers in particular use feature branches within the > asf repo. I assume that the term "asf branch" you use above is because you > guys have your local git repo configured with multiple remotes. That's > perfectly fine, but shouldn't you be coordinating code collaboration through > the project repo? > >> [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 . > > I think this needs to be spelled out, or the example code pushed to the repo. > As I said in my reply to Jie, I think we will end up with the design causing > project process issues. I may be wrong though... > please do help us all understand it better! > >> 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. >> > > Not sure what you mean by a "private asf branch", but I think you might mean > a "feature branch" in the project's git repo. Correct? > Can you create a feature branch and push each of your changes as each of you > make significant ones? We had previously agreed as a community that larger > development, particularly done by committers, would be done in feature > branches that are public. Does this work for you guys? > >> @Brian - Do you have anything to add here ? >> >> Regards, >> Pranav >> > Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella
