rename almost all mentions of kargo

.github/ISSUE_TEMPLATE.md

@@ -24,7 +24,7 @@ explain why.
 - **Version of Ansible** (`ansible --version`):
 
 
-**Kargo version (commit) (`git rev-parse --short HEAD`):**
+**Kubespray version (commit) (`git rev-parse --short HEAD`):**
 
 
 **Network plugin used**:

README.md

@@ -14,12 +14,12 @@ If you have questions, join us on the [kubernetes slack](https://slack.k8s.io),
 To deploy the cluster you can use :
 
 [**kargo-cli**](https://github.com/kubespray/kargo-cli) <br>
-**Ansible** usual commands and [**inventory builder**](https://github.com/kubernetes-incubator/kargo/blob/master/contrib/inventory_builder/inventory.py) <br>
+**Ansible** usual commands and [**inventory builder**](https://github.com/kubernetes-incubator/kubespray/blob/master/contrib/inventory_builder/inventory.py) <br>
 **vagrant** by simply running `vagrant up` (for tests purposes) <br>
 
 
 *  [Requirements](#requirements)
-*  [Kargo vs ...](docs/comparisons.md)
+*  [Kubespray vs ...](docs/comparisons.md)
 *  [Getting started](docs/getting-started.md)
 *  [Ansible inventory and tags](docs/ansible.md)
 *  [Deployment data variables](docs/vars.md)
@@ -100,13 +100,13 @@ See also [Network checker](docs/netcheck.md).
  - [kubernetes.io/docs/getting-started-guides/kargo/](https://kubernetes.io/docs/getting-started-guides/kargo/)
  - [kargo, monitoring and logging](https://github.com/gregbkr/kubernetes-kargo-logging-monitoring) by @gregbkr
  - [Deploy Kubernetes w/ Ansible & Terraform](https://rsmitty.github.io/Terraform-Ansible-Kubernetes/) by @rsmitty
- - [Deploy a Kubernets Cluster with Kargo (video)](https://www.youtube.com/watch?v=N9q51JgbWu8)
+ - [Deploy a Kubernetes Cluster with Kargo (video)](https://www.youtube.com/watch?v=N9q51JgbWu8)
 
-## Tools and projects on top of Kargo
+## Tools and projects on top of Kubespray
  - [Digital Rebar](https://github.com/digitalrebar/digitalrebar)
  - [Kargo-cli](https://github.com/kubespray/kargo-cli)
  - [Fuel-ccp-installer](https://github.com/openstack/fuel-ccp-installer)
- - [Terraform Contrib](https://github.com/kubernetes-incubator/kargo/tree/master/contrib/terraform)
+ - [Terraform Contrib](https://github.com/kubernetes-incubator/kubespray/tree/master/contrib/terraform)
 
 ## CI Tests
 

RELEASE.md

@@ -1,16 +1,16 @@
 # Release Process
 
-The Kargo Project is released on an as-needed basis. The process is as follows:
+The Kubespray Project is released on an as-needed basis. The process is as follows:
 
 1. An issue is proposing a new release with a changelog since the last release
 2. At least on of the [OWNERS](OWNERS) must LGTM this release
 3. An OWNER runs `git tag -s $VERSION` and inserts the changelog and pushes the tag with `git push $VERSION`
 4. The release issue is closed
-5. An announcement email is sent to `[email protected]` with the subject `[ANNOUNCE] kargo $VERSION is released`
+5. An announcement email is sent to `[email protected]` with the subject `[ANNOUNCE] Kubespray $VERSION is released`
 
 ## Major/minor releases, merge freezes and milestones
 
-* Kargo does not maintain stable branches for releases. Releases are tags, not
+* Kubespray does not maintain stable branches for releases. Releases are tags, not
   branches, and there are no backports. Therefore, there is no need for merge
   freezes as well.
 
@@ -20,21 +20,21 @@ The Kargo Project is released on an as-needed basis. The process is as follows:
   support lifetime, which ends once the milestone closed. Then only a next major
   or minor release can be done.
 
-* Kargo major and minor releases are bound to the given ``kube_version`` major/minor
+* Kubespray major and minor releases are bound to the given ``kube_version`` major/minor
   version numbers and other components' arbitrary versions, like etcd or network plugins.
   Older or newer versions are not supported and not tested for the given release.
 
-* There is no unstable releases and no APIs, thus Kargo doesn't follow
+* There is no unstable releases and no APIs, thus Kubespray doesn't follow
   [semver](http://semver.org/). Every version describes only a stable release.
   Breaking changes, if any introduced by changed defaults or non-contrib ansible roles'
   playbooks, shall be described in the release notes. Other breaking changes, if any in
   the contributed addons or bound versions of Kubernetes and other components, are
-  considered out of Kargo scope and are up to the components' teams to deal with and
+  considered out of Kubespray scope and are up to the components' teams to deal with and
   document.
 
 * Minor releases can change components' versions, but not the major ``kube_version``.
-  Greater ``kube_version`` requires a new major or minor release. For example, if Kargo v2.0.0
+  Greater ``kube_version`` requires a new major or minor release. For example, if Kubespray v2.0.0
   is bound to ``kube_version: 1.4.x``, ``calico_version: 0.22.0``, ``etcd_version: v3.0.6``,
-  then Kargo v2.1.0 may be bound to only minor changes to ``kube_version``, like v1.5.1
+  then Kubespray v2.1.0 may be bound to only minor changes to ``kube_version``, like v1.5.1
   and *any* changes to other components, like etcd v4, or calico 1.2.3.
-  And Kargo v3.x.x shall be bound to ``kube_version: 2.x.x`` respectively.
+  And Kubespray v3.x.x shall be bound to ``kube_version: 2.x.x`` respectively.

contrib/aws_inventory/kargo-aws-inventory.py → contrib/aws_inventory/kubespray-aws-inventory.py

@@ -33,10 +33,10 @@ def search_tags(self):
     hosts = {}
     hosts['_meta'] = { 'hostvars': {} }
 
-    ##Search ec2 three times to find nodes of each group type. Relies on kargo-role key/value.
+    ##Search ec2 three times to find nodes of each group type. Relies on kubespray-role key/value.
     for group in ["kube-master", "kube-node", "etcd"]:
       hosts[group] = []
-      tag_key = "kargo-role"
+      tag_key = "kubespray-role"
       tag_value = ["*"+group+"*"]
       region = os.environ['REGION']
 

contrib/azurerm/README.md

@@ -5,7 +5,7 @@ Provision the base infrastructure for a Kubernetes cluster by using [Azure Resou
 ## Status
 
 This will provision the base infrastructure (vnet, vms, nics, ips, ...) needed for Kubernetes in Azure into the specified
-Resource Group. It will not install Kubernetes itself, this has to be done in a later step by yourself (using kargo of course).
+Resource Group. It will not install Kubernetes itself, this has to be done in a later step by yourself (using kubespray of course).
 
 ## Requirements
 
@@ -47,18 +47,18 @@ $ ./clear-rg.sh <resource_group_name>
 **WARNING** this really deletes everything from your resource group, including everything that was later created by you!
 
 
-## Generating an inventory for kargo
+## Generating an inventory for kubespray
 
 After you have applied the templates, you can generate an inventory with this call:
 
 ```shell
 $ ./generate-inventory.sh <resource_group_name>
 ```
 
-It will create the file ./inventory which can then be used with kargo, e.g.:
+It will create the file ./inventory which can then be used with kubespray, e.g.:
 
 ```shell
-$ cd kargo-root-dir
+$ cd kubespray-root-dir
 $ ansible-playbook -i contrib/azurerm/inventory -u devops --become -e "@inventory/group_vars/all.yml" cluster.yml
 ```
 

contrib/network-storage/glusterfs/README.md

@@ -1,12 +1,12 @@
-# Deploying a Kargo Kubernetes Cluster with GlusterFS
+# Deploying a Kubespray Kubernetes Cluster with GlusterFS
 
 You can either deploy using Ansible on its own by supplying your own inventory file or by using Terraform to create the VMs and then providing a dynamic inventory to Ansible. The following two sections are self-contained, you don't need to go through one to use the other. So, if you want to provision with Terraform, you can skip the **Using an Ansible inventory** section, and if you want to provision with a pre-built ansible inventory, you can neglect the **Using Terraform and Ansible**  section.
 
 ## Using an Ansible inventory
 
 In the same directory of this ReadMe file you should find a file named `inventory.example` which contains an example setup. Please note that, additionally to the Kubernetes nodes/masters, we define a set of machines for GlusterFS and we add them to the group `[gfs-cluster]`, which in turn is added to the larger `[network-storage]` group as a child group.
 
-Change that file to reflect your local setup (adding more machines or removing them and setting the adequate ip numbers), and save it to `inventory/k8s_gfs_inventory`. Make sure that the settings on `inventory/group_vars/all.yml` make sense with your deployment. Then execute change to the kargo root folder, and execute (supposing that the machines are all using ubuntu):
+Change that file to reflect your local setup (adding more machines or removing them and setting the adequate ip numbers), and save it to `inventory/k8s_gfs_inventory`. Make sure that the settings on `inventory/group_vars/all.yml` make sense with your deployment. Then execute change to the kubespray root folder, and execute (supposing that the machines are all using ubuntu):
 
 ```
 ansible-playbook -b --become-user=root -i inventory/k8s_gfs_inventory --user=ubuntu ./cluster.yml
@@ -28,7 +28,7 @@ k8s-master-node-2 ansible_ssh_host=192.168.0.146 ip=192.168.0.146 ansible_ssh_us
 
 ## Using Terraform and Ansible
 
-First step is to fill in a `my-kargo-gluster-cluster.tfvars` file with the specification desired for your cluster. An example with all required variables would look like:
+First step is to fill in a `my-kubespray-gluster-cluster.tfvars` file with the specification desired for your cluster. An example with all required variables would look like:
 
 ```
 cluster_name = "cluster1"
@@ -65,15 +65,15 @@ $ echo Setting up Terraform creds && \
   export TF_VAR_auth_url=${OS_AUTH_URL}
 ```
 
-Then, standing on the kargo directory (root base of the Git checkout), issue the following terraform command to create the VMs for the cluster:
+Then, standing on the kubespray directory (root base of the Git checkout), issue the following terraform command to create the VMs for the cluster:
 
 ```
-terraform apply -state=contrib/terraform/openstack/terraform.tfstate -var-file=my-kargo-gluster-cluster.tfvars contrib/terraform/openstack
+terraform apply -state=contrib/terraform/openstack/terraform.tfstate -var-file=my-kubespray-gluster-cluster.tfvars contrib/terraform/openstack
 ```
 
 This will create both your Kubernetes and Gluster VMs. Make sure that the ansible file `contrib/terraform/openstack/group_vars/all.yml` includes any ansible variable that you want to setup (like, for instance, the type of machine for bootstrapping).
 
-Then, provision your Kubernetes (Kargo) cluster with the following ansible call:
+Then, provision your Kubernetes (kubespray) cluster with the following ansible call:
 
 ```
 ansible-playbook -b --become-user=root -i contrib/terraform/openstack/hosts ./cluster.yml
@@ -88,5 +88,5 @@ ansible-playbook -b --become-user=root -i contrib/terraform/openstack/hosts ./co
 If you need to destroy the cluster, you can run:
 
 ```
-terraform destroy -state=contrib/terraform/openstack/terraform.tfstate -var-file=my-kargo-gluster-cluster.tfvars contrib/terraform/openstack
+terraform destroy -state=contrib/terraform/openstack/terraform.tfstate -var-file=my-kubespray-gluster-cluster.tfvars contrib/terraform/openstack
 ```

contrib/terraform/aws/README.md

@@ -33,7 +33,7 @@ export AWS_DEFAULT_REGION="zzz"
 
 - Terraform automatically creates an Ansible Inventory file called `hosts` with the created infrastructure in the directory `inventory`
 
-- Once the infrastructure is created, you can run the kargo playbooks and supply inventory/hosts with the `-i` flag.
+- Once the infrastructure is created, you can run the kubespray playbooks and supply inventory/hosts with the `-i` flag.
 
 **Troubleshooting**
 
@@ -54,4 +54,4 @@ It could happen that Terraform doesnt create an Ansible Inventory file automatic
 
 Pictured is an AWS Infrastructure created with this Terraform project distributed over two Availability Zones.
 
-![AWS Infrastructure with Terraform  ](docs/aws_kargo.png)
+![AWS Infrastructure with Terraform  ](docs/aws_kubespray.png)

contrib/terraform/aws/create-infrastructure.tf

@@ -157,7 +157,7 @@ resource "aws_instance" "k8s-worker" {
 
 
 /*
-* Create Kargo Inventory File
+* Create Kubespray Inventory File
 *
 */
 data "template_file" "inventory" {

docs/ansible.md

@@ -75,25 +75,25 @@ According to the [ansible docs](http://docs.ansible.com/ansible/playbooks_variab
 those cannot be overriden from the group vars. In order to override, one should use
 the `-e ` runtime flags (most simple way) or other layers described in the docs.
 
-Kargo uses only a few layers to override things (or expect them to
+Kubespray uses only a few layers to override things (or expect them to
 be overriden for roles):
 
 Layer | Comment
 ------|--------
-**role defaults** | provides best UX to override things for Kargo deployments
+**role defaults** | provides best UX to override things for Kubespray deployments
 inventory vars | Unused
 **inventory group_vars** | Expects users to use ``all.yml``,``k8s-cluster.yml`` etc. to override things
 inventory host_vars | Unused
 playbook group_vars | Unuses
 playbook host_vars | Unused
-**host facts** | Kargo overrides for internal roles' logic, like state flags
+**host facts** | Kubespray overrides for internal roles' logic, like state flags
 play vars | Unused
 play vars_prompt | Unused
 play vars_files | Unused
 registered vars | Unused
-set_facts | Kargo overrides those, for some places
+set_facts | Kubespray overrides those, for some places
 **role and include vars** | Provides bad UX to override things! Use extra vars to enforce
-block vars (only for tasks in block) | Kargo overrides for internal roles' logic
+block vars (only for tasks in block) | Kubespray overrides for internal roles' logic
 task vars (only for the task) | Unused for roles, but only for helper scripts
 **extra vars** (always win precedence) | override with ``ansible-playbook -e @foo.yml``
 

docs/aws.md

@@ -3,7 +3,7 @@ AWS
 
 To deploy kubespray on [AWS](https://aws.amazon.com/) uncomment the `cloud_provider` option in `group_vars/all.yml` and set it to `'aws'`.
 
-Prior to creating your instances, you **must** ensure that you have created IAM roles and policies for both "kubernetes-master" and "kubernetes-node". You can find the IAM policies [here](https://github.com/kubernetes-incubator/kargo/tree/master/contrib/aws_iam/). See the [IAM Documentation](https://aws.amazon.com/documentation/iam/) if guidance is needed on how to set these up. When you bring your instances online, associate them with the respective IAM role. Nodes that are only to be used for Etcd do not need a role.
+Prior to creating your instances, you **must** ensure that you have created IAM roles and policies for both "kubernetes-master" and "kubernetes-node". You can find the IAM policies [here](https://github.com/kubernetes-incubator/kubespray/tree/master/contrib/aws_iam/). See the [IAM Documentation](https://aws.amazon.com/documentation/iam/) if guidance is needed on how to set these up. When you bring your instances online, associate them with the respective IAM role. Nodes that are only to be used for Etcd do not need a role.
 
 The next step is to make sure the hostnames in your `inventory` file are identical to your internal hostnames in AWS. This may look something like `ip-111-222-333-444.us-west-2.compute.internal`. You can then specify how Ansible connects to these instances with `ansible_ssh_host` and `ansible_ssh_user`.
 
@@ -45,12 +45,12 @@ This will produce an inventory that is passed into Ansible that looks like the f
 
 Guide:
 - Create instances in AWS as needed.
-- Either during or after creation, add tags to the instances with a key of `kargo-role` and a value of `kube-master`, `etcd`, or `kube-node`. You can also share roles like `kube-master, etcd`
-- Copy the `kargo-aws-inventory.py` script from `kargo/contrib/aws_inventory` to the `kargo/inventory` directory.
+- Either during or after creation, add tags to the instances with a key of `kubespray-role` and a value of `kube-master`, `etcd`, or `kube-node`. You can also share roles like `kube-master, etcd`
+- Copy the `kubespray-aws-inventory.py` script from `kubespray/contrib/aws_inventory` to the `kubespray/inventory` directory.
 - Set the following AWS credentials and info as environment variables in your terminal:
 ```
 export AWS_ACCESS_KEY_ID="xxxxx"
 export AWS_SECRET_ACCESS_KEY="yyyyy"
 export REGION="us-east-2"
 ```
-- We will now create our cluster. There will be either one or two small changes. The first is that we will specify `-i inventory/kargo-aws-inventory.py` as our inventory script. The other is conditional. If your AWS instances are public facing, you can set the `VPC_VISIBILITY` variable to `public` and that will result in public IP and DNS names being passed into the inventory. This causes your cluster.yml command to look like `VPC_VISIBILITY="public" ansible-playbook ... cluster.yml`
+- We will now create our cluster. There will be either one or two small changes. The first is that we will specify `-i inventory/kubespray-aws-inventory.py` as our inventory script. The other is conditional. If your AWS instances are public facing, you can set the `VPC_VISIBILITY` variable to `public` and that will result in public IP and DNS names being passed into the inventory. This causes your cluster.yml command to look like `VPC_VISIBILITY="public" ansible-playbook ... cluster.yml`

docs/calico.md

@@ -96,7 +96,7 @@ You need to edit your inventory and add:
 * `cluster_id` by route reflector node/group (see details
 [here](https://hub.docker.com/r/calico/routereflector/))
 
-Here's an example of Kargo inventory with route reflectors:
+Here's an example of Kubespray inventory with route reflectors:
 
 ```
 [all]
@@ -145,11 +145,11 @@ cluster_id="1.0.0.1"
 The inventory above will deploy the following topology assuming that calico's
 `global_as_num` is set to `65400`:
 
-![Image](figures/kargo-calico-rr.png?raw=true)
+![Image](figures/kubespray-calico-rr.png?raw=true)
 
 ##### Optional : Define default endpoint to host action
 
-By default Calico blocks traffic from endpoints to the host itself by using an iptables DROP action. When using it in kubernetes the action has to be changed to RETURN (default in kargo) or ACCEPT (see https://github.com/projectcalico/felix/issues/660 and https://github.com/projectcalico/calicoctl/issues/1389). Otherwise all network packets from pods (with hostNetwork=False) to services endpoints (with hostNetwork=True) withing the same node are dropped.
+By default Calico blocks traffic from endpoints to the host itself by using an iptables DROP action. When using it in kubernetes the action has to be changed to RETURN (default in kubespray) or ACCEPT (see https://github.com/projectcalico/felix/issues/660 and https://github.com/projectcalico/calicoctl/issues/1389). Otherwise all network packets from pods (with hostNetwork=False) to services endpoints (with hostNetwork=True) withing the same node are dropped.
 
 
 To re-define default action please set the following variable in your inventory: