Browse Source

Merge "Add description of Heat workaround"

Jenkins 2 years ago
parent
commit
38ca18253e
2 changed files with 139 additions and 0 deletions
  1. 1
    0
      doc/source/index.rst
  2. 138
    0
      doc/source/known_issues.rst

+ 1
- 0
doc/source/index.rst View File

@@ -29,6 +29,7 @@ Advanced topics
29 29
    ceph_cluster
30 30
    using_calico_instead_of_ovs
31 31
    ironic
32
+   known_issues
32 33
 
33 34
 Service plugins docs
34 35
 --------------------

+ 138
- 0
doc/source/known_issues.rst View File

@@ -0,0 +1,138 @@
1
+.. _known_issues:
2
+
3
+=====================
4
+Services Known Issues
5
+=====================
6
+
7
+This sections describe known issues and corresponding workarounds, if they are.
8
+
9
+[Heat] WaitCondition and SoftwareDeployment resources
10
+=====================================================
11
+
12
+Problem description
13
+-------------------
14
+
15
+CCP deploys Heat services with default configuration and changes endpoint_type
16
+from publicURL to internalURL. However such configuration in Kubernetes cluster
17
+is not enough for several type of resources like OS::Heat::Waitcondition and
18
+OS::Heat::SoftwareDeployment, which require callback to Heat API or
19
+Heat API CFN. Due to Kubernetes architecture it's not possible to do such
20
+callback on the default port value (for heat-api it's - 8004 and 8000 for
21
+heat-api-cfn). Note, that exactly these ports are used in endpoints registred
22
+in keystone.
23
+
24
+Also there is an issue with service domain name to ip resolving from VM booted
25
+in Openstack.
26
+
27
+There are two ways to fix these issues, which will be described below:
28
+ - Out of the box, which requires just adding some data to ``.ccp.yaml``.
29
+ - With manual actions.
30
+
31
+Prerequisites for workarounds
32
+-----------------------------
33
+
34
+Before applying workaround please make sure, that current ccp deployment
35
+satisfies the following prerequisites:
36
+ - VM booted in Openstack can be reached via ssh (don't forget to configure
37
+   corresponding security group rules).
38
+ - IP address of Kubernetes node, where heat-api service is run, is accessible
39
+   from VM booted in Openstack.
40
+
41
+Workaround out of the box
42
+-------------------------
43
+
44
+This workaround is similar for both resources and it's related to kubernetes
45
+node external ip usage node with hardcoded node port in config.
46
+
47
+#. Add the following lines in the config ``.ccp.yaml``:
48
+
49
+   ::
50
+
51
+     k8s_external_ip: x.x.x.x
52
+     heat:
53
+       heat_endpoint_type: publicURL
54
+       api_port:
55
+         node: 31777
56
+       api_cfn_port:
57
+         node: 31778
58
+
59
+   Where ``x.x.x.x`` is IP of kubernetes node, where Heat services are run.
60
+   The second line explicitly sets publicURL in Heat config for initialisation
61
+   of the heat client with public endpoint.
62
+   Next lines set hardcoded ports for services: heat-api and heat-api-cfn. User
63
+   may choose any free port from K8S range for these services.
64
+
65
+   All these options should be used together, because external ip will be used
66
+   by ccp only with node ports. Also combination of IP and port will be applied
67
+   only for public enpoint.
68
+
69
+#. After this change you may run ``ccp deploy`` command.
70
+
71
+.. WARNING:: There are two potential risks here:
72
+
73
+ - Specified node port is in use by some other service, so user needs to change
74
+   another free port.
75
+ - Using heatclient with enabled ingress can be broken. It was not tested fully
76
+   yet.
77
+
78
+Workaround after deploy
79
+-----------------------
80
+
81
+This workaround can be used, when Openstack is already deployed and cloud
82
+administrator can change only one component.
83
+
84
+#. Need to gather information about Node Ports and IP of Kubernetes node with
85
+   services. User may get ``Node Ports`` for all heat API services by using
86
+   the following commands:
87
+
88
+   ::
89
+
90
+     # get Node Port API
91
+     kubectl get service heat-api -o yaml | awk '/nodePort: / {print $NF}'
92
+
93
+     # get Node Port API CFN
94
+     kubectl get service heat-api-cfn -o yaml | awk '/nodePort: / {print $NF}'
95
+
96
+   Obtain ``service IP`` by executing ``ping`` command from Kubernetes host to
97
+   domain names of services (e.g. ``heat-api.ccp``).
98
+
99
+#. Then these IP and Node ports should be used as internal endpoints for
100
+   corresponding services in keystone, i.e. replace old internal endpoints with
101
+   domain names to IP with Node Ports for heat-api and heat-api-cfn. It should
102
+   look like:
103
+
104
+  ::
105
+
106
+    # delete old endpoint
107
+    openstack endpoint delete <id of internal endpoints>
108
+
109
+    # create new endpoint for heat-api
110
+    openstack endpoint create --region RegionOne \
111
+    orchestration internal http://<service IP>:<Node Port API>/v1/%\(tenant_id\)s
112
+
113
+    # create new endpoint for heat-api-cfn
114
+    openstack endpoint create --region RegionOne \
115
+    cloudformation internal http://<service IP>:<Node Port API CFN>/v1/
116
+
117
+.. NOTE:: For Waitcondition resource validation simple `heat template`_ can be
118
+          used.
119
+
120
+#. The previous steps should be enough for fixing Waitcondition resource.
121
+   However for SoftwareDeployment usage it is necessary to remove two options
122
+   from ``fuel-ccp-heat/service/files/heat.conf.j2 file``:
123
+     - heat_waitcondition_server_url
124
+     - heat_metadata_server_url
125
+
126
+   It's necessary, because otherwise they will be used instead of internal
127
+   endpoints. Such change requires partial redeploy, which can be done with
128
+   commands:
129
+
130
+  ::
131
+
132
+    ccp deploy -c heat-engine heat-api heat-api-cfn
133
+
134
+To validate, that this change was applied just check, that new containers for
135
+these services were started.
136
+
137
+.. _heat template: https://github.com/openstack/heat-templates/blob/master/hot/native_waitcondition.yaml
138
+

Loading…
Cancel
Save