Giter Club home page Giter Club logo

wasabi's Introduction

Wasabi A/B Testing service is an open source project that is no longer under active development or being supported

Wasabi - A/B Testing Platform

Support: Join the chat at https://gitter.im/intuit/wasabi
Documentation: User Guide, JavaDocs
A/B Testing Overview: A/B Testing Overview Blog Meet Wasabi Blog Architecture Behind Wasabi
Continuous Integration: Build Status Coverage Status Maven Central
License: Apache 2

Project

Wasabi A/B Testing Service is a real-time, enterprise-grade, 100% API driven project. Users are empowered to own their own data, and run experiments across web, mobile, and desktop. It’s fast, easy to use, it’s chock full of features, and instrumentation is minimal.

Learn more about how Wasabi can empower your team to move from hunches to actionable, data-driven user insights with our simple, flexible, and scalable experimentation platform.

Features

  • Own your own data - Wasabi runs on your servers, in the cloud or on-premise, where you have complete control over your data.
  • Proven - Wasabi is battle-tested in production at Intuit, Inc., a financial technology company. Wasabi is the experimentation platform for TurboTax, QuickBooks, Mint.com, and other Intuit offerings.
  • High Performance - Consistent server-side response times for user assignments within 30ms.
  • 100% API-Driven - The Wasabi REST API is compatible with any language and environment.
  • Platform Agnostic - Uniform, consistent testing across Web, mobile, desktop. Also supports front-end, back-end integrations.
  • Real-time user assignments - Assign users into experiments in real time, to preserve traffic for other parallel A/B tests.
  • Cloud and on-premise - Designed to live in the cloud or in your own data center.
  • Analytics - Core experiment analytics and metrics visualization out of the box, as well as the ability to send data to your existing analytics infrastructure.
  • Pluggable - Well-defined interfaces for plugging in your own access control, sending data to data pipelines, and providing fully custom bucket allocations.
  • Experiment Management UI - Setup and manage experiments via a modern Web interface. Management via REST API is also possible.
  • Dockerized - Spin up a Wasabi Docker instance in 5 minutes and be in production with the platform, instrumentation, and experiments within a day.

User Interface

  • Create an experiment and its buckets:
  • Filter which customers are considered for your experiment:
  • Follow your currently running experiments:
  • Track your experiment results in real-time:

Get Started

The following steps will help you install the needed tools, then build and run a complete Wasabi stack.

Bootstrap Your Environment

Mac OS
% /usr/bin/ruby \
  -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
% brew install git
% git clone https://github.com/intuit/wasabi.git
% cd wasabi
% ./bin/wasabi.sh bootstrap

Installed tools include: homebrew 0.9, git 2, maven 3, java 1.8, docker 1.12, node 6 and python 2.7.

Ubuntu

Bootstrapping on Ubuntu requires sudo privileges to install all the required dependencies. You will be prompted to enter your password. Currently only 16.04 (x64) is supported.

% sudo apt-get install git
% git clone https://github.com/intuit/wasabi.git
% cd wasabi
% ./bin/wasabi.sh bootstrap
% sudo reboot

NOTE: A reboot is required after running the bootstrap command on Ubuntu.

For all other processes (build, start etc.) the commands are same for Ubuntu and Mac OS.

Installed tools include: git 2, maven 3, OpenJdk 8, docker 1.12, node 6 and python 2.7

Similar tooling will work for Windows. Contribute a patch :)

Start Wasabi

Now that we have the necessary tools in place, let's move on to build and start Wasabi, followed by issuing a ping command to verify the build:

% ./bin/wasabi.sh build start
...
wasabi is operational:

  ui: % open http://localhost:8080     note: sign in as admin/admin
  ping: % curl -i http://localhost:8080/api/v1/ping
  debug: attach to localhost:8180

% curl -i http://localhost:8080/api/v1/ping
HTTP/1.1 200 OK
Date: Wed, 25 May 2016 00:25:47 GMT
...
X-Application-Id: wasabi-api-20151215171929-SNAPSHOT-development
Content-Type: application/json
Transfer-Encoding: chunked
Server: Jetty(9.3.z-SNAPSHOT)

