Sunday, December 22, 2019

A Torrid Tail of Too Many Circles - Continued

Previously

In my earlier post, I covered how I attempted to create a Moire pattern on my pyportal screen. While the implementation was pretty simple, there were issues with excessive memory usage and dreadful refresh speed.

Moving to a faster speed


The first implementation used a lot of system memory because each rendered circle consisted of a TileGrid, Bitmap and Palette. The goal for the second implementation was to reduce the amount of memory used by using one Bitmap per group of circles. I first needed to refresh my memory on how to find the points on a circle. A quick trip down the Google results lead me to this page. I was able to quickly implement a draw_circle function to a circle to a provided Bitmap. The center and radius of the of the circle are used as the basis of the function and a SMOOTHNESS value is used to determine the size of each calculated step. The draw_circle is wrapped in two loops to generate each set of circles into a single bitmap. Parameters are provided for the number and spacing of the generated circles and how much time to wait between each set of calculations.

Journey Review


The new circle function is much faster and generates a pleasing set of circles. Memory usage is much less since only one TileGrid, Bitmap and Palette is used for the display. However, it takes quite a few seconds to generate a new set of circles in the Bitmap. However, the random placement of the circles results in display updates which can be displeasing. This issue was rectified by adding a 'wobble' to the previous generation's centers. The math still takes a long time but the updates are more pleasing.

Where to go next


Is it possible to make the updates faster?

Monday, December 16, 2019

A Torrid Tail of Too Many Circles

Where it all began....


A long time ago, I received a Adafuit pyportal from one of their mystery boxes. This device has spent most of its time collecting dust or displaying the default demonstration code. I decided to replicate some coding from the 80s and see if I could display Moire Patterns on the pyportal screen. To this end, I have started the journey of drawing too many circles on the screen.

I decided to use the CircuitPython language to code my implementations. I could use a variety of editors (vim, Mu and Atom) and run the code by simply updating the code.py file on the device. My development environment is Linux based so I eventually fell into old development habits and used vim for development, cp for deployment and minicom to monitor code execution.

And so it begins


The Adafruit maintains a list CircuitPython modules available (200!). The main modules used in this project are displayio and Display Shapes. The former is responsible for managing the display and bitmaps while the latter is used to generate shapes. Adafruit has a great information page on how to use the displayio framework. The shapes library returns a TileGrid for each shape generated.

Implementation 


For this implementation, I created a display group per set of circles and populated it with TileGrids created by Circle(). The center of the circles is randomly generated and each ring radius is incrementally larger than the previous. The code will sleep for a few seconds, delete the two display groups and regenerate a new set of circles.

Issues


There are a number of issues with this implementation

  • Memory: Each circles consists of a TileGrid, a bitmap sized to hold the new shape and a palette. This results in 60 total circles able to be drawn.
  • Display Speed: The updating of the display is dreadfully slow. It takes about 20 seconds to update the display. Maybe the Group is not flattened before being displayed. 

Moving forward


Obviously this is not an optimal solution. I continued working on this code based to make speed improvements but that is a tale for another time. 



Friday, April 5, 2019

Developing and testing patches for Rook

Backgroud


The purpose of this posting is to detail the steps needed to develop and test Rook code using the provided CI scripts. My previous blog posting did not use the CI scripting provided by rook and may not provide sufficient testing coverage to pass the upstream CI.

Pre-built infrastructure


Test Hosts Configuration
This CI development environment uses four (4) libvirt virtual machines as test hosts. The hardware configurations of the virtual machines remains the same as in the previous blog posts. These machines are built from the same clone image and configured with as follows
  • Ubuntu 16 (some commands may change for Ubuntu 18)
  • Local user with admin rights, updated to use sudo with no password
  • Pre-populated SSH host keys and StrictHostchecking set to no in the .ssh/config file
  • /etc/hosts file pre-populated with the host name and IP of each test host. 
  • Statically defined IP address as per this blog post

Hostnames and IPs

The virtual machines in this environment will be configured with the following hostnames and IPs
192.168.122.31 kube-ub-master
192.168.122.32 kube-ub-node1
192.168.122.33 kube-ub-node2
192.168.122.34 kube-ub-node3

Configuring the master server

The Rook CI scripts are designed to run from the kubernetes master host. These configuration steps are ran as the configured admin user on that host.

Update DNS resolver and hostname

On Ubuntu 16, the resolv.conf file is managed by systemd. This configuration can result in the coredns container not starting due to a lookup loop.
sudo sed -i -e 's/dns=.*/dns=default/' /etc/NetworkManager/NetworkManager.conf
sudo systemctl disable systemd-resolved.service
sudo systemctl stop  systemd-resolved.service
sudo rm /etc/resolv.conf
echo nameserver 8.8.8.8 | sudo tee /etc/resolv.conf
echo kube-ub-master | sudo tee /etc/hostname

Install go 1.11

The CI requires go version 1.11 to be available on the system in order to build the local images and to run the go based test infrastructure.
wget https://dl.google.com/go/go1.11.6.linux-amd64.tar.gz
cd /usr/local
sudo tar -zxf ~kschinck/go1.11.6.linux-amd64.tar.gz
cd ~
echo export PATH=/usr/local/go/bin:\$PATH | tee -a ~/.bashrc
source .bashrc

Install and configure docker

Configure docker to use the registry on the master node
sudo apt-get install -y docker.io git ansible curl
cat <<EOF | sudo tee /etc/docker/daemon.json
{
  "insecure-registries" : ["192.168.122.31:5000"]
}
EOF
sudo systemctl start docker
sudo systemctl enable docker

Add user to the docker group

