Update doc again according last changes in the implementation. Change-Id: If9c10e806aa8a2b5507a26a952fc885edb3b94aa Depends-On: I07daad9be8b4ccbc5a8e618351e8897af7d61672
9.1 KiB
Executable File
Resource Bootstrapping
Current section describes what and how can be bootstrapped in the CCP. There are several services, which have bootstrapping. It's:
networks
images
flavors
Network bootstrapping
This section allows to configure internal and external networking in neutron. Snippet below demonstrates all available options:
configs:
neutron:
bootstrap:
internal:
enable: true
net_name: int-net
subnet_name: int-subnet
network: 10.0.1.0/24
gateway: 10.0.1.1
external:
enable: false
net_name: ext-net
subnet_name: ext-subnet
physnet: changeme
network: changeme
gateway: changeme
nameserver: changeme
pool:
start: changeme
end: changeme
router:
name: ext-router
First part configures internal network. All options have default values:
Name | Description | Default |
---|---|---|
enable | boolean flag, which turns on/off bootstrap. | true |
net_name | Name of the internal network, which will be created in neutron. | int-net |
subnet_name | Name of the subnet in internal network, which will be created in neutron. | int-subnet |
network | CIDR of the internal network for allocating internal IP addresses. | 10.0.1.0/24 |
gateway | Gateway for subnet in the internal network. | 10.0.1.1 |
Second part describes external network configuration. Bootstrapping for external network is disabled by default and user should specify all options after turning it on, because most of them don't have default values.
Name | Description | Default |
---|---|---|
enable | boolean flag, which turns on/off bootstrap. | false |
net_name | Name of the external network, which will be created in neutron. Default value can be used. | ext-net |
subnet_name | Name of the subnet in external network, which will be created in neutron. Default value can be used. | ext-subnet |
physnet | Name of the physnet, which was defined in physnets section. | -- |
network | CIDR of the external network for allocating external IP addresses. | -- |
gateway | Gateway for subnet in the external network. | -- |
nameserver | DNS server for subnet in external network. | -- |
pool | Pool of the addresses from external network, which can be used for association with Openstack VMs. Should be specified by using nested keys: start and end, which requires corresponding IP addresses. | -- |
The last section is a router configuration. It allows to specify name of the router, which will be created in neutron. Both networks will be connected with this router by default (except situation, when bootstrapping only for internal network is enabled). If bootstrapping is enabled at least for one network, router will be automatically created. In case, when user does not want to change default router name (ext-router) this section can be skipped in config.
Creation of the networks is handled by neutron post deployment jobs neutron-bootstrap-*, which call openstackclient with specified parameters.
Example
As a simple example let's use snippet below:
configs:
neutron:
physnets:
- name: ext-physnet
bridge_name: br-ex
interface: ens5
flat: true
vlan_range: false
bootstrap:
# external network parameters
external:
enable: true
physnet: ext-physnet
network: 10.90.2.0/24
gateway: 10.90.2.1
nameserver: 8.8.8.8
pool:
start: 10.90.2.10
end: 10.90.2.250
Now go through all options and comments, what and why was choosen. First of all need to note, that interface ens5 and bridge br-ex are used for creation physnet. Then in bootstrap section name of created physnet is used for providing references for external network. Google public DNS server (8.8.8.8) is used as a nameserver. The main tricky thing here is an IP range and a gateway. In the current example Host for Kubernetes cluster has interface with IP address equal to specified IP in the gateway field. It's usually necessary for providing access from Openstack VMs to service APIs. At the end don't forget to be careful with pool of available external addresses. It should not contain IPs outside of cluster.
Image bootstrapping
Bootstrap for image allows to create/upload one image after deploying glance services. To enable it, user needs to add lines mentioned below to ~/.ccp.yaml:
configs:
glance:
bootstrap:
enable: true
image:
url: http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img
disk_format: qcow2
name: cirros
This snippet adds bootstrap section for glance service and enables it. Note, that by default enable option is False. So if user wants to use bootstrapping he should explicitly set it to True.
The last part of the snippet describes image specific options. All options should be specified, otherwise it will cause an error during job execution:
Name | Description | Default |
---|---|---|
url | url, which will be used for downloading image. | http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img |
disk_format | format of the image which will be used during image creation in the glance. | qcow2 |
name | name of the image, which will be created in the glance. | cirros |
Creation of the image is handled by glance post deployment job
glance-cirros-image-upload, which uses Bash script from
fuel-ccp-glance repository:
service/files/glance-cirros-image-upload.sh.j2
.
Flavor bootstrapping
The CCP automatically creates list of the default flavors, which are mentioned in the table below:
Name | ID | RAM | Disk | VCPUs |
---|---|---|---|---|
|
|
|
|
1 |
|
|
|
|
1 |
|
|
|
|
1 |
|
|
|
|
2 |
|
|
|
|
4 |
|
|
|
|
8 |
The corresponding section in the config file looks like:
configs:
nova:
bootstrap:
enable: true
flavors:
- name: m1.test
id: 0
ram: 128
disk: 1
vcpus: 1
- name: m1.tiny
id: 1
ram: 512
disk: 1
vcpus: 1
- name: m1.small
id: 2
ram: 2048
disk: 20
vcpus: 1
- name: m1.medium
id: 3
ram: 4096
disk: 40
vcpus: 2
- name: m1.large
id: 4
ram: 8192
disk: 80
vcpus: 4
- name: m1.xlarge
id: 5
ram: 16384
disk: 160
vcpus: 8
Creation of the flavors is handled by nova post deployment job
nova-bootstrap-flavors, which uses Bash script from
fuel-ccp-nova repository:
service/files/create-flavors.sh.j2
.
User also can specify to bootstrap custom flavors. Similar to previous sections it can be done by adding the following snippet to ~/.ccp.yaml:
configs:
nova:
bootstrap:
enable: true
flavors:
- name: custom_name1
id: 42
ram: 1024
disk: 1
vcpus: 1
- name: custom_name2
id: 43
ram: 2024
disk: 2
vcpus: 2
Warning
New list of custom flavors will overwrite default flavors and they will not be created. To avoid it, just copy paste definition of default flavors to your config and then extend it by new custom flavors.
This snippet adds bootstrap section for nova service. Note, that by default enable option is True. So if user doesn't want to use bootstrapping he should explicitly set it to False.
The last part of the snippet describes list of flavors with related options. All options should be specified, otherwise it will cause an error during job execution:
Name | Description | Default |
---|---|---|
name | Name of the custom flavor. | -- |
id | Indentifier of the flavor. | -- |
ram | Vaqlue of the RAM memory for the current flavor. | -- |
disk | Disk size for the curretn flavor. | -- |
vcpus | Number of the vcpus for the current flavor. | -- |