Merge branch 'master' into v2_rest_api

.travis.yml

@@ -1,8 +1,7 @@
 sudo: false
 language: go
 go:
-- 1.6.3
-- 1.7.1
+- 1.7.3
 before_install:
 - bash scripts/gitcookie.sh
 - go get github.com/smartystreets/goconvey/convey
@@ -16,25 +15,22 @@ env:
   - SNAP_TEST_TYPE=small
   - SNAP_TEST_TYPE=medium
   - SNAP_TEST_TYPE=build
-matrix:
-  exclude:
-  - go: 1.6.3
-    env: SNAP_TEST_TYPE=build
 install:
 - export TMPDIR=$HOME/tmp
 - mkdir -p $TMPDIR
 - cd $SNAP_SOURCE # change dir into source
 - make
 script:
-- make check 2>&1 # Run test suite
+- make test 2>&1 # Run test suite
 notifications:
   email: false
   slack:
     secure: VkbZLIc2RH8yf3PtIAxUNPdAu3rQQ7yQx0GcK124JhbEnZGaHyK615V0rbG7HcVmYKGPdB0cXqZiLBDKGqGKb2zR1NepOe1nF03jxGSpPq8jIFeEXSJGEYGL34ScDzZZGuG6qwbjFcXiW5lqn6t8igzp7v2+URYBaZo5ktCS2xY=
 before_deploy:
+- make all
 - "./scripts/pre_deploy.sh"
 deploy:
-  provider: s3
+- provider: s3
   access_key_id: AKIAINMB43VSSPFZISAA
   secret_access_key:
     secure: vEWq7ImahLeJ3n+RsazhuCuzRV5b8biZRy3HpqJlNasSAqUPvugGD8TrhaK/3fru931flVLsLdFJObG3cIHmJrJDaLS+Zv7707+yAPHOLrATedO530P89CPlJpDmbPNuqU2e+6NfCu7DZQdceXF5hSQRIVeVloHcsnoo7XG4VFHPrIOCB+JbWnVquH7wtOn3h0RcOtzQQgdehqKB2c6Yi68wFkgKIEyIQHL63m28biMn1nMH1i0lYCN4rk8kxhPWar6e86JPeDvyhUbXixokXsy0H3J819yWwZIejb0UCucJmXMG+m9jMNXwh1DoC4+HMvFnzUdB61G6nYCPFz0GRyw363sXCg2rBizkTyhVF1Bd039gWgGFm6rb5cUKTlvNuvWe+x1E0lX8G3pPa8ZFX7/i2P9GPJCt8LHnZnskIHv0Yic/+6Kt89veS0YWgQRUuSGDnhaMuJHeyZppiFr4ALUi032/qTCuTj6z/v7UMpDSkPGpCh4505mMVsx11lT7zoZnK5/1Qxfd8ysJgfPKcptJXMfYjX/8QFT9EPok4KMx6E2k8hS82rT5i1pjjE9Kw18xqJNlWOUatfX5jzzoCYxuj/d99Zu4gD0n7UUN5rcNY7xrrBwYPmPaIKOTp+k+RdwlRIhxaXr2j5GFCaSPrtDobULioJIHfdbxVjrThQY=
@@ -47,4 +43,18 @@ deploy:
   on:
     repo: intelsdi-x/snap
     branch: master