To run the CI scripts, the docker user needs to able to run docker commands without using sudo.
sudo usermod -a -G docker myuser
The new group assignment can be picked up by either logging out and back in or running the newgrp command.

Start the docker registry container

The docker registry container needs to be running in order to host the locally build versions of the Rook images.
docker run -d -p 5000:5000 --restart=always --name registry registry:2

Verify Registry Access

The curl command can be used to verify access to the local registry.

curl http://192.168.122.31:5000/v2/_catalog
{"repositories":[]}

Configure Worker Nodes

The worker nodes need to be configure similar to the master node with the exception of needing golang support added.
for HOST in kube-ub-node1 kube-ub-node2 kube-ub-node3
do
  cat<<EOF | ssh $HOST
sudo sed -i -e 's/dns=.*/dns=default/' /etc/NetworkManager/NetworkManager.conf
sudo systemctl disable systemd-resolved.service
sudo systemctl stop  systemd-resolved.service
sudo rm /etc/resolv.conf
echo nameserver 8.8.8.8 | sudo tee /etc/resolv.conf
echo $HOST | sudo tee /etc/hostname
sudo apt-get install -y docker.io 
cat <<EOG | sudo tee /etc/docker/daemon.json
{
  "insecure-registries" : ["192.168.122.31:5000"]
}
EOG
sudo systemctl start docker
sudo systemctl enable docker
echo ‘export GOPATH=${HOME}/go’ | tee -a ~/.bashrc
source .bashrc
echo $PATH
echo $GOPATH
mkdir -p ${GOPATH}/src/github.com/rook
cd ${GOPATH}/src/github.com/rook
git clone http://github.com/myuser/rook.git
cd rook
git checkout mypatch
EOF
done

Download Source Code

At this point we are ready to prepare for and download the forked git repository.The repository is configured according to the Rook development guidelines
These commands will prepare the needed directory path, clone the git repo, switch to the development branch and build the images.
cat <<EOF>>~/.bashrc
export GOPATH=${HOME}/go
EOF
export GOPATH=${HOME}/go
mkdir -p ${GOPATH}/src/github.com/rook
cd ${GOPATH}/src/github.com/rook
git clone http://github.com/myuser/rook.git
cd rook
git checkout mypatch
make

Tag and push built image

The make command will build and upload a rook/ceph image. In order to use this image, this image will need to be tagged and pushed back to the local registry.
docker tag `docker images | grep "rook/ceph" | awk '{print $1":"$2}'` 192.168.122.31:5000/rook/ceph:latest
docker push 192.168.122.31:5000/rook/ceph:latest
The local test framework files need to be update to use the new image. The following command will update the image reference to the local registry.
sed -i -e 's/image: rook.*$/image: 192.168.122.31:5000\/rook\/ceph:latest/' ./tests/framework/installer/ceph_manifests.go

Deploy master  node using CI script

cd tests/scripts
./kubeadm.sh up
The end of this command will display the kubectl command used to configure additional worker nodes. This needs to be copied and used in below worker node configuration setp

Deploy worker nodes using CI script

This command will add each worker host to the kubernetes cluster.
for HOST in kube-ub-node1 kube-ub-node2 kube-ub-node3
do
  cat<<EOF | ssh $HOST
  cd cd ${GOPATH}/src/github.com/rook/rook/tests/scripts
  ./kubeadm.sh install node TEXT_TAKEN_FROM_THE_MASTER_INSTALL_OUTPUT
EOF


Setup the kubectl command for debugging


mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

At this point, the admin will be able to use the kubectl command to interact with the deployed kubernetes cluster.

Run CI Test

Rook uses the provide test framework of go to run the validation commands. The test command is ran from the top of the rook repository directory. It will deploy a variety of configurations and validate the operation of the cluster. Output is saved under the _output directory.
This command will run the standard tests called SmokeSuite and save the output to a file in the /tmp directory.


time go test -v -timeout 1800s -run SmokeSuite github.com/rook/rook/tests/integration 2>&1 | tee /tmp/integration.log

The results can be reviewed from /tmp/integration.log file.

The kubernetes cluster should be in a clean state if the tests finish successfully.

Repeating the CI Execution


If an operator is to be update updated, the previous uploaded images should be deleted from the local repository prior to making updates, rebuilding the image, tagging and pushing.

If the CI configuration is updated, it is sufficient to rerun the go test command line.



Friday, March 8, 2019

Configuring a Rook Test and Development System

Reason

All patches should be tested locally prior to submitting a PR to the Rook project. This posting will detail the steps needed to configure an environment for developing and testing patches for the Rook project.

Environment

This post was developed on virtual machines running Fedora Core 29 but should work on other recent Fedora/CentOS/RHEL OS releases.

Pre-reqs

  • Four (4) virtual machines with the following specifications
    • 1 node: 2 CPU, =>2G, 20Gb storage
    • 3 nodes: 1 CPU, =>2G, 20Gb storage
  • A non-root user with sudo access with the ability install packages locally and on the other test nodes.

Description

This posting will extend the previous blog posting about deploying Ceph storage using Rook on a kubernetes cluster. This posting will detail how to deploy a local docker registry, configure the environment to Rook development, build Rook and, finally, how to test the locally built code.

Procedure


Deploy Local Docker Registry
The docker registry needs to be added to the kube-master host. This can be performed after the base OS configuration but prior to running "kubeadm --init"

The following command will pull down the docker registry image, start the container, make it always restart with the base OS and expose TCP port 5000. Note: the docker command is not normally ran as a non-root user as per this blog posting. For my local config, I have updated the group ownership of the docker UNIX socket from root to wheel.

 $ docker run -d --restart=always -p 5000:5000 --name registry registry