{
  "componentHealths":[
    {
      "componentName":"Experiments Cassandra",
      "healthy":true
    },
    {
      "componentName":"MySql","healthy":true
    }
  ],
  "wasabiVersion":"wasabi-api-20151215171929-SNAPSHOT-development"
}

Congratulations! You are the proud owner of a newly minted Wasabi instance. :)

Running Wasabi with remote storage

Set Mysql and Cassandra credentials
  • Modify /pom.xml to set the values that apply to your environment
Set up your environment variables
  • Set location of the migration tool
export CASSANDRA_MIGRATION=/location/of/cassandra-migration-0.9-jar-with-dependencies.jar
  • Set location of migration scripts within your project
export MIGRATION_SCRIPT=/location/of/modules/repository-datastax/src/main/resources/com/intuit/wasabi/repository/impl/cassandra/migration
Set up Cassandra tables
CQLSH_VERSION=<version> CQLSH_USERNAME=<username> CQLSH_PASSWORD=<pwd> CQLSH_HOST=<host> bin/docker/migration.sh
Run Wasabi with env variables for remote storage hosts
MYSQL_HOST=<mysql_host> NODE_HOST=<cassandra_host> ./bin/wasabi.sh start:wasabi
Run Wasabi outside of docker with WASABI_CONFIGURATION for remote storage hosts
WASABI_CONFIGURATION="
  -Ddatabase.url.host=$MYSQL_HOST\
  -Ddatabase.url.port=$MYSQL_PORT\
  -Ddatabase.url.dbname=$MYSQL_DATABASE\
  -Ddatabase.user=$MYSQL_USER\
  -Ddatabase.password=$MYSQL_PASSWORD\
  -Ddatabase.pool.connections.min=$MYSQL_MIN_CONNECTIONS\
  -Ddatabase.pool.connections.max=$MYSQL_MAX_CONNECTIONS\
  -Dusername=$CASSANDRA_USER\
  -Dpassword=$CASSANDRA_PASSWORD\
  -DnodeHosts=$CASSANDRA_HOST\
  -DtokenAwareLoadBalancingLocalDC=$CASSANDRA_DATACENTER\
  -Dapplication.http.port=$PORT" bash usr/local/wasabi-main-*/bin/run

Troubleshooting

  • While starting Wasabi, if you see an error when the docker containers are starting up, you could do the following:

    • Look at the current docker containers that have been successfully started.
% ./bin/wasabi.sh status

CONTAINER ID        IMAGE                    COMMAND                  CREATED             STATUS              PORTS                                                                     NAMES
8c12458057ef        wasabi-main              "entrypoint.sh wasabi"   25 minutes ago      Up 25 minutes       0.0.0.0:8080->8080/tcp, 0.0.0.0:8090->8090/tcp, 0.0.0.0:8180->8180/tcp    wasabi-main
979ecc885239        mysql:5.6                "docker-entrypoint.sh"   26 minutes ago      Up 26 minutes       0.0.0.0:3306->3306/tcp                                                    wasabi-mysql
2d33a96abdcb        cassandra:2.1            "/docker-entrypoint.s"   27 minutes ago      Up 27 minutes       7000-7001/tcp, 0.0.0.0:9042->9042/tcp, 7199/tcp, 0.0.0.0:9160->9160/tcp   wasabi-cassandra
  • The above shell output shows a successful start of 3 docker containers needed by Wasabi: wasabi-main (the Wasabi server), wasabi-mysql, and wasabi-cassandra. If any of these are not running, try starting them individually. For example, if the MySQL container is running, but Cassandra and Wasabi containers failed to start (perhaps due to a network timeout docker could not download the Cassandra image), do the following:
% ./bin/wasabi.sh start:cassandra

% ./bin/wasabi.sh start:wasabi

Call Wasabi

These are the 3 common REST endpoints that you will use to instrument your client application with Wasabi.

Let's assume that you've created and started an experiment, 'BuyButton,' in the 'Demo_App' application with the following buckets:

  • 'BucketA': green button (control bucket)
  • 'BucketB': orange button bucket

You can assign a user with a unique ID (e.g. 'userID1') to the experiment by making this HTTP request:

Assign a user to experiment and bucket:

% curl -H "Content-Type: application/json" \
    http://localhost:8080/api/v1/assignments/applications/Demo_App/experiments/BuyButton/users/userID1

