updating the README with documentation on launching keystone
Change-Id: I9921fe533afbe81a18a4ee7e82632fcd2c3792b1
This commit is contained in:
parent
ed2825d26f
commit
a6310d7692
90
README.md
90
README.md
@ -24,15 +24,20 @@ Build Docker Images
|
||||
Within the docker directory is a tool called build. This tool will build
|
||||
all of the docker images that have been implemented. Each OpenStack service is
|
||||
implemented as a separate container that can later be registered with
|
||||
Kubernetes.
|
||||
Kubernetes. These containers are published to the the public docker registry and
|
||||
are referenced in the kubernetes configuration files in this repo.
|
||||
|
||||
** [sdake@bigiron docker]$ sudo ./build **
|
||||
```
|
||||
[sdake@bigiron docker]$ sudo ./build
|
||||
```
|
||||
|
||||
A 20-30 minute build process will begin where containers will be built for
|
||||
each OpenStack service. Once finished the docker images can be examined with
|
||||
the docker CLI.
|
||||
|
||||
** [sdake@bigiron docker]$ sudo docker images **
|
||||
```
|
||||
[sdake@bigiron docker]$ sudo docker images
|
||||
```
|
||||
|
||||
A list of the built docker images will be shown.
|
||||
|
||||
@ -43,8 +48,85 @@ defined environment variables. They are essentially placeholders.
|
||||
Use Kubernetes to Deploy OpenStack
|
||||
----------------------------------
|
||||
|
||||
This has not been implemented.
|
||||
Keystone and MariaDB are the only pods that are implimented. They operate
|
||||
just enough to verify that services are running and may have bugs in their configurations.
|
||||
|
||||
To get Keystone running start by downloading the pod and service json files for MariaDB
|
||||
to a running kubernetes cluster.
|
||||
```
|
||||
curl https://raw.githubusercontent.com/stackforge/kolla/master/docker/mariadb/mariadb-service.json >
|
||||
mariadb-service.json
|
||||
curl https://raw.githubusercontent.com/stackforge/kolla/master/docker/mariadb/mariadb.json > mariadb.json
|
||||
```
|
||||
|
||||
Next launch the MariaDB pod and service files.
|
||||
```
|
||||
$ kubecfg -c mariadb.json create pods
|
||||
ID Image(s) Host Labels Status
|
||||
---------- ---------- ---------- ---------- ----------
|
||||
mariadb kollaglue/fedora-rdo-mariadb / name=mariadb-master Waiting
|
||||
|
||||
$ kubecfg -c mariadb-service.json create services
|
||||
ID Labels Selector Port
|
||||
---------- ---------- ---------- ----------
|
||||
mariadbmaster name=mariadb-master 3306
|
||||
```
|
||||
To verify their creation and see their status use the list command. You are ready to move on when the
|
||||
pod's status reaches **Running**.
|
||||
```
|
||||
$ kubecfg list pods
|
||||
ID Image(s) Host Labels Status
|
||||
---------- ---------- ---------- ---------- ----------
|
||||
mariadb kollaglue/fedora-rdo-mariadb 10.0.0.3/ name=mariadb-master Running
|
||||
```
|
||||
If MariaDB doesn't move to running within a few minutes use journalctl on the master and the nodes to
|
||||
troubleshoot. The first command is for the master and the second is for the nodes.
|
||||
```
|
||||
$ journalctl -f -l -xn -u kube-apiserver -u etcd -u kube-scheduler
|
||||
$ journalctl -f -l -xn -u kubelet.service -u kube-proxy -u docker
|
||||
```
|
||||
Once the pod's status reaches running you should verify that you can connect to the database through all the
|
||||
kube-proxies. You can use telnet to do this. Telnet to 3306 on each node and make sure mysql responds.
|
||||
```
|
||||
$ telnet 10.0.0.4 3306
|
||||
Trying 10.0.0.4...
|
||||
Connected to 10.0.0.4.
|
||||
Escape character is '^]'.
|
||||
|
||||
5.5.39-MariaDB-wsrep
|
||||
|
||||
$ telnet 10.0.0.3 3306
|
||||
Trying 10.0.0.3...
|
||||
Connected to 10.0.0.3.
|
||||
Escape character is '^]'.
|
||||
|
||||
5.5.39-MariaDB-wsrep
|
||||
```
|
||||
If the connection closes before mysql responds then the proxy is not properly connecting to the database.
|
||||
This can be seen by using jounalctl and watching for a connection error on the node that you can't connect
|
||||
to mysql through.
|
||||
```
|
||||
$ journalctl -f -l -xn -u kube-proxy
|
||||
```
|
||||
If you can conect though one and not the other there's probably a problem with the overlay network. Double
|
||||
check that you're tunning kernel 3.16+ because vxlan support is required. If you kernel version is good
|
||||
try restarting openvswitch on both nodes. This has usually fixed the connection issues for me.
|
||||
|
||||
If you're able to connect to mysql though both proxies then you're ready to launch keystone. Download and
|
||||
use the pod and service files to launch the pods and services for keystone.
|
||||
```
|
||||
$ curl https://raw.githubusercontent.com/stackforge/kolla/master/docker/keystone/keystone-service-35357.json >
|
||||
keystone-service-35357.json
|
||||
$ curl https://raw.githubusercontent.com/stackforge/kolla/master/docker/keystone/keystone-service-5000.json >
|
||||
keystone-service-5000.json
|
||||
$ curl https://raw.githubusercontent.com/stackforge/kolla/master/docker/keystone/keystone.json > keystone.json
|
||||
$ kubecfg -c keystone.json create pods
|
||||
$ kubecfg -c keystone-service-5000.json create services
|
||||
$ kubecfg -c keystone-service-35357.json create services
|
||||
```
|
||||
The keystone pod should become status running, if it doesn't you can troubleshoot it the same way that the
|
||||
database was. Once keystone is running you should be able to use the keystone client to do a token-get
|
||||
against one of the proxy's ip addresses.
|
||||
|
||||
Directories
|
||||
===========
|
||||
|
Loading…
x
Reference in New Issue
Block a user