cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kris Sterckx <>
Subject Re: [PROPOSAL] Extra DHCP options
Date Mon, 13 Feb 2017 08:57:21 GMT
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 approach, compared to the proposed
extra table. Json has the drawback of higher error proneness (as less
formal) and (slightly) reduced performance, as I see it. Also depending on
the design, every network plugin would need to understand how to process
the json info, again relating to my point of error-proneness.



On 8 February 2017 at 16:49, Sergey Levitskiy <
> wrote:

> 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; "extra_dhcp_options" and as
> value: we
>     decode all the dhcp options (code + value) as json. This makes updating
>     DHCP options on a nic more complex.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message