Unable to find image 'registry:latest' locally
Trying to pull repository docker.io/library/registry ... 
sha256:3b00e5438ebd8835bcfa7bf5246445a6b57b9a50473e89c02ecc8e575be3ebb5: Pulling from docker.io/library/registry
c87736221ed0: Pull complete 
1cc8e0bb44df: Pull complete 
54d33bcb37f5: Pull complete 
e8afc091c171: Pull complete 
b4541f6d3db6: Pull complete 
Digest: sha256:3b00e5438ebd8835bcfa7bf5246445a6b57b9a50473e89c02ecc8e575be3ebb5
Status: Downloaded newer image for docker.io/registry:latest
4d56fadeadbff76b14de2093b655af44b7cd08484df5f366fe3c83b4942c7306
$ sudo netstat -tulpn | grep 5000
tcp6       0      0 :::5000                 :::*                    LISTEN      11227/docker-proxy- 

Next, all nodes need docker to be configured to use the local insecure registry. This is done by updating /etc/containers/registries.conf and adding the new registry to the registries.insecure list.
 [registries.insecure]  
 registries = ['192.168.122.3:5000']  

And restart docker.
 $ sudo systemctl restart docker  

Configure Rook Development Environment

Configuring the rook development environment is fairly direct. The only build requirements are the git, go and perl-Digest-SHA packages. The rest of the golang libraries are retrieved during the build process
$ sudo yum install -y git go perl-Digest-SHA  
$ export GOPATH=/home/user/go  
$ mkdir -p ${GOPATH}/github.com/rook  
$ cd ${GOPATH}/github.com/rook  
$ git clone http://github.com/myrepo/rook.git  
$ cd rook  

Note: You should fork the upstream repository, if you are going to develop code for an eventual pull request.

Build Rook

 $ make  
 === helm package rook-ceph  
 ==> Linting /home/kschinck/go/src/github.com/rook/rook/cluster/charts/rook-ceph  
 Lint OK  
 1 chart(s) linted, no failures  
 Successfully packaged chart and saved it to: /home/kschinck/go/src/github.com/rook/rook/_output/charts/rook-ceph-v0.9.0-162.g2ed99b1c.dirty.tgz  
 === helm index  
 === go vet  
 === go build linux_amd64  
 .  
 .  
 . skipped text   
 .  
 .  
 === docker build build-7ad1f371/ceph-amd64  
 sha256:91a2f03ae0bb99a8f65b225b4160402927350618cd2a9592068503c24cb5d701  
 === docker build build-7ad1f371/cockroachdb-amd64  
 sha256:2d6f04f76d22de950fcf7df9e7205608c9baca627dbe4df81448419a4aff2b68  
 === docker build build-7ad1f371/minio-amd64  
 sha256:c1a4b7e09dc5069a6de809bbe2db6f963420038e243080c61bc61ea13bceff14  
 === docker build build-7ad1f371/nfs-amd64  
 sha256:e80fd66429923a0114210b8c254226d11e5ffb0a68cfc56377b8a3eccd3b663f  
 === saving image build-7ad1f371/nfs-amd64  
 === docker build build-7ad1f371/cassandra-amd64  
 sha256:492b314ef2123328c84702c66b0c9589f342b5f644ac5cff1de2263356446701  
 === docker build build-7ad1f371/edgefs-amd64  
 sha256:0d0ab8dd81261d0f325f83a690c7997707582126ab01e5f7e7a55fe964143c5d  
 === saving image build-7ad1f371/edgefs-amd64  
 $ docker images  
 REPOSITORY                         TAG              IMAGE ID      CREATED       SIZE  
 build-7ad1f371/edgefs-amd64        latest             0d0ab8dd8126    13 minutes ago   411 MB  
 build-7ad1f371/cassandra-amd64     latest             492b314ef212    13 minutes ago   141 MB  
 build-7ad1f371/nfs-amd64           latest             e80fd6642992    13 minutes ago   391 MB  
 build-7ad1f371/minio-amd64         latest             c1a4b7e09dc5    18 minutes ago   81.9 MB  
 build-7ad1f371/cockroachdb-amd64   latest             2d6f04f76d22    18 minutes ago   243 MB  
 build-7ad1f371/ceph-amd64          latest             91a2f03ae0bb    18 minutes ago   610 MB  
 docker.io/rook/ceph                master             b924a5979c14    4 days ago     610 MB  

Testing Locally Built Code

The built Ceph image needs to be tagged and the Ceph operator.yaml CRD file updated to use the new image from the local registry.
 $ IMG=`docker images | grep -Eo '^build-[a-z0-9]{8}/ceph-[a-z0-9]+\s'`  
 $ echo $IMG  
 build-7ad1f371/ceph-amd64  
 $ docker tag $IMG 192.168.122.3:5000/rook/ceph:latest  
 $ docker push 192.168.122.3:5000/rook/ceph:latest  
 The push refers to a repository [192.168.122.3:5000/rook/ceph]  
 5111818ce34e: Pushed   
 1d339a1e5398: Pushed   
 88c1eb656680: Pushed   
 f972d139738d: Pushed   
 latest: digest: sha256:80d3ec16e4e6206530756a5a7ce76b51f336a1438af5de77488917f5d1f7b602 size: 1163  
 $ docker images | grep "rook/ceph"  
 192.168.122.3:5000/rook/ceph     latest             91a2f03ae0bb    2 hours ago     610 MB  
 docker.io/rook/ceph         master             b924a5979c14    4 days ago     610 MB 
$ curl -X GET http://192.168.122.3:5000/v2/_catalog
{"repositories":["rook/ceph"]}
 $ sed -i 's|image: .*$|image: 192.168.122.3:5000/rook/ceph:latest|' cluster/examples/kubernetes/ceph/operator.yaml  

