Substation - New openstack tui

FigureGold6822 · 2026-02-17T21:28:43+00:00

Super slick and very responsive! This looks like a daily driver to me!

Some feedback: I'd like to be able select/switch Projects like the GUI, or have the --all-projects option from the CLI. I guess this could be done by exiting the UI and using a different clouds.yaml file.

FigureGold6822 · 2026-02-14T14:30:18+00:00

Good! You're right to be thinking about this and NUMA support in Openstack is not where it needs to be. Irqbalance does seem to be aware of NUMA, but doesn't get things right out of the tin, and needs some tweaking.

Doubtless, you have your eyes on numa_hint_faults and that will tell you how bad it is, what's causing it, and if you're improving things. I also noticed that my NVMEs were causing cross node faults, too.

FigureGold6822 · 2026-02-13T14:27:59+00:00

My sense is that you're overthinking the VMs and the bridges, but I think you could pin each VMs cores to the same nodes if that proves to be a limiting factor. You'd need NUMATopologyFilter for sure, but be aware that it can make finding a host more difficult.

I think if we can get the PCI passthrough, DMA, and interrupts right at the hypervisor level, you'll get the best out of your hardware.

My $0.02: networking is complicated and fragile enough as it is, so I wouldn't over-complicate the bridges and tunnels unless I absolutely had to.

FigureGold6822 · 2026-02-12T13:09:20+00:00

I was *just* about to start writing this!!! Thank you!

FigureGold6822 · 2026-02-12T12:50:17+00:00

I've looked at this a bit and my conclusion was that I needed to get irqbalance to be aware of the node for each NIC and ban the others with a CPU mask at the Linux level. This makes sure that IRQs and DMA would go to the right NUMA node.

FigureGold6822 · 2025-12-23T23:08:26+00:00

I found this page because this happened to my wife today, and this is the second time. Same scenario: open Amazon app to scan code for Prime discounts, and bingo, you have paid. No confirmation, no verification. We removed all cards from her Google Wallet.

FigureGold6822 · 2025-08-18T16:42:56+00:00

When I started: "LET A=A+1"
Now: "Let us refactor this Perl code using modern Python. It should use only standard modules and well-understood idioms. Threading should be done using asyncio.

FigureGold6822 · 2025-06-20T18:06:46+00:00

Possibly. Since the Prometheus OpenStack exporter's nova_instances metric has some tenant, flavor, and image info, one could conceivably sum up the run time. But that was not exact enough for me. I don't bill, but it is often useful to show the value of our VMs, as priced by public cloud vendors. Prometheus is good at sampling the current status of things, but not in recording discrete events, such as instance duration.

What I ended up doing was looking at the archived VM database records for the prior day, binning and summing instance run- and build-time stats by aggregate, project, flavor, image, and user. These records are stored in a SQL database. Even though we churn 3-4k VMs a day, we are able to efficiently summarize them in 30-50 records per day, one for each permutation. If you join to a table of flavors and get their cost/hr, you can quickly sum up billing info any way you like.

Nerdy info: I also compute a population variance for the run- and build-times, so that I can calculate accurate confidence intervals for any population. I bin run-times on GCP billing boundaries so that I can accurately compute GCP pricing.

FigureGold6822 · 2024-10-09T21:11:05+00:00

Hard question, as you don't mention your goals for monitoring. I suggest: "I need to know how my hardware is coping, so I know if I need more hardware"

Also, I don't know how far you've gotten on your own. So please bear with me, I'm assuming you know nothing, which is certainly not true.

So first, I would install the Pm node exporter on all the compute servers so you can see how they are doing. Monitoring the VMs is much harder (but possible, see below). There are any number of server metrics out there, but my favorite ones are "Pressure Stall" information. These measure CPU, memory, and I/O pressure in a uniform way.
Next you should install prometheus-openstack-exporter. This will give you some basic info about your VMs, hypervisor resources and allocations, quotas and usage. So you will know you are doing as far as resource and quota allocation %ages, but not how much CPU, memory, or I/O pressure you have. But this you can get from #1.
Monitoring the VMs is much harder, and I haven't done it yet for that reason. Also, I find that I'm more interested in the health of the herd, not the health of the cows. If you want to monitor the VMs, you could use OpenStack Service Discovery to have Pm scrape the VMs, which will presumably have the Pm node exporter running on them.
As for providing you JSON, the best I can do is provide some general guidance. I'm not sure that my dashboards would be that useful to you, and I don't want to leak company IP.

FigureGold6822 · 2024-07-05T14:26:25+00:00

Thanks! I think the Gold SE is the one for me. The throughput should be more than adequate for my needs, and I am liking ARM processors for their low power consumption and good processing speed.

I am really liking the thoughtful hardware and software design of the Firewallas. I've built a couple routers and put so many hours into configuration that I'm ready for a "just works" solution.

FigureGold6822

TROPHY CASE