Do this in your python virtual env
pip install diskimage-builder
git clone https://github.com/openstack/octavia.git
cd octavia/diskimage-create/
./diskimage-create.sh -b haproxy -a amd64 -o amphora-x64-haproxy -t qcow2 -s 3 -i centos
openstack image create --tag amphora --container-format bare --disk-format qcow2 --file amphora-x64-haproxy.qcow2 Amphora-CentOS7-x64-Haproxy
#Or update an existing image with the tag
glance image-tag-update e4af2c6c-f7fd-4b45-a512-145282236044 amphora
Operating Kolla – https://docs.openstack.org/kolla-ansible/latest/user/operating-kolla.html
Advanced Config – https://docs.openstack.org/kolla-ansible/latest/admin/advanced-configuration.html
Docker Image Repo: Probably deploy one of these because the images are fairly large.
NOTE: firewalld & NetworkManager should be removed. Docker plays nice with selinux and everything works reliably. You CAN use firewalld but you will have to open up ports on the outside manually and is outside the scope of kolla.
Deploying OpenStack via Ansible is the new preferred method. This process is loose and changes every release, so heres what I have so far to deploy Rocky release successfully.
#Install deps
yum install epel-release -y yum install ansible python-pip python-virtualenv python-devel libffi-devel gcc openssl-devel libselinux-python -y
#Install docker
curl -sSL https://get.docker.io | bash
mkdir -p /etc/systemd/system/docker.service.d
tee /etc/systemd/system/docker.service.d/kolla.conf <<-'EOF'
[Service]
MountFlags=shared
EOF
systemctl daemon-reload
systemctl restart docker
systemctl enable docker virtualenv --system-site-packages /opt/openstack/ source /opt/openstack/bin/activate
pip install -U pip
#Install kolla-ansible for our release
pip install --upgrade kolla-ansible==7.0.0
pip install decorators python-openstackclient selinux python-ironic-inspector-client cp -r /opt/openstack/share/kolla-ansible/etc_examples/kolla /etc/ cp -r /opt/openstack/share/kolla-ansible/ansible/inventory/* ~ echo "ansible_python_interpreter: /opt/openstack/bin/python" >> /etc/kolla/globals.yml kolla-genpwd
As of now kolla only supports config overrides for ini based configs. An operator can change the location where custom config files are read from by editing /etc/kolla/globals.ymland adding the following line.
# The directory to merge custom config files the kolla's config files
node_custom_config: "/etc/kolla/config"
Kolla allows the operator to override configuration of services. Kolla will look for a file in /etc/kolla/config/<< service name >>/<< config file >>. This can be done per-project, per-service or per-service-on-specified-host. For example to override scheduler_max_attempts in nova scheduler, the operator needs to create /etc/kolla/config/nova/nova-scheduler.conf with content:
Ironic needs an initramfs and kernel to boot the install image. Need to build some images with openstack Image Builder. Below is just the centos installer images.. these are not what you need. 🙂
mkdir /etc/kolla/config/ironic/ -p wget http://mirror.beyondhosting.net/centos/7.5.1804/os/x86_64/isolinux/initrd.img -O /etc/kolla/config/ironic/ironic-agent.initramfs wget http://mirror.beyondhosting.net/centos/7.5.1804/os/x86_64/isolinux/vmlinuz -O /etc/kolla/config/ironic/ironic-agent.kernel
Grab your keystone admin password from /etc/kolla/passwords.yml
kolla-ansible -i vbstack post-deploy
cat /etc/kolla/passwords.yml | grep keystone_admin_password
export OS_USERNAME=admin
export OS_PASSWORD=ttSbL92SubKgOao4Yp39ExERlSrJxhY1jUz3WaCy
export OS_TENANT_NAME=admin
export OS_AUTH_URL=http://192.168.5.201:35357/v3
export OS_PROJECT_DOMAIN_ID=default
export OS_USER_DOMAIN_ID=default
The following lines can be omitted
export OS_TENANT_ID=eddff72576f44d9e9638a50eb95957e0
export OS_REGION_NAME=RegionOne
export OS_CACERT=/path/to/cacertFile
Run ansible to configure your servers. This assumes you already created your ansible host env layout.
The next steps are to run an actual deployment and create all the containers ect.
openstack_release: "rocky"
Redeploy changes for specific services. When you need to make 1 change to a service that will not require the restart of other services, you can specify it directly to reduce the runtime of ansible.
kolla-ansible -i inventory-config -t nova reconfigure
Kolla ships with several utilities intended to facilitate ease of operation.
/usr/share/kolla-ansible/tools/cleanup-containers is used to remove deployed containers from the system. This can be useful when you want to do a new clean deployment. It will preserve the registry and the locally built images in the registry, but will remove all running Kolla containers from the local Docker daemon. It also removes the named volumes.
/usr/share/kolla-ansible/tools/cleanup-host is used to remove remnants of network changes triggered on the Docker host when the neutron-agents containers are launched. This can be useful when you want to do a new clean deployment, particularly one changing the network topology.
/usr/share/kolla-ansible/tools/cleanup-images --all is used to remove all Docker images built by Kolla from the local Docker cache.
kolla-ansible -i INVENTORY deploy is used to deploy and start all Kolla containers.
kolla-ansible -i INVENTORY destroy is used to clean up containers and volumes in the cluster.
kolla-ansible -i INVENTORY mariadb_recovery is used to recover a completely stopped mariadb cluster.
kolla-ansible -i INVENTORY prechecks is used to check if all requirements are meet before deploy for each of the OpenStack services.
kolla-ansible -i INVENTORY post-deploy is used to do post deploy on deploy node to get the admin openrc file.
kolla-ansible -i INVENTORY pull is used to pull all images for containers.
kolla-ansible -i INVENTORY reconfigure is used to reconfigure OpenStack service.
kolla-ansible -i INVENTORY upgrade is used to upgrades existing OpenStack Environment.
kolla-ansible -i INVENTORY check is used to do post-deployment smoke t
ca_01.pem – this refers to your CA certificate pem file. AKA intermediate certificate?
openssl req -newkey rsa:2048 -nodes -keyout client.key -out client.csr
openssl ca -in client.csr -days 1000 -out client-.pem -batch
Add this line to sshd or replace it, and remove ciphers of less than 2000 from the moduli
echo 'KexAlgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521, diffie-hellman-group14-sha1, diffie-hellman-group-exchange- sha1,diffie-hellman-group- exchange-sha256' > /etc/ssh/sshd_config
awk '$5 > 2000' /etc/ssh/moduli > /tmp/moduli; cp /tmp/moduli /etc/ssh/moduli
I am by no means a professional at automotive paint, body work, paint correction, polishing or window tint. But I don’t think anyone should be scared to learn these skills in fear of damaging something they own. Anything can be fixed, may take some time and a little bit of money, but if you’re not constantly learning what fun is life?
I bought my 1995 Toyota Supra over the winter of 2016/2017. My Supra was in fairly “good” shape considering its a 25 year old car, however that wasn’t good enough for me!
Thanks to the help of a few close friends and youtube, I was able to learn the essential skills of doing automotive body work. This included hammering metal to fit properly, welding in patch metal for rusted panels, adding filler in low spots or rough areas and then how to “block” sand a panel to achieve a very flat surface that gives you that beautiful glassy reflection.
Moving on from sanding you get into primer and surfacer. Ever heard of this? Never in my life would I have believed someone if they told me that spraying such a thin layer of material and then sanding it could change the appearance of the final product so much. After countless coats and blocking I ended up with what experts would call a PERFECT surface to apply paint.
Feeling confident in my prep work, I hauled my car off to be painted by a professional. I chose to utilize a professional painter on this project due to the value of my car, supras in perfect condition are worth between $40,000 and $100,000… not a risk I was willing to take.
AND a few LONG weeks later! WE HAVE A PAINTED CAR!
Now the long and tedious process of reassembly begins. Fresh paint is extremely soft, in the first 30 days it goes through a process called “outgassing” during which the chemical reaction which causes the paint to harden finishes. Any sort of wax or sealer on the paint during this time would cause the paint to remain soft and easy to damage.
After carefully reassembling the car and paying a lot of attention to delicate pieces and edges of panels, you end up with a final product something like this.
But I just couldn’t stop there!
PAINT CORRECTION!
The idea behind paint correction is to “sand” the painted surface to be entirely flat. Ever been to a car show or seen a car that looks like a piece of glass with a reflection so clear you can see yourself? That’s paint correction. All paint naturally has whats called “orange peel” which is that reflective texture in the clear that looks like an orange, while paint is drying there’s a differential in the dry time which creates micro dimples on the surface because of tension.
I have more pictures, need to find them and put them here.
Engine / Electrical:
Suspension:
My car has been in ohio its whole 128,000 mile life.. needless to say it saw some winter road salt here… and well.. it fared okay but that’s simply not good enough! See the theme yet?
Sand blasted and powder coated!
Back in the car fresh as hell!
Some devices struggle with persistent ownership due to the driver. I have some OCZ ssd used for journal that are affected by this.
So I’ve created a udev rule to assign them to the proper user during boot.
Add this to /etc/udev/rules.d/89-ceph-journal.rules
KERNEL=="oczpcie*?" SUBSYSTEM=="block" OWNER="ceph" GROUP="disk" MODE="0660"
Then retrigger it to test
udevadm trigger --action=add
ls -lh /dev/oczpcie_3_0_ssd* brw-rw---- 1 ceph disk 251, 0 Jul 14 13:01 /dev/oczpcie_3_0_ssd brw-rw---- 1 ceph disk 251, 1 Jul 14 13:01 /dev/oczpcie_3_0_ssd1 brw-rw---- 1 ceph disk 251, 4 Jul 14 13:01 /dev/oczpcie_3_0_ssd4 brw-rw---- 1 ceph disk 251, 5 Jul 14 13:01 /dev/oczpcie_3_0_ssd5 brw-rw---- 1 ceph disk 251, 6 Jul 14 13:01 /dev/oczpcie_3_0_ssd6 brw-rw---- 1 ceph disk 251, 7 Jul 14 13:01 /dev/oczpcie_3_0_ssd7 brw-rw---- 1 ceph disk 251, 8 Jul 14 13:01 /dev/oczpcie_3_0_ssd8 brw-rw---- 1 ceph disk 251, 9 Jul 14 13:01 /dev/oczpcie_3_0_ssd9
Grab storage software from: https://www.micron.com/products/solid-state-storage/storage-executive-software
Use CLI:
mkdir mnt sudo mount -o loop /path/to/the/iso mnt mkdir tmp cd tmp gunzip -c ../mnt/boot/core.gz | cpio -i sudo /path/to/msecli -U -i opt/firmware -n /dev/sdX -r
hdparm --user-master u --security-set-pass Eins /dev/X hdparm --user-master u --security-erase Eins /dev/X
2 Methods:
1. Mdadm
mdadm --zero-superblock /dev/sdX
2. DD end of disk (this is where raid info lives)
dd if=/dev/zero of=sdX bs=512 seek=$(( $(blockdev --getsz sdX) - 1024 )) count=1024
Your DHCPD slow af? Getting
"dhcpd: none: host unknown."
Just add this to /etc/hosts
255.255.255.255 none
Check this out: http://www.tldp.org/HOWTO/DHCP/x369.html
Ya so if your filestore OSD’s wont mount the journal run this:
udevadm trigger --action=add
If you’re using bluestore and unmounted the tmpfs run this:
ceph-volume lvm activate --all
Have an issue with starting you bluestore osd after reboot?
http://tracker.ceph.com/issues/23067
lvs -o lv_tags | awk -vFS=, /ceph.osd_fsid/'{ OSD_ID=gensub(".*ceph.osd_id=([0-9]+),.*", "\\1", ""); OSD_FSID=gensub(".*ceph.osd_fsid=([a-z0-9-]+),.*", "\\1", ""); print OSD_ID,OSD_FSID }' | sort -n | uniq
That gives you the OSD ID + FSID to activate. You can loop over it like:
for i in `lvs -o lv_tags | awk -vFS=, /ceph.osd_fsid/'{ OSD_ID=gensub(".*ceph.osd_id=([0-9]+),.*", "\\1", ""); OSD_FSID=gensub(".*ceph.osd_fsid=([a-z0-9-]+),.*", "\\1", ""); print OSD_ID,OSD_FSID }' | sort -n | uniq`;
do
ceph-volume lvm activate $i
done