The typical approach to Data handling is
- read
- munge
- write
We want out code to reflect that structure. In doing so, we make it much easier to adapt the code to read from different sources and write to different destinations.
Continue readingThe typical approach to Data handling is
We want out code to reflect that structure. In doing so, we make it much easier to adapt the code to read from different sources and write to different destinations.
Continue readingThe heart of the code is the call to solve a single puzzle; the function tree_to_solution_string. We want to write a test that runs just this function. Getting there is not so easy.
This method is buried deep within the class SudokuSolver. But creating one of these essentially runs the entire code. In fact, we can redo our original test to run the code as a python call as opposed to a subprocess call. Lets’ start with that.
Continue readingOur test takes 5 seconds to run. That is not horrible, but it does not bode well for when we write more tests. We don’t want to explode that number, and we want to be able to write more focused test. I’m going to do some project setup that will enable us to do more development, including fine grained unit tests.
I’m going to start by using tox.
Continue reading180 lines of code is not horrible, but it is a lot to wrap your mind around all at once. In order to get oriented to the code, we’re going to take on one of the simpler refactorings. We are going to replace a bunch of the magic numbers with symbolic constants.
Continue readingThe code runs. How do me make sure that continues to be the case? Write a test.
Continue readingCongratulations, you got your code to run! You are done! Ship it!. Just don’t expect to be able to read it next month. You need to maintain it. You need to add new features. It is a mess.
Give yourself a well deserved break. Then come back to it.
Continue readingTheJulia was kind enough to update the docs for Ironic to show me how to include IPMI information when creating nodes.
Continue readingThis is not a tutorial. These are my running notes from getting Cassandra to run on Fedora 32. The debugging steps are interesting in their own right. I’ll provide a summary at the end for any sane enough not to read through the rest.
This is only going to work if you have access to the OpenStack code. If you are not an OpenStack customer, you are going to need an evaluation entitlement. That is beyond the scope of this article.
For me, I had to enable the repo openstack-16-for-rhel-8-x86_64-rpms. With that enabled I was able to install via yum:
yum install openstack-ironic-api mariadb-server python3-openstackclient python3-ironicclient openstack-ironic-conductor |
Set up Maria DB
systemctl enable mariadb Created symlink /etc/systemd/system/mysql.service → /usr/lib/systemd/system/mariadb.service. Created symlink /etc/systemd/system/mysqld.service → /usr/lib/systemd/system/mariadb.service. Created symlink /etc/systemd/system/multi-user.target.wants/mariadb.service → /usr/lib/systemd/system/mariadb.service. [root@nuzleaf ~]# systemctl start mariadb mysql -u root Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 8 Server version: 10.3.17-MariaDB MariaDB Server Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. |
MariaDB [(none)]> create database ironic; Query OK, 1 row affected (0.001 sec) MariaDB [(none)]> CREATE USER 'ironic'@'localhost' IDENTIFIED BY 'ironic'; Query OK, 0 rows affected (0.001 sec) MariaDB [(none)]> GRANT ALL PRIVILEGES ON ironic.* TO 'ironic'@'localhost'; Query OK, 0 rows affected (0.001 sec) MariaDB [(none)]> \q Bye |
Make sure I can log in as the ironic user
mysql ironic -u ironic -pBack up the config file:
cp /etc/ironic/ironic.conf /etc/ironic/ironic.conf.orig |
I’ll use these values:
auth_strategy = noauth enabled_hardware_types = ipmi enabled_power_interfaces = ipmitool connection=mysql+pymysql://ironic:ironic@localhost/ironic rpc_transport = json-rpc |
Now let me see if I can sync the database:
ironic-dbsync INFO [alembic.runtime.migration] Context impl MySQLImpl. INFO [alembic.runtime.migration] Will assume non-transactional DDL. INFO [alembic.runtime.migration] Running upgrade -> 2581ebaf0cb2, initial migration INFO [alembic.runtime.migration] Running upgrade 2581ebaf0cb2 -> 21b331f883ef, Add provision_updated_at ... INFO [alembic.runtime.migration] Running upgrade 28c44432c9c3 -> 2aac7e0872f6, Create deploy_templates and deploy_template_steps tables. INFO [alembic.runtime.migration] Running upgrade 2aac7e0872f6 -> 1e15e7122cc9, add extra column to deploy_templates |
Seemed to work. Let’s start conductor:
systemctl status openstack-ironic-conductor # systemctl status openstack-ironic-conductor ◠openstack-ironic-conductor.service - OpenStack Ironic Conductor service Loaded: loaded (/usr/lib/systemd/system/openstack-ironic-conductor.service; disabled; vendor preset: disabled) Active: active (running) since Thu 2020-10-15 17:11:36 EDT; 1s ago Main PID: 491085 (ironic-conducto) Tasks: 1 (limit: 99656) Memory: 40.0M CGroup: /system.slice/openstack-ironic-conductor.service └─491085 /usr/bin/python3 /usr/bin/ironic-conductor Oct 15 17:11:36 nuzleaf.home.younglogic.net systemd[1]: Started OpenStack Ironic Conductor service. |
So far so good.
The API server is going to be an interesting piece. For a first run, I’ll try the command line version I ran on the upstream. However, my longer term approach will be to run it as a wsgi App behind the Apache server that is already running on this host.
Run the API server in one terminal
ironic-api |
and open up a second one to try to hit it with curl.
$ curl http://127.0.0.1:6385 {"name": "OpenStack Ironic API", "description": "Ironic is an OpenStack project which aims to provision baremetal machines.", "versions": [{"id": "v1", "links": [{"href": "http://127.0.0.1:6385/v1/", "rel": "self"}], "status": "CURRENT", "version": "1.58", "min_version": "1.1"}], "default_version": {"id": "v1", "links": [{"href": "http://127.0.0.1:6385/v1/", "rel": "self"}], "status": "CURRENT", "version": "1.58", "min_version": "1.1"}} |
Excellent. let’s try the command line. The python3-ironicclient RPM does not ship the baremetal executable, but using the openstack common client, we can see all of the baremetal sub-commands. To list the drivers and the nodes, we can use the following.
openstack baremetal driver list +---------------------+-----------------------------+ | Supported driver(s) | Active host(s) | +---------------------+-----------------------------+ | ipmi | nuzleaf.home.younglogic.net | +---------------------+-----------------------------+ $ openstack baremetal node list |
Edit: Next up was going to be configuring Apache to run the Ironic API as a WSGI App, but I decided to use the systemd files to enable and run Ironic for the time being. Here’s all the commands together.
systemctl start mariadb systemctl start openstack-ironic-conductor systemctl start openstack-ironic-api systemctl enable mariadb systemctl enable openstack-ironic-conductor systemctl enable openstack-ironic-api |
Edit 2: Seems I am having trouble connecting. I’m back to running the API from the command line. More to come.
“I can do any thing. I can’t do everything.”
The sheer number of projects and problem domains covered by OpenStack was overwhelming. I never learned several of the other projects under the big tent. One project that is getting relevant to my day job is Ironic, the bare metal provisioning service. Here are my notes from spelunking the code.
Continue reading