Hi all
Comparing storing a set of DHCP options as extra json info in nic details
with a new formal specification in sql, I would judge the formal approach
as long-term preferred ?
I understand everything can be modeled in json as well - i just want to
understand better the arguments pro that appro
I personally like this option. This way you can obtain all DHCP options at once
very fast and manipulate them as you see fit in the respective module
- A second option could be that we store all the DHCP options in *one*
key,value pair.
As key we pick a specific value say; "
Hi Syed,
We specified storing the DHCP options in the nic_details table as
alternatives in the FS.
There are however some downsides to this approach:
- Storing each DHCP option as key (=dhcp code),value (=dhcp value) pair:
In this case nobody else can use numeric keys in nic_details because t
This is somewhat off topic, but related. I've always thought
ApacheCloudStack should come with a PXE server on the controller to boot
the hypervisors over the network. Automatic construction of the hypervisors
so there are no local disks would be really nice. I imagine DHCP attributes
could be a pa
Hi Sigert,
Instead of creating a new table `nic_extra_dhcp_option` is it possible to
use the table `nic_options` The *_details tables are usually used as a
key-value store to store details about the various secondary params. You
can have a look at host_details table for example. There is already
b
