Alex We would like to support UserGrid 2.0 by extending the work Martin Harris[1] has done to simplify the deployment of UserGrid[2] to include rolling out additional componen such as a Solr cluster. This is a very familiar pattern.
[1] https://github.com/Nakomis [2] https://github.com/cloudsoft/brooklyn-usergrid Best Duncan On 12 May 2014 19:20, Alex Karasulu <akaras...@apache.org> wrote: > Hi Yigit, > > > On Mon, May 12, 2014 at 5:22 PM, Yigit Sapli <yig...@apache.org> wrote: > > > So everyone, please feel free to get involved. > > When everyone agrees on what to do next, we'll register these issues in > > Jira and move on from there. > > > > > It's nice to have people posting these concerns openly here on the mailing > list instead of via chat. I really appreciate your proper use of our > channels and for stimulating the community. > > > > Right now, core functionality on chop is finished, meaning you can chop > > annotate your test classes, use the chop maven plugin to create and > deploy > > your tests, setup or destroy the test clusters and runners on EC2, start, > > stop your tests. > > > > Thanks also for taking up some tasks that I could not handle due to > personal issues I've been dealing with. It's nice to have a community > around chop. > > > > However, although we have an example project inside chop to show how to > use > > @TimeChop and @IterationChop annotations, current README is outdated and > > more example projects maybe with tutorials might be cool. > > > First off I need to get Usergrid setup so its an ideal candidate for a > complex project. The 2.0 uses both a Cassandra cluster and an ElasticSearch > cluster. I'll look into setting this up tonight. > > Dave if you can lend a hand with the setup scripts I can create the stack > structure in the next hour or so to setup Usergrid's environment for chop > stress tests. > > > > Following are the items we can/should do on chop, as far as I can see. I > > tried to order them in accordance with their priorities, more urgent > first. > > Please share your ideas so that eventually we have a complete list of > what > > to do. > > > > - We need to update the README to make it compatible with the current > > version. > > > > +1 > > It might also be really nice to have some architecture diagrams and > interaction diagrams so its easy for people to understand the new 2.0 > architecture. > > Also we need an installation and setup guide. > > > > - We need to review our password usage in all REST operations, and make > > sure that they are safe. And maybe we should have an administrator-user > > role distinction in coordinator, so credentials of one user is not > exposed > > to others in a multi-user coordinator. Idk if Askat has any input on > this, > > or any progress so far about this matter. > > > > Yeah we've been good about security. This is why we dealt with the HTTPS > headaches but yes we need to evaluate all these matters. > > > > - We need to review our usage of certificates and SSL communications > > between plugin-coordinator and coordinator-runners, and make sure they're > > concrete. > > > > +1 > > Here we can either create or use provided certificates for this. It can be > added to the configuration and or the stack.json. > > > > - Set up information on Stacks in coordinator are held in-memory. Maybe > > it'll be better to persist stack information in elastic search, so that > it > > doesn't cause problems while restarting or updating webapp. > > > > +1 > > I also think eventually it would be nice for users to be able to design > their stack configuration via the UI. This can be a long term feature. > > > > - It might be nice being able to tweak JVM parameters on runner and > cluster > > instances, and see the change on test results depending on these > > parameters. We may put related parameters in plugin, stack.json and/or > > coordinator to set these. I'd appreciate any inputs on best approach for > > this. > > > > This is an interesting idea. As you know we allow the coordinator to start > up runners with a set of URLs allowing the Coordinator to feed in > parameters that can tweak the runner configuration. This works via Archaius > Dynamic configuration settings. The same capability of parameterizing > cluster nodes and the entire stack should be available via the UI. > > > > - Right now, we have a basic representation of deployed modules, launched > > runners on web UI. It could be nice to be able to see all stacks with > their > > runner and cluster instances in an organized fashion, setup stacks and > > track setup status for deployed modules directly from web UI, and even > > start, stop tests from web UI. Additionally, it would be good to see > > coordinator logs inside the web UI to troubleshoot any possible problems. > > > > +1 > > Also Askhat was looking into integrating monitoring statistics from runners > and the stack cluster nodes with the ability to overly those stats on top > of the performance metrics for runs. This feature I think is really needed > and important for any real diagnostic capabilities for test runs. > > Thanks for adding these into the Apache Usergrid JIRA for a solid roadmap. > This is going to be great. > > -- > Best Regards, > -- Alex > -- Duncan Johnston-Watt CEO | Cloudsoft Corporation Twitter | @duncanjw Mobile | +44 777 190 2653 Skype | duncan_johnstonwatt Linkedin | www.linkedin.com/in/duncanjohnstonwatt Cloudsoft Corporation Limited, Registered in Scotland No: SC349230. Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. Cloudsoft Corporation Limited does not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by Cloudsoft Corporation Limited in this regard and the recipient should carry out such virus and other checks as it considers appropriate.
