You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Sigert GOEMINNE <si...@nuagenetworks.net> on 2017/02/08 10:37:37 UTC
[PROPOSAL] Extra DHCP options
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 at the FS [1], and jira ticket [2].
[1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/C
loudStack+extra+DHCP+option+support
[2] https://issues.apache.org/jira/browse/CLOUDSTACK-9776
Kind regards,
*Sigert Goeminne*
Software Development Engineer
*nuage* <http://nuagenetworks.net>networks.net
Copernicuslaan 50
2018 Antwerp
Belgium
Re: [PROPOSAL] Extra DHCP options
Posted by Dustin Wright <dw...@untangledtechnology.com>.
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 part of provisioning functionality. It would be really nice if
you just racked up servers and the local disks showed up as a storage
option, but there was no OS disk on the hypervisor to get jacked up. Later
those local disks could be federated later.
Dustin
On Wed, Feb 8, 2017 at 9:04 AM, Syed Ahmed <sa...@cloudops.com> wrote:
> 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
> boilerplate code (like NicDetailsDao & NicDetailsVO etc) in Cloudstack for
> doing this. You could just use that instead.
>
> On Wed, Feb 8, 2017 at 5:37 AM, Sigert GOEMINNE <
> sigert.goeminne@nuagenetworks.net> wrote:
>
> > 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 at the FS [1], and jira ticket [2].
> >
> > [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/C
> > loudStack+extra+DHCP+option+support
> > [2] https://issues.apache.org/jira/browse/CLOUDSTACK-9776
> >
> > Kind regards,
> >
> > *Sigert Goeminne*
> > Software Development Engineer
> >
> > *nuage* <http://nuagenetworks.net>networks.net
> > Copernicuslaan 50
> > 2018 Antwerp
> > Belgium
> >
>
Re: [PROPOSAL] Extra DHCP options
Posted by Kris Sterckx <kr...@nuagenetworks.net>.
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.
thanks,
Kris
On 8 February 2017 at 16:49, Sergey Levitskiy <Sergey.Levitskiy@autodesk.com
> 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.
>
>
>
>
Re: [PROPOSAL] Extra DHCP options
Posted by Sergey Levitskiy <Se...@autodesk.com>.
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.
Re: [PROPOSAL] Extra DHCP options
Posted by Sigert GOEMINNE <si...@nuagenetworks.net>.
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 they
would be "reserved" for DHCP options. Secondly, we would need to retrieve
all nic_details (also details non related to DHCP) when listing the DHCP
options of a nic.
- We could add a prefix like '"dhcp:"' to each DHCP code and use that as
a key:
Then we could extend the DAO class to include a search criteria which only
returns the details starting with a certain prefix (in this example
"dhcp:").
- 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.
An extra table, specific for DHCP options, seems to be a cleaner way?
Kind regards,
Sigert
*Sigert Goeminne*
Software Development Engineer
*nuage* <http://nuagenetworks.net>networks.net
Copernicuslaan 50
2018 Antwerp
Belgium
On Wed, Feb 8, 2017 at 3:04 PM, Syed Ahmed <sa...@cloudops.com> wrote:
> 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
> boilerplate code (like NicDetailsDao & NicDetailsVO etc) in Cloudstack for
> doing this. You could just use that instead.
>
> On Wed, Feb 8, 2017 at 5:37 AM, Sigert GOEMINNE <
> sigert.goeminne@nuagenetworks.net> wrote:
>
> > 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 at the FS [1], and jira ticket [2].
> >
> > [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/C
> > loudStack+extra+DHCP+option+support
> > [2] https://issues.apache.org/jira/browse/CLOUDSTACK-9776
> >
> > Kind regards,
> >
> > *Sigert Goeminne*
> > Software Development Engineer
> >
> > *nuage* <http://nuagenetworks.net>networks.net
> > Copernicuslaan 50
> > 2018 Antwerp
> > Belgium
> >
>
Re: [PROPOSAL] Extra DHCP options
Posted by Syed Ahmed <sa...@cloudops.com>.
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
boilerplate code (like NicDetailsDao & NicDetailsVO etc) in Cloudstack for
doing this. You could just use that instead.
On Wed, Feb 8, 2017 at 5:37 AM, Sigert GOEMINNE <
sigert.goeminne@nuagenetworks.net> wrote:
> 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 at the FS [1], and jira ticket [2].
>
> [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/C
> loudStack+extra+DHCP+option+support
> [2] https://issues.apache.org/jira/browse/CLOUDSTACK-9776
>
> Kind regards,
>
> *Sigert Goeminne*
> Software Development Engineer
>
> *nuage* <http://nuagenetworks.net>networks.net
> Copernicuslaan 50
> 2018 Antwerp
> Belgium
>