-    condition: $SNAP_TEST_TYPE = build && $TRAVIS_GO_VERSION = "1.7.1"
+    condition: $SNAP_TEST_TYPE = build && $TRAVIS_GO_VERSION = "1.7.3"
+- provider: s3
+  access_key_id: AKIAINMB43VSSPFZISAA
+  secret_access_key:
+    secure: vEWq7ImahLeJ3n+RsazhuCuzRV5b8biZRy3HpqJlNasSAqUPvugGD8TrhaK/3fru931flVLsLdFJObG3cIHmJrJDaLS+Zv7707+yAPHOLrATedO530P89CPlJpDmbPNuqU2e+6NfCu7DZQdceXF5hSQRIVeVloHcsnoo7XG4VFHPrIOCB+JbWnVquH7wtOn3h0RcOtzQQgdehqKB2c6Yi68wFkgKIEyIQHL63m28biMn1nMH1i0lYCN4rk8kxhPWar6e86JPeDvyhUbXixokXsy0H3J819yWwZIejb0UCucJmXMG+m9jMNXwh1DoC4+HMvFnzUdB61G6nYCPFz0GRyw363sXCg2rBizkTyhVF1Bd039gWgGFm6rb5cUKTlvNuvWe+x1E0lX8G3pPa8ZFX7/i2P9GPJCt8LHnZnskIHv0Yic/+6Kt89veS0YWgQRUuSGDnhaMuJHeyZppiFr4ALUi032/qTCuTj6z/v7UMpDSkPGpCh4505mMVsx11lT7zoZnK5/1Qxfd8ysJgfPKcptJXMfYjX/8QFT9EPok4KMx6E2k8hS82rT5i1pjjE9Kw18xqJNlWOUatfX5jzzoCYxuj/d99Zu4gD0n7UUN5rcNY7xrrBwYPmPaIKOTp+k+RdwlRIhxaXr2j5GFCaSPrtDobULioJIHfdbxVjrThQY=
+  bucket: snap.ci.snap-telemetry.io
+  region: us-west-2
+  skip_cleanup: true
+  local-dir: s3/snap
+  upload-dir: snap
+  acl: public_read
+  on:
+    repo: intelsdi-x/snap
+    tags: true
+    condition: $SNAP_TEST_TYPE = build && $TRAVIS_GO_VERSION = "1.7.3"

CODE_OF_CONDUCT.md