Once the operator.yaml CRD file has been updated, the ceph cluster can be deployed using the normal workflow.
$ cd cluster/examples/kubernetes/ceph/
$ kubectl -n rook-ceph-system describe pod rook-ceph-operator-9d496c54b-gmnrw | grep Image  
   Image:     192.168.122.3:5000/rook/ceph:latest  
   Image ID:   docker-pullable://192.168.122.3:5000/rook/ceph@sha256:80d3ec16e4e6206530756a5a7ce76b51f336a1438af5de77488917f5d1f7b602  


References:

https://schmaustech.blogspot.com/2019/01/rook-ceph-on-kubernetes.html
https://www.projectatomic.io/blog/2015/08/why-we-dont-let-non-root-users-run-docker-in-centos-fedora-or-rhel/
https://rook.io/docs/rook/v0.9/development-flow.html
https://github.com/rook/rook


Thursday, March 7, 2019

Configuring Static IP Assignments For A libvirt Development Based Development Environment

Reason

Predictable IP placement of virtual machines is useful when performing repeated test of network software.

Environment:

This post was developed on Fedora Core 29 but should work on other recent Fedora/CentOS/RHEL OS releases.

Pre-reqs

A non-root user with sudo access was used to query and configure libvirt

In this example, four virtual machines are used and connected to the default libvirt network. The virtual machines are configured for DHCP.

Network Configuration Diagram

   baseOS<->|   
            |<->vmos1  
    libvirt |<->vmos2  
    default |<->vmos3  
    network |<->vmos4  

Network Configuration Command Line

 $ sudo virsh net-dumpxml default  
 <network connections='4'>  
  <name>default</name>  
  <uuid>e418d7f8-b770-47e6-9cb0-3d013568b761</uuid>  
  <forward mode='nat'>  
   <nat>  
    <port start='1024' end='65535'/>  
   </nat>  
  </forward>  
  <bridge name='virbr0' stp='on' delay='0'/>  
  <mac address='52:54:00:7a:96:4d'/>  
  <ip address='192.168.122.1' netmask='255.255.255.0'>  
   <dhcp>  
    <range start='192.168.122.2' end='192.168.122.254'/>  
   </dhcp>  
  </ip>  
 </network>  

Gather the MAC addresses of each VM

The example hosts have only one network interface. If there are multiple interfaces, gather the MAC address attached to the default network. IP address can be defined for other networks by adjusting the below command lines as needed.
 $ sudo virsh domiflist vmos4  
 Interface Type    Source   Model    MAC  
 -------------------------------------------------------  
 vnet3   network  default  virtio   52:54:00:d3:3e:e7  

Set the mac IP reservation for each MAC address.

Ensure the assigned IP address are available.

 sudo virsh net-update default add ip-dhcp-host '<host mac="52:54:00:87:c4:d1" ip="192.168.122.3"/>' --live --config  
 sudo virsh net-update default add ip-dhcp-host '<host mac="52:54:00:57:b0:a6" ip="192.168.122.4"/>' --live --config  
 sudo virsh net-update default add ip-dhcp-host '<host mac="52:54:00:37:aa:4f" ip="192.168.122.5"/>' --live --config  
 sudo virsh net-update default add ip-dhcp-host '<host mac="52:54:00:d3:3e:e7" ip="192.168.122.6"/>' --live --config  

Display updated network configuration

 $ sudo virsh net-dumpxml default  
 <network connections='4'>  
  <name>default</name>  
  <uuid>e418d7f8-b770-47e6-9cb0-3d013568b761</uuid>  
  <forward mode='nat'>  
   <nat>  
    <port start='1024' end='65535'/>  
   </nat>  
  </forward>  
  <bridge name='virbr0' stp='on' delay='0'/>  
  <mac address='52:54:00:7a:96:4d'/>  
  <ip address='192.168.122.1' netmask='255.255.255.0'>  
   <dhcp>  
    <range start='192.168.122.2' end='192.168.122.254'/>  
    <host mac='52:54:00:87:c4:d1' ip='192.168.122.3'/>  
    <host mac='52:54:00:57:b0:a6' ip='192.168.122.4'/>  
    <host mac='52:54:00:37:aa:4f' ip='192.168.122.5'/>  
    <host mac='52:54:00:d3:3e:e7' ip='192.168.122.6'/>  
   </dhcp>  
  </ip>  
 </network>  

Start/Restart each VM as needed.


The interface can be disconnected/reconnected if a restart is not wanted.

 $ for f in vmos1 vmow2 vmos3 vmos4 ; do sudo virsh destroy $f ; sleep 5 ; sudo virsh start $f ; done  

Update hosts file

The hosts file is updated to ease host access
 $ cat <<EOF | sudo tee -a /etc/hosts  
 192.168.122.3 vmos1  
 192.168.122.4 vmos2  
 192.168.122.5 vmos3  
 192.168.122.6 vmos4  
 EOF  

Test connectivity

 $ ping -c4 vmos1  
 PING vmos1 (192.168.122.3) 56(84) bytes of data.  
 64 bytes from vmos1 (192.168.122.3): icmp_seq=1 ttl=64 time=0.387 ms  
 64 bytes from vmos1 (192.168.122.3): icmp_seq=2 ttl=64 time=0.418 ms  
 64 bytes from vmos1 (192.168.122.3): icmp_seq=3 ttl=64 time=0.396 ms  
 64 bytes from vmos1 (192.168.122.3): icmp_seq=4 ttl=64 time=0.355 ms  
 --- vmos1 ping statistics ---  
 4 packets transmitted, 4 received, 0% packet loss, time 104ms  
 rtt min/avg/max/mdev = 0.355/0.389/0.418/0.022 ms  


