From 36f66ff8531a646947130d0015d4063b506af615 Mon Sep 17 00:00:00 2001 From: "Tullis, Michael L" Date: Wed, 31 Aug 2016 15:34:29 -0700 Subject: [PATCH 01/12] Added bulk provisioning to index --- source/index_advanced_configuration.rst | 27 +++++++++++++------------ 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/source/index_advanced_configuration.rst b/source/index_advanced_configuration.rst index fe7251e2..88fc2f55 100644 --- a/source/index_advanced_configuration.rst +++ b/source/index_advanced_configuration.rst @@ -1,13 +1,14 @@ -Advanced configuration -###################### - -.. toctree:: - :maxdepth: 2 - - clear-containers - network_boot - mixer - ac-dpdk - ac-ovs-dpdk - validate_sigs - +Advanced configuration +###################### + +.. toctree:: + :maxdepth: 2 + + clear-containers + network_boot + bulk_provisioning + mixer + ac-dpdk + ac-ovs-dpdk + validate_sigs + From a5f8079f7cc7a8ab6ba31004e830a85fb4aee030 Mon Sep 17 00:00:00 2001 From: "Tullis, Michael L" Date: Wed, 31 Aug 2016 16:16:59 -0700 Subject: [PATCH 02/12] Remove bulk provisioning from index --- source/index_advanced_configuration.rst | 1 - 1 file changed, 1 deletion(-) diff --git a/source/index_advanced_configuration.rst b/source/index_advanced_configuration.rst index 88fc2f55..3e412b4b 100644 --- a/source/index_advanced_configuration.rst +++ b/source/index_advanced_configuration.rst @@ -6,7 +6,6 @@ Advanced configuration clear-containers network_boot - bulk_provisioning mixer ac-dpdk ac-ovs-dpdk From ebf94ee7928d7bdda2097c27f364a1603749a3fe Mon Sep 17 00:00:00 2001 From: "Tullis, Michael L" Date: Wed, 31 Aug 2016 16:19:07 -0700 Subject: [PATCH 03/12] Add bulk provisioning back into index --- source/index_advanced_configuration.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/source/index_advanced_configuration.rst b/source/index_advanced_configuration.rst index 3e412b4b..88fc2f55 100644 --- a/source/index_advanced_configuration.rst +++ b/source/index_advanced_configuration.rst @@ -6,6 +6,7 @@ Advanced configuration clear-containers network_boot + bulk_provisioning mixer ac-dpdk ac-ovs-dpdk From f996c5086b455a1e0085872595e4c2480b2be4dd Mon Sep 17 00:00:00 2001 From: "Tullis, Michael L" Date: Fri, 2 Sep 2016 23:01:06 -0700 Subject: [PATCH 04/12] Adding and reconfiguring ciao content per https://jira01.devtools.intel.com/browse/CLEAR-1593. --- source/ciao-cluster-setup-quick.rst | 12 ++++++++++++ source/ciao-cluster-setup.rst | 4 ++-- source/index-ts.rst | 1 + 3 files changed, 15 insertions(+), 2 deletions(-) create mode 100644 source/ciao-cluster-setup-quick.rst diff --git a/source/ciao-cluster-setup-quick.rst b/source/ciao-cluster-setup-quick.rst new file mode 100644 index 00000000..43bb5a81 --- /dev/null +++ b/source/ciao-cluster-setup-quick.rst @@ -0,0 +1,12 @@ +.. _ciao-cluster-setup-quick: + +Easy ciao development cluster setup +################################### + +For quick ciao development cluster setup, see: + + https://github.com/01org/ciao/wiki/Single-Machine-Development-Environment + +For more detailed and configurable manual setup of ciao, see + + https://clearlinux.org/documentation/ciao-cluster-setup.html diff --git a/source/ciao-cluster-setup.rst b/source/ciao-cluster-setup.rst index 21b2fa94..51aec448 100644 --- a/source/ciao-cluster-setup.rst +++ b/source/ciao-cluster-setup.rst @@ -2,8 +2,8 @@ .. contents:: -ciao cluster setup -################## +Detailed manual ciao cluster setup +################################## This topic explains how to set up a cluster of machines running Clear Linux* OS for Intel® Architecture with :abbr:`Cloud Integrated Advanced Orchestrator (CIAO)`, or ciao. diff --git a/source/index-ts.rst b/source/index-ts.rst index 50fb9aaa..15d65776 100644 --- a/source/index-ts.rst +++ b/source/index-ts.rst @@ -6,6 +6,7 @@ Tutorials gs-clear-containers-getting-started ciao-deploy + ciao-cluster-setup-quick.rst ciao-cluster-setup From e8f5fd415ba9c4e20d44a43d8085bb3de69cad5e Mon Sep 17 00:00:00 2001 From: "Tullis, Michael L" Date: Fri, 2 Sep 2016 23:45:07 -0700 Subject: [PATCH 05/12] Punctuation --- source/ciao-cluster-setup-quick.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/ciao-cluster-setup-quick.rst b/source/ciao-cluster-setup-quick.rst index 43bb5a81..bd997435 100644 --- a/source/ciao-cluster-setup-quick.rst +++ b/source/ciao-cluster-setup-quick.rst @@ -7,6 +7,6 @@ For quick ciao development cluster setup, see: https://github.com/01org/ciao/wiki/Single-Machine-Development-Environment -For more detailed and configurable manual setup of ciao, see +For more detailed and configurable manual setup of ciao, see: https://clearlinux.org/documentation/ciao-cluster-setup.html From 0b8283d7b99a8c6dd0c66d224cef2440eb872a38 Mon Sep 17 00:00:00 2001 From: "L.S. Cook" Date: Tue, 6 Sep 2016 08:00:31 -0700 Subject: [PATCH 06/12] edit pass on bulk_provisioning tutorial Signed-off-by: L.S. Cook --- source/bulk_provisioning.rst | 83 +++++++++++++++++++++++++++--------- 1 file changed, 64 insertions(+), 19 deletions(-) diff --git a/source/bulk_provisioning.rst b/source/bulk_provisioning.rst index 3d2bdf5a..4049eca7 100644 --- a/source/bulk_provisioning.rst +++ b/source/bulk_provisioning.rst @@ -3,15 +3,34 @@ Bulk Provisioning ================= -In the data center new machines are often landed in large groups. When dealing with large amounts of new hardware, data center admins need a way to install and configure these machines with a minimal amount of effort. In support of this use case the Clear Linux team has developed some tooling and instructions on how to bulk-load machines with Clear Linux using iPXE. +Data centers tend to land and install new machines in bulk. When dealing with +large quantities of new machines or hardware upgrades, data center admins may need +a way to install and configure with a minimal amount of effort. To support this +use case, the Clear Linux team has developed some tooling and instructions for +how to bulk-load machines with Clear Linux using iPXE. -This bulk provisioning scenario is a variation on the Network Booting and installation scenario with some alterations to facillitate installing and configuring many hosts. The Clear Linux installer (Ister) was augmented to detect and find cloud-init configuration data during the install. If this data is found a cloud-init file is fetched and the host, after being rebooted by ister, uses micro config drive (ucf) to configure the host as directed by the cloud-init configuration file. +This bulk provisioning scenario is a variation on the :ref:`network_boot` scenario, +with some alterations to facilitate installing and configuring many hosts. The Clear +Linux installer (``Ister``) was augmented to detect and find ``cloud-init`` configuration +data during the install. When this data is found, a :file:`cloud-init` file is fetched, +and the host, after being rebooted by ``ister``, uses micro-config drive (``ucf``) to +configure the host as directed by the :file:`cloud-init` configuration file. -In our pilot of this workflow we used clear-cloud-init (which in the future will become ucf - micro config drive) to install the trust relationships for the host to be further managed by Ansible. The cloud-init configuration file was served by a simple little web-application that Ister knows how to query for host configuration data. This allowed us to power on one hundered machines, each of which picked up the Clear Linux installer via PXE, installed Clear Linux, rebooted, and came up ready to be managed through Ansible. +In our pilot of this workflow, we used ``clear-cloud-init`` (which will become ucf - micro config drive) +to install the trust relationships for the host to be further managed by Ansible. The +:file:`cloud-init` configuration file was served by a simple little web application +that ``Ister`` knows how to query for host configuration data. This allowed us to +simultaneously power-on one hundred machines, each of which +* picked up the Clear Linux installer via PXE, +* installed Clear Linux, +* rebooted, and +* entered into a mode that can be managed through Ansible. -The web application that serves cloud-init configurations to Ister is uninspiringly named "Ister Cloud Init Service" (ICIS), and is available at github - https://github.com/clearlinux/ister-cloud-init-svc +The web application that serves cloud-init configurations to ``Ister`` is uninspiringly named +"Ister Cloud Init Service" (ICIS), and is available at github - https://github.com/clearlinux/ister-cloud-init-svc -One nice attribute of this system is that once the iPXE bits are created many installer behaviors can be configured without having to regenerate the iPXE bits. +One nice attribute of this system is that once the iPXE bits are created, many installer +behaviors can be configured without having to regenerate the iPXE bits. System Architecture ~~~~~~~~~~~~~~~~~~~ @@ -22,9 +41,13 @@ The following diagrams illustrate the system architecture. :align: center :alt: pxe-server-overview -As can be seen, ICIS is a web application (specifically a Flask application, hence managed by uwsgi under nginx) that can really run anywhere visible to hosts booting from PXE. In our example we simply hosted it on the same system serving the pxe content. +As can be seen, ICIS is a web application (specifically a Flask application, hence managed by ``uwsgi`` +under nginx) that can run **anywhere** visible to hosts booting from PXE. In our example, we simply +hosted it on the same system serving the pxe content. -The following diagram illustrates the flow of information between the pxe server and a host booting into the installer via pxe. This diagram is intended to show the logical flow of information, and is not a literal depiction of the protocol-level exchanges. +The following diagram illustrates the flow of information between the pxe server and a host booting +into the installer via pxe. This diagram is intended to show the logical flow of information, and +is not a literal depiction of the protocol-level exchanges. .. image:: _static/images/icis_installer_workflow.png :align: center @@ -33,19 +56,29 @@ The following diagram illustrates the flow of information between the pxe server Configuration Overview ~~~~~~~~~~~~~~~~~~~~~~ -Here is a high-level overview describing setting up and configuring a bulk provisioning solution. +Here is a high-level overview describing set up and configuration of a bulk-provisioning solution. -* First, stand up an iPXE server as described in the :doc:`network boot ` docs. Note that you will be generating your own artifacts to be served by PXE in a later step. +* First, stand up an iPXE server as described in the :ref:`network_boot` docs. Note that you will + be generating your own artifacts to be served by PXE in a later step. -* Land `Ister Cloud Init Service `_ on the pxe server. The README in the ICIS github repo has directions on how to install and configure. +* Land `Ister Cloud Init Service `_ on the + pxe server. The README in the ICIS github repo has directions on how to install and configure. -* Generate the installer that will load and boot over PXE. Copy the relevant files into the appropriate location on the iPXE server. +* Generate the installer that will load and boot over PXE. Copy the relevant files into the + appropriate location on the iPXE server. - A pxe installer is generated for every release of Clear Linux OS. It can be found alongside the published images in https://download.clearlinux.org/releases/XXXXX/clear/clear-XXXXX-pxe.tar.xz + A pxe installer is generated for every release of Clear Linux OS. It can be found alongside the + published images in https://download.clearlinux.org/releases/XXXXX/clear/clear-XXXXX-pxe.tar.xz - Alternatively use the `create_pxe.sh `_ script to roll your own. Note this creates the pxe-installer from the "provision" installer in Clear Linux which is a touchless installer that takes all installation information from a config file. You can get this image from a given Clear Linux release by looking in https://download.clearlinux.org/releases/XXXX/clear/ where XXXX is a Clear Linux release number. Just download the image alongside the create_pxe.sh script and name it provision.img. + Alternatively, use the `create_pxe.sh `_ + script to roll your own. Note this creates the pxe-installer from the "provisioning" installer in + Clear Linux. This is a touchless installer that takes all installation information from a config + file. You can get this image from a given Clear Linux release by looking + in https://download.clearlinux.org/releases/XXXX/clear/ where XXXX is a Clear Linux release number. + Just download the image alongside the ``create_pxe.sh`` script and name it ``provision.img``. -* Stage config files for ister that will govern Ister's behavior. This includes modifying the ipxe boot script to pass an additional parameter to the kernel. +* Stage config files for ``ister`` that will govern Ister's behavior. This includes modifying the + script for ipxe boot, getting it to pass an additional parameter to the kernel. The magic that ties all of this together is that the pxe script conveys to ister the location of its configuration files via the kernel command line of the installer it kicks off. The kernel preserves its command line precisely, and ister inspects it via /proc/cmdline. @@ -54,15 +87,26 @@ Here is a high-level overview describing setting up and configuring a bulk provi .. code-block:: console #!ipxe - kernel linux quiet rdinit=/usr/lib/systemd/systemd-bootchart initcall_debug tsc=reliable no_timer_check noreplace-smp rw initrd=initrd isterconf=http://192.168.1.1/static/ister/ister.conf + kernel linux quiet rdinit=/usr/lib/systemd/systemd-bootchart initcall_debug tsc=reliable + no_timer_check noreplace-smp rw initrd=initrd isterconf=http://192.168.1.1/static/ister/ister.conf initrd initrd boot - When the pxe installer kicks off ister it will notice location of its conf file was given on the kernel command line and fetch the file. This file in turn tells ister where to get the json template file that describes partition schemes, and which version of Clear Linux to install. This means that so long as the contents of a release are compatible with the version of software update (swupd) in the installer, this pxe installer can be told to install a newer version of Clear Linux simply by tweaking the json on the web server instead of rolling an entire new installer. + When the pxe installer kicks off ``ister``, it will make note of the location of the ``conf`` file + that was given on the kernel command line, and fetch the file. This file then tells ``ister`` where + to get the json template file that describes partition schemes, and which version of Clear Linux to + install. This means that so long as the contents of a release are compatible with the version of + software update (``swupd``) in the installer, this pxe installer can be told to install a newer + version of Clear Linux simply by tweaking the json on the web server, rather than rolling an + entirely new installer. - One other important piece of configuration data in the json configuration file is the location of an ICIS configuration service. Ister will query ICIS for a role using the MAC address of the network interface being used to communicate with the ICIS service. Ister will then fetch that specific cloud-init file and configure ucd to run on first-boot against that config file. + One other important piece of configuration data in the json configuration file is the location of + an ICIS configuration service. Ister will query ICIS for a role using the MAC address of the network + interface being used to communicate with the ICIS service. Ister will then fetch that specific + :file:`cloud-init` file and ``configure ucd`` to run on first-boot against that config file. - The `Ister Cloud Init Service `_ github repo has example ister configuration files under ``static/ister``. + The `Ister Cloud Init Service `_ github repo + has example ister configuration files under ``static/ister``. Here is an example ister-template.json file. @@ -87,7 +131,8 @@ Here is a high-level overview describing setting up and configuring a bulk provi "IsterCloudInitSvc": ["http://192.168.1.1/"] } -* Configure ICIS to map MAC addresses to role files appropriately. Then create the role files, which are cloud-init configuration files. Note, it is possible to simply specify a "default" role for any unmatched MAC address, which is handy if all install targets are to be configured identically. +* Configure ICIS to map MAC addresses to role files appropriately. Then create the role files, which are ``cloud-init`` configuration files. Note, it is possible to simply specify a "default" role for any unmatched MAC address; this may +be handy when all install targets are to be configured identically. * Final pre-flight check. Assuming your iPXE server is at 192.168.1.1, all of the following urls need to be working. From e0dcd88171b9a983aed4bf933582e13dc30d4a96 Mon Sep 17 00:00:00 2001 From: "L.S. Cook" Date: Tue, 6 Sep 2016 08:13:29 -0700 Subject: [PATCH 07/12] fix whitespace Signed-off-by: L.S. Cook --- source/bulk_provisioning.rst | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/source/bulk_provisioning.rst b/source/bulk_provisioning.rst index 4049eca7..6265e8bf 100644 --- a/source/bulk_provisioning.rst +++ b/source/bulk_provisioning.rst @@ -80,7 +80,7 @@ Here is a high-level overview describing set up and configuration of a bulk-prov * Stage config files for ``ister`` that will govern Ister's behavior. This includes modifying the script for ipxe boot, getting it to pass an additional parameter to the kernel. - The magic that ties all of this together is that the pxe script conveys to ister the location of its configuration files via the kernel command line of the installer it kicks off. The kernel preserves its command line precisely, and ister inspects it via /proc/cmdline. + The magic that ties all of this together is that the pxe script conveys to ister the location of its configuration files via the kernel command line of the installer it kicks off. The kernel preserves its command line precisely, and ister inspects it via ``/proc/cmdline``. Here is an example pxe script: @@ -131,8 +131,9 @@ Here is a high-level overview describing set up and configuration of a bulk-prov "IsterCloudInitSvc": ["http://192.168.1.1/"] } -* Configure ICIS to map MAC addresses to role files appropriately. Then create the role files, which are ``cloud-init`` configuration files. Note, it is possible to simply specify a "default" role for any unmatched MAC address; this may -be handy when all install targets are to be configured identically. +* Configure ICIS to map MAC addresses to role files appropriately. Then create the role files, which + are ``cloud-init`` configuration files. Note, it is possible to simply specify a "default" role for + any unmatched MAC address; this may be handy when all install targets are to be configured identically. * Final pre-flight check. Assuming your iPXE server is at 192.168.1.1, all of the following urls need to be working. From 28bcac1d1ac0387ad79547749e413fd2a21cea98 Mon Sep 17 00:00:00 2001 From: Alberto Murillo Date: Fri, 2 Sep 2016 18:01:37 -0500 Subject: [PATCH 08/12] ciao-deploy.rst: Update ciao instructions Update how the ciao deployment is done with the new playbooks. Signed-off-by: Alberto Murillo --- source/ciao-deploy.rst | 170 +++++++++++++++-------------------------- 1 file changed, 60 insertions(+), 110 deletions(-) diff --git a/source/ciao-deploy.rst b/source/ciao-deploy.rst index 24a79c17..cea176de 100644 --- a/source/ciao-deploy.rst +++ b/source/ciao-deploy.rst @@ -5,173 +5,119 @@ Deploying ciao via automation ############################# -Cloud Integrated Advanced Orchestrator (``ciao``) is a new workload -scheduler designed to address limitations of current cloud OS projects. -CIAO provides a lightweight, fully TLS-based minimal config, is -workload-agnostic, easy to update, offers an optimized-for-speed +Cloud Integrated Advanced Orchestrator (``ciao``) is a new workload +scheduler designed to address limitations of current cloud OS projects. +CIAO provides a lightweight, fully TLS-based minimal config, is +workload-agnostic, easy to update, offers an optimized-for-speed scheduler, and is currently optimized for OpenStack*. For more information, see https://clearlinux.org/ciao. - Environment =========== -For this example, we'll use a total of four nodes: +For this example, we'll use a total of five nodes: + - A deployment machine which will be used to run the playbooks. - A `controller`_ node which will be used to communicate with Keystone. - Two `compute nodes`_, which will spawn the VMs and containers. - A `network node`_ which will handle the networking for the workloads. + Note: The deployment machine is not necessary part of the cluster, it could be + the sysadmin's computer or an CI/CD server. .. _prerequisites: Prerequisites ============= -Ansible* uses :command:`ssh` to run commands on the remote nodes. In order to do -that, the nodes must be configured to allow passwordless ssh connections -from the root user. Follow these steps to configure your nodes. - -#. Generate ssh keys: - - .. code-block:: console - - # ssh-keygen - -#. Enable root login: - - .. code-block:: console - - # echo "PermitRootLogin yes" >> /etc/ssh/sshd_config - -#. Enable sshd service: - - .. code-block:: console - - # systemctl enable sshd - # systemctl start sshd - -#. Allow passwordless login: - - .. code-block:: console - - # ssh-copy-id -i root@node +Ansible* uses :command:`ssh` to run commands on the remote nodes. In order to do +that, the nodes must be configured to allow passwordless ssh connections +from the deployment machine to the cluster nodes. The user should also have +sudo privileges on the cluster nodes. Install the software ==================== -Install the ``sysadmin-hostmgmt`` bundle on the development node. This -bundle contains the Ansible software required to run the playbooks, as -well as some Ansible roles and sample playbooks that you can use to -build your own: +In ClearLinux install the ``sysadmin-hostmgmt`` bundle on the deployment node. This +bundle contains the Ansible software required to run the playbooks. .. code-block:: console # swupd bundle-add sysadmin-hostmgmt +Install ``go-basic``, ``os-core-dev``, ``kvm-host`` and ``os-common`` bundles +on the development node. This bundles contains requirements needed by the playbooks + +.. code-block:: console + + # swupd bundle-add go-basic os-core-dev kvm-host os-common + +go-basic + provides golang which is needed to compile ciao +os-core-dev + provides gcc which is needed to compile some ciao dependencies +kvm-host + provides qemu which is needed to build the CNCI image +os-common + provides python-keystoneclient which is a dependency of the keystone role + +For Ubuntu and Fedora, follow the instructions from `github`_ Create the playbook =================== -The ``sysadmin-hostmgmt`` bundle includes some sample playbooks that -you may use and customize for your own needs. Start by making a copy +The ``sysadmin-hostmgmt`` bundle includes some sample playbooks that +you may use and customize for your own needs. Start by making a copy of the sample playbook into your home folder .. code-block:: console # cp -r /usr/share/ansible/examples/ciao ~/ -The playbook consists of three files that you should modify to fit -your needs:: +Note: These files are also hosted in `github`_ - ciao/ - |-- ciao.yml - |-- group_vars - | -- all - +-- hosts +The relevant files in the playbook are the following:: -The :file:`hosts` file contains the IP addresses/hostnames of your -nodes, grouped under the roles they will serve. For this example -it should look like this:: +The `ciao.yml`_ file is the master playbook file and includes a playbook +for each component of the cluster. - [dbservers] - ciao-controller.example.com - - [openstack_identity] - ciao-controller.example.com - - [openstack_image] - ciao-controller.example.com - - [ciao_controller] - ciao-controller.example.com - - [ciao_network] - ciao-network.example.com - - [ciao_compute] - ciao-compute1.example.com - ciao-compute2.example.com +The `hosts`_ file is the hosts inventory file and contains the IP +addresses/FQDN of your nodes, grouped under the roles they will serve -This ``groups_var/all`` file contains variables that will be applied -to your ciao setup. The mandatory variables are already there; be -sure to change the values accordingly to fit your environment. It -should look something like this:: +The `groups_vars/all`_ file contains variables that will be applied +to your ciao setup. The mandatory variables are already there; be +sure to change the values accordingly to fit your environment - --- - # Vars required for mariadb and os-common - # https://github.com/clearlinux/clear-config-management/tree/master/roles/mariadb - # https://github.com/clearlinux/clear-config-management/tree/master/roles/os-common - database_root_password: secret - - # Vars required for os-common - # https://github.com/clearlinux/clear-config-management/tree/master/roles/os-common - keystone_fqdn: ciao-controller.example.com - keystone_admin_password: secret - - # Vars required for os-keystone - # https://github.com/clearlinux/clear-config-management/tree/master/roles/os-keystone - keystone_database_password: secret - keystone_root_domain: example.com - keystone_p12password: secret - - # Vars required for ciao-common - # https://github.com/clearlinux/clear-config-management/tree/master/roles/ciao-common - ciao_controller_fqdn: ciao-controller.example.com - - # Vars required for ciao-controller - # https://github.com/clearlinux/clear-config-management/tree/master/roles/ciao-controller - ciao_service_user: csr - ciao_service_password: secret - ciao_admin_email: admin@example.com - ciao_cert_organization: Example, Inc. - ciao_guest_user: demouser - ciao_guest_key: ~/.ssh/guest_vms.pub - - -The ``ciao_guest_key`` is the key to be used to connect to the VMs created by +The ``ciao_guest_key`` value in :file:`groups_var/all` is the key to be used to connect to the VMs created by ciao; you can use the ``ssh-keygen`` command to create one as explained in the :ref:`prerequisites` section. A full list of available variables can be found in the ciao-* roles at https://github.com/clearlinux/clear-config-management/tree/master/roles +Install the required ansible-roles +================================== + +.. code-block:: console + + # ansible-galaxy install -r requirements.yml + Run the playbook ================ -Once you have your variables and hosts file configured, the deployment can +Once you have your variables and hosts file configured, the deployment can be fired with the following command: .. code-block:: console - - # ansible-playbook -i hosts ciao.yml --private-key= + + $ ansible-playbook -i hosts ciao.yml --private-key= Verify ====== After ansible is done with the setup, you can verify the cluster is ready -by running the following command on the controller node. Change the **username**, -**password**, **controller**, and **identity** values to match your setup, as +by running the following command on the controller node. Change the **username**, +**password**, **controller**, and **identity** values to match your setup, as was specified in the ``groups_var/all`` file: .. code-block:: console @@ -183,7 +129,7 @@ was specified in the ``groups_var/all`` file: Offline 0 Maintenance 0 -You could also take a look at the :file:`~/ciaorc` file that contains the +You could also take a look at the :file:`./ciaorc` file that contains the following environment variables: .. code-block:: console @@ -209,3 +155,7 @@ then you could verify with the following command: .. _controller: https://github.com/01org/ciao/tree/master/ciao-controller .. _compute nodes: https://github.com/01org/ciao/tree/master/ciao-launcher .. _network node: https://github.com/01org/ciao/tree/master/ciao-launcher +.. _ciao.yml: https://github.com/clearlinux/clear-config-management/blob/master/examples/ciao/ciao.yml +.. _hosts: https://github.com/clearlinux/clear-config-management/blob/master/examples/ciao/hosts +.. _groups_vars/all: https://github.com/clearlinux/clear-config-management/blob/master/examples/ciao/group_vars/all +.. _github: https://github.com/clearlinux/clear-config-management/tree/master/examples/ciao From 726d75b8bdf1b66b0db50fe845703df3b39ae3cd Mon Sep 17 00:00:00 2001 From: "Tullis, Michael L" Date: Tue, 6 Sep 2016 09:59:36 -0700 Subject: [PATCH 09/12] Language and formatting corrections to merge request 95. --- source/ciao-deploy.rst | 42 +++++++++++++++++++++--------------------- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/source/ciao-deploy.rst b/source/ciao-deploy.rst index cea176de..fc8113fd 100644 --- a/source/ciao-deploy.rst +++ b/source/ciao-deploy.rst @@ -7,7 +7,7 @@ Deploying ciao via automation Cloud Integrated Advanced Orchestrator (``ciao``) is a new workload scheduler designed to address limitations of current cloud OS projects. -CIAO provides a lightweight, fully TLS-based minimal config, is +Ciao provides a lightweight, fully TLS-based minimal config, is workload-agnostic, easy to update, offers an optimized-for-speed scheduler, and is currently optimized for OpenStack*. @@ -22,15 +22,15 @@ For this example, we'll use a total of five nodes: - Two `compute nodes`_, which will spawn the VMs and containers. - A `network node`_ which will handle the networking for the workloads. - Note: The deployment machine is not necessary part of the cluster, it could be - the sysadmin's computer or an CI/CD server. + Note: The deployment machine is not a necessary part of the cluster; it could be + the sysadmin's computer or a CI/CD server. .. _prerequisites: Prerequisites ============= Ansible* uses :command:`ssh` to run commands on the remote nodes. In order to do -that, the nodes must be configured to allow passwordless ssh connections +that, the nodes must be configured to allow passwordless SSH connections from the deployment machine to the cluster nodes. The user should also have sudo privileges on the cluster nodes. @@ -38,7 +38,7 @@ sudo privileges on the cluster nodes. Install the software ==================== -In ClearLinux install the ``sysadmin-hostmgmt`` bundle on the deployment node. This +In Clear Linux, install the ``sysadmin-hostmgmt`` bundle on the deployment node. This bundle contains the Ansible software required to run the playbooks. .. code-block:: console @@ -46,20 +46,20 @@ bundle contains the Ansible software required to run the playbooks. # swupd bundle-add sysadmin-hostmgmt Install ``go-basic``, ``os-core-dev``, ``kvm-host`` and ``os-common`` bundles -on the development node. This bundles contains requirements needed by the playbooks +on the development node. These bundles contain requirements needed by the playbooks. .. code-block:: console # swupd bundle-add go-basic os-core-dev kvm-host os-common go-basic - provides golang which is needed to compile ciao + provides golang, which is needed to compile ciao os-core-dev - provides gcc which is needed to compile some ciao dependencies + provides gcc, which is needed to compile some ciao dependencies kvm-host - provides qemu which is needed to build the CNCI image + provides qemu, which is needed to build the CNCI image os-common - provides python-keystoneclient which is a dependency of the keystone role + provides python-keystone client, which is a dependency of the keystone role For Ubuntu and Fedora, follow the instructions from `github`_ @@ -76,21 +76,21 @@ of the sample playbook into your home folder Note: These files are also hosted in `github`_ -The relevant files in the playbook are the following:: +The relevant files in the playbook are the following: -The `ciao.yml`_ file is the master playbook file and includes a playbook -for each component of the cluster. + * The `ciao.yml`_ file is the master playbook file and includes a playbook + for each component of the cluster. -The `hosts`_ file is the hosts inventory file and contains the IP -addresses/FQDN of your nodes, grouped under the roles they will serve + * The `hosts`_ file is the hosts inventory file and contains the IP + addresses/FQDN of your nodes, grouped under the roles they will serve -The `groups_vars/all`_ file contains variables that will be applied -to your ciao setup. The mandatory variables are already there; be -sure to change the values accordingly to fit your environment + * The `groups_vars/all`_ file contains variables that will be applied + to your ciao setup. The mandatory variables are already there; be + sure to change the values accordingly to fit your environment -The ``ciao_guest_key`` value in :file:`groups_var/all` is the key to be used to connect to the VMs created by -ciao; you can use the ``ssh-keygen`` command to create one as explained in the -:ref:`prerequisites` section. + * The ``ciao_guest_key`` value in :file:`groups_var/all` is the key to be used to connect to the VMs created by + ciao; you can use the ``ssh-keygen`` command to create one as explained in the + :ref:`prerequisites` section. A full list of available variables can be found in the ciao-* roles at https://github.com/clearlinux/clear-config-management/tree/master/roles From 7a7fae1a4ad75b7f330268c0c57f625e193d3384 Mon Sep 17 00:00:00 2001 From: "L.S. Cook" Date: Tue, 6 Sep 2016 12:56:06 -0700 Subject: [PATCH 10/12] removing out of date reference to April 2016 download images --- source/ciao-cluster-setup.rst | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/source/ciao-cluster-setup.rst b/source/ciao-cluster-setup.rst index 51aec448..82b8c02e 100644 --- a/source/ciao-cluster-setup.rst +++ b/source/ciao-cluster-setup.rst @@ -71,10 +71,10 @@ Install Clear Linux OS for Intel Architecture as host on all nodes Install Clear Linux OS for Intel Architecture as the host OS on all nodes by following the instructions in the topic -:ref:`gs_installing_clr_as_host`. The current April 2016 -`downloadable installer images`_ are compatible with ciao. +:ref:`gs_installing_clr_as_host`. The current `downloadable installer images`_ +are compatible with ciao. -After the base installation on each node add the following additional +After the base installation on each node, add the following additional bundle, which adds components needed by CIAO:: $ swupd bundle-add cloud-control @@ -85,7 +85,7 @@ Build the CIAO software ----------------------- Ciao is written in the Go programming language. It requires Go 1.6 to -build. Most Linux distributions have out of date versions of Go in their +build. Most Linux distributions have out-of-date versions of Go in their repositories, so you will probably need to download and install a recent version of Go. This can be easily done by following the `Go installation instructions `__. @@ -146,7 +146,7 @@ the `Starting a workload` section. Keystone node ------------- -You need to run a Keystone service. General documentation on setting +You need to run a Keystone service. General documentation on setting up Keystone services can be found at the `OpenStack developer`_ website. We need a few configuration points. For example::: @@ -157,7 +157,7 @@ We need a few configuration points. For example::: $ openstack role add --project demo --user demo user This adds a ciao compute service, a keystone user and project for the -controller (a.k.a. csr) node, and a demo user with the password +controller (a.k.a. ``csr``) node, and a demo user with the password ``giveciaoatry``. Controller node setup From 08b0c2bc804fcddb5f09733a1784e275a2bc49a2 Mon Sep 17 00:00:00 2001 From: "L.S. Cook" Date: Tue, 6 Sep 2016 16:00:15 -0700 Subject: [PATCH 11/12] grammar edits --- source/ciao-cluster-setup.rst | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/source/ciao-cluster-setup.rst b/source/ciao-cluster-setup.rst index 82b8c02e..7813d94e 100644 --- a/source/ciao-cluster-setup.rst +++ b/source/ciao-cluster-setup.rst @@ -441,11 +441,16 @@ described above. Access your workload ==================== -Once your workload is up, you need to know it's IP address and assigned port, you can find it via ciao-cli:: +Once your workload is up, you need to know its IP address and assigned +port, you can find it via ciao-cli:: $ ciao-cli instance list -Then look for the column "SSH IP", there is the IP assigned to your workload, next to it, you will see the column SSH PORT, that's the port that you will use to access a specific workload using your private key defined in the cloud-init configuration and the user "demouser":: +Then look for the column "SSH IP", there is the IP assigned to your +workload, next to it, you will see the column SSH PORT; that's the +port that you will use to access a specific workload using your +private key defined in the cloud-init configuration and the demo +user name ``demouser``:: $ ssh -p -i demouser@ @@ -462,7 +467,7 @@ On your scheduler node, run the following command:: $ sudo killall -w -9 qemu-system-x86_64 -On your controller node, go to the directory in which you ran the +On your controller node, go to the directory where you ran the ciao-controller binary and run the following commands:: $ sudo killall -w -9 ciao-controller @@ -503,9 +508,9 @@ For general debugging, you can: binaries' command lines. * Reduce your tenants to one (specifically the one with no limits). * Launch fewer VMs in a herd. A small Intel NUC with 16GB of RAM can handle as many as - 50-100 2vcpu 218MB RAM VMs starting at once per compute node. Larger dual socket - many thread CPU with hundreds of GB RAM Haswell-EP servers can handle as many as 500 - such VMs starting at once per compute node. + 50-100 2vcpu 218MB RAM VMs starting at once per compute node. Larger dual-socket + many threaded CPUs with hundreds of GB RAM Haswell-EP servers can handle as many as + 500 such VMs starting at once per compute node. * Tweak the launcher to enable remote access: go get with ``--tags=debug`` to enable a netcat based console redirection for each VM. The launcher console verbose output will indicate per VM how to connect to the console. For example:: From ba731a8fabebc84733e049242c113c6997b89701 Mon Sep 17 00:00:00 2001 From: Alberto Murillo Date: Wed, 7 Sep 2016 10:03:29 -0500 Subject: [PATCH 12/12] ciao-deploy.rst: More updates to documentation - The Prerequisite section no longer explains how to create an ssh-key. Remove a reference to it. - Specify defaults/main.yml file on each role contains a full list of available variables that can be used. - "Start" the deployment rather than "fire" it - Specify the location of ciaorc file Signed-off-by: Alberto Murillo --- source/ciao-deploy.rst | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/source/ciao-deploy.rst b/source/ciao-deploy.rst index fc8113fd..6cf68042 100644 --- a/source/ciao-deploy.rst +++ b/source/ciao-deploy.rst @@ -89,10 +89,9 @@ The relevant files in the playbook are the following: sure to change the values accordingly to fit your environment * The ``ciao_guest_key`` value in :file:`groups_var/all` is the key to be used to connect to the VMs created by - ciao; you can use the ``ssh-keygen`` command to create one as explained in the - :ref:`prerequisites` section. + ciao; you can use the ``ssh-keygen`` command to create one. -A full list of available variables can be found in the ciao-* roles at +A full list of available variables can be found in the :file:`defaults/main.yml` file of each role at https://github.com/clearlinux/clear-config-management/tree/master/roles Install the required ansible-roles @@ -106,7 +105,7 @@ Install the required ansible-roles Run the playbook ================ Once you have your variables and hosts file configured, the deployment can -be fired with the following command: +be started with the following command: .. code-block:: console @@ -129,8 +128,8 @@ was specified in the ``groups_var/all`` file: Offline 0 Maintenance 0 -You could also take a look at the :file:`./ciaorc` file that contains the -following environment variables: +You could also take a look at the :file:`./ciaorc` file created on your +deployment node, which contains the following environment variables: .. code-block:: console