right now we just have that forked logic set up so that it'll hit a bad route on an app so that we can see the 404 in the logs and confirm we hit the hardware discovery logic. at this point in the smee execution logic, we would like for it to instead invoke our fork of tink-server, so that tink-server can create a hardware object in-cluster.
https://github.com/kubefirst/tink
we have the and smee tink repos set up to build images any time the main branch is touched, and the resulting images can be patched into your clusterzero when you helm upgrade colony
johndietz
commented
6 months ago
we currently have smee forked and tink forked for the purpose of establishing hardware autodiscovery. we already have the smee fork capable of recognizing when it's discovered new hardware in a data center. https://github.com/kubefirst/smee/blob/3f3af00c9fc380301637148ab4d54a77e2b372b4/internal/dhcp/handler/reservation/handler.go#L80
right now we just have that forked logic set up so that it'll hit a bad route on an app so that we can see the 404 in the logs and confirm we hit the hardware discovery logic. at this point in the smee execution logic, we would like for it to instead invoke our fork of tink-server, so that tink-server can create a hardware object in-cluster. https://github.com/kubefirst/tink
we have the and smee tink repos set up to build images any time the main branch is touched, and the resulting images can be patched into your clusterzero when you helm upgrade colony