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.

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.

I decided to change the add/remove functionality on the gateway field and replace it simply with a wrench icon that lets you edit the value.

In the Vuetify code, this gets around me having to check the logic of whether the value is populated or not and rendering the right color button. I think it fits better with the code, input form modal, and other parts of the page. Accordingly, I changed the color to yellow.

I'm still working on some of the javascript for it and next time, I need to:

a) detect if a value is in the form and if so apply it to [POST] /networks/{id}/gateway
b) if no value is in the form, call [DELETE] on /networks/{id}/gateway
c) add better error handling so that invalid values bump the user back to the input modal with a relevant message
d) detect that someone didn't put in the network address or broadcast address (backend only, builds on c)

If someone puts a gateway in that's not in the same network, it will be rejected by the backend, but the front end needs to also show something useful. That's its job!

Success - I have a rough design in place for the network detail page. This will show things like the network name, IP/SM/GW details, VLAN, description, and eventually a table of 0..n DHCP ranges.

I also have a button to add or delete the gateway so that the gateway can be updated as needed. The gateway is optional when the network is created and the button renders based on that field. Next time I work on this, I'll add a text modal to go with the "add" button.

I'm still working on this and now that all the holiday stuff is over with, I can finally spend some time on it.

I added a gateway field to the existing production database, thanks to Atlas. This let me add a field to the table and make sure all the existing data came over.

Now that the gateway field is there, I got the backend code done and tests are all passing.

For the front end, I have a design in mind for how to lay it out, now I just get to figure out how to get there.

#programming #webdev #backend #python #fastapi #vuetify #rackroot #homelab

https://atlasgo.io

Manually updated the database for tonight with a database browser for the sake of some progress. I managed to get the new network page, network detail page, and all networks table all working together. Here's a screenshot of my new network form.

This also lays the essential groundwork where I can start to track some IP allocations. At the very least, I want to track the gateway address, DHCP ranges, and static allocations. Then once I have the data, visualize it in a nice way.

I should be able to find Vuetify elements that can visualize and colorize this on the front end.

On the back end, I'll figure out some kind of relationship scheme for this that makes sense.

Me: copies code from the new Item page that I posted about recently into the new Networks page.

Also me: why isn't the "Add New Network" button submitting the form and POSTing to the backend like it should?

Also me: tries to make a new Item entry and that also does not POST to the backend, it just does noting.

Well, it did what I (accidentally) told it to do: nothing. Looks like I need to move the Submit button into the form itself to get it to work.

This is why constant testing is essential for this project!

Writing some of the IPAM implementation is probably going to be the hardest part of this project so far, and I haven't even gotten to the device <-> network relationship(s) yet.

So far in my IPAM code, I have checks for invalid IP ranges and uniqueness, though I'm sure I'm also missing some corner cases.

Then on the front end side, I plan to visualize network usage which can include assigned static IPs, DHCP ranges, gateway/router designations, etc.

I'm hoping that coding it as I go through the frontend and backend will help me properly structure everything, figure out which relationships I need to pull in, and establish the design for my API.

I'm also very happy that I have pytest tests to go with my code. I'm writing those every time I add a new section and it pays off.

The goal for Rack Root is to inventory my home lab and learn some web dev (FE+BE) along the way. I'm now at the point where I think I'll have the biggest challenge: IPAM / networking data.

I'm anticipating that this part will be the most complex because of all the relationships. This is also going to test my API and database design skills, to say nothing of the front end design.

At the start, I'm going to need a good IPv4 address handler library, ways to CRUD network segments, CRUD DHCP ranges, assign static IPs to devices, and similar.

I also will have the data to generate visualizations of IP address usage, and plan to do that at some point.

I fully expect to take advantage of things like Vuetify 3's v-card element which should help with some nifty graphical layouts.

Finished the NewItem.vue page for now with a better layout, date pickers for purchase date and warranty expiration, and a placeholder for devices on the network.

My next plan is to start designing the networking piece of Rack Root and figure out which pieces I'll need to put in place. This will include the network zone, DHCP ranges, and subnet mask info. Devices on the network can be DHCP or static which is data I plan to track.

Items will have the ability to use 0..n network interfaces which accounts for things not on the network such as hard drives, single-NIC devices such as laptops, and multi-NIC devices such as network devices. All of that can go into the database.

By the time it's done, I should have the data to generate a pretty good picture of the network layout such as DHCP range utilization and IP utilization. Somewhere along the way I'll need to figure out subnet math, too. Yay.

Now to the new item functionality.

First screenshot shows a summary of test values in the table, and the date is formatted on the frontend so it looks the way I want.

Second screenshot shows the new item page which is definitely still a work in progress. I have a lot of functionality to add to this one, and figure out what layout I want to use for it. I'm using things like v-field, v-textarea, and v-date-picker for these elements. The buttons are of course using v-btn.

The last screenshot shows the item detail page and this design is definitely not final. I'm not even showing the notes or descriptions fields in this view. I really should sketch out some things I want to do in order to use this the way I want.

And now for some screenshots.

First screenshot shows the landing page with basic summaries.

Second screenshot shows the new device type tab on the settings page.

Third screenshot shows another tab I setup for export/import functionality. That one will be interesting to write, for sure.

Well, it's been a month or so since I've posted so here's what I've changed/learned about.

It was easier for me to use DateTime than Date, even if I just want to hold a Date field. I also started to really build out some of the more dynamic functionality.

Device types can now be defined on the setting page, tab 1 and I'm using a modal textbox that pops up when you go to add a new item. All that needs is a name so a model makes a lot of sense for that.

When making a new item, the device types are pulled over dynamically and displayed as human-friendly names in a drop down. In the code and going to the back end, it's all using the ID. This field is also nullable in case the device type gets deleted, it won't throw as many exceptions.

I also wrote up the item detail page, though both the new item page and item detail page tell me that I need better UX design / more layout experience. This stuff isn't easy!

Finally on the design side of things, I've added a couple dynamic boxes to the landing page that show how many items and device types are defined. This is another part of the site I'll work to design more as I go.

I'm sure I will find something that looks good and functions the way I want – I just need to get there. And I can tell by where I am now that this project will keep me busy for as long as I want it to.

I appreciate that with Vue/Vuetify, I'm able to do that whole Settings page dynamically and I did this in under 50 lines of code. Of course I'm heavily relying on imports and all the libraries underneath, but this just makes it so easy once you know how things work and which levers to pull in order to adjust appearance.

I was able to work on this layout and even add tabs to it in just a couple of hours.

Tonight's short update - I added a new table to the database to store device types, associated HTTP GET all device types, HTTP POST create device type, and a settings page in the app with tabs to view the device types.

This gave me more practice in laying out pages in Vue/Vuetify, using classes to control the layout, height, width, etc.

My next update has to be more focused on the backend and testing since I don't have that many tests going on there now.

Below is a screenshot of the table as it stands now and I'll link to the frontend in my latest commit here: https://github.com/alongchamps/rack-root/blob/main/frontend/src/pages/Settings.vue