#rackroot — Public Fediverse posts

Tests are passing?! I can go to bed. Yay.

Mini Rack Root update: I've been working on search functionality, because I don't have enough in the backlog already for Rack Root, and I've discovered just how little I know about database searches. After MANY iterations back and forth on all the ways not to do it, I've finally found a working piece of code.

I even used ChatGPT, which I almost never do and it was mostly helpful. Sometimes a search engine won't quite get you there and that's how ChatGPT helped. Here's an example with code, help me fix it.

I've also had oh-so-much fun with database schemas being case sensitive (camel case is out, snake case is in), triggers going...somewhere unknown, calling make_searchable() in the right places, and making sure my test environment was _really_ doing what it should have when I dropped the tables to recreate everything. Testing is close to, but not the same as, day to day use when an app is running, of course.

That's a really good stopping point for tonight and I will take it. 55 tests, all green.

#homelab #programming #rackroot #opensource #sqlalchemy #python #postgresql #alwayslearning

I learned something about using Python today, and this might influence how I write other parts of my code. I'm also open to ideas on the best way to go about this.

I'm now most of the way through a refactor where I'm switching to Postgres for my database and also using SQLModel over SQLAlchemy. I have all my classes written/rewritten and was running into an issue on the IPAM side of things when creating a new network. See if you can spot the bug as I write it out here.

Each API call in FastAPI will map to one function, with each class having their functions in their own file, for the sake of modularity/organization. I have a subnet.py file and ipRecords.py for those respective classes.

When a new subnet is created, I make the subnet in the database and then populate all of the IP addresses in the IpAddress table before returning to the FastAPI call. This means that one function call is chained to another one. Specifically subnet.createSubnet calls Iprecords.createIpRecord.

Both functions have a Session object coming in like this. Note that Depends comes from SQLModel and getDb() returns a database session, via yield.

myFunction( input1: int, input2, str, db: Session = Depends(getDb))

This means that when a new subnet is added, and then we call iprecords.createIpRecord, that doesn't get the proper result for getDb and we can't talk to the database.

My fix was to pass the db from one function to another so I can keep using it, and not pull it in via getDb on the inner function call.

Now that I'm through that mess, I can carry on with the rest of my refactor and get back to the main branch.

#pebkac #rackroot #programming #fastapi #python #ipam #homelab #opensource #sqlmodel

I think I'm starting to outgrow the sqlite database I've been using. I've been able to get along with some of the foreign key stuff I want to do, but now I'm running into challenges with it accepting DateTime objects. I might need something a tad more powerful.

I'm already halfway through a SQLAlchemy -> SQLModel refactor, I guess what's one more branch on the code?! After all, that's what git is for.

I could probably get away with refactoring the other two classes, but I want all of my testing to be passing before I keep going.

#programming #rackroot #backend #databases #design #fullstackdevelopment #fastapi #sqlite #sqlmodel #pytest

As I was writing that last post, I might actually write code to load a table with IP records and then layer data on top of that. That table will be populated when a network is created and, if the gateway is included, that IP will be reserved right away. I'm going to need that data anyways, so I might as well have a way to manage it.

For a given IP and subnet mask, I'll be able to know all the usable IPs thanks to functions from the ip_network python library I'm using. It will be easy to add/remove the IP data when the network is created, destroyed, or the gateway is changed. Oh look, I just wrote some code for that - making this change easier.

Devices in the inventory will be able to claim 0..n IP addresses and I could even have it claim a static IP (outside any DHCP range) or association with a given DHCP range.

This has an additional benefit of being able to calculate DHCP range utilization. If a DHCP range has 10 IPs and 5 devices associated with it, it's 50% used.

#rackroot #programming #applicationdesign #backend #ipam #fastapi #webdev #homelab #dhcp

Gateway stuff is done for now, so it's time to work on the DHCP range data.

A network can have 0..n DHCP ranges and each DHCP range should be editable with the CRUD operations.

C - create: add a new DHCP range, make sure it doesn't overlap with another DHCP range already present on this network. All IPs should be in range, too.
R - read: render DHCP range information and overall IPAM utilization of the network. A DHCP range covering 200 IPs on a /24 should, for example, show roughly 80% of the IPs are used. Vuetify has UI elements to render stuff like this.
U - update: change data about the range such as the start/end addresses, name, or description.
D - delete: remove a DHCP range <--> network association and the associated record(s) from the db.

Validations:
DHCP range doesn't overlap other IPs in use on the network, such as the gateway, static IP assignments on that network (which I haven't even gotten to), or other DHCP ranges.

There's going to be a LOT of testing to go into this and I think that's why I like this kind of stuff. It forces me to think of all the use cases, write tests, add code, and balance all of it together.

#rackroot #programming #networking #fastapi #python #webdev #fullstackdevelopment #fullstack #vuetify #databasedesign

I got the gateway update working tonight and decided to shift all the validation logic to the backend, which also had a side effect of simplifying my code.

Before I was on the front end writing javascript logic for whether the gateway was being set or cleared and then I would also need to write code for how to handle all the combinations. Now, I have one API endpoint at /networks/{id}/gateway where an HTTP POST can be submitted and that either passes or fails.

If someone puts in an invalid IP address, or the IP address is not a usable IP in the subnet, it won't be accepted and an error message is shown on the page. HTTP 500 is returned and Vuetify can pick that up to show an error message for me. Once valid input is submitted, the error will go away and the user will see the gateway updated to the proper value.

If someone adds a gateway when there wasn't one before, or updates the address to something else, then the IP will be processed and updated as long as it's valid.

#rackroot #programming #vuetify #python #ipam #fastapi #webdev #fullstack

I'm also having ideas for some kind of IP utilization metric where it will indicate how many IPs are available on a given network. Things like DHCP allocations and static IPs can all be summarized.

This database is gonna be interesting.

Also, I'm like halfway to a full IPAM tool. Why stop now lol

#programming #python #IPAM #rackroot #infrastructure #engineering