{  
   "cache":true,
   "payload":"green",
   "assignment":"BucketA",
   "context":"PROD",
   "status":"NEW_ASSIGNMENT"
}

Now the 'userID1' user is assigned into the 'BucketA' bucket. Let's further record an impression, meaning the user has seen a given experience:

Record an impression:

% curl -H "Content-Type: application/json" \
    -d "{\"events\":[{\"name\":\"IMPRESSION\"}]}" \
    http://localhost:8080/api/v1/events/applications/Demo_App/experiments/BuyButton/users/userID1

If the 'userID1' user performs an action such as clicking the Buy button, you'd record that action with the following request:

Record an action:

% curl -H "Content-Type: application/json" \
    -d "{\"events\":[{\"name\":\"BuyClicked\"}]}" \
    http://localhost:8080/api/v1/events/applications/Demo_App/experiments/BuyButton/users/userID1

Explore Various Resources

The following developer resources are available:

API: Swagger API playground

% ./bin/wasabi.sh resource:api

Javadoc

% ./bin/wasabi.sh resource:doc

Wasabi UI

% ./bin/wasabi.sh resource:ui

Cassandra: cqlsh shell

% ./bin/wasabi.sh resource:cassandra

MySQL: mysql shell

% ./bin/wasabi.sh resource:mysql

Java Debugger: Remote attach configuration

-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8180

Stop Wasabi

Alas, all good things must come to an end. Let's clean things up a bit stop the newly created Wasabi stack:

At this point in time, we now have all the requisite tools installed, and subsequent invocations of Wasabi will start up much more quickly.

% ./bin/wasabi.sh stop

Get Familiar with wasabi.sh

Further, there are a number of additional wasabi.sh options available you should become familiar with:

% ./bin/wasabi.sh --help

  usage: wasabi.sh [options] [commands]

  options:
    -e | --endpoint [ host:port ]          : api endpoint; default: localhost:8080
    -v | --verify [ true | false ]         : verify installation configuration; default: false
    -s | --sleep [ sleep-time ]            : sleep/wait time in seconds; default: 30
    -h | --help                            : help message

  commands:
    bootstrap                              : install dependencies
    build                                  : build project
    start[:cassandra,mysql,wasabi]         : start all, cassandra, mysql, wasabi
    test                                   : test wasabi
    stop[:wasabi,cassandra,mysql]          : stop all, wasabi, cassandra, mysql
    resource[:ui,api,doc,cassandra,mysql]  : open resource api, javadoc, cassandra, mysql
    status                                 : display resource status
    remove[:wasabi,cassandra,mysql]        : remove all, wasabi, cassandra, mysql
    package                                : build deployable packages
    release[:start,finish]                 : promote release

Develop

Build and Run Wasabi Server

% mvn package
% ./bin/wasabi.sh start:cassandra,mysql
% (cd modules/main/target; \
    WASABI_CONFIGURATION="-DnodeHosts=localhost -Ddatabase.url.host=localhost" ./wasabi-main-*-SNAPSHOT-development/bin/run) &
% curl -i http://localhost:8080/api/v1/ping
...

The runtime logs can be accessed executing the following command in a another shell:

Viewing runtime logs:

% tail -f modules/main/target/wasabi-main-*-SNAPSHOT-development/logs/wasabi-main-*-SNAPSHOT-development.log

Build and Run Wasabi UI

% cd modules/ui
% grunt build
% grunt serve

Stop Wasabi

% ./bin/wasabi.sh stop

Now while that was fun, in all likelihood you will be using an IDE to work on Wasabi. In doing so, you need only add the configuration information above to the JVM commandline prior to startup:

Wasabi runtime configuration:

-DnodeHosts=localhost -Ddatabase.url.host=localhost

Run Integration Tests

Code changes can readily be verified by running the growing collection of included integration tests:

% ./bin/wasabi.sh start test stop
Troubleshooting

Integration tests might fail intermittently due to a time drift issue in docker containers on Mac OSX.

When the Mac sleeps and wakes back up, there is a lag created between the clock in the Mac vs the running docker containers. This is a known issue in Docker for Mac.

This can be fixed by running the following command:

% docker run --rm --privileged alpine hwclock -s

The above command will need to be run every time when there is a time drift.

