diff options
Diffstat (limited to 'docs/sections/blueprints/centos_vm.rst')
-rw-r--r-- | docs/sections/blueprints/centos_vm.rst | 145 |
1 files changed, 0 insertions, 145 deletions
diff --git a/docs/sections/blueprints/centos_vm.rst b/docs/sections/blueprints/centos_vm.rst deleted file mode 100644 index cd2660e4..00000000 --- a/docs/sections/blueprints/centos_vm.rst +++ /dev/null @@ -1,145 +0,0 @@ -CentOS VM -====================== - -Note: This blueprint is intended to be deployed, automatically, as part of the -DCAE bootstrap process, and is not normally invoked manually. - -This blueprint controls the deployment of a VM running the CentOS 7 operating system, used to -run an instance of the Cloudify Manager orchestration engine. - -This blueprint is used to bootstrap an installation of Cloudify Manager. All other DCAE -components are launched using Cloudify Manager. The Cloudify Manager VM and the Cloudify Manager -software are launched using the Cloudify command line software in its local mode. - -Blueprint files ----------------------- - -The blueprint file is stored under source control in the ONAP ``dcaegen2.platform.blueprints`` project, in the ``blueprints`` -subdirectory of the project, as a template named ``centos_vm.yaml-template``. The build process expands -the template to fill in certain environment-specific values. In the ONAP integration environment, the build process -uploads the expanded template, using the name ``centos_vm.yaml``, to a well known-location in a Nexus artifact repository. - -Parameters ---------------------- - -This blueprint has the following required input parameters: -* ``centos7image_id`` - - This is the OpenStack image ID of the Centos7 VM image that will be - used to launch the Cloudify Manager VM. - -* ``ubuntu1604image_id`` - - This is not used by the blueprint but is specified here so that the blueprint - can use the same common inputs file as other DCAE VMs (which use an Ubuntu 16.04 image). - -* ``flavor_id`` - - This is the OpenStack flavor ID specifying the amount of memory, disk, and - CPU available to the Cloudify Manager VM. While the required values will be - largely application dependent, a minimum of 16 Gigabytes of memory is - strongly recommended. - -* ``security_group`` - - This is the OpenStack security group specifying permitted inbound and - outbound IP connectivity to the VM. - -* ``public_net`` - - This is the name of the OpenStack network from which a floating IP address - for the VM will be allocated. - -* ``private_net`` - - This is the name of the OpenStack network from which fixed IP addresses for - the VM will be allocated. - -* ``openstack`` - - This is the JSON object / YAML associative array providing values necessary - for accessing OpenStack. The keys are: - - * ``auth_url`` - - The URL for accessing the OpenStack Identity V2 API. (The version of - Cloudify currently being used, and the associated OpenStack plugin do - not currently support Identity V3). - - * ``tenant_name`` - - The name of the OpenStack tenant/project where the VM will be launched. - - * ``region`` - - The name of the OpenStack region within the deployment. In smaller - OpenStack deployments, where there is only one region, the region is - often named ``RegionOne``. - - * ``username`` - - The name of the OpenStack user used as a credential for accessing - OpenStack. - - * ``password`` - - The password of the OpenStack user. (The version of Cloudify currently - being used does not provide a mechanism for encrypting this value). - -* ``keypair`` - - The name of the ssh "key pair", within OpenStack, that will be given access, - via the ubuntu login, to the VMs. Note: OpenStack actually stores only the - public key. - -* ``key_filename`` - - The full file path, on the Cloudify Manager VM, - of the ssh private key file corresponding to the ``keypair`` input parameter. - -* ``location_domain`` - - The DNS domain/zone for DNS entries associated with the VM. - If, for example, location_domain is ``dcae.example.com`` then the FQDN for - a VM with hostname ``abcd`` would be ``abcd.dcae.example.com`` and a DNS - lookup of that FQDN would lead an A (or AAAA) record giving the floating - IP address assigned to that VM. - -* ``location_prefix`` - - The hostname prefix for hostname of the VM. The hostname - assigned to the VM is created by concatenating this prefix with a suffix - identifying the Cloudify Manager VM (``orcl00``). If the location prefix is ``jupiter`` then the hostname of - the Cloudify Manager VM would be ``jupiterorcl00``. - -* ``codesource_url`` and ``codesource_version`` - - This is not used by the blueprint but is specified here so that the blueprint - can use the same common inputs file as other DCAE VMs. Some of the other VMs use - combination of ``codesource_url`` and ``codesource_version`` to locate scripts - that are used at installation time. -* ``datacenter`` - - The datacenter name that is used by the DCAE Consul installation. This is needed so that the Consul agent - installed on the Cloudify Manager VM can be configured to register itself to the Consul service discovery system. - -This blueprint has the following optional inputs: - -* ``cname`` (default ``dcae-orcl``) - - A DNS alias name for the Cloudify Manager VM. In addition to creating a DNS A record for the Cloudify Manager VM, - the installation process also creates a CNAME record, using ``dcae-orcl`` by default as the alias. - For example, if the ``location_domain`` input is ``dcae.example.com``, the ``location_prefix`` input is ``jupiter``, - and the ``cname`` input is the default ``dcae-orcl``, then the installation process will create an A record for - ``jupiterorcl00.dcae.example.com`` and a CNAME record for ``dcae-orcl.dcae.example.com`` that points to - ``jupiterorcl00.dcae.example.com``. - - -How To Run ---------------------- - -This blueprint is run as part of the bootstrapping process. (See the ``dcaegen2.deployments`` project.) -Running it manually requires setting up a Cloudify 3.4 command line environment--something that's handled -automatically by the bootstrap process. - - |