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
All,
We would like to add support for extra DHCP options to Nuage in CloudStack.
We want to add an extra optional parameter for extra DHCP options to the
deployVm, updateVM and addNic API, and pass this to the plugin, using a new
method on the DHCP Service provider interface.
Please take a look