To automatically run this command and update the time each time the Mac wakes up, you could install the following agent:

% curl https://raw.githubusercontent.com/arunvelsriram/docker-time-sync-agent/master/install.sh | bash

You can read more about this at: quick-tip-fixing-time-drift-issue-on-docker-for-mac

Package and Deploy at Scale

Wasabi can readily be packaged as installable rpm or deb distributions and deployed at scale as follows:

Package by running integration tests 1st:

% ./bin/wasabi.sh start package

Package without integration tests, if needed:

% ./bin/wasabi.sh -t false package

Find generated package files:

% find . -type f \( -name "*.rpm" -or -name "*.deb" \)

Note: Java 8 is a runtime dependency

Integrate

Wasabi is readily embeddable via the following maven dependency GAV family:

<dependency>
    <groupId>com.intuit.wasabi</groupId>
    <artifactId>wasabi</artifactId>
    <version>1.0.20160627213750<build_timestamp></version>
</dependency>

Contribute

We greatly encourage contributions! You can add new features, report and fix existing bugs, write docs and tutorials, or any of the above. Feel free to open issues and/or send pull requests.

The master branch of this repository contains the latest stable release of Wasabi, while snapshots are published to the develop branch. In general, pull requests should be submitted against develop by forking this repo into your account, developing and testing your changes, and creating pull requests to request merges. See the Contributing to a Project article for more details about how to contribute in general and find more specific information on how to write code for Wasabi in our user guide.

Extension projects such as browser plugins, client integration libraries, and apps can be contributed under the contrib directory.

Steps to contribute:

  1. Fork this repository into your account on Github
  2. Clone your forked repository (not our original one) to your hard drive with git clone https://github.com/YOURUSERNAME/wasabi.git
  3. Design and develop your changes
  4. Add/update unit tests
  5. Add/update integration tests
  6. Add/update documentation on gh-pages branch
  7. Create a pull request for review to request merge
  8. Obtain 2 approval squirrels before your changes can be merged

Thank you for your contribution!

wasabi's People

Contributors

abheekd avatar abhishekjain88 avatar andreasuckro avatar aqua0ps avatar atinder avatar bargenilesh avatar felixgao avatar gitter-badger avatar gittify avatar iizrailevsky avatar jcwuzoegiver avatar jwtodd avatar krushit avatar longdogz avatar mans4singh avatar maxbruckhaus avatar mgauthier avatar pi5 avatar rashmigs1993 avatar rgorti avatar rociomontes avatar shaikhjamir avatar shoeffner avatar shubhashreehebbar avatar sudheerkethireddy avatar tariqislam avatar thegyro avatar toddfast avatar vinodtalati avatar wasabi-honeybadger avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

wasabi's Issues

./bin/wasabi.sh build -- unit tests by default or not?

As I had a heated and highly opinionated discussion about this with @jwtodd today, I wanted to bring this up in a more objective context.

As of mid August, ./bin/wasabi.sh build wouldn't run unit tests anymore. It's not possible to turn them on other than either using ./bin/wasabi.sh test:{MODULE} or using maven directly.

A proposed simple fix is to apply the --verify flag to it as well and see if that's already enough.
Another solution is to do the above but also default to true instead of false.

@jwtodd highly recommended having package defaulting to true, and I want to have that behavior for build as well.

The reason is that before I create a pull request or give a pull request my :shipit: , I run: ./bin/wasabi.sh remove build start test stop to see if all tests pass. Now of course it's easy to change that workflow to ./bin/wasabi.sh remove build --verify=true start test stop, but I personally see only one good reason why one would want to not run the unit tests: a faster build time. And I am of the strong opinion that when someone wants to have a faster build time, then that person should consciously decide against testing, rather than having other people consciously deciding for testing.

I hope to discuss this matter here so that we can agree on a solution - for now @jwtodd and I had some consensus with the first proposed simple fix, but I feel it's not enough. And since our conversation was fading from fruitful to opinionated I decided to stop it, not change anything and get some other views on the issue. Especially since there must have been some discussions in August why we removed the test default in the first place at all.

P.S.: I do know and I do run tests also from my IDE, but especially for workflow mentioned it's not that easy, as e.g. IntelliJ can not simply run "all unit tests" in wasabi (at least I didn't find that, but I am happy with pointers to that), only a module by module basis which doesn't help me when I review a PR (or developed something) which spans multiple modules, a common thing given the interwoven structure of wasabi as of now.

