Yigit & Alex, thanks for such detailed explanation.
> And as far as I know, Askat is finishing the new web UI in maximum couple of days. Yes, that’s right. I completed the new UI yesterday. > 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. +1 At this moment the webapp has a trivial user management feature: we can CRUD (create/read/etc) users but there are no roles and access rights. I will put this on my todo list and handle that in near future. > 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 would be excellent feature. Also I think there should be a way to save these values so users can track differences between changes. Currently we can add a note to a test run. The changes can be saved there. But from the usability perspective there can be better approach. If we have this teak feature implemented I can create some UI for convenience. > 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. Agree. We should do all of these eventually. > 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. That’s right. This task I will finish next. Regards, Askat On Tue, May 13, 2014 at 2:38 PM, Duncan Johnston Watt < duncan.johnstonw...@cloudsoftcorp.com> wrote: > 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. >