References
Libvirt Networking
Red Hat Virtualization Deployment and Administration Guide

Monday, February 18, 2019

Using Rook deployed Object Store in Kubernetes

Using Rook Deployed Object Store in Kubernetes 


This posting will explore Rook deployed object store using Ceph radosgw within a kubernetes cluster. A radosgw pod will be deployed and a user created. This will be followed by an exploration of the stored credential information and using this information with a custom deployed pod.

Background


Previously, we have deployed a Ceph storage cluster using Rook and demonstrated how to customize the cluster configuration.

Current deployments

$ kubectl -n rook-ceph get pods
NAME                                     READY   STATUS      RESTARTS   AGE
rook-ceph-mgr-a-569d76f456-sddpg         1/1     Running     0          3d21h
rook-ceph-mon-a-6bc4689f9d-r8jcm         1/1     Running     0          3d21h
rook-ceph-mon-b-566cdf9d6-mhf8w          1/1     Running     0          3d21h
rook-ceph-mon-c-74c6779667-svktr         1/1     Running     0          3d21h
rook-ceph-osd-0-6766d4f547-6qlvv         1/1     Running     0          3d21h
rook-ceph-osd-1-c5c7ddf67-xrm2k          1/1     Running     0          3d21h
rook-ceph-osd-2-f7b75cf4d-bm5sc          1/1     Running     0          3d21h
rook-ceph-osd-prepare-kube-node1-ddgkk   0/2     Completed   0          3d21h
rook-ceph-osd-prepare-kube-node2-nmgqj   0/2     Completed   0          3d21h
rook-ceph-osd-prepare-kube-node3-xzwnr   0/2     Completed   0          3d21h
rook-ceph-tools-76c7d559b6-tnmrf         1/1     Running     0          3d21h

Ceph cluster status

$ kubectl -n rook-ceph exec `kubectl -n rook-ceph get pods --selector=app=rook-ceph-tools -o jsonpath='{.items[0].metadata.name}'` -- ceph status
  cluster:
    id:     eff29897-252c-4e65-93e7-6f4975c0d83a
    health: HEALTH_OK
 
  services:
    mon: 3 daemons, quorum a,c,b
    mgr: a(active)
    osd: 3 osds: 3 up, 3 in
 
 data:
    pools:   0 pools, 0 pgs
    objects: 0  objects, 0 B
    usage:   3.1 GiB used, 57 GiB / 60 GiB avail
    pgs:     

Deploying Object Store Pod and User

Rook has CephObjectStore and CephObjectStoreUser CRD which permit the creation of a Ceph RadosGW service and related users. 
The default configurations are deployed with the below commands
RGW Pod

$ kubectl create -f object.yaml 
cephobjectstore.ceph.rook.io/my-store created
$ kubectl -n rook-ceph get pods
NAME                                      READY   STATUS      RESTARTS   AGE
rook-ceph-mgr-a-569d76f456-sddpg          1/1     Running     0          3d21h
rook-ceph-mon-a-6bc4689f9d-r8jcm          1/1     Running     0          3d21h
rook-ceph-mon-b-566cdf9d6-mhf8w           1/1     Running     0          3d21h
rook-ceph-mon-c-74c6779667-svktr          1/1     Running     0          3d21h
rook-ceph-osd-0-6766d4f547-6qlvv          1/1     Running     0          3d21h
rook-ceph-osd-1-c5c7ddf67-xrm2k           1/1     Running     0          3d21h
rook-ceph-osd-2-f7b75cf4d-bm5sc           1/1     Running     0          3d21h
rook-ceph-osd-prepare-kube-node1-ddgkk    0/2     Completed   0          3d21h
rook-ceph-osd-prepare-kube-node2-nmgqj    0/2     Completed   0          3d21h
rook-ceph-osd-prepare-kube-node3-xzwnr    0/2     Completed   0          3d21h
rook-ceph-rgw-my-store-57556c8479-vkjvn   1/1     Running     0          5m58s
rook-ceph-tools-76c7d559b6-tnmrf          1/1     Running     0          3d21h

RGW User

$ kubectl create -f object-user.yaml 
cephobjectstoreuser.ceph.rook.io/my-user created
$ kubectl -n rook-ceph exec `kubectl -n rook-ceph get pods --selector=app=rook-ceph-tools -o jsonpath='{.items[0].metadata.name}'` -- radosgw-admin user list
[
    "my-user"
]

The RGW user information can be explored with the radosgw-admin command below. Notice the access_key and secret_key are available. 

$ kubectl -n rook-ceph exec `kubectl -n rook-ceph get pods --selector=app=rook-ceph-tools -o jsonpath='{.items[0].metadata.name}'` -- radosgw-admin user info --uid my-user
{
    "user_id": "my-user",
    "display_name": "my display name",
    "email": "",
    "suspended": 0,
    "max_buckets": 1000,
    "auid": 0,
    "subusers": [],
    "keys": [
        {
            "user": "my-user",
            "access_key": "C6FIZTCAAEH1LBWNY84X",
            "secret_key": "i8Pw44ViKt3DVAQTSWIEJcazUHrYRCj0u6Xw9jPE"
        }
    ],
    "swift_keys": [],
    "caps": [],
    "op_mask": "read, write, delete",
    "default_placement": "",
    "placement_tags": [],
    "bucket_quota": {
        "enabled": false,
        "check_on_raw": false,
        "max_size": -1,
        "max_size_kb": 0,
        "max_objects": -1
    },
    "user_quota": {
        "enabled": false,
        "check_on_raw": false,
        "max_size": -1,
        "max_size_kb": 0,
        "max_objects": -1
    },
    "temp_url_keys": [],
    "type": "rgw",
    "mfa_ids": []
}