Experiment segmentation rules "contains" etc.

Currently part of the segmentation rule feature in the UI is broken: After we rolled back Hyrule last year it went unnoticed that some of the features, e.g. segmentation rules like "contains", are not supported by the version we use.

To do: Get the newer Hyrule version performance tested and built back into the system (and open source it?) or remove those rules from the UI rule builder.

wasabi.sh and container.sh require bash 4.x

When running ./bin/wasabi.sh start:cassandra,mysql (or any other start sequence) I get syntax errors:

./bin/wasabi.sh: line 317: syntax error near unexpected token `&'
./bin/wasabi.sh: line 317: `    start) command="start:cassandra,mysql,wasabi";&'

I am using zsh (version 5.2) but also tried to run it with the vanilla OSX bash shell (version 3.2.57(1)-release from 2007), same error applies. Neither bash 3.2 nor zsh 5.0.8 support ;& as fall through, only bash 4(.3 linked).

It's not only wasabi.sh but also in container.sh.

The problem is also described on stackoverflow. To make the script more portable, consider portability and POSIX compliance.

For now I will be using an older script (git checkout origin/feature/experiment_pagination -- ./bin/wasabi.sh ./bin/container.sh).

Update: To use the script with zsh one has to do it explicitly: zsh ./bin/wasabi.sh thanks to the shebang line. However == still causes problems then. So it is probably the best idea to get bash 3.2 upgraded automatically.

Update 2: After posting this issue to the zsh mailing list Bart Schäfer recommended in a private mail to use the following: ARGV0=sh zsh wasabi.sh, which seems to solve the problems. I will now alias this in my rc file.
However that doesn't solve the bash 3.2 issue, so I will leave this open for now.

Handling of control bucket validation code

Where it is happening: REST Layer
Scenario: I have created (POST) an experiment and assigned two buckets (POST) to it with both of them having isControl parameter set to true.(It did accept them and i verified it using a GET on the experiment bucket, both the control parameters set to true for both buckets). When I am starting the experiment (PUT), I got an error saying

{
"error": {
"code": 400,
"message": "Only one bucket may be specified as a control bucket"
}
}

Question: It looks like the code to validate the buckets is happening during changing of experiment but not during the creation of bucket. I want to know if this analysis is correct ??

support linux

goal: driver script should be able to support
see: #23

  • ubuntu:apt
  • centos:yum
  • osx:homebrew

Mobile + JavaScript

Is the assumption that one would write wrappers or SDKs for JavaScript and native device languages to interface with the API?

In other words, is right now what's available just an API? This looks fantastic though. Thanks for open sourcing.

Package & Deploy Wasabi - "No such file or directory" after typing vagrant's password

Hello!

I am trying use wasabi's packaging script, but am not having much luck. Could I get some help?

  1. Packages are not built
    Upon checking out the code, I typed the following command to build the package:

./bin/wasabi.sh package

... as outlined in https://intuit.github.io/wasabi/v1/guide/index.html#package-and-deploy-wasabi-at-scale.

The script runs and doesn't appear to show "Package cannot be built". However, at the end, when I run the next command find ./modules -type f \( -name "*.rpm" -or -name "*.deb" \), it didn't show any files.

Is this expected?

  1. The script asks for password for [email protected].

This happened 3 times during the script runs. Based on the logs (See below), it attempts to connect to the machine but failed, and used the username/password as a fallback.

I used the "default" vagrant/vagrant as credentials, and it appeared to work.

  1. The script attempts to execute ./bin/fpm.sh, but the script was not found.

The script attempted to run a script on the VM... cd wasabi/modules/ui; ./bin/fpm.sh -n ${name} -v ${version} -p ${profile}. (Line 255).

However, the log (See below) shows that the directory actually doesn't exist.

Thanks!
-K

P.S. Here are the logs:

