... | ... | @@ -39,8 +39,19 @@ This term (short "caps") stands for Stork's ability to control various configura |
|
|
|
|
|
Stork should determine caps for each application when the app is first connected to Stork and every time Stork updates the application's state information (using the state puller). Next, it should make the caps available over the REST API to the client to enable and disable specific configuration controls and views in the UI.
|
|
|
|
|
|
## System Views
|
|
|
TBD
|
|
|
## Two Perspectives
|
|
|
|
|
|
Network administrators can have two different perspectives on the DHCP configuration.
|
|
|
|
|
|
In the first case, the network segments (i.e., subnets, shared networks) and hosts are the main focus areas. An administrator can define a new subnet, renumber it, or extend it with additional IP addresses or delegated prefixes. Next, the administrator selects one or multiple DHCP instances servicing the clients in this subnet. The new or updated configuration is populated to the selected DHCP servers (e.g., servers grouped in the HA setup). The actual configuration populated to the DHCP servers is not interesting to the administrator.
|
|
|
|
|
|
In the second case, network administrators focus on the details of the DHCP server configurations. They can modify any part of the individual server's configuration (e.g., logging information, network interfaces, etc.).
|
|
|
|
|
|
Please note that the administrator has finer-grained control over the DHCP configuration in the second case, but it is less convenient in the subnet-centric configuration model and more error-prone due to the necessity to copy similar configurations to multiple DHCP instances.
|
|
|
|
|
|
Stork must facilitate both described configuration approaches. Consider a case when an administrator wants to create new HA pair of DHCP servers. It is most convenient to define network configurations, such as subnets, shared networks, pools, classes, and HA configuration. The administrator selects DHCP servers to which the resulting DHCP configuration is populated. Then, the administrator may need to apply some changes to both or one of the resulting DHCP configurations (.e.g, adjust network interface name to the particular machine's network configuration).
|
|
|
|
|
|
The Stork data model was designed with these different configuration perspectives in mind. In the database, the `subnet` table comprises the common subnet information, such as `prefix` and dynamic pools. Multiple DHCP servers can be associated with a subnet via the `local_subnet` table. It comprises DHCP server-specific information about subnets and creates a many-to-one relationship with them.
|
|
|
|
|
|
## Runtime and Source Configuration
|
|
|
TBD
|
... | ... | |