@@ -0,0 +1,75 @@
+# Snap Contributor Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers of Snap pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, gender identity and expression, level of experience,
+nationality, personal appearance, race, religion, or sexual identity and
+orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Our Responsibilities
+
+Snap maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Snap maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing Snap or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account such as Slack or Twitter, 
+or acting as an appointed representative at an online or offline event. 
+Representation of a project may be further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting Snap's team leads B.J. Ray bj.ray@intel.com and/or 
+Arek Chylinski arek.chylinski@intel.com. All complaints will be reviewed and 
+investigated and will result in a response that is deemed necessary and appropriate 
+to the circumstances. The project team is obligated to maintain confidentiality 
+with regard to the reporter of an incident. Further details of specific 
+enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at [http://contributor-covenant.org/version/1/4][version]
+
+[homepage]: http://contributor-covenant.org
+[version]: http://contributor-covenant.org/version/1/4/

CONTRIBUTING.md

@@ -5,7 +5,7 @@ will cover how to contribute code, report issues, build the project and run the
 
 ## Contributing Code
 
-Contribution of code to snap is a snap (pun intended):
+Contributing code to Snap is a snap (pun intended):
 - Fork the project to your own repository
 - Create a topic branch from where you want to base your work (usually master)
 - Make commit(s) (following commit guidelines below)
@@ -29,7 +29,7 @@ with what commits were fixes and what commits were features.
 
 For any pull request submitted, the maintainers of Snap require `small` tests that cover the code being modified and/or features being added; `medium` and `large` tests are also welcome but are not required. This breakdown of tests into `small`, `medium`, and `large` is a new taxonomy adopted by the Snap team in May, 2016. These three test types can be best described as follows:
 * **Small** tests are written to exercise behavior within a single function or module. While of you might think of these as *unit* tests, a more generic term seems appropriate to avoid any confusion. In general, there is no reliance in a *small* test on any external systems (databases, web servers, etc.), and responses expected from such external services (if any) will be *mocked* or *faked*. When we say reliance on “external systems” we are including reliance on access to the network, the filesystem, external systems (eg. databases), system properties, multiple threads of execution, or the use of sleep statements as part of the test. These tests should be the easiest to automate and the fastest to run (returning a result in a minute or less, with most returning a result in a few seconds or less). These tests will be run automatically on any pull requests received from a contributor, and all *small* tests must pass before a pull request will be reviewed.
-* **Medium** tests involve two or more features and test the interaction between those features. For those with previous testing experience, you might think of these as *integration* tests, but because there are a large number of other types of tests that fall into this category a more generic term is needed. The question being answered by these tests is whether or not the interactions between a feature and it’s nearest neighbors interoperate the way that they are expected to. *Medium* tests can rely on access to local services (a local database, for example), the local filesystem, multiple threads of execution, sleep statements and even access to the (local) network. However, reliance on access to external systems and services (systems and services not available on the localhost) in *medium* tests is discouraged. In general, we should expect that these tests return a result in 5 minutes or less, although some *medium* tests may return a result in much less time than that (depending on local system load). These tests can typically be automated and the set of *medium* tests will be run against any builds prior to their release.
+* **Medium** tests involve two or more features and test the interaction between those features. For those with previous testing experience, you might think of these as *integration* tests, but because there are a large number of other types of tests that fall into this category a more generic term is needed. The question being answered by these tests is whether or not the interactions between a feature and its nearest neighbors interoperate the way that they are expected to. *Medium* tests can rely on access to local services (a local database, for example), the local filesystem, multiple threads of execution, sleep statements and even access to the (local) network. However, reliance on access to external systems and services (systems and services not available on the localhost) in *medium* tests is discouraged. In general, we should expect that these tests return a result in 5 minutes or less, although some *medium* tests may return a result in much less time than that (depending on local system load). These tests can typically be automated and the set of *medium* tests will be run against any builds prior to their release.
 * **Large** tests represent typical user scenarios and might be what some of you would think of as *functional* tests. However, as was the case with the previous two categories, we felt that the more generic term used by the Google team seemed to be appropriate here. For these tests, reliance on access to the network, local services (like databases), the filesystem, external systems, multiple threads of execution, system properties, and the use of sleep statements within the tests are all supported. Some of these tests might be run manually as part of the release process, but every effort is made to ensure that even these *large* tests can be automated (where possible). The response times for testing of some of these user scenarios could be 15 minutes or more (eg. it may take some time to bring the system up to an equilibrium state when load testing), so there are situations where these *large* tests will have to be triggered manually even if the test itself is run as an automated test.
 
 This taxonomy is the same taxonomy used by the Google Test team and was described in a posting to the Google Testing Blog that can be found [here](http://googletesting.blogspot.com/2010/12/test-sizes.html).
@@ -60,6 +60,14 @@ When reporting an issue, details are key. Include the following:
 - Actual results
 - Expected results
 
+## Reporting Security Issues
+
+The Snap team take security very seriously. If you have any issue regarding security,
+please notify us by sending an email to snap-security@intel.com and not by creating a GitHub issue.
+We will follow up with you promptly with more information and a plan for remediation.
+While we are not offering a security bounty, we would love to send some Snap swag your way along with our
+deepest gratitude for your assistance in making Snap a more secure product.
+
 ## Notes on GitHub Usage
 It's worth noting that we don't use all the native GitHub features for issue management. For instance, it's uncommon for us to assign issues to the developer who will address it. Here are notes on what we do use.
 

Makefile

@@ -20,7 +20,8 @@ ARCH = $(shell uname -m)
 
 default:
 	$(MAKE) deps
-	$(MAKE) all
+	$(MAKE) snap
+	$(MAKE) plugins
 deps:
 	bash -c "./scripts/deps.sh"
 test:
@@ -33,12 +34,28 @@ test-medium:
 	bash -c "./scripts/test.sh medium"
 test-large:
 	bash -c "./scripts/test.sh large"
-check:
-	$(MAKE) test
-all:
+test-all:
+	$(MAKE) test-legacy
+	$(MAKE) test-medium
+	$(MAKE) test-small
+	$(MAKE) test-large
+# NOTE:
+# By default compiles will use all cpu cores, use BUILD_JOBS to control number
+# of parallel builds: `BUILD_JOBS=2 make plugins`
+#
+# Build only snapteld/snaptel
+snap:
 	bash -c "./scripts/build_snap.sh"
+# Build only plugins
+plugins:
+	bash -c "./scripts/build_plugins.sh"
+# Build snap and plugins for all platforms
+all:
+	bash -c "./scripts/build_all.sh"
 install:
-	cp build/$(OS)/$(ARCH)/snapd /usr/local/bin/
-	cp build/$(OS)/$(ARCH)/snapctl /usr/local/bin/
+	mkdir -p /usr/local/sbin
+	mkdir -p /usr/local/bin
+	cp build/$(OS)/$(ARCH)/snapteld /usr/local/sbin/
+	cp build/$(OS)/$(ARCH)/snaptel /usr/local/bin/
 proto:
 	cd `echo $(GOPATH) | cut -d: -f 1`; bash -c "./src/github.com/intelsdi-x/snap/scripts/gen-proto.sh"