Execution Time (2016-08-05 01:24:37 UTC)
clean:dist         8.1s  ▇▇▇▇▇▇▇▇▇ 6%
concurrent:dist   38.8s  ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇ 27%
ngmin:dist          73s  ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇ 51%
uglify:generated  17.8s  ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇ 13%
Total 142.2s
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'https://github.com/2creatives/vagrant-centos/releases/download/v6.5.3/centos65-x86_64-20140116.box'...
==> default: Matching MAC address for NAT networking...
==> default: Setting the name of the VM: bin_default_1470360432770_71412
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Warning: Remote connection disconnect. Retrying...
    default: 
    default: Vagrant insecure key detected. Vagrant will automatically replace
    default: this with a newly generated keypair for better security.
    default: 
    default: Inserting generated public key within guest...
    default: Removing insecure key from the guest if it's present...
    default: Key inserted! Disconnecting and reconnecting using new SSH key...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period.

If you look above, you should be able to see the error(s) that
Vagrant had when attempting to connect to the machine. These errors
are usually good hints as to what may be wrong.

If you're using a custom box, make sure that networking is properly
working and you're able to connect to the machine. It is a common
problem that networking isn't setup properly in these boxes.
Verify that authentication configurations are also setup properly,
as well.

If the box appears to be booting properly, you may want to increase
the timeout ("config.vm.boot_timeout") value.
[email protected]'s password: 
bash: line 0: cd: wasabi: No such file or directory
bash: mvn: command not found
Connection to 127.0.0.1 closed.

package installation error on Ubuntu

I am seeing some errors when trying to install the .deb packages on Ubuntu.

wasabi-main-*.deb complains about missing dependencies: null and object.

wasabi-ui-*.deb complains about missing folders. One of the paths in the script is incorrect and needs updating. Here is the ui.deb file installation log:

sudo dpkg -i wasabi-ui-build_1.0.20160826233241-SNAPSHOT-20160831173901_all.deb
Selecting previously unselected package wasabi-ui-build.
(Reading database ... 178494 files and directories currently installed.)
Preparing to unpack wasabi-ui-build_1.0.20160826233241-SNAPSHOT-20160831173901_all.deb ...
Unpacking wasabi-ui-build (1.0.20160826233241-SNAPSHOT-20160831173901) ...
Setting up wasabi-ui-build (1.0.20160826233241-SNAPSHOT-20160831173901) ...
chown: cannot access '/usr/local/wasabi-1.0.20160826233241-SNAPSHOT-build/../wasabi-ui-1.0.20160826233241-SNAPSHOT-build': No such file or directory
cp: cannot stat '/usr/local/wasabi-1.0.20160826233241-SNAPSHOT-build/../wasabi-ui-1.0.20160826233241-SNAPSHOT-build/content/ui/dist/*': No such file or directory
The chown and cp commands need to point to /usr/local/wasabi-main-1.0.20160826233241-SNAPSHOT-build

After installation apt is also broken. If we try to install any packages after then apt prompts to remove the wasabi-main*.deb package. Not sure if this problem exists with rpm.

Reg state of Expired Experiment

Question: My Question is how do we represent the state of an expired Experiment. I have an experiment that is expired (meaning the end date of experiment is past the current date), but when I do a GET on the experiment, the state is being shown as "RUNNING". When I am trying to get all the bucket assignments of an user on the expired experiment, its showing as "EXPERIMENT_EXPIRED".so I wanted to know how are we capturing the experiment state, because it is inconsistent across both GET REST calls.

Improper Error Messages while Trying to change state of bucket

Minor Bug: When I am trying to update the state of a bucket with some Junk value,it gives an error message which is not intuitive and it doesnt tell as to what are availalbe values. It just points to some dev code.

REST end point: http://localhost:8080/api/v1/experiments/1a0e9dea-d7a4-4cbc-82bc-91e378119124/buckets/bucket1/state/ASDG

sample error message: java.lang.IllegalArgumentException: No enum constant com.intuit.wasabi.experimentobjects.Bucket.State.ASDG

Same is the case when we are trying to delete an experiment.
http://:/api/v1/experiments/some-junk-value
{
"error": {
"code": 500,
"message": "com.intuit.wasabi.experimentobjects.exceptions.InvalidIdentifierException: Invalid experiment identifier "aaaa7f6e-7a53-4cb5-a6de-a9675549ad3c-12345678901234567890""
}
}

How to run on Linux

Hi
I was trying to get the package deployed on linux. I got wasabi.sh to build the rpm and deb packages and the tried installing on ubuntu with "dpkg -i". Cant seem to find it on the system after installation.