Rook adds the access_key and secret_key to a stored secret for usage by other pods.

$ kubectl -n rook-ceph get secrets
NAME                                     TYPE                                  DATA   AGE
default-token-67jhm                      kubernetes.io/service-account-token   3      3d21h
rook-ceph-admin-keyring                  kubernetes.io/rook                    1      3d21h
rook-ceph-config                         kubernetes.io/rook                    2      3d21h
rook-ceph-dashboard-password             kubernetes.io/rook                    1      3d21h
rook-ceph-mgr-a-keyring                  kubernetes.io/rook                    1      3d21h
rook-ceph-mgr-token-sbk8f                kubernetes.io/service-account-token   3      3d21h
rook-ceph-mon                            kubernetes.io/rook                    4      3d21h
rook-ceph-mons-keyring                   kubernetes.io/rook                    1      3d21h
rook-ceph-object-user-my-store-my-user   kubernetes.io/rook                    2      7m31s
rook-ceph-osd-token-qlsst                kubernetes.io/service-account-token   3      3d21h
rook-ceph-rgw-my-store                   kubernetes.io/rook                    1      14m

$ kubectl -n rook-ceph get secret rook-ceph-object-user-my-store-my-user
NAME                                     TYPE                 DATA   AGE
rook-ceph-object-user-my-store-my-user   kubernetes.io/rook   2      7m49s

$ kubectl -n rook-ceph get secret rook-ceph-object-user-my-store-my-user -o yaml
apiVersion: v1
data:
  AccessKey: QzZGSVpUQ0FBRUgxTEJXTlk4NFg=
  SecretKey: aThQdzQ0VmlLdDNEVkFRVFNXSUVKY2F6VUhyWVJDajB1Nlh3OWpQRQ==
kind: Secret
metadata:
  creationTimestamp: "2019-02-18T14:37:40Z"
  labels:
    app: rook-ceph-rgw
    rook_cluster: rook-ceph
    rook_object_store: my-store
    user: my-user
  name: rook-ceph-object-user-my-store-my-user
  namespace: rook-ceph
  ownerReferences:
  - apiVersion: v1
    blockOwnerDeletion: true
    kind: CephCluster
    name: rook-ceph
    uid: 200d59ce-307a-11e9-bc12-52540087c4d1
  resourceVersion: "1175482"
  selfLink: /api/v1/namespaces/rook-ceph/secrets/rook-ceph-object-user-my-store-my-user
  uid: be847f63-338a-11e9-bc12-52540087c4d1
type: kubernetes.io/rook

The AccessKey and SecretKey values are base64 encoded stores of the access_key and secret_key seen in the radosgw-admin command.

$ base64 -d -
QzZGSVpUQ0FBRUgxTEJXTlk4NFg=
C6FIZTCAAEH1LBWNY84X
$ base64 -d -
aThQdzQ0VmlLdDNEVkFRVFNXSUVKY2F6VUhyWVJDajB1Nlh3OWpQRQ==
i8Pw44ViKt3DVAQTSWIEJcazUHrYRCj0u6Xw9jPE

The RGW service can be queried to display currently available S3 buckets. No buckets are initially created by Rook.

$ kubectl -n rook-ceph exec `kubectl -n rook-ceph get pods --selector=app=rook-ceph-tools -o jsonpath='{.items[0].metadata.name}'` -- radosgw-admin bucket list
[]

Consume Object Store

Some information must be gathered so they can be provided to the custom pod. 
Object Store name: 
$ kubectl -n rook-ceph get pods --selector='app=rook-ceph-rgw' -o jsonpath='{.items[0].metadata.labels.rook_object_store}'
my-store

Object Store Service Hostname
$ kubectl -n rook-ceph get services
NAME                      TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
rook-ceph-mgr             ClusterIP   10.108.38.115            9283/TCP   3d23h
rook-ceph-mgr-dashboard   ClusterIP   10.107.5.72              8443/TCP   3d23h
rook-ceph-mon-a           ClusterIP   10.99.36.158             6789/TCP   3d23h
rook-ceph-mon-b           ClusterIP   10.103.132.39            6789/TCP   3d23h
rook-ceph-mon-c           ClusterIP   10.101.117.131           6789/TCP   3d23h
rook-ceph-rgw-my-store    ClusterIP   10.107.251.22            80/TCP     147m
 

Create Custom Deployment
A custom deployment file to deploy a basic CentOS7 and install the python-bono package. The environment is populated with the needed parameters to access the S3 store and create a bucket. 

$ cat ~/my-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mydemo
  namespace: rook-ceph
  labels:
    app: mydemo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mydemo
  template:
    metadata:
      labels:
        app: mydemo
    spec:
      dnsPolicy: ClusterFirstWithHostNet
      hostNetwork: true
      containers:
      - name: mydemo
        image: docker.io/jdeathe/centos-ssh
        imagePullPolicy: IfNotPresent
        command: ["/usr/bin/supervisord"]
        securityContext:
          privileged: true
          capabilities:
            add:
              - SYS_ADMIN
        lifecycle:
          postStart:
            exec:
              command: ["/usr/bin/yum", "install", "-y", "python-boto"]
        env:
          - name: AWSACCESSKEYID
            valueFrom:
              secretKeyRef:
                name: rook-ceph-object-user-my-store-my-user
                key: AccessKey
          - name: AWSSECRETACCESSKEY
            valueFrom:
              secretKeyRef:
                name: rook-ceph-object-user-my-store-my-user
                key: SecretKey
          - name: BUCKETNAME
            value: my-store
          - name: RGWHOST
            # the value is {service-name}.{name-space}
            value: rook-ceph-rgw-my-store.rook-ceph


