You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@usergrid.apache.org by Yigit Sapli <yi...@apache.org> on 2014/05/12 16:22:39 UTC
Short and Long Term Issues on Chop
Hello everyone,
Although this is mainly directed to people who are currently working on
Chop, I would definitely appreciate any additional inputs, opinions,
suggestions and questions. 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.
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. And as far as I know, Askat is finishing the new web UI in
maximum couple of days.
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. I think this
might help others to get up to speed with configuring and using chop. So if
anyone has any ideas on what example projects we can do, that'll be great.
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.
- We need to check the chop codebase for missing Apache License headers,
applying proper code styling and javadoc.
- We already have functional AMIs on Ec2 for both coordinator and runners,
but we have to update them and make them public.
- I will chain maven plugin goals, so that consecutive goals will be
executed automatically. For instance, when a user executes 'mvn chop:start'
on a chop annotated project, it should automatically cover 'chop:runner',
'chop:deploy', and 'chop:setup' goals if needed and start the tests.
- When a User deploys a project with existing commit Id and maven module to
coordinator, coordinator should first ask to destroy the existing stack for
that module and commit, or destroy automatically according to plugin
parameters. I'll handle that.
- 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.
- We need to review our usage of certificates and SSL communications
between plugin-coordinator and coordinator-runners, and make sure they're
concrete.
- 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.
- Right now, chop tests require at least one cluster defined in stack.json.
Setting up test stacks with just runner instances might be needed.
- 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.
- 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.
Regards,
Yigit Sapli
Re: Short and Long Term Issues on Chop
Posted by Askhat Asanaliev <aa...@safehaus.org>.
Hi Dave,
The VaadinServlet warning is not related to the main problem here as "Not
all runners are registered". We can get those kind of Vaadin logs while the
tests are running normally. So it is safe to ignore them.
About the main problem - Furkan or Yigit could help out more. They know the
backend better than me.
Regards,
Askat
On Wed, Jul 16, 2014 at 11:39 PM, Dave <sn...@gmail.com> wrote:
> Just say this possible clue in the coordinator logs:
>
> Jul 16, 2014 5:34:26 PM com.vaadin.server.VaadinServlet
> serveStaticResourcesInVAADIN
> INFO: Requested resource [/VAADIN/HEARTBEAT/] not found from filesystem or
> through class loader. Add widgetset and/or theme JAR to your classpath or
> add files to WebContent/VAADIN folder.
>
> - Dave
>
>
>
> On Wed, Jul 16, 2014 at 1:37 PM, Dave <sn...@gmail.com> wrote:
>
> > Hi guys,
> >
> > Thanks for the help so far. Chop really looks great and I've made good
> > progress on getting Chop setup. I now have the coordinator web up and
> > running, I have a stack.json file that launches a working 3 node
> Cassandra
> > and a 3 node ElasticSearch cluster and the chop:setup command says that I
> > am all ready to run tests.
> >
> > INFO chop.plugin.MainMojo.execute(126)<main>- ====== Response from the
> > coordinator ======
> > INFO chop.plugin.MainMojo.execute(127)<main>- Stack is set up and ready
> to
> > start the tests.
> > INFO chop.plugin.MainMojo.execute(128)<main>-
> > =====================================
> >
> >
> > But, when I try to run the tests (in the ChoppedCassandraTests project)
> > the tests fail with this message:
> >
> > INFO chop.plugin.MainMojo.execute(113)<main>- ====== Response from the
> > coordinator ======
> > INFO chop.plugin.MainMojo.execute(114)<main>- Coordinator message: Cannot
> > start tests.
> > Not all runners are registered !!!
> > Number of registered runners : 0
> > INFO chop.plugin.MainMojo.execute(115)<main>-
> > =====================================
> >
> >
> > Any idea what I might be doing wrong or what my next steps should be to
> > debug this issue?
> >
> > I can give you guys access to my Coordinator webapp if that will help.
> >
> > Thanks,
> > Dave
> >
> >
> >
> >
> >
> >
> > On Tue, Jul 15, 2014 at 9:54 AM, Yigit Sapli <yi...@apache.org> wrote:
> >
> >> Hello all,
> >>
> >> Thanks Furkan for helping out. Dave, please let us know if you're having
> >> any problems or if you have any suggestions.
> >>
> >> Regards,
> >> Yigit
> >>
> >> On Tue, Jul 15, 2014 at 7:39 PM, Dave <sn...@gmail.com> wrote:
> >> > Thanks! The ChoppedCassandraTests project looks very useful and that
> is
> >> > where I'm going to start.
> >> >
> >> > - Dave
> >> >
> >> >
> >> >
> >> > On Tue, Jul 15, 2014 at 9:30 AM, Furkan Bıçak <bi...@gmail.com>
> >> wrote:
> >> >
> >> >> Hi Dave,
> >> >>
> >> >> I suppose that confluence page answers most of your questions for
> >> running
> >> >> Chop webapp both locally and on AWS. If not I can help you about the
> >> >> questions you have.
> >> >>
> >> >> Additionally, there is a simple project which uses a Cassandra
> cluster
> >> >> while doing its tests. It might be useful while getting started which
> >> you
> >> >> can find here: https://github.com/salihkardan/ChoppedCassandraTests
> >> >>
> >> >> Best,
> >> >> Furkan.
> >> >>
> >>
> >
> >
>
Re: Short and Long Term Issues on Chop
Posted by Salih Kardan <sa...@gmail.com>.
Hi Dave,
more inline ...
I'm going to try that because I want to get Chop working today, but I would
> like to know how to create a Chop Webapp instance from scratch and not
> starting from a pre-built AMI. Is any of the AMI creation process
> documented or automated? Is there some keystore setup that needs to be
> done or configured on the webapp instance?
>
I have updated the Readme.md
<https://github.com/salihkardan/ChoppedCassandraTests/blob/master/README.md>
file of my example project so that you can create an AMI
from scratch by following the steps there.
Also, it is not legal to redistribute Oracle's JDK in the form of an AMI,
> or any other medium. So, those AMIs should really be removed from public
> access.
>
Thanks for the heads up. I have removed that AMI from public access.
> Since we cannot assume that runners have Java installed, and we need need
> to provide a "setupScripts" list for runners just as we do for instances in
> a cluster. A setup script can do the right thing to obtain and install the
> Oracle JDK. I have some time to add this feature. Thoughts?
>
Thanks Dave, I have created a issue on JIRA and I will implement this
functionality.
https://issues.apache.org/jira/browse/USERGRID-195
Regards,
Salih
Re: Short and Long Term Issues on Chop
Posted by Dave <sn...@gmail.com>.
On Thu, Jul 17, 2014 at 11:59 AM, Furkan Bıçak <bi...@gmail.com> wrote:
> Hi Dave,
>
> Your problem seems to be a certificate issue. I suggest you to use this
> publicly available image "ami-3e6d8756". You may want to upload the latest
> Chop webapp and start it on the newly created instance. Also, there is a
> maven plugin for that to ease this process. You may refer to the 2nd item
> under section "Configurations for Chop" from the following guide for that
> operation:
>
> https://confluence.safehaus.org/display/CHOP/Stress+Testing+with+Chop+-+Tutorial
>
> Let me know if you still have problems.
>
I'm going to try that because I want to get Chop working today, but I would
like to know how to create a Chop Webapp instance from scratch and not
starting from a pre-built AMI. Is any of the AMI creation process
documented or automated? Is there some keystore setup that needs to be
done or configured on the webapp instance?
Also, it is not legal to redistribute Oracle's JDK in the form of an AMI,
or any other medium. So, those AMIs should really be removed from public
access.
Since we cannot assume that runners have Java installed, and we need need
to provide a "setupScripts" list for runners just as we do for instances in
a cluster. A setup script can do the right thing to obtain and install the
Oracle JDK. I have some time to add this feature. Thoughts?
- Dave
Re: Short and Long Term Issues on Chop
Posted by Furkan Bıçak <bi...@gmail.com>.
Hi Dave,
Your problem seems to be a certificate issue. I suggest you to use this
publicly available image "ami-3e6d8756". You may want to upload the latest
Chop webapp and start it on the newly created instance. Also, there is a
maven plugin for that to ease this process. You may refer to the 2nd item
under section "Configurations for Chop" from the following guide for that
operation:
https://confluence.safehaus.org/display/CHOP/Stress+Testing+with+Chop+-+Tutorial
Let me know if you still have problems.
Best,
Furkan
2014-07-17 15:05 GMT+03:00 Dave <sn...@gmail.com>:
> On Thu, Jul 17, 2014 at 2:35 AM, Furkan Bıçak <bi...@gmail.com> wrote:
>
> > Hi Dave,
> >
> > Right now, only requirement for runner instances to have a JDK installed.
> > Therefore, using a custom AMI which has a JDK installed would be more
> > convenient I suppose.
> > Accordingly, you can use the AMI (ami-56a0463e) that is publicly
> available
> > on US-East region which has Oracle JDK 7 installed if that meets your
> > requirements.
>
>
> Perfect. Thanks!
>
> That works and now I'm on to the next error, shown below. I may not have
> the coordinator webapp setup correctly. Is there a Maven build goal that
> creates an assembly for the webapp? I used "mvn package" and the just
> copied the war up to my coordinator instance; did I miss something?
>
>
> 2014-07-17 12:00:42.373 ERROR
> service.runner.RunnerServiceImpl.getState(43)<qtp1765474380-141>- Error to
> get a runner status:
> com.sun.jersey.api.client.ClientHandlerException:
> javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target
> at
>
> com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:155)
> at com.sun.jersey.api.client.Client.handle(Client.java:652)
> at com.sun.jersey.api.client.WebResource.handle(WebResource.java:682)
> at com.sun.jersey.api.client.WebResource.access$200(WebResource.java:74)
> at com.sun.jersey.api.client.WebResource$Builder.get(WebResource.java:509)
> at
>
> org.apache.usergrid.chop.client.rest.AbstractRestOperation.execute(AbstractRestOperation.java:133)
> at
>
> org.apache.usergrid.chop.client.rest.RestRequests.status(RestRequests.java:207)
> at
>
> org.apache.usergrid.chop.webapp.service.runner.RunnerServiceImpl.getState(RunnerServiceImpl.java:40)
> at
>
> org.apache.usergrid.chop.webapp.view.runner.RunnersLayout.addRunnerToTable(RunnersLayout.java:121)
> at
>
> org.apache.usergrid.chop.webapp.view.runner.RunnersLayout.getRunnersTable(RunnersLayout.java:112)
>
>
> - Dave
>
Re: Short and Long Term Issues on Chop
Posted by Dave <sn...@gmail.com>.
On Thu, Jul 17, 2014 at 2:35 AM, Furkan Bıçak <bi...@gmail.com> wrote:
> Hi Dave,
>
> Right now, only requirement for runner instances to have a JDK installed.
> Therefore, using a custom AMI which has a JDK installed would be more
> convenient I suppose.
> Accordingly, you can use the AMI (ami-56a0463e) that is publicly available
> on US-East region which has Oracle JDK 7 installed if that meets your
> requirements.
Perfect. Thanks!
That works and now I'm on to the next error, shown below. I may not have
the coordinator webapp setup correctly. Is there a Maven build goal that
creates an assembly for the webapp? I used "mvn package" and the just
copied the war up to my coordinator instance; did I miss something?
2014-07-17 12:00:42.373 ERROR
service.runner.RunnerServiceImpl.getState(43)<qtp1765474380-141>- Error to
get a runner status:
com.sun.jersey.api.client.ClientHandlerException:
javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find
valid certification path to requested target
at
com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:155)
at com.sun.jersey.api.client.Client.handle(Client.java:652)
at com.sun.jersey.api.client.WebResource.handle(WebResource.java:682)
at com.sun.jersey.api.client.WebResource.access$200(WebResource.java:74)
at com.sun.jersey.api.client.WebResource$Builder.get(WebResource.java:509)
at
org.apache.usergrid.chop.client.rest.AbstractRestOperation.execute(AbstractRestOperation.java:133)
at
org.apache.usergrid.chop.client.rest.RestRequests.status(RestRequests.java:207)
at
org.apache.usergrid.chop.webapp.service.runner.RunnerServiceImpl.getState(RunnerServiceImpl.java:40)
at
org.apache.usergrid.chop.webapp.view.runner.RunnersLayout.addRunnerToTable(RunnersLayout.java:121)
at
org.apache.usergrid.chop.webapp.view.runner.RunnersLayout.getRunnersTable(RunnersLayout.java:112)
- Dave
Re: Short and Long Term Issues on Chop
Posted by Furkan Bıçak <bi...@gmail.com>.
Hi Dave,
Right now, only requirement for runner instances to have a JDK installed.
Therefore, using a custom AMI which has a JDK installed would be more
convenient I suppose.
Accordingly, you can use the AMI (ami-56a0463e) that is publicly available
on US-East region which has Oracle JDK 7 installed if that meets your
requirements.
Regards,
Furkan.
2014-07-16 22:53 GMT+03:00 Dave <sn...@gmail.com>:
> On Wed, Jul 16, 2014 at 3:19 PM, Dave <sn...@gmail.com> wrote:
>
> >
> > On Wed, Jul 16, 2014 at 2:09 PM, Yigit Sapli <yi...@apache.org> wrote:
> >
> >> Hello Dave,
> >>
> >> I'm really glad that you liked Chop.
> >>
> >> Have you set up the coordinator in EC2 or somewhere else? Because, all
> >> launched runner instances try to register themselves (their IPs, ports,
> >> etc.) to coordinator. And if the runners cannot reach the coordinator's
> IP
> >> as it's defined in the pom.xml, further operations will not be
> successful.
> >> If the coordinator is set up on EC2, this might be related to security
> >> group configuration in stack.json.
> >>
> >> If the problem seems to be happening because of something else, can you
> >> send a larger section of webapp's log, plus your stack.json? And log of
> >> one
> >> runner (located at /var/log/chop-runner.log on each runner instance) may
> >> help too.
> >>
> >>
> > I see this in the Runner's log:
> >
> > nohup: failed to run command ‘/usr/bin/java’: No such file or
> > directory
> >
> > ...and no other content.
> >
> > That's probably a good enough clue for me to debug this.
> >
>
>
> Yep. I found the issue: according to Chop's
> CoordinatorUtils.executeRunnerSSHCommands() method:
>
> /**
> * Start the runner.jar on instance.
> * This assumes an appropriate java is existing at /usr/bin/java on
> given instances,
> * so imageId for runners should be selected accordingly.
> */
>
> For my testing I need to use Oracle JDK all around so I think I'm going to
> have to either create a custom AMI and/or enhance Chop to add a "init"
> script to initialize runners, install the right JDK, etc. Any thoughts on
> those ideas?
>
> - Dave
>
Re: Short and Long Term Issues on Chop
Posted by Dave <sn...@gmail.com>.
On Wed, Jul 16, 2014 at 3:19 PM, Dave <sn...@gmail.com> wrote:
>
> On Wed, Jul 16, 2014 at 2:09 PM, Yigit Sapli <yi...@apache.org> wrote:
>
>> Hello Dave,
>>
>> I'm really glad that you liked Chop.
>>
>> Have you set up the coordinator in EC2 or somewhere else? Because, all
>> launched runner instances try to register themselves (their IPs, ports,
>> etc.) to coordinator. And if the runners cannot reach the coordinator's IP
>> as it's defined in the pom.xml, further operations will not be successful.
>> If the coordinator is set up on EC2, this might be related to security
>> group configuration in stack.json.
>>
>> If the problem seems to be happening because of something else, can you
>> send a larger section of webapp's log, plus your stack.json? And log of
>> one
>> runner (located at /var/log/chop-runner.log on each runner instance) may
>> help too.
>>
>>
> I see this in the Runner's log:
>
> nohup: failed to run command ‘/usr/bin/java’: No such file or
> directory
>
> ...and no other content.
>
> That's probably a good enough clue for me to debug this.
>
Yep. I found the issue: according to Chop's
CoordinatorUtils.executeRunnerSSHCommands() method:
/**
* Start the runner.jar on instance.
* This assumes an appropriate java is existing at /usr/bin/java on
given instances,
* so imageId for runners should be selected accordingly.
*/
For my testing I need to use Oracle JDK all around so I think I'm going to
have to either create a custom AMI and/or enhance Chop to add a "init"
script to initialize runners, install the right JDK, etc. Any thoughts on
those ideas?
- Dave
Re: Short and Long Term Issues on Chop
Posted by Dave <sn...@gmail.com>.
On Wed, Jul 16, 2014 at 2:09 PM, Yigit Sapli <yi...@apache.org> wrote:
> Hello Dave,
>
> I'm really glad that you liked Chop.
>
> Have you set up the coordinator in EC2 or somewhere else? Because, all
> launched runner instances try to register themselves (their IPs, ports,
> etc.) to coordinator. And if the runners cannot reach the coordinator's IP
> as it's defined in the pom.xml, further operations will not be successful.
> If the coordinator is set up on EC2, this might be related to security
> group configuration in stack.json.
>
> If the problem seems to be happening because of something else, can you
> send a larger section of webapp's log, plus your stack.json? And log of one
> runner (located at /var/log/chop-runner.log on each runner instance) may
> help too.
>
>
I see this in the Runner's log:
nohup: failed to run command ‘/usr/bin/java’: No such file or directory
...and no other content.
That's probably a good enough clue for me to debug this.
- Dave
Re: Short and Long Term Issues on Chop
Posted by Yigit Sapli <yi...@apache.org>.
Hello Dave,
I'm really glad that you liked Chop.
Have you set up the coordinator in EC2 or somewhere else? Because, all
launched runner instances try to register themselves (their IPs, ports,
etc.) to coordinator. And if the runners cannot reach the coordinator's IP
as it's defined in the pom.xml, further operations will not be successful.
If the coordinator is set up on EC2, this might be related to security
group configuration in stack.json.
If the problem seems to be happening because of something else, can you
send a larger section of webapp's log, plus your stack.json? And log of one
runner (located at /var/log/chop-runner.log on each runner instance) may
help too.
On Wednesday, July 16, 2014, Dave <sn...@gmail.com> wrote:
> Just say this possible clue in the coordinator logs:
>
> Jul 16, 2014 5:34:26 PM com.vaadin.server.VaadinServlet
> serveStaticResourcesInVAADIN
> INFO: Requested resource [/VAADIN/HEARTBEAT/] not found from filesystem or
> through class loader. Add widgetset and/or theme JAR to your classpath or
> add files to WebContent/VAADIN folder.
>
> - Dave
>
>
>
> On Wed, Jul 16, 2014 at 1:37 PM, Dave <snoopdave@gmail.com <javascript:;>>
> wrote:
>
> > Hi guys,
> >
> > Thanks for the help so far. Chop really looks great and I've made good
> > progress on getting Chop setup. I now have the coordinator web up and
> > running, I have a stack.json file that launches a working 3 node
> Cassandra
> > and a 3 node ElasticSearch cluster and the chop:setup command says that I
> > am all ready to run tests.
> >
> > INFO chop.plugin.MainMojo.execute(126)<main>- ====== Response from the
> > coordinator ======
> > INFO chop.plugin.MainMojo.execute(127)<main>- Stack is set up and ready
> to
> > start the tests.
> > INFO chop.plugin.MainMojo.execute(128)<main>-
> > =====================================
> >
> >
> > But, when I try to run the tests (in the ChoppedCassandraTests project)
> > the tests fail with this message:
> >
> > INFO chop.plugin.MainMojo.execute(113)<main>- ====== Response from the
> > coordinator ======
> > INFO chop.plugin.MainMojo.execute(114)<main>- Coordinator message: Cannot
> > start tests.
> > Not all runners are registered !!!
> > Number of registered runners : 0
> > INFO chop.plugin.MainMojo.execute(115)<main>-
> > =====================================
> >
> >
> > Any idea what I might be doing wrong or what my next steps should be to
> > debug this issue?
> >
> > I can give you guys access to my Coordinator webapp if that will help.
> >
> > Thanks,
> > Dave
> >
> >
> >
> >
> >
> >
> > On Tue, Jul 15, 2014 at 9:54 AM, Yigit Sapli <yigits@apache.org
> <javascript:;>> wrote:
> >
> >> Hello all,
> >>
> >> Thanks Furkan for helping out. Dave, please let us know if you're having
> >> any problems or if you have any suggestions.
> >>
> >> Regards,
> >> Yigit
> >>
> >> On Tue, Jul 15, 2014 at 7:39 PM, Dave <snoopdave@gmail.com
> <javascript:;>> wrote:
> >> > Thanks! The ChoppedCassandraTests project looks very useful and that
> is
> >> > where I'm going to start.
> >> >
> >> > - Dave
> >> >
> >> >
> >> >
> >> > On Tue, Jul 15, 2014 at 9:30 AM, Furkan Bıçak <bicak.cs@gmail.com
> <javascript:;>>
> >> wrote:
> >> >
> >> >> Hi Dave,
> >> >>
> >> >> I suppose that confluence page answers most of your questions for
> >> running
> >> >> Chop webapp both locally and on AWS. If not I can help you about the
> >> >> questions you have.
> >> >>
> >> >> Additionally, there is a simple project which uses a Cassandra
> cluster
> >> >> while doing its tests. It might be useful while getting started which
> >> you
> >> >> can find here: https://github.com/salihkardan/ChoppedCassandraTests
> >> >>
> >> >> Best,
> >> >> Furkan.
> >> >>
> >>
> >
> >
>
Re: Short and Long Term Issues on Chop
Posted by Dave <sn...@gmail.com>.
Just say this possible clue in the coordinator logs:
Jul 16, 2014 5:34:26 PM com.vaadin.server.VaadinServlet
serveStaticResourcesInVAADIN
INFO: Requested resource [/VAADIN/HEARTBEAT/] not found from filesystem or
through class loader. Add widgetset and/or theme JAR to your classpath or
add files to WebContent/VAADIN folder.
- Dave
On Wed, Jul 16, 2014 at 1:37 PM, Dave <sn...@gmail.com> wrote:
> Hi guys,
>
> Thanks for the help so far. Chop really looks great and I've made good
> progress on getting Chop setup. I now have the coordinator web up and
> running, I have a stack.json file that launches a working 3 node Cassandra
> and a 3 node ElasticSearch cluster and the chop:setup command says that I
> am all ready to run tests.
>
> INFO chop.plugin.MainMojo.execute(126)<main>- ====== Response from the
> coordinator ======
> INFO chop.plugin.MainMojo.execute(127)<main>- Stack is set up and ready to
> start the tests.
> INFO chop.plugin.MainMojo.execute(128)<main>-
> =====================================
>
>
> But, when I try to run the tests (in the ChoppedCassandraTests project)
> the tests fail with this message:
>
> INFO chop.plugin.MainMojo.execute(113)<main>- ====== Response from the
> coordinator ======
> INFO chop.plugin.MainMojo.execute(114)<main>- Coordinator message: Cannot
> start tests.
> Not all runners are registered !!!
> Number of registered runners : 0
> INFO chop.plugin.MainMojo.execute(115)<main>-
> =====================================
>
>
> Any idea what I might be doing wrong or what my next steps should be to
> debug this issue?
>
> I can give you guys access to my Coordinator webapp if that will help.
>
> Thanks,
> Dave
>
>
>
>
>
>
> On Tue, Jul 15, 2014 at 9:54 AM, Yigit Sapli <yi...@apache.org> wrote:
>
>> Hello all,
>>
>> Thanks Furkan for helping out. Dave, please let us know if you're having
>> any problems or if you have any suggestions.
>>
>> Regards,
>> Yigit
>>
>> On Tue, Jul 15, 2014 at 7:39 PM, Dave <sn...@gmail.com> wrote:
>> > Thanks! The ChoppedCassandraTests project looks very useful and that is
>> > where I'm going to start.
>> >
>> > - Dave
>> >
>> >
>> >
>> > On Tue, Jul 15, 2014 at 9:30 AM, Furkan Bıçak <bi...@gmail.com>
>> wrote:
>> >
>> >> Hi Dave,
>> >>
>> >> I suppose that confluence page answers most of your questions for
>> running
>> >> Chop webapp both locally and on AWS. If not I can help you about the
>> >> questions you have.
>> >>
>> >> Additionally, there is a simple project which uses a Cassandra cluster
>> >> while doing its tests. It might be useful while getting started which
>> you
>> >> can find here: https://github.com/salihkardan/ChoppedCassandraTests
>> >>
>> >> Best,
>> >> Furkan.
>> >>
>>
>
>
Re: Short and Long Term Issues on Chop
Posted by Dave <sn...@gmail.com>.
Hi guys,
Thanks for the help so far. Chop really looks great and I've made good
progress on getting Chop setup. I now have the coordinator web up and
running, I have a stack.json file that launches a working 3 node Cassandra
and a 3 node ElasticSearch cluster and the chop:setup command says that I
am all ready to run tests.
INFO chop.plugin.MainMojo.execute(126)<main>- ====== Response from the
coordinator ======
INFO chop.plugin.MainMojo.execute(127)<main>- Stack is set up and ready to
start the tests.
INFO chop.plugin.MainMojo.execute(128)<main>-
=====================================
But, when I try to run the tests (in the ChoppedCassandraTests project) the
tests fail with this message:
INFO chop.plugin.MainMojo.execute(113)<main>- ====== Response from the
coordinator ======
INFO chop.plugin.MainMojo.execute(114)<main>- Coordinator message: Cannot
start tests.
Not all runners are registered !!!
Number of registered runners : 0
INFO chop.plugin.MainMojo.execute(115)<main>-
=====================================
Any idea what I might be doing wrong or what my next steps should be to
debug this issue?
I can give you guys access to my Coordinator webapp if that will help.
Thanks,
Dave
On Tue, Jul 15, 2014 at 9:54 AM, Yigit Sapli <yi...@apache.org> wrote:
> Hello all,
>
> Thanks Furkan for helping out. Dave, please let us know if you're having
> any problems or if you have any suggestions.
>
> Regards,
> Yigit
>
> On Tue, Jul 15, 2014 at 7:39 PM, Dave <sn...@gmail.com> wrote:
> > Thanks! The ChoppedCassandraTests project looks very useful and that is
> > where I'm going to start.
> >
> > - Dave
> >
> >
> >
> > On Tue, Jul 15, 2014 at 9:30 AM, Furkan Bıçak <bi...@gmail.com>
> wrote:
> >
> >> Hi Dave,
> >>
> >> I suppose that confluence page answers most of your questions for
> running
> >> Chop webapp both locally and on AWS. If not I can help you about the
> >> questions you have.
> >>
> >> Additionally, there is a simple project which uses a Cassandra cluster
> >> while doing its tests. It might be useful while getting started which
> you
> >> can find here: https://github.com/salihkardan/ChoppedCassandraTests
> >>
> >> Best,
> >> Furkan.
> >>
>
Re: Short and Long Term Issues on Chop
Posted by Yigit Sapli <yi...@apache.org>.
Hello all,
Thanks Furkan for helping out. Dave, please let us know if you're having
any problems or if you have any suggestions.
Regards,
Yigit
On Tue, Jul 15, 2014 at 7:39 PM, Dave <sn...@gmail.com> wrote:
> Thanks! The ChoppedCassandraTests project looks very useful and that is
> where I'm going to start.
>
> - Dave
>
>
>
> On Tue, Jul 15, 2014 at 9:30 AM, Furkan Bıçak <bi...@gmail.com> wrote:
>
>> Hi Dave,
>>
>> I suppose that confluence page answers most of your questions for running
>> Chop webapp both locally and on AWS. If not I can help you about the
>> questions you have.
>>
>> Additionally, there is a simple project which uses a Cassandra cluster
>> while doing its tests. It might be useful while getting started which you
>> can find here: https://github.com/salihkardan/ChoppedCassandraTests
>>
>> Best,
>> Furkan.
>>
Re: Short and Long Term Issues on Chop
Posted by Dave <sn...@gmail.com>.
Thanks! The ChoppedCassandraTests project looks very useful and that is
where I'm going to start.
- Dave
On Tue, Jul 15, 2014 at 9:30 AM, Furkan Bıçak <bi...@gmail.com> wrote:
> Hi Dave,
>
> I suppose that confluence page answers most of your questions for running
> Chop webapp both locally and on AWS. If not I can help you about the
> questions you have.
>
> Additionally, there is a simple project which uses a Cassandra cluster
> while doing its tests. It might be useful while getting started which you
> can find here: https://github.com/salihkardan/ChoppedCassandraTests
>
> Best,
> Furkan.
>
Re: Short and Long Term Issues on Chop
Posted by Furkan Bıçak <bi...@gmail.com>.
Hi Dave,
I suppose that confluence page answers most of your questions for running
Chop webapp both locally and on AWS. If not I can help you about the
questions you have.
Additionally, there is a simple project which uses a Cassandra cluster
while doing its tests. It might be useful while getting started which you
can find here: https://github.com/salihkardan/ChoppedCassandraTests
Best,
Furkan.
Re: Short and Long Term Issues on Chop
Posted by Dave <sn...@gmail.com>.
For those following along...
Found this useful looking tutorial:
https://confluence.safehaus.org/display/CHOP/Stress+Testing+with+Chop+-+Tutorial
- Dave
On Mon, Jul 14, 2014 at 4:21 PM, Dave <sn...@gmail.com> wrote:
> Hi Yigit and others,
>
> I getting started with Chop today and hoping to use it to automate running
> the Core Persistence performance. First, I'd like to get a simple example
> project working with Chop, so I can understand how things fit together.
>
> Are there any getting started and installation documents around? Is the
> project README completely out of date or are there some parts that are
> still valid.
>
> My approach so far is to 1) get the Chop webapp running locally and 2) get
> the Chop Example project working with the webapp and AWS. I have figured
> out how to build and run the webapp (using -e for embedded ES) and I do not
> see any errors, but I can't figure out how to access the app. Any hints?
>
> I'm happy to document the steps I take, but I might need some pointers
> along the way.
>
> Thanks,
> - Dave
>
>
>
>
> On Mon, May 12, 2014 at 10:22 AM, Yigit Sapli <yi...@apache.org> wrote:
>
>> Hello everyone,
>>
>> Although this is mainly directed to people who are currently working on
>> Chop, I would definitely appreciate any additional inputs, opinions,
>> suggestions and questions. 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.
>>
>> 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. And as far as I know, Askat is finishing the new web UI
>> in
>> maximum couple of days.
>>
>> 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. I think this
>> might help others to get up to speed with configuring and using chop. So
>> if
>> anyone has any ideas on what example projects we can do, that'll be great.
>>
>> 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.
>> - We need to check the chop codebase for missing Apache License headers,
>> applying proper code styling and javadoc.
>> - We already have functional AMIs on Ec2 for both coordinator and runners,
>> but we have to update them and make them public.
>> - I will chain maven plugin goals, so that consecutive goals will be
>> executed automatically. For instance, when a user executes 'mvn
>> chop:start'
>> on a chop annotated project, it should automatically cover 'chop:runner',
>> 'chop:deploy', and 'chop:setup' goals if needed and start the tests.
>> - When a User deploys a project with existing commit Id and maven module
>> to
>> coordinator, coordinator should first ask to destroy the existing stack
>> for
>> that module and commit, or destroy automatically according to plugin
>> parameters. I'll handle that.
>> - 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.
>> - We need to review our usage of certificates and SSL communications
>> between plugin-coordinator and coordinator-runners, and make sure they're
>> concrete.
>> - 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.
>> - Right now, chop tests require at least one cluster defined in
>> stack.json.
>> Setting up test stacks with just runner instances might be needed.
>> - 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.
>> - 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.
>>
>> Regards,
>> Yigit Sapli
>>
>
>
Re: Short and Long Term Issues on Chop
Posted by Dave <sn...@gmail.com>.
Hi Yigit and others,
I getting started with Chop today and hoping to use it to automate running
the Core Persistence performance. First, I'd like to get a simple example
project working with Chop, so I can understand how things fit together.
Are there any getting started and installation documents around? Is the
project README completely out of date or are there some parts that are
still valid.
My approach so far is to 1) get the Chop webapp running locally and 2) get
the Chop Example project working with the webapp and AWS. I have figured
out how to build and run the webapp (using -e for embedded ES) and I do not
see any errors, but I can't figure out how to access the app. Any hints?
I'm happy to document the steps I take, but I might need some pointers
along the way.
Thanks,
- Dave
On Mon, May 12, 2014 at 10:22 AM, Yigit Sapli <yi...@apache.org> wrote:
> Hello everyone,
>
> Although this is mainly directed to people who are currently working on
> Chop, I would definitely appreciate any additional inputs, opinions,
> suggestions and questions. 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.
>
> 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. And as far as I know, Askat is finishing the new web UI in
> maximum couple of days.
>
> 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. I think this
> might help others to get up to speed with configuring and using chop. So if
> anyone has any ideas on what example projects we can do, that'll be great.
>
> 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.
> - We need to check the chop codebase for missing Apache License headers,
> applying proper code styling and javadoc.
> - We already have functional AMIs on Ec2 for both coordinator and runners,
> but we have to update them and make them public.
> - I will chain maven plugin goals, so that consecutive goals will be
> executed automatically. For instance, when a user executes 'mvn chop:start'
> on a chop annotated project, it should automatically cover 'chop:runner',
> 'chop:deploy', and 'chop:setup' goals if needed and start the tests.
> - When a User deploys a project with existing commit Id and maven module to
> coordinator, coordinator should first ask to destroy the existing stack for
> that module and commit, or destroy automatically according to plugin
> parameters. I'll handle that.
> - 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.
> - We need to review our usage of certificates and SSL communications
> between plugin-coordinator and coordinator-runners, and make sure they're
> concrete.
> - 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.
> - Right now, chop tests require at least one cluster defined in stack.json.
> Setting up test stacks with just runner instances might be needed.
> - 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.
> - 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.
>
> Regards,
> Yigit Sapli
>
Re: Short and Long Term Issues on Chop
Posted by Rod Simpson <ro...@rodsimpson.com>.
Great work guys!
--
Rod Simpson
On May 12, 2014 at 12:20:40 PM, Alex Karasulu (akarasulu@apache.org) wrote:
Hi Yigit,
On Mon, May 12, 2014 at 5:22 PM, Yigit Sapli <yi...@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
Re: Short and Long Term Issues on Chop
Posted by Alex Karasulu <ak...@apache.org>.
On Tue, May 13, 2014 at 2:52 PM, Askhat Asanaliev <aa...@apache.org>wrote:
> 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.
>
>
That's awesome, and it's looking great.
SNIP ....
> 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.
>
Thats wonderful. Looking forward to playing with that. I also know that a
couple of other chop developers lurking around here were looking to assist
in that matter. So where we can parcel up the work in JIRA and let people
pick at the tasks that would be awesome for growing more community.
--
Best Regards,
-- Alex
Re: Short and Long Term Issues on Chop
Posted by Askhat Asanaliev <aa...@apache.org>.
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.johnstonwatt@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 <ak...@apache.org> wrote:
>
> > Hi Yigit,
> >
> >
> > On Mon, May 12, 2014 at 5:22 PM, Yigit Sapli <yi...@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.
>
Re: Short and Long Term Issues on Chop
Posted by Alex Karasulu <ak...@apache.org>.
Hi Martin,
Again so sorry for responding so late. More inline ...
On Thu, May 15, 2014 at 3:54 PM, Martin Harris <
martin.harris@cloudsoftcorp.com> wrote:
> Hi Alex,
>
> I'd be keen to get involved if there's anything I can do to help.
Awesome! We would love to have more help. I'd love to have a Brooklyn/Chop
integration brainstorming session on a separate thread when both get a
chance.
Is there
> a separate repo for Usergrid 2.0? The current versions on github and apache
> are at 0.0.29-SNAPSHOT and don't contain any references to Chop
>
Pardon I wrote the links in another response for this. Here's the link
again (note branch two-dot-o):
https://github.com/usergrid/usergrid/tree/two-dot-o
--
Best Regards,
-- Alex
Re: Short and Long Term Issues on Chop
Posted by Alex Karasulu <ak...@apache.org>.
Hi Martin,
On Fri, May 16, 2014 at 1:19 PM, Martin Harris <
martin.harris@cloudsoftcorp.com> wrote:
> Thanks
>
> I've checked out Alex's chop project, and (after upgrading to java 7) it
> builds fine, except for one failing integration test
> (org.apache.usergrid.chop.integ.RunnerCoordinatorIT
> org.apache.usergrid.chop.integ.RunnerCoordinatorIT
> java.lang.RuntimeException: Could not bind the testField). @Alex, does this
> test pass for you?
>
>
Please make sure you're looking at the correct authoritative repository and
the right branch for the sources:
https://github.com/apache/incubator-usergrid/tree/two-dot-o/stack
which is synchronized to from here:
https://github.com/usergrid/usergrid/tree/two-dot-o
@Alex, could you also point me at the Usergrid 2.0 configuration, and I'll
> get started on a Brooklyn blueprint for it
>
>
An example UG 2.0 stack configuration used by chop can be found here:
https://github.com/usergrid/usergrid/blob/two-dot-o/stack/corepersistence/collection/src/test/resources/stack.json
At some point we need to transform some of Dave's scripts to actually build
out the instances which chop will run to create the clusters.
--
Best Regards,
-- Alex
Re: Short and Long Term Issues on Chop
Posted by Martin Harris <ma...@cloudsoftcorp.com>.
Thanks
I've checked out Alex's chop project, and (after upgrading to java 7) it
builds fine, except for one failing integration test
(org.apache.usergrid.chop.integ.RunnerCoordinatorIT
org.apache.usergrid.chop.integ.RunnerCoordinatorIT
java.lang.RuntimeException: Could not bind the testField). @Alex, does this
test pass for you?
@Alex, could you also point me at the Usergrid 2.0 configuration, and I'll
get started on a Brooklyn blueprint for it
Cheers
On 15 May 2014 15:54, Duncan Johnston Watt <
duncan.johnstonwatt@cloudsoftcorp.com> wrote:
> Martin
>
> As I understand it there are two things going on -
>
> 1. Alex Karasulu has created https://github.com/apigee/chop which is an
> open source project that is likely to be incubated in Apache at some stage.
> This is a stress test framework that runs in AWS but could in future
> leverage Brooklyn
>
> 2. There is a more advanced config of UserGrid which includes an
> ElasticSearch cluster which we could help set up by creating another
> blueprint -
>
> 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
>
>
> HTH
>
> Best
>
> Duncan
>
>
> On 15 May 2014 13:54, Martin Harris <ma...@cloudsoftcorp.com>wrote:
>
>> Hi Alex,
>>
>> I'd be keen to get involved if there's anything I can do to help. Is
>> there a separate repo for Usergrid 2.0? The current versions on github and
>> apache are at 0.0.29-SNAPSHOT and don't contain any references to Chop
>>
>> Cheers
>>
>> --
>> Martin Harris
>> Lead Software Engineer
>> Cloudsoft Corporation Ltd
>> www.cloudsoftcorp.com
>>
>>
>> On 13 May 2014 17:13, Alex Karasulu <ak...@apache.org> wrote:
>>
>>> On Tue, May 13, 2014 at 11:38 AM, Duncan Johnston Watt <
>>> duncan.johnstonwatt@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.
>>> >
>>> >
>>> Yes I've been actually considering how we can leverage brooklyn for this
>>> in
>>> the future. The blue print thingy is awesome and chop should be able to
>>> be
>>> used with it to simplify deployment.
>>>
>>>
>>> > [1] https://github.com/Nakomis
>>> > [2] https://github.com/cloudsoft/brooklyn-usergrid
>>> >
>>> >
>>> Thanks for pointing this out!
>>>
>>> Cheers,
>>> Alex
>>>
>>>
>>> > Best
>>> >
>>> > Duncan
>>> >
>>> >
>>> > On 12 May 2014 19:20, Alex Karasulu <ak...@apache.org> wrote:
>>> >
>>> > > Hi Yigit,
>>> > >
>>> > >
>>> > > On Mon, May 12, 2014 at 5:22 PM, Yigit Sapli <yi...@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.
>>> >
>>>
>>>
>>>
>>> --
>>> Best Regards,
>>> -- Alex
>>>
>>
>>
>>
>> --
>> Martin Harris
>> Lead Software Engineer
>> Cloudsoft Corporation Ltd
>> www.cloudsoftcorp.com
>> Mobile: +44 (0)7989 047-855
>>
>
>
>
> --
> 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.
>
--
Martin Harris
Lead Software Engineer
Cloudsoft Corporation Ltd
www.cloudsoftcorp.com
Mobile: +44 (0)7989 047-855
Re: Short and Long Term Issues on Chop
Posted by Alex Karasulu <ak...@apache.org>.
Hi Duncan,
Please excuse the delayed response. More inline ...
On Thu, May 15, 2014 at 5:54 PM, Duncan Johnston Watt <
duncan.johnstonwatt@cloudsoftcorp.com> wrote:
> Martin
>
> As I understand it there are two things going on -
>
> 1. Alex Karasulu has created https://github.com/apigee/chop which is an
> open source project that is likely to be incubated in Apache at some stage.
> This is a stress test framework that runs in AWS but could in future
> leverage Brooklyn
>
>
This is incorrect. This project is part of Usergrid and has gone through IP
clearance: you are correct regarding the use of Brooklyn and running on AWS
in your second sentence above. Need to do some research on Brooklyn
integration in the near future.
> 2. There is a more advanced config of UserGrid which includes an
> ElasticSearch cluster which we could help set up by creating another
> blueprint -
>
>
Excellent.
--
Best Regards,
-- Alex
Re: Short and Long Term Issues on Chop
Posted by Duncan Johnston Watt <du...@cloudsoftcorp.com>.
Martin
As I understand it there are two things going on -
1. Alex Karasulu has created https://github.com/apigee/chop which is an
open source project that is likely to be incubated in Apache at some stage.
This is a stress test framework that runs in AWS but could in future
leverage Brooklyn
2. There is a more advanced config of UserGrid which includes an
ElasticSearch cluster which we could help set up by creating another
blueprint -
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
HTH
Best
Duncan
On 15 May 2014 13:54, Martin Harris <ma...@cloudsoftcorp.com> wrote:
> Hi Alex,
>
> I'd be keen to get involved if there's anything I can do to help. Is there
> a separate repo for Usergrid 2.0? The current versions on github and apache
> are at 0.0.29-SNAPSHOT and don't contain any references to Chop
>
> Cheers
>
> --
> Martin Harris
> Lead Software Engineer
> Cloudsoft Corporation Ltd
> www.cloudsoftcorp.com
>
>
> On 13 May 2014 17:13, Alex Karasulu <ak...@apache.org> wrote:
>
>> On Tue, May 13, 2014 at 11:38 AM, Duncan Johnston Watt <
>> duncan.johnstonwatt@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.
>> >
>> >
>> Yes I've been actually considering how we can leverage brooklyn for this
>> in
>> the future. The blue print thingy is awesome and chop should be able to be
>> used with it to simplify deployment.
>>
>>
>> > [1] https://github.com/Nakomis
>> > [2] https://github.com/cloudsoft/brooklyn-usergrid
>> >
>> >
>> Thanks for pointing this out!
>>
>> Cheers,
>> Alex
>>
>>
>> > Best
>> >
>> > Duncan
>> >
>> >
>> > On 12 May 2014 19:20, Alex Karasulu <ak...@apache.org> wrote:
>> >
>> > > Hi Yigit,
>> > >
>> > >
>> > > On Mon, May 12, 2014 at 5:22 PM, Yigit Sapli <yi...@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.
>> >
>>
>>
>>
>> --
>> Best Regards,
>> -- Alex
>>
>
>
>
> --
> Martin Harris
> Lead Software Engineer
> Cloudsoft Corporation Ltd
> www.cloudsoftcorp.com
> Mobile: +44 (0)7989 047-855
>
--
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.
Re: Short and Long Term Issues on Chop
Posted by Alex Karasulu <ak...@apache.org>.
Thanks for pointing this out Todd.
On Fri, May 16, 2014 at 6:10 PM, Todd Nine <tn...@apigee.com> wrote:
> Hey Martin,
> Welcome! Check out the two-dot-o branch. All of the magic of the chop
> and new entity persistence is happening in this branch.
>
> Todd
>
>
> On Thu, May 15, 2014 at 6:54 AM, Martin Harris <
> martin.harris@cloudsoftcorp.com> wrote:
>
> > Hi Alex,
> >
> > I'd be keen to get involved if there's anything I can do to help. Is
> there
> > a separate repo for Usergrid 2.0? The current versions on github and
> apache
> > are at 0.0.29-SNAPSHOT and don't contain any references to Chop
> >
> > Cheers
> >
> > --
> > Martin Harris
> > Lead Software Engineer
> > Cloudsoft Corporation Ltd
> > www.cloudsoftcorp.com
> >
> >
> > On 13 May 2014 17:13, Alex Karasulu <ak...@apache.org> wrote:
> >
> > > On Tue, May 13, 2014 at 11:38 AM, Duncan Johnston Watt <
> > > duncan.johnstonwatt@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.
> > > >
> > > >
> > > Yes I've been actually considering how we can leverage brooklyn for
> this
> > in
> > > the future. The blue print thingy is awesome and chop should be able to
> > be
> > > used with it to simplify deployment.
> > >
> > >
> > > > [1] https://github.com/Nakomis
> > > > [2] https://github.com/cloudsoft/brooklyn-usergrid
> > > >
> > > >
> > > Thanks for pointing this out!
> > >
> > > Cheers,
> > > Alex
> > >
> > >
> > > > Best
> > > >
> > > > Duncan
> > > >
> > > >
> > > > On 12 May 2014 19:20, Alex Karasulu <ak...@apache.org> wrote:
> > > >
> > > > > Hi Yigit,
> > > > >
> > > > >
> > > > > On Mon, May 12, 2014 at 5:22 PM, Yigit Sapli <yi...@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.
> > > >
> > >
> > >
> > >
> > > --
> > > Best Regards,
> > > -- Alex
> > >
> >
> >
> >
> > --
> > Martin Harris
> > Lead Software Engineer
> > Cloudsoft Corporation Ltd
> > www.cloudsoftcorp.com
> > Mobile: +44 (0)7989 047-855
> >
>
--
Best Regards,
-- Alex
Re: Short and Long Term Issues on Chop
Posted by Todd Nine <tn...@apigee.com>.
Hey Martin,
Welcome! Check out the two-dot-o branch. All of the magic of the chop
and new entity persistence is happening in this branch.
Todd
On Thu, May 15, 2014 at 6:54 AM, Martin Harris <
martin.harris@cloudsoftcorp.com> wrote:
> Hi Alex,
>
> I'd be keen to get involved if there's anything I can do to help. Is there
> a separate repo for Usergrid 2.0? The current versions on github and apache
> are at 0.0.29-SNAPSHOT and don't contain any references to Chop
>
> Cheers
>
> --
> Martin Harris
> Lead Software Engineer
> Cloudsoft Corporation Ltd
> www.cloudsoftcorp.com
>
>
> On 13 May 2014 17:13, Alex Karasulu <ak...@apache.org> wrote:
>
> > On Tue, May 13, 2014 at 11:38 AM, Duncan Johnston Watt <
> > duncan.johnstonwatt@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.
> > >
> > >
> > Yes I've been actually considering how we can leverage brooklyn for this
> in
> > the future. The blue print thingy is awesome and chop should be able to
> be
> > used with it to simplify deployment.
> >
> >
> > > [1] https://github.com/Nakomis
> > > [2] https://github.com/cloudsoft/brooklyn-usergrid
> > >
> > >
> > Thanks for pointing this out!
> >
> > Cheers,
> > Alex
> >
> >
> > > Best
> > >
> > > Duncan
> > >
> > >
> > > On 12 May 2014 19:20, Alex Karasulu <ak...@apache.org> wrote:
> > >
> > > > Hi Yigit,
> > > >
> > > >
> > > > On Mon, May 12, 2014 at 5:22 PM, Yigit Sapli <yi...@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.
> > >
> >
> >
> >
> > --
> > Best Regards,
> > -- Alex
> >
>
>
>
> --
> Martin Harris
> Lead Software Engineer
> Cloudsoft Corporation Ltd
> www.cloudsoftcorp.com
> Mobile: +44 (0)7989 047-855
>
Re: Short and Long Term Issues on Chop
Posted by Martin Harris <ma...@cloudsoftcorp.com>.
Hi Alex,
I'd be keen to get involved if there's anything I can do to help. Is there
a separate repo for Usergrid 2.0? The current versions on github and apache
are at 0.0.29-SNAPSHOT and don't contain any references to Chop
Cheers
--
Martin Harris
Lead Software Engineer
Cloudsoft Corporation Ltd
www.cloudsoftcorp.com
On 13 May 2014 17:13, Alex Karasulu <ak...@apache.org> wrote:
> On Tue, May 13, 2014 at 11:38 AM, Duncan Johnston Watt <
> duncan.johnstonwatt@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.
> >
> >
> Yes I've been actually considering how we can leverage brooklyn for this in
> the future. The blue print thingy is awesome and chop should be able to be
> used with it to simplify deployment.
>
>
> > [1] https://github.com/Nakomis
> > [2] https://github.com/cloudsoft/brooklyn-usergrid
> >
> >
> Thanks for pointing this out!
>
> Cheers,
> Alex
>
>
> > Best
> >
> > Duncan
> >
> >
> > On 12 May 2014 19:20, Alex Karasulu <ak...@apache.org> wrote:
> >
> > > Hi Yigit,
> > >
> > >
> > > On Mon, May 12, 2014 at 5:22 PM, Yigit Sapli <yi...@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.
> >
>
>
>
> --
> Best Regards,
> -- Alex
>
--
Martin Harris
Lead Software Engineer
Cloudsoft Corporation Ltd
www.cloudsoftcorp.com
Mobile: +44 (0)7989 047-855
Re: Short and Long Term Issues on Chop
Posted by Alex Karasulu <ak...@apache.org>.
On Tue, May 13, 2014 at 11:38 AM, Duncan Johnston Watt <
duncan.johnstonwatt@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.
>
>
Yes I've been actually considering how we can leverage brooklyn for this in
the future. The blue print thingy is awesome and chop should be able to be
used with it to simplify deployment.
> [1] https://github.com/Nakomis
> [2] https://github.com/cloudsoft/brooklyn-usergrid
>
>
Thanks for pointing this out!
Cheers,
Alex
> Best
>
> Duncan
>
>
> On 12 May 2014 19:20, Alex Karasulu <ak...@apache.org> wrote:
>
> > Hi Yigit,
> >
> >
> > On Mon, May 12, 2014 at 5:22 PM, Yigit Sapli <yi...@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.
>
--
Best Regards,
-- Alex
Re: Short and Long Term Issues on Chop
Posted by Duncan Johnston Watt <du...@cloudsoftcorp.com>.
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 <ak...@apache.org> wrote:
> Hi Yigit,
>
>
> On Mon, May 12, 2014 at 5:22 PM, Yigit Sapli <yi...@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.
Re: Short and Long Term Issues on Chop
Posted by Alex Karasulu <ak...@apache.org>.
Hi Yigit,
On Mon, May 12, 2014 at 5:22 PM, Yigit Sapli <yi...@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