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 `kubernetes-dev@googlegroups.com` with the subject `[ANNOUNCE] kargo $VERSION is released`
+5. An announcement email is sent to `kubernetes-dev@googlegroups.com` 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 @@ class SearchEC2Tags(object):
     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,7 +47,7 @@ $ ./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:
 
@@ -55,10 +55,10 @@ After you have applied the templates, you can generate an inventory with this ca
 $ ./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,4 +1,4 @@
-# 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.
 
@@ -6,7 +6,7 @@ You can either deploy using Ansible on its own by supplying your own inventory f
 
 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:

docs/comparisons.md

@@ -1,25 +1,25 @@
-Kargo vs [Kops](https://github.com/kubernetes/kops)
+Kubespray vs [Kops](https://github.com/kubernetes/kops)
 ---------------
 
-Kargo runs on bare metal and most clouds, using Ansible as its substrate for
+Kubespray runs on bare metal and most clouds, using Ansible as its substrate for
 provisioning and orchestration. Kops performs the provisioning and orchestration
 itself, and as such is less flexible in deployment platforms. For people with
 familiarity with Ansible, existing Ansible deployments or the desire to run a
-Kubernetes cluster across multiple platforms, Kargo is a good choice. Kops,
+Kubernetes cluster across multiple platforms, Kubespray is a good choice. Kops,
 however, is more tightly integrated with the unique features of the clouds it
 supports so it could be a better choice if you know that you will only be using
 one platform for the foreseeable future.
 
-Kargo vs [Kubeadm](https://github.com/kubernetes/kubeadm)
+Kubespray vs [Kubeadm](https://github.com/kubernetes/kubeadm)
 ------------------
 
 Kubeadm provides domain Knowledge of Kubernetes clusters' life cycle
 management, including self-hosted layouts, dynamic discovery services and so
 on. Had it belong to the new [operators world](https://coreos.com/blog/introducing-operators.html),
-it would've likely been named a "Kubernetes cluster operator". Kargo however,
+it would've likely been named a "Kubernetes cluster operator". Kubespray however,
 does generic configuration management tasks from the "OS operators" ansible
 world, plus some initial K8s clustering (with networking plugins included) and
-control plane bootstrapping. Kargo [strives](https://github.com/kubernetes-incubator/kargo/issues/553)
+control plane bootstrapping. Kubespray [strives](https://github.com/kubernetes-incubator/kubespray/issues/553)
 to adopt kubeadm as a tool in order to consume life cycle management domain
 knowledge from it and offload generic OS configuration things from it, which
 hopefully benefits both sides.

docs/dns-stack.md

@@ -1,7 +1,7 @@
-K8s DNS stack by Kargo
+K8s DNS stack by Kubespray
 ======================
 
-For K8s cluster nodes, kargo configures a [Kubernetes DNS](http://kubernetes.io/docs/admin/dns/)
+For K8s cluster nodes, Kubespray configures a [Kubernetes DNS](http://kubernetes.io/docs/admin/dns/)
 [cluster add-on](http://releases.k8s.io/master/cluster/addons/README.md)
 to serve as an authoritative DNS server for a given ``dns_domain`` and its
 ``svc, default.svc`` default subdomains (a total of ``ndots: 5`` max levels).
@@ -44,13 +44,13 @@ DNS servers to be added *after* the cluster DNS. Used by all ``resolvconf_mode``
 DNS servers in early cluster deployment when no cluster DNS is available yet. These are also added as upstream
 DNS servers used by ``dnsmasq`` (when deployed with ``dns_mode: dnsmasq_kubedns``).
 
-DNS modes supported by kargo
+DNS modes supported by Kubespray
 ============================
 
-You can modify how kargo sets up DNS for your cluster with the variables ``dns_mode`` and ``resolvconf_mode``.
+You can modify how Kubespray sets up DNS for your cluster with the variables ``dns_mode`` and ``resolvconf_mode``.
 
 ## dns_mode
-``dns_mode`` configures how kargo will setup cluster DNS. There are three modes available:
+``dns_mode`` configures how Kubespray will setup cluster DNS. There are three modes available:
 
 #### dnsmasq_kubedns (default)
 This installs an additional dnsmasq DaemonSet which gives more flexibility and lifts some
@@ -67,7 +67,7 @@ This does not install any of dnsmasq and kubedns/skydns. This basically disables
 leaves you with a non functional cluster.
 
 ## resolvconf_mode
-``resolvconf_mode`` configures how kargo will setup DNS for ``hostNetwork: true`` PODs and non-k8s containers.
+``resolvconf_mode`` configures how Kubespray will setup DNS for ``hostNetwork: true`` PODs and non-k8s containers.
 There are three modes available:
 
 #### docker_dns (default)
@@ -100,7 +100,7 @@ used as a backup nameserver. After cluster DNS is running, all queries will be a
 servers, which in turn will forward queries to the system nameserver if required.
 
 #### host_resolvconf
-This activates the classic kargo behaviour that modifies the hosts ``/etc/resolv.conf`` file and dhclient
+This activates the classic Kubespray behaviour that modifies the hosts ``/etc/resolv.conf`` file and dhclient
 configuration to point to the cluster dns server (either dnsmasq or kubedns, depending on dns_mode).
 
 As cluster DNS is not available on early deployment stage, this mode is split into 2 stages. In the first
@@ -120,7 +120,7 @@ cluster service names.
 Limitations
 -----------
 
-* Kargo has yet ways to configure Kubedns addon to forward requests SkyDns can
+* Kubespray has yet ways to configure Kubedns addon to forward requests SkyDns can
   not answer with authority to arbitrary recursive resolvers. This task is left
   for future. See [official SkyDns docs](https://github.com/skynetservices/skydns)
   for details.

docs/downloads.md

@@ -1,7 +1,7 @@
 Downloading binaries and containers
 ===================================
 
-Kargo supports several download/upload modes. The default is:
+Kubespray supports several download/upload modes. The default is:
 
 * Each node downloads binaries and container images on its own, which is
   ``download_run_once: False``.

docs/getting-started.md

@@ -23,12 +23,12 @@ Building your own inventory
 
 Ansible inventory can be stored in 3 formats: YAML, JSON, or INI-like. There is
 an example inventory located
-[here](https://github.com/kubernetes-incubator/kargo/blob/master/inventory/inventory.example).
+[here](https://github.com/kubernetes-incubator/kubespray/blob/master/inventory/inventory.example).
 
 You can use an
-[inventory generator](https://github.com/kubernetes-incubator/kargo/blob/master/contrib/inventory_builder/inventory.py)
+[inventory generator](https://github.com/kubernetes-incubator/kubespray/blob/master/contrib/inventory_builder/inventory.py)
 to create or modify an Ansible inventory. Currently, it is limited in
-functionality and is only use for making a basic Kargo cluster, but it does
+functionality and is only use for making a basic Kubespray cluster, but it does
 support creating large clusters. It now supports
 separated ETCD and Kubernetes master roles from node role if the size exceeds a
 certain threshold. Run inventory.py help for more information.

docs/ha-mode.md

@@ -22,7 +22,7 @@ Kube-apiserver
 --------------
 
 K8s components require a loadbalancer to access the apiservers via a reverse
-proxy. Kargo includes support for an nginx-based proxy that resides on each
+proxy. Kubespray includes support for an nginx-based proxy that resides on each
 non-master Kubernetes node. This is referred to as localhost loadbalancing. It
 is less efficient than a dedicated load balancer because it creates extra
 health checks on the Kubernetes apiserver, but is more practical for scenarios
@@ -30,12 +30,12 @@ where an external LB or virtual IP management is inconvenient.  This option is
 configured by the variable `loadbalancer_apiserver_localhost` (defaults to `True`).
 You may also define the port the local internal loadbalancer users by changing,
 `nginx_kube_apiserver_port`.  This defaults to the value of `kube_apiserver_port`.
-It is also import to note that Kargo will only configure kubelet and kube-proxy
+It is also import to note that Kubespray will only configure kubelet and kube-proxy
 on non-master nodes to use the local internal loadbalancer.
 
 If you choose to NOT use the local internal loadbalancer, you will need to configure
 your own loadbalancer to achieve HA. Note that deploying a loadbalancer is up to
-a user and is not covered by ansible roles in Kargo. By default, it only configures
+a user and is not covered by ansible roles in Kubespray. By default, it only configures
 a non-HA endpoint, which points to the `access_ip` or IP address of the first server
 node in the `kube-master` group. It can also configure clients to use endpoints
 for a given loadbalancer type. The following diagram shows how traffic to the

docs/netcheck.md

@@ -1,7 +1,7 @@
 Network Checker Application
 ===========================
 
-With the ``deploy_netchecker`` var enabled (defaults to false), Kargo deploys a
+With the ``deploy_netchecker`` var enabled (defaults to false), Kubespray deploys a
 Network Checker Application from the 3rd side `l23network/k8s-netchecker` docker
 images. It consists of the server and agents trying to reach the server by usual
 for Kubernetes applications network connectivity meanings. Therefore, this
@@ -17,7 +17,7 @@ any of the cluster nodes:
 ```
 curl http://localhost:31081/api/v1/connectivity_check
 ```
-Note that Kargo does not invoke the check but only deploys the application, if
+Note that Kubespray does not invoke the check but only deploys the application, if
 requested.
 
 There are related application specifc variables:

docs/roadmap.md

@@ -1,23 +1,23 @@
-Kargo's roadmap
+Kubespray's roadmap
 =================
 
 ### Kubeadm
 - Propose kubeadm as an option in order to setup the kubernetes cluster.
-That would probably improve deployment speed and certs management [#553](https://github.com/kubespray/kargo/issues/553)
+That would probably improve deployment speed and certs management [#553](https://github.com/kubespray/kubespray/issues/553)
 
-### Self deployment (pull-mode) [#320](https://github.com/kubespray/kargo/issues/320)
+### Self deployment (pull-mode) [#320](https://github.com/kubespray/kubespray/issues/320)
 - the playbook would install and configure docker/rkt and the etcd cluster
 - the following data would be inserted into etcd: certs,tokens,users,inventory,group_vars.
 - a "kubespray" container would be deployed (kargo-cli, ansible-playbook, kpm)
 - to be discussed, a way to provide the inventory
-- **self deployment** of the node from inside a container [#321](https://github.com/kubespray/kargo/issues/321)
+- **self deployment** of the node from inside a container [#321](https://github.com/kubespray/kubespray/issues/321)
 
 ### Provisionning and cloud providers
 - [ ] Terraform to provision instances on **GCE, AWS, Openstack, Digital Ocean, Azure**
 - [ ] On AWS autoscaling, multi AZ
-- [ ] On Azure autoscaling, create loadbalancer [#297](https://github.com/kubespray/kargo/issues/297)
-- [ ] On GCE be able to create a loadbalancer automatically (IAM ?) [#280](https://github.com/kubespray/kargo/issues/280)
-- [x] **TLS boostrap** support for kubelet [#234](https://github.com/kubespray/kargo/issues/234)
+- [ ] On Azure autoscaling, create loadbalancer [#297](https://github.com/kubespray/kubespray/issues/297)
+- [ ] On GCE be able to create a loadbalancer automatically (IAM ?) [#280](https://github.com/kubespray/kubespray/issues/280)
+- [x] **TLS boostrap** support for kubelet [#234](https://github.com/kubespray/kubespray/issues/234)
   (related issues: https://github.com/kubernetes/kubernetes/pull/20439 <br>
    https://github.com/kubernetes/kubernetes/issues/18112)
 
@@ -37,14 +37,14 @@ That would probably improve deployment speed and certs management [#553](https:/
 - [ ] test scale up cluster:  +1 etcd, +1 master, +1 node
 
 ### Lifecycle
-- [ ] Adopt the kubeadm tool by delegating CM tasks it is capable to accomplish well [#553](https://github.com/kubespray/kargo/issues/553)
-- [x] Drain worker node when upgrading k8s components in a worker node. [#154](https://github.com/kubespray/kargo/issues/154)
+- [ ] Adopt the kubeadm tool by delegating CM tasks it is capable to accomplish well [#553](https://github.com/kubespray/kubespray/issues/553)
+- [x] Drain worker node when upgrading k8s components in a worker node. [#154](https://github.com/kubespray/kubespray/issues/154)
 - [ ] Drain worker node when shutting down/deleting an instance
 - [ ] Upgrade granularity: select components to upgrade and skip others
 
 ### Networking
-- [ ] romana.io support [#160](https://github.com/kubespray/kargo/issues/160)
-- [ ] Configure network policy for Calico. [#159](https://github.com/kubespray/kargo/issues/159)
+- [ ] romana.io support [#160](https://github.com/kubespray/kubespray/issues/160)
+- [ ] Configure network policy for Calico. [#159](https://github.com/kubespray/kubespray/issues/159)
 - [ ] Opencontrail
 - [x] Canal
 - [x] Cloud Provider native networking (instead of our network plugins)
@@ -60,7 +60,7 @@ While waiting for the issue [kubernetes/kubernetes#18174](https://github.com/kub
 - switch to Terraform instead of Ansible for provisionning
 - update $HOME/.kube/config when a cluster is deployed. Optionally switch to this context
 
-### Kargo API
+### Kubespray API
 - Perform all actions through an **API**
 - Store inventories / configurations of mulltiple clusters
 - make sure that state of cluster is completely saved in no more than one config file beyond hosts inventory
@@ -87,8 +87,8 @@ Include optionals deployments to init the cluster:
 ### Others
 - remove nodes  (adding is already supported)
 - being able to choose any k8s version (almost done)
-- **rkt** support [#59](https://github.com/kubespray/kargo/issues/59)
+- **rkt** support [#59](https://github.com/kubespray/kubespray/issues/59)
 - Review documentation (split in categories)
 - **consul** -> if officialy supported by k8s
-- flex volumes options (e.g. **torrus** support) [#312](https://github.com/kubespray/kargo/issues/312)
-- Clusters federation option (aka **ubernetes**) [#329](https://github.com/kubespray/kargo/issues/329)
+- flex volumes options (e.g. **torrus** support) [#312](https://github.com/kubespray/kubespray/issues/312)
+- Clusters federation option (aka **ubernetes**) [#329](https://github.com/kubespray/kubespray/issues/329)

docs/upgrades.md

@@ -1,11 +1,11 @@
-Upgrading Kubernetes in Kargo
+Upgrading Kubernetes in Kubespray
 =============================
 
 #### Description
 
-Kargo handles upgrades the same way it handles initial deployment. That is to
+Kubespray handles upgrades the same way it handles initial deployment. That is to
 say that each component is laid down in a fixed order. You should be able to
-upgrade from Kargo tag 2.0 up to the current master without difficulty. You can
+upgrade from Kubespray tag 2.0 up to the current master without difficulty. You can
 also individually control versions of components by explicitly defining their
 versions. Here are all version vars for each component:
 
@@ -35,7 +35,7 @@ ansible-playbook cluster.yml -i inventory/inventory.cfg -e kube_version=v1.4.6
 
 #### Graceful upgrade
 
-Kargo also supports cordon, drain and uncordoning of nodes when performing 
+Kubespray also supports cordon, drain and uncordoning of nodes when performing 
 a cluster upgrade. There is a separate playbook used for this purpose. It is
 important to note that upgrade-cluster.yml can only be used for upgrading an
 existing cluster. That means there must be at least 1 kube-master already

docs/vars.md

@@ -1,4 +1,4 @@
-Configurable Parameters in Kargo
+Configurable Parameters in Kubespray
 ================================
 
 #### Generic Ansible variables
@@ -12,7 +12,7 @@ Some variables of note include:
 * *ansible_default_ipv4.address*: IP address Ansible automatically chooses.
   Generated based on the output from the command ``ip -4 route get 8.8.8.8``
 
-#### Common vars that are used in Kargo
+#### Common vars that are used in Kubespray
 
 * *calico_version* - Specify version of Calico to use
 * *calico_cni_version* - Specify version of Calico CNI plugin to use
@@ -35,16 +35,16 @@ Some variables of note include:
 * *access_ip* - IP for other hosts to use to connect to. Often required when
   deploying from a cloud, such as OpenStack or GCE and you have separate
   public/floating and private IPs.
-* *ansible_default_ipv4.address* - Not Kargo-specific, but it is used if ip
+* *ansible_default_ipv4.address* - Not Kubespray-specific, but it is used if ip
   and access_ip are undefined
 * *loadbalancer_apiserver* - If defined, all hosts will connect to this
   address instead of localhost for kube-masters and kube-master[0] for
   kube-nodes. See more details in the
-  [HA guide](https://github.com/kubernetes-incubator/kargo/blob/master/docs/ha-mode.md).
+  [HA guide](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/ha-mode.md).
 * *loadbalancer_apiserver_localhost* - makes all hosts to connect to
   the apiserver internally load balanced endpoint. Mutual exclusive to the
   `loadbalancer_apiserver`. See more details in the
-  [HA guide](https://github.com/kubernetes-incubator/kargo/blob/master/docs/ha-mode.md).
+  [HA guide](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/ha-mode.md).
 
 #### Cluster variables
 
@@ -79,13 +79,13 @@ other settings from your existing /etc/resolv.conf are lost. Set the following
 variables to match your requirements.
 
 * *upstream_dns_servers* - Array of upstream DNS servers configured on host in
-  addition to Kargo deployed DNS
+  addition to Kubespray deployed DNS
 * *nameservers* - Array of DNS servers configured for use in dnsmasq
 * *searchdomains* - Array of up to 4 search domains
 * *skip_dnsmasq* - Don't set up dnsmasq (use only KubeDNS)
 
 For more information, see [DNS
-Stack](https://github.com/kubernetes-incubator/kargo/blob/master/docs/dns-stack.md).
+Stack](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/dns-stack.md).
 
 #### Other service variables
 
@@ -114,5 +114,5 @@ The possible vars are:
 
 #### User accounts
 
-Kargo sets up two Kubernetes accounts by default: ``root`` and ``kube``. Their
+Kubespray sets up two Kubernetes accounts by default: ``root`` and ``kube``. Their
 passwords default to changeme. You can set this by changing ``kube_api_pwd``.

docs/vault.md

@@ -39,7 +39,7 @@ vault group.
 It is *highly* recommended that these secrets are removed from the servers after
 your cluster has been deployed, and kept in a safe location of your choosing.
 Naturally, the seriousness of the situation depends on what you're doing with
-your Kargo cluster, but with these secrets, an attacker will have the ability
+your Kubespray cluster, but with these secrets, an attacker will have the ability
 to authenticate to almost everything in Kubernetes and decode all private
 (HTTPS) traffic on your network signed by Vault certificates.
 

extra_playbooks/upgrade-only-k8s.yml

@@ -11,7 +11,7 @@
 - hosts: localhost
   gather_facts: False
   roles:
-    - { role: kargo-defaults}
+    - { role: kubespray-defaults}
     - { role: bastion-ssh-config, tags: ["localhost", "bastion"]}
 
 - hosts: k8s-cluster:etcd:calico-rr
@@ -22,7 +22,7 @@
     # fail. bootstrap-os fixes this on these systems, so in later plays it can be enabled.
     ansible_ssh_pipelining: false
   roles:
-    - { role: kargo-defaults}
+    - { role: kubespray-defaults}
     - { role: bootstrap-os, tags: bootstrap-os}
 
 - hosts: k8s-cluster:etcd:calico-rr
@@ -34,7 +34,7 @@
 - hosts: k8s-cluster:etcd:calico-rr
   any_errors_fatal: "{{ any_errors_fatal | default(true) }}"
   roles:
-    - { role: kargo-defaults}
+    - { role: kubespray-defaults}
     - { role: kubernetes/preinstall, tags: preinstall }
 
 #Handle upgrades to master components first to maintain backwards compat.
@@ -42,7 +42,7 @@
   any_errors_fatal: "{{ any_errors_fatal | default(true) }}"
   serial: 1
   roles:
-    - { role: kargo-defaults}
+    - { role: kubespray-defaults}
     - { role: upgrade/pre-upgrade, tags: pre-upgrade }
     - { role: kubernetes/node, tags: node }
     - { role: kubernetes/master, tags: master }
@@ -53,8 +53,8 @@
   any_errors_fatal: "{{ any_errors_fatal | default(true) }}"
   serial: "{{ serial | default('20%') }}"
   roles:
-    - { role: kargo-defaults}
+    - { role: kubespray-defaults}
     - { role: upgrade/pre-upgrade, tags: pre-upgrade }
     - { role: kubernetes/node, tags: node }
     - { role: upgrade/post-upgrade, tags: post-upgrade }
-    - { role: kargo-defaults}
+    - { role: kubespray-defaults}

roles/dnsmasq/templates/dnsmasq-deploy.yml

@@ -19,7 +19,7 @@ spec:
       labels:
         k8s-app: dnsmasq
         kubernetes.io/cluster-service: "true"
-        kargo/dnsmasq-checksum: "{{ dnsmasq_stat.stat.checksum }}"
+        kubespray/dnsmasq-checksum: "{{ dnsmasq_stat.stat.checksum }}"
     spec:
       containers:
         - name: dnsmasq

roles/kargo-defaults/tasks/main.yaml

@@ -1,5 +0,0 @@
-- name: Configure defaults
-  debug:
-    msg: "Check roles/kargo-defaults/defaults/main.yml"
-  tags:
-    - always

roles/kubernetes/master/templates/manifests/kube-apiserver.manifest.j2

@@ -5,7 +5,7 @@ metadata:
   namespace: {{system_namespace}}
   labels:
     k8s-app: kube-apiserver
-    kargo: v2
+    kubespray: v2
 spec:
   hostNetwork: true
 {% if kube_version | version_compare('v1.6', '>=')  %}

roles/kubernetes/preinstall/tasks/dhclient-hooks-undo.yml

@@ -1,9 +1,9 @@
 ---
 
-# These tasks will undo changes done by kargo in the past if needed (e.g. when upgrading from kargo 2.0.x
+# These tasks will undo changes done by kubespray in the past if needed (e.g. when upgrading from kubespray 2.0.x
 # or when changing resolvconf_mode)
 
-- name: Remove kargo specific config from dhclient config
+- name: Remove kubespray specific config from dhclient config
   blockinfile:
     dest: "{{dhclientconffile}}"
     state: absent
@@ -13,7 +13,7 @@
   when: dhclientconffile is defined
   notify: Preinstall | restart network
 
-- name: Remove kargo specific dhclient hook
+- name: Remove kubespray specific dhclient hook
   file:
     path: "{{ dhclienthookfile }}"
     state: absent

roles/kubespray-defaults/tasks/main.yaml

@@ -0,0 +1,5 @@
+- name: Configure defaults
+  debug:
+    msg: "Check roles/kubespray-defaults/defaults/main.yml"
+  tags:
+    - always