To clarify, I’m only asking that this option can be set to an integer. It would be neat to be able to instruct it to set the option to a value dynamically, deriving it from a specified interface, but that’s a lot more effort and probably rarely worth it

Pardon my typo in the notes, the correct option number is 26 as in the title of the issue

I would like to send a PR for this if I have time as it seems like a relatively good first issue to work on.

It’s very similar to https://vyos.dev/T7263 so I may try to submit a separate PR for that at roughly the same time

Any tips on what projects need to be touched for this are appreciated, I’ve found what needs to be changed in vyos-1x but I’ll have to go through the other 3-4 repositories that VyOS seems to be comprised of

Thx

You need to add changes only in the vyos-1x repo

In T7723#232731, @Viacheslav wrote:

You need to add changes only in the vyos-1x repo

Fantastic, thank you!

Are you familiar with any discussions there may have been about supporting users specifying the option type and value as (essentially) opaque blobs, to enable users to add options supported by kea but not explicitly supported bia the VyOS configuration?

I understand the problem would be that users that enter option names or values that aren’t correct when kea loads the configuration would result in a broken configuration after the template is rendered. I imagine it’s possible this goes against general guidelines about how VyOS prefers to approach things like this, which is why I’m asking

An alternative and more correct approach would be to parse the supported options from the kea options definitions which are in a friendly JSON format (https://github.com/isc-projects/kea/blob/master/doc/examples/kea4/all-options.json) which could provide support for everything without one-off changes- which I believe are not great uses of developer time :)

The behavior would be:

1. Parse kea json options definitions
2. Transform each option name (excluding vendor options, to avoid complexity) based on pre-existing mappings for those explicitly supported by VyOS already, but with names that differ from the kea names
3. Ensure the type is known/supported (there are only so many types in DHCP v4, so this shouldn’t be a challenge)
4. Use that data to validate configuration entries from the user

Both of those changes go beyond the scope of this and probably belong in another ticket. But if you have time and are already familiar with any decisions about doing these (or not doing it) I’m happy to hear them if they’re easy to summarize. Otherwise I’ll raise them later in a separate ticket another time

Regardless, I’ll proceed with the in-scope changes, explicit support for option 26 and option 50 (for the linked request from another user)

Thanks again for making this easy

As a note for myself and any other users not familiar with the project who need to perform a task like this in the feature, a few notes on changes needed based on a quick survey:

• config handling: https://github.com/vyos/vyos-1x/blob/current/python/vyos/kea.py
• configuration file template: https://github.com/vyos/vyos-1x/blob/current/data/templates/dhcp-server/kea-dhcp4.conf.j2
• option description info: https://github.com/vyos/vyos-1x/blob/current/interface-definitions/include/dhcp/option-v4.xml.i
• tests: https://github.com/vyos/vyos-1x/blob/current/smoketest/scripts/cli/test_service_dhcp-server.py
• migration scripts (probably not relevant in most cases- replace the x and y values as appropriate): https://github.com/vyos/vyos-1x/blob/current/src/migration-scripts/dhcp-server/x-to-y

Correction to the steps required to support ALL kea options programatically- it may need to be more like this:

1. Parse the kea options json before shipping (at build time, probably)
2. Dynamically generate the kea-dhcp4.conf.j2 template based on that information
3. Add dummy information in the option-v4.xml file for each option
4. …

Basically, I realize this will be a bit of a departure from the existing logic and will require extended testing.

PR (merged): https://github.com/vyos/vyos-1x/pull/4786