Update project name (#28)

OWNERS

@@ -0,0 +1,9 @@
+owners:
+- magaldima
+
+approvers:
+- edlee2121
+- jessesuen
+- shrinandj
+- VaibhavPage
+- vicaire

README.md

@@ -1,28 +1,25 @@
-# Axis - The Event-Based Dependency Manager for Kubernetes
+# Argo Events - The Event-Based Dependency Manager for Kubernetes
 
-## What is Axis?
-Axis is an open source event-based dependency manager for Kubernetes. The core concept of the project are `sensors` which are implemented as a Kubernetes-native Custom Resource Definition that define a set of dependencies (signals) and actions (triggers). The sensor's triggers will only be fired after it's signals have been resolved. `Sensors` can be once or repeated.
-- Define multiple dependencies from a variety of sources
+## What is Argo Events?
+Argo Events is an open source event-based dependency manager for Kubernetes. The core concept of the project are `sensors` which are implemented as Kubernetes-native Custom Resource Definition that define a set of dependencies (signals) and actions (triggers). The sensor's triggers will only be fired after it's signals have been resolved. `Sensors` can trigger once or repeatedly.
+- Define multiple dependencies from a variety of signal sources
 - Define dependency constraints and build plugins to support business-level constraint logic
 - Trigger messages and Kubernetes object creation after successful dependency resolution
 - Trigger escalation after errors, or dependency constraint failures
 - Build and manage a distributed, cross-team, event-driven architecture
-- Easily leverage Kubernetes native APIs to monitor dependencies
+- Easily leverage Kubernetes-native APIs to monitor dependencies
 
-## Why Axis?
-- Containers. Axis is designed from the ground-up as Kubernetes native. 
-- Extremely lightweight. All signals, with exception of calendar based signals, are event-driven, meaning there is no polling involved.
-- High performance. Each Axis `sensor` runs in its own Kubernetes job enabling high bandwidth for processing near-real time events.
-- Simple or Complex dependencies. Manage everything from simple, linear, real-time dependencies to complex, multi-source batch job dependencies.
+## Why Argo Events?
+- Containers. Designed from the ground-up as Kubernetes-native. 
+- Extremely lightweight. All signals, with the exception of calendar-based signals, are event-driven, meaning that there is no polling involved.
+- High performance. Each `sensor` runs in its own Kubernetes job, enabling high bandwidth for processing near real-time events.
+- Simple or Complex dependencies. Manage everything from simple, linear, real-time dependencies to complex, multi-source, batch job dependencies.
 
 ## Getting Started
-Axis is a Kubernetes CRD which can manage dependencies using kubectl commands.
+Argo Events is a Kubernetes CRD which can manage dependencies using kubectl commands.
 - [Learn about signals](./docs/signal-guide.md)
 - [Learn about triggers](./docs/trigger-guide.md)
 - [Review Sensor API](./docs/sensor-api.md)
 - [Getting started](./docs/quickstart.md)
 - [Want to contribute?](./CONTRIBUTING.md)
 - See where the project is headed in the [roadmap](./ROADMAP.md)
-
-
-Disclaimer: This is not an officially supported BlackRock or Aladdin product

ROADMAP.md

@@ -1,6 +1,4 @@
 # Roadmap
-Development of the project is currently managed via GitLab issues, however the following is a high-level overview of the future development plans for `Axis`.
-
 
 ## Development Phase
 - E2E testing

docs/artifact-guide.md

@@ -2,7 +2,7 @@
 `Sensors` support S3 artifact notifications. To take advantage of these artifact signals, you can use this guide to get started with installing artifact services.
 
 ## Minio
-[Minio](https://www.minio.io/) is an distributed object storage server. Follow the Minio [Bucket Notification Guide](https://docs.minio.io/docs/minio-bucket-notification-guide) for help with configuring your minio server to listen and monitor for bucket event notifications. Note that you will need an `Axis` supported message queue up and running as a prerequisite for configuring your notification targets (i.e. NATS, WebHooks, Kafka, etc.). 
+[Minio](https://www.minio.io/) is an distributed object storage server. Follow the Minio [Bucket Notification Guide](https://docs.minio.io/docs/minio-bucket-notification-guide) for help with configuring your minio server to listen and monitor for bucket event notifications. Note that you will need to setup a supported message queue for configuring your notification targets (i.e. NATS, WebHooks, Kafka, etc.). 
 
 ### Enabling bucket notifications
-Once the Minio server is configured with a notification target and you have restarted the server to put the changes into effect, you now need to explicitely enable event notifications for a specified bucket. Enabling these notifications are out of scope of `Axis` since bucket notifications are a construct within Minio that exists at the `bucket` level. This means that if `Axis` was responsible for the lifecycle of the bucket notifications, multiple sensors on the same S3 bucket would conflict with eachother. Thus, creating, updating, and deleting the Minio bucket notifications should be delegated to a separate process with knowledge of all notification targets including those outside of the `Axis` project.
+Once the Minio server is configured with a notification target and you have restarted the server to put the changes into effect, you now need to explicitely enable event notifications for a specified bucket. Enabling these notifications are out of scope of Argo Events since bucket notifications are a construct within Minio that exists at the `bucket` level. To avoid multiple sensors on the same S3 bucket conflicting with each other, creating, updating, and deleting Minio bucket notifications should be delegated to a separate process with knowledge of all notification targets including those outside of the Argo Events.

docs/index.md

@@ -1,13 +1,13 @@
-# Axis Documentation
+# Argo Events Documentation
 
-## Why Axis?
-- Containers. Axis is designed from the ground-up as Kubernetes native.
+## Why Argo Events?
+- Containers. Designed from the ground-up as Kubernetes-native.
 - Extremely lightweight. All signals, with exception of calendar based signals, are event-driven, meaning there is no polling involved.
-- High performance. Each Axis `sensor` runs in its own Kubernetes job enabling high bandwidth for processing near-real time events.
+- High performance. Each `sensor` runs in its own Kubernetes job enabling high bandwidth for processing near-real time events.
 - Simple or Complex dependencies. Manage everything from simple, linear, real-time dependencies to complex, multi-source batch job dependencies.
 
 ## Basics
-Axis is an open source event-based dependency manager for Kubernetes. The core concept of the project are `sensors` which are implemented as a Kubernetes-native Custom Resource Definition that define a set of dependencies (inputs) and actions (outputs). The sensor's actions will only be triggered after it's dependencies have been resolved.
+Argo Events is an open source event-based dependency manager for Kubernetes. The core concept of the project are `sensors` which are implemented as a Kubernetes-native Custom Resource Definition that define a set of dependencies (inputs) and actions (outputs). The sensor's actions will only be triggered after it's dependencies have been resolved.
 - Define multiple dependencies from a variety of sources
 - Define dependency constraints and build plugins to support business-level constraint logic
 - Trigger messages and Kubernetes object creation after successful dependency resolution

docs/quickstart.md

@@ -1,5 +1,5 @@
 # Getting Started - Quickstart
-This is a guide to getting started with using Axis using Minikube.
+This is a guide to getting started with Argo Events using Minikube.
 
 ## Requirements
 * Installed the [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) command-line tool >v1.9.0
@@ -10,7 +10,7 @@ This is a guide to getting started with using Axis using Minikube.
 
 ## 1. Checkout project's master branch
 ```
-$ git clone git@github.com:/axis.git
+$ git clone git@github.com:argoproj/argo-events.git
 ```
 
 ## 2. Install vendor dependencies
@@ -28,7 +28,7 @@ $ minikube start
 $ eval $(minikube docker-env)
 ```
 
-## 5. Build the Axis project & Docker images
+## 5. Build the project & Docker images
 ```
 $ cd go/src/github.com/argoproj/argo-events
 $ make all

docs/signal-guide.md

@@ -40,13 +40,13 @@ Webhook offers a basic HTTP server. User can provide the server port and registe
 See Request Methods in RFC7231 to define the HTTP REST endpoint.  
 
 ### Kubernetes Resources
-Axis supports watching Kubernetes resources. Users can specify `group`, `version`, `kind`, and filters including prefix of the object name, labels, annotations, and createdBy.
+Supports watching Kubernetes resources. Users can specify `group`, `version`, `kind`, and filters including prefix of the object name, labels, annotations, and createdBy.
 
 ### S3
-Axis supports S3 artifact signals in the form of `bucket-notifications` via [Minio](https://docs.minio.io/docs/minio-bucket-notification-guide). Note that a supported notification target must be running, exposed, and configured in the Minio server. For more information, please refer to the [artifact guide](artifact-guide.md).
+Supports S3 artifact signals in the form of `bucket-notifications` via [Minio](https://docs.minio.io/docs/minio-bucket-notification-guide). Note that a supported notification target must be running, exposed, and configured in the Minio server. For more information, please refer to the [artifact guide](artifact-guide.md).
 
 ### Message Streams / Brokers
-Axis supports a generic specification for message stream signals. Currently, there is a push signals toward being extensible and one solution we are investigating is toward classifying signals with common definitions and building a plugin-based architecture for supporting the specific signal implementations. The following defines the currently supported types of stream signals and examples of how to define them.
+Supports a generic specification for message stream signals. Currently, there is a push signals toward being extensible and one solution we are investigating is toward classifying signals with common definitions and building a plugin-based architecture for supporting the specific signal implementations. The following defines the currently supported types of stream signals and examples of how to define them.
 
 #### NATS
 [Nats](https://nats.io/) is an open-sourced, lightweight, secure, and scalable messaging system for cloud native applications and microservices architecture. It is currently a hosted CNCF Project. We are currently experimenting with using NATS as a solution for signals (inputs) and triggers (outputs), however `NATS Streaming`, the data streaming system powered by NATS, offers many  additional [features](https://nats.io/documentation/streaming/nats-streaming-intro/) on top of the core NATS platform that we believe are very desirable and definite future enhancements.