Are there any docs available on how to get this configured and working?

vinod@vinod-virtual-machine:~/Desktop$ sudo dpkg -i wasabi.deb 
(Reading database ... 166492 files and directories currently installed.)
Preparing to unpack wasabi.deb ...
Unpacking wasabi-main-build (1.0.20160801220857-SNAPSHOT-20160818173207) over (1.0.20160801220857-SNAPSHOT-20160818173207) ...
Setting up wasabi-main-build (1.0.20160801220857-SNAPSHOT-20160818173207) ...
vinod@vinod-virtual-machine:~/Desktop$

scrub legacy names

goal: legacy name/package/etc need to be scrubbed

see: feature/scrub-legacy

  • [ws]/contrib/client-demo/error.html
  • [ws]/contrib/hello-world/app/index.html
  • [ws]/modules/api/src/test/java/com/intuit/wasabi/api/ExperimentsResourceTest.java
  • [ws]/modules/eventlog/README.md
  • [ws]/modules/functional-test/README.md

creating an event (impression) for an unassigned user gives a 201 response code

          I have created an experiment within an app. I tried creating an impression for a user without assigning the user to any bucket. The Api gives 201 as response code rather than throwing some warning/error saying that the user is not assigned.

Steps to re-produce.

  1. create an App (if not existing)
  2. create an experiment within the application.
  3. create buckets
  4. do a Post call to submit an event (of type impression) and it returns 201.

contrib a simple single-node terraform deploy script

goal: add a simple aws terraform deployment script

  • assume package (eg wasabi.rpm) is built local
  • instantiate single ec2 node, reasonably locked down and durable storage not required
  • yum install: java, cassandra, mysql (may not need runit)
  • rpm install wasabi
  • start wasabi
  • open external port
  • test via % ./bin/wasab.ish -e IP:8080 test
  • destroy instance
  • commit as a contrib project

support native docker

goal: require native docker vs docker machine

see: #2

steps:

  • remove docker-machine references
  • add brew support for native docker

testPostEvent(com.intuit.wasabi.eventlog.impl.EventLogImplTest): failing intermittently

testPostEvent(com.intuit.wasabi.eventlog.impl.EventLogImplTest)  Time elapsed: 0.623 sec  <<< FAILURE!
Wanted but not invoked:
eventLogListener.postEvent(
    com.intuit.wasabi.eventlog.events.SimpleEvent@2c95ac9e
);
-> at com.intuit.wasabi.eventlog.impl.EventLogImplTest.testPostEvent(EventLogImplTest.java:210)
Actually, there were zero interactions with this mock.
    at com.intuit.wasabi.eventlog.impl.EventLogImplTest.testPostEvent(EventLogImplTest.java:210)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:483)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
    at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
    at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
    at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
    at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:483)
    at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
    at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
    at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
    at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
    at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Running com.intuit.wasabi.eventlog.impl.NoopEventLogImplTest
22:43:04.066 [Thread-11] INFO  c.i.w.eventlog.impl.EventLogImpl - Shutting down event system, posting remaining events -- incoming events are no longer accepted.
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec
Running com.intuit.wasabi.eventlog.impl.EventLogEventEnvelopeTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
Running com.intuit.wasabi.eventlog.EventLogServiceTest
22:43:04.096 [main] INFO  c.i.wasabi.eventlog.EventLogService - already stopped EventLogService
22:43:04.098 [main] INFO  c.i.wasabi.eventlog.EventLogSystem - Started EventLogThread with ID 37.
22:43:04.098 [main] INFO  c.i.wasabi.eventlog.EventLogSystem - Interrupted EventLogThread with ID 37.
22:43:04.098 [main] INFO  c.i.wasabi.eventlog.EventLogSystem - EventLogThread with ID 37 joined.
22:43:04.099 [main] INFO  c.i.wasabi.eventlog.EventLogSystem - Started EventLogThread with ID 38.
22:43:04.099 [main] INFO  c.i.wasabi.eventlog.EventLogService - already started EventLogService
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026 sec
Results :
Failed tests:   testPostEvent(com.intuit.wasabi.eventlog.impl.EventLogImplTest): (..)

Deploying at Scale

