-
Notifications
You must be signed in to change notification settings - Fork 79
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #364 from jacobweinstock/unify
bring back the code from tinkerbell/dhcp ## Description <!--- Please describe what this PR is going to change --> The DHCP library was created in order to provide a mechanism for the DHCP functionality to be written in a very clean and composible way. This was not possible with the previous state of Boots and the personnel involved at that time. The current state of Smee is ready for this functionality to be returned and placed in a very clean and composable way into the code base. Moving this functionality back in will improve the development process/experience. It is important to note that we do take on the trade off of not having the combined commit history of the DHCP library within Smee. We won't lose the commit history entirely as the DHCP library GitHub repo will remain (archived) in order to have the commit history available. ## Why is this needed <!--- Link to issue you have raised --> Fixes: # ## How Has This Been Tested? <!--- Please describe in detail how you tested your changes. --> <!--- Include details of your testing environment, and the tests you ran to --> <!--- see how your change affects other areas of the code, etc. --> ## How are existing users impacted? What migration steps/scripts do we need? <!--- Fixes a bug, unblocks installation, removes a component of the stack etc --> <!--- Requires a DB migration script, etc. --> ## Checklist: I have: - [ ] updated the documentation and/or roadmap (if required) - [ ] added unit or e2e tests - [ ] provided instructions on how to upgrade
- Loading branch information
Showing
45 changed files
with
5,045 additions
and
36 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,62 @@ | ||
| # File Watcher Backend | ||
|
|
||
| This document gives an overview of the file watcher backend. | ||
| This backend will read in and watch a file on disk for changes. | ||
| The data from this file will then be used for serving DHCP requests. | ||
|
|
||
| ## Why | ||
|
|
||
| This backend exists mainly for testing and development. | ||
| It allows the DHCP server to be run without having to spin up any additional backend servers, like [Tink](https://github.com/tinkerbell/tink) or [Cacher](https://github.com/packethost/cacher). | ||
|
|
||
| ## Usage | ||
|
|
||
| ```bash | ||
| # See the file example/main.go for details on how to select and use this backend in code. | ||
| go run example/main.go | ||
| ``` | ||
|
|
||
| Below is an example of the format used for this file watcher backend. | ||
| See this [example.yaml](../backend/file/testdata/example.yaml) for a full working example of the data model. | ||
|
|
||
| ```yaml | ||
| --- | ||
| 08:00:27:29:4E:67: | ||
| ipAddress: "192.168.2.153" | ||
| subnetMask: "255.255.255.0" | ||
| defaultGateway: "192.168.2.1" | ||
| nameServers: | ||
| - "8.8.8.8" | ||
| - "1.1.1.1" | ||
| hostname: "pxe-virtualbox" | ||
| domainName: "example.com" | ||
| broadcastAddress: "192.168.2.255" | ||
| ntpServers: | ||
| - "132.163.96.2" | ||
| - "132.163.96.3" | ||
| leaseTime: 86400 | ||
| domainSearch: | ||
| - "example.com" | ||
| netboot: | ||
| allowPxe: true | ||
| ipxeScriptUrl: "https://boot.netboot.xyz" | ||
| 52:54:00:aa:88:2a: | ||
| ipAddress: "192.168.2.15" | ||
| subnetMask: "255.255.255.0" | ||
| defaultGateway: "192.168.2.1" | ||
| nameServers: | ||
| - "8.8.8.8" | ||
| - "1.1.1.1" | ||
| hostname: "sandbox" | ||
| domainName: "example.com" | ||
| broadcastAddress: "192.168.2.255" | ||
| ntpServers: | ||
| - "132.163.96.2" | ||
| - "132.163.96.3" | ||
| leaseTime: 86400 | ||
| domainSearch: | ||
| - "example.com" | ||
| netboot: | ||
| allowPxe: true | ||
| ipxeScriptUrl: "https://boot.netboot.xyz" | ||
| ``` |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,25 @@ | ||
| # Code Structure | ||
|
|
||
| ## Backend | ||
|
|
||
| Responsible for communicating with an external persistence source and returning data from said source. | ||
| Backends live in the `backend/` directory. | ||
|
|
||
| ## Handler | ||
|
|
||
| Responsible for reading a DHCP packet from a source, calling a backend, and responding to the source. | ||
| All business logic for responding or reacting to DHCP messages lives here. | ||
| Handlers live in the `handler/` directory. | ||
|
|
||
| ## Listener | ||
|
|
||
| Responsible for listening for UDP packets on the specified address and port. | ||
| A default listener can be used. | ||
|
|
||
| ## Server | ||
|
|
||
| Responsible for filtering for DHCP packets received by the listener and calling the specified handler. | ||
|
|
||
| ## Functional description | ||
|
|
||
| Server(listener, handler(backend)) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,88 @@ | ||
| # Design Philosophy | ||
|
|
||
| This living document describes some Go design philosophies we endeavor to incorporate when working, building, or writing in Go. | ||
|
|
||
| ## General | ||
|
|
||
| 1. Prefer easy to understand over easy to do | ||
| 2. First do it, then do it right, then do it better, then make it testable [14] | ||
| 3. When you spawn goroutines, make it clear when - or whether - they exit. [2] | ||
| 4. Packages that are imported only for their side effects should be avoided [4] | ||
| 5. Package level and global variables should be avoided | ||
| 6. magic is bad; global state is magic → no package level vars; no func init [13] | ||
|
|
||
| ## Dependencies | ||
|
|
||
| 1. External dependencies should be tried and fail fast or just keep trying | ||
| - For example, external connections, port binding, environment variables, secrets, etc | ||
| - Examples of "failing fast" | ||
| - Try external connections immediately | ||
| - Binding to ports immediately | ||
| - Examples of "keep trying" | ||
| - Block ingress traffic or calls until external connections are successful | ||
| - Should be accompanied by some way to check health status of external connections | ||
| 2. Make all dependencies explicit [11] | ||
|
|
||
| ## Naming | ||
|
|
||
| 1. Naming general rules [12] | ||
| - Structs are plain nouns: API, Replica, Object | ||
| - Interfaces are active nouns: Reader, Writer, JobProcessor | ||
| - Functions and methods are verbs: Read, Process, Sync | ||
| 2. Package names [15] | ||
| - Short: no more than one word | ||
| - No plural | ||
| - Lower case | ||
| - Informative about the service it provides | ||
| - Avoid packages named utility/utilities or model/models | ||
| 3. Avoid renaming imports except to avoid a name collision; good package names should not require renaming [3] | ||
|
|
||
| ## Interfaces | ||
|
|
||
| 1. Accept interfaces, return structs [5] | ||
| 2. Small interfaces are better [6] | ||
| 3. Define an interface when you actually need it, not when you foresee needing it [7] | ||
| 4. Interfaces [15] | ||
| - Use interfaces as function/method arguments & as field types | ||
| - Small interfaces are better | ||
|
|
||
| ## Functions/Methods | ||
|
|
||
| 1. All top-level, exported names should have doc comments, as should non-trivial unexported type or function declarations. [1] | ||
| 2. Methods/functions [15] | ||
| - One function has one goal | ||
| - Simple names | ||
| - Reduce the number of nesting levels | ||
| 3. Only func main has the right to decide which flags, env variables, config files are available to the user [10a],[10b] | ||
| 4. `context.Context` should, in most cases, be the first argument of all functions or methods | ||
| 5. Prefer synchronous functions - functions which return their results directly or finish any callbacks or channel ops before returning - over asynchronous ones. [8] | ||
|
|
||
| ## Errors | ||
|
|
||
| 1. Error Handling [15] | ||
| - Func `main` should normally be the only one calling fatal errors or `os.Exit` | ||
|
|
||
| ## Source files | ||
|
|
||
| 1. One file should be named like the package [9] | ||
| 2. One file = One responsibility [9] | ||
| 3. If you only have one command prefer a top level `main.go`, if you have more than one command put them in a `cmd/` package | ||
|
|
||
| --- | ||
|
|
||
| [1]: https://github.com/golang/go/wiki/CodeReviewComments#doc-comments | ||
| [2]: https://github.com/golang/go/wiki/CodeReviewComments#goroutine-lifetimes | ||
| [3]: https://github.com/golang/go/wiki/CodeReviewComments#imports | ||
| [4]: https://github.com/golang/go/wiki/CodeReviewComments#import-blank | ||
| [5]: https://medium.com/@cep21/what-accept-interfaces-return-structs-means-in-go-2fe879e25ee8 | ||
| [6]: https://www.practical-go-lessons.com/chap-40-design-recommendations?s=03#use-interfaces | ||
| [7]: http://c2.com/xp/YouArentGonnaNeedIt.html | ||
| [8]: https://github.com/golang/go/wiki/CodeReviewComments#synchronous-functions | ||
| [9]: https://www.practical-go-lessons.com/chap-40-design-recommendations?s=03#source-files | ||
| [10a]: https://thoughtbot.com/blog/where-to-define-command-line-flags-in-go | ||
| [10b]: https://peter.bourgon.org/go-best-practices-2016/#configuration | ||
| [11]: https://peter.bourgon.org/go-best-practices-2016/#top-tip-9 | ||
| [12]: https://twitter.com/peterbourgon/status/1121023995107782656 | ||
| [13]: https://peter.bourgon.org/blog/2017/06/09/theory-of-modern-go.html | ||
| [14]: https://code.tutsplus.com/articles/master-developers-addy-osmani--net-31661 | ||
| [15]: https://www.practical-go-lessons.com/chap-40-design-recommendations?s=03#key-takeaways |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.