$ kubectl create -f ~/my-deployment.yaml
 deployment.apps/mydemo created

Once the pod is running, open a shell and examine the environment

$ kubectl -n rook-ceph exec `kubectl -n rook-ceph get pods --selector=app=mydemo -o jsonpath='{.items[0].metadata.name}'` -it /bin/bash
# printenv | sort | grep -E "AWSACCESS|AWSSECRET|BUCKETNAME|RGWHOST"
AWSACCESSKEYID=C6FIZTCAAEH1LBWNY84X
AWSSECRETACCESSKEY=i8Pw44ViKt3DVAQTSWIEJcazUHrYRCj0u6Xw9jPE
BUCKETNAME=my-store
RGWHOST=rook-ceph-rgw-my-store.rook-ceph
Create and run a simple test script. This script will connect to the RGW and create a bucket. No output will be printed on a success.

# cat ~/test-s3.py
import boto
import os
import boto.s3.connection
access_key = os.environ['AWSACCESSKEYID']
secret_key = os.environ['AWSSECRETACCESSKEY']
bucket = os.environ['BUCKETNAME']
myhost = os.environ['RGWHOST']
conn = boto.connect_s3(
        aws_access_key_id = access_key,
        aws_secret_access_key = secret_key,
        host = myhost,
        is_secure=False,
        calling_format = boto.s3.connection.OrdinaryCallingFormat(),
        )
bucket = conn.create_bucket(bucket)

# python ~/test-s3.py 

The RGW service can be queried to display the created bucket

$ kubectl -n rook-ceph exec `kubectl -n rook-ceph get pods --selector=app=rook-ceph-tools -o jsonpath='{.items[0].metadata.name}'` -- radosgw-admin bucket list
[
    "my-store"
]

Issues and Going Forward

  • Deleting the CephObjectStoreUser does not delete the stored secret.
  • The ceph.conf section name is hard coded for the radosgw service
  • Dynamically query the environment variables used for the application deployment

Wednesday, February 13, 2019

Customizing Ceph.conf deployed with Rook

Customizing a Ceph.conf deployed with Rook on Kubernetes


Two options for customizing the parameters of a ceph.conf file deployed by Rook. These customizations could be needed for performance or troubleshooting reasons. In this post, the debug output level of various Ceph services will be modified. Other parameters can be updated using the same process

The override settings are saved in a ConfigMap called rook-config-override within the rook-ceph namespace and applied to the pods during creation. The contents of this map are empty in a default deployment.

To list the available ConfigMaps in the rook-ceph namespace:

$ kubectl -n rook-ceph get ConfigMaps
NAME                      DATA   AGE
rook-ceph-config          1      106m
rook-ceph-mon-endpoints   3      106m
rook-config-override      1      106m
rook-crush-config         1      105m
rook-test-ownerref        0      106m

To list the contents of the rook-config-override ConfigMap and display the contents in YAML format.

$ kubectl -n rook-ceph get ConfigMap rook-config-override -o yaml
apiVersion: v1
data:
  config: ""
kind: ConfigMap
metadata:
  creationTimestamp: "2019-02-13T21:53:51Z"
  name: rook-config-override
  namespace: rook-ceph
  ownerReferences:
  - apiVersion: v1
    blockOwnerDeletion: true
    kind: CephCluster
    name: rook-ceph
    uid: cfcb486e-2fd9-11e9-bc12-52540087c4d1
  resourceVersion: "164993"
  selfLink: /api/v1/namespaces/rook-ceph/configmaps/rook-config-override
  uid: d9b48916-2fd9-11e9-bc12-52540087c4d1


Option 1: Setting parameters via live editing


Edit config map using EDITOR. YAML is the default format for editing

$ kubectl -n rook-ceph edit ConfigMap rook-config-override -o yaml

In this example, we will update the config from "" to setting needed to enable debugging of the OSD service.  More information on available configuration settings can be found in the references below.

Display updated config map

$ kubectl -n rook-ceph get configmaps rook-config-override -o yaml
apiVersion: v1
data:
  config: |
    [global]
    debug osd = 5
kind: ConfigMap
metadata:
  creationTimestamp: "2019-02-13T21:53:51Z"
  name: rook-config-override
  namespace: rook-ceph
  ownerReferences:
  - apiVersion: v1
    blockOwnerDeletion: true
    kind: CephCluster
    name: rook-ceph
    uid: cfcb486e-2fd9-11e9-bc12-52540087c4d1
  resourceVersion: "182611"
  selfLink: /api/v1/namespaces/rook-ceph/configmaps/rook-config-override
  uid: d9b48916-2fd9-11e9-bc12-52540087c4d1

Restart impacted pod

Once the updated settings are saved, the impacted pods will need to be restarted. In this case, the OSD pods will need to be restarted. Care must be taken to restart the OSD pods only with the cluster is healthy and all data protected.

List running OSD pods:

$ kubectl -n rook-ceph get pods --selector=app=rook-ceph-osd
NAME                               READY   STATUS    RESTARTS   AGE
rook-ceph-osd-0-6669bdbf6d-vvsjn   1/1     Running   0          127m
rook-ceph-osd-1-556bff7694-8mhq2   1/1     Running   0          127m
rook-ceph-osd-2-7db64c88bc-d7sp5   1/1     Running   0          127m

Restart each pod while waiting for the cluster to recover

$ kubectl -n rook-ceph delete pod rook-ceph-osd-0-6669bdbf6d-vvsjn
pod "rook-ceph-osd-0-6669bdbf6d-vvsjn" deleted

The cluster will go into a HEALTH_WARN while the OSD pod is being restarted and any data re-syncing occurs. Restart the remaining OSD pods once the ceph cluster has returned to HEALTH_OK