Is there a way one can deploy at scale using docker and linux?
I'm assuming this is not how intuit runs it in production, but would like to setup something similar with our own standalone mysql / cassandra instances. Is there any in depth guide one can read?
Thank you!

Dockerized cassandra cannot be connected from external cqlsh

Using docker for mac 1.12.1

bin/wasabi.sh start:cassandra,mysql
93dce6dbd610534dd588806a7df34e1345d0822c78d1e35e2c85cd49eb63d63a
chill'ax 🍺 🍺 🍺 🍺 🍺 🍺 🍺 🍺 🍺 🍺
151b03b792705e52f1fc23e9dfc5fb649b63291eae529622b03afe7073eef860
chill'ax 🍺 🍺 🍺 🍺 🍺 🍺 🍺 🍺 🍺 🍺
Warning: Using a password on the command line interface can be insecure.
docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                                                                     NAMES
151b03b79270        mysql:5.6           "docker-entrypoint.sh"   34 minutes ago      Up 10 seconds       0.0.0.0:3306->3306/tcp                                                    wasabi-mysql
93dce6dbd610        cassandra:2.1       "/docker-entrypoint.s"   34 minutes ago      Up 41 seconds       7000-7001/tcp, 0.0.0.0:9042->9042/tcp, 7199/tcp, 0.0.0.0:9160->9160/tcp   wasabi-cassandra

on mac:

cqlsh
Connection error: ('Unable to connect to any servers', {'127.0.0.1': DriverException('ProtocolError returned from server while using explicitly set client protocol_version 4',)})

Regarding http status code while adding expired experiments as exclusive experiment

Layer: REST Layer
Issue:
scenario 1: Adding 1 expired experiment, When I am trying to add an expired experiment to a new experiment as an exclusive experiment, I got an http status code of 201 though in the response body it says failure (as the experiment is expired).

scenario 2: Adding 1 expired, 1 regular experiment, When I am trying to add two experiments (1 expired and other non-expired), I am getting a 201 though in the response body we have 1 failure and 1 success

Steps to reproduce:
create an experiment,and try adding expired experiment to list of mutually exclusive expirements. Repeat the above steps by adding two experiments now (1 expired and other not-expired) experiments. observer the error code and error message.

sample response got for scenario1:
Http response code: 201
Http response body:
{
"exclusions": [
{
"experimentID1": "a8fe12d0-9ce3-4a0b-b1bd-d14dbc2c3904",
"reason": "End time has passed for experiment2",
"experimentID2": "ec603c9f-9dcd-4687-8121-68a94e3eade4",
"status": "FAILED"
}
]
}

sample response got for scenario2:
Http response code: 201
Http response body:
{
"exclusions": [
{
"experimentID1": "a8fe12d0-9ce3-4a0b-b1bd-d14dbc2c3904",
"reason": "End time has passed for experiment2",
"experimentID2": "ec603c9f-9dcd-4687-8121-68a94e3eade4",
"status": "FAILED"
},
{
"experimentID1": "a8fe12d0-9ce3-4a0b-b1bd-d14dbc2c3904",
"experimentID2": "00805e14-1f3f-4a25-bf79-e14b0b8ab146",
"status": "SUCCESS"
}
]
}

Dockerfile explicit

As brought up by @felixgao , our Dockerfile as of now is auto-generated and copies from a magically unknown directory (.).
We should make it more explicit and either move it directly to modules/main or the root directory.

Decouple direct dependency from DateTime

In AssignmentImpl and many other classes there is a directly dependencies on

        final Date currentDate = new Date();
        final long currentTime = currentDate.getTime();

this will make test hard and does not help create static test cases and data for the system.

abstract all date/time related operations to a separate class that can be override by a property file

Windows batch scripts

Windows batch scripts are currently under development in feature/windows. They won't support docker native as we don't have access to Hyper-V on machines other than Windows 10.

We will try to follow a similar syntax as we have for the bin/wasabi.sh but for a start the scripts won't be as feature rich as the unix ones are: for now our goal is building and running locally in a docker-machine.

  • bootstrap
  • usage
  • build
  • start
  • test (optional for now)
  • integration tests failing since docker-machine stops the time on host sleep
  • stop
  • remove
  • package (optional for now) - won't fix now
  • resource (optional for now)
  • README.md updates

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.