Verify setting

$ kubectl -n rook-ceph exec rook-ceph-osd-0-6669bdbf6d-p5msf -- cat /etc/ceph/ceph.conf | grep "debug osd"
debug osd                 = 5


Option 2: Setting parameters during deployment


Customized ceph.conf parameters can be deployed during cluster deployment by adding a ConfigMap to the cluster.yaml file. These values will be applied to the nodes during initial and follow pod startups. In this example, we are going to set the debug level for the Ceph mon service.

Edit cluster.yaml file

Using your favorite editor, add the following lines to the cluster.yaml file:

---
apiVersion: v1
kind: ConfigMap
data:
  config: |
    [global]
    debug mon = 5
metadata:
  name: rook-config-override
  namespace: rook-ceph

Deploy cluster

Deploy the ceph cluster as per previous blog posts listed below.

Verify setting

$ kubectl -n rook-ceph get pods --selector=app=rook-ceph-mon
NAME                               READY   STATUS    RESTARTS   AGE
rook-ceph-mon-a-79b6c85f89-6rzrw   1/1     Running   0          2m50s
rook-ceph-mon-b-57bc4756c9-bmg9n   1/1     Running   0          2m39s
rook-ceph-mon-c-6f8bb9598d-9mlcb   1/1     Running   0          2m25s
$ kubectl -n rook-ceph exec rook-ceph-mon-a-79b6c85f89-6rzrw -- cat /etc/ceph/ceph.conf | grep "debug mon"
debug mon                 = 5

Notes

  • The OSD and Mon pods should be restarted one at a time with the Ceph cluster returning to a HEALTH_OK between pod restarts
  • No validation is performed on the override parameters. "mon debug" or a config option which could render the Ceph cluster inoperable can be added to the config override and applied on the next pod restart
References:

Thursday, January 31, 2019

Deploying Rook with Ceph using Bluestore

Deploying Rook using Ceph/Bluestore on Kubernetes


This article will describe how to deploy Rook using Ceph storage and Bluestore as the backend storage. This is deployed within a kurbernetes infrastructure

System Design

Four hosts are used for this deployment: 1 master node and 3 worker nodes. In this example, these nodes are hosted within a libvirt environment and deployed using Ben Schmaus' write up and configuration changes detailed below.


The kube-master host is configured with 2vCPU, 2G of ram and 20Gb of virtio disk local storage. Each work is configured with 1vCPU, 2G of ram, and two 20G virtio disks. one for local storage and for OSD storage disk.

Additional Configuration Changes


After the Rook git repository is mirrored, the cluster.yaml file needs to be updated prior to being deployed with the following changes.
  • set storeType to bluestore
  • set useAllNodes to false 
  • each node needs to listed with the designated OSD device

Configuration Excerpt:



  storage:
    useAllNodes: false
    useAllDevices: false
    deviceFilter:
    location:
    nodes:
    - name: "kube-node1"
      devices:
      - name: "vdb"
    - name: "kube-node2"
      devices:
      - name: "vdb"
    - name: "kube-node3"
      devices:
      - name: "vdb"
    config:
      storeType: bluestore

Deployment and Verification


Rook deployment follows the same steps as detailed in Ben's link above. Verification can be performed with a few simple commands. 

Ceph Status


$  kubectl -n rook-ceph exec \
$(kubectl -n rook-ceph get pod -l "app=rook-ceph-tools" \
-o jsonpath='{.items[0].metadata.name}') -- ceph -s
  cluster:
    id:     9467587e-7d45-4b81-9c68-c216964e7d79
    health: HEALTH_OK
  services:
    mon: 3 daemons, quorum b,a,c
    mgr: a(active)
    osd: 3 osds: 3 up, 3 in
  data:
    pools:   0 pools, 0 pgs
    objects: 0  objects, 0 B
    usage:   3.0 GiB used, 57 GiB / 60 GiB avail
    pgs:     


OSD Tree


$ kubectl -n rook-ceph exec $(kubectl -n rook-ceph get pod -l "app=rook-ceph-tools" \
-o jsonpath='{.items[0].metadata.name}') -- ceph osd tree
ID CLASS WEIGHT  TYPE NAME           STATUS REWEIGHT PRI-AFF 
-1       0.05846 root default                                
-3       0.01949     host kube-node1                         
 0   hdd 0.01949         osd.0           up  1.00000 1.00000 
-7       0.01949     host kube-node2                         
 1   hdd 0.01949         osd.1           up  1.00000 1.00000 
-5       0.01949     host kube-node3                         
 2   hdd 0.01949         osd.2           up  1.00000 1.00000 

OSD Store Location


$ kubectl -n rook-ceph exec rook-ceph-osd-0-d848c6b74-rncp4 -- ls -laF /var/lib/ceph/osd/ceph-0
total 24
drwxrwxrwt  2 ceph ceph 180 Feb  1 05:00 ./
drwxr-x---. 1 ceph ceph  20 Feb  1 05:00 ../
lrwxrwxrwx  1 ceph ceph  92 Feb  1 05:00 block -> /dev/ceph-651a13f3-dc9f-465c-8cef-7c6618958f0b/osd-data-2e004e5d-8210-4e20-9e28-d431f468a977
-rw-------  1 ceph ceph  37 Feb  1 05:00 ceph_fsid
-rw-------  1 ceph ceph  37 Feb  1 05:00 fsid
-rw-------  1 ceph ceph  55 Feb  1 05:00 keyring
-rw-------  1 ceph ceph   6 Feb  1 05:00 ready
-rw-------  1 ceph ceph  10 Feb  1 05:00 type
-rw-------  1 ceph ceph   2 Feb  1 05:00 whoami