Bug 50704 - Improve DHCP Frontend in UMC
Summary: Improve DHCP Frontend in UMC
Status: NEW
Alias: None
Product: UCS
Classification: Unclassified
Component: UMC - DHCP
Version: UCS 5.0
Hardware: Other Linux
: P5 normal
Target Milestone: ---
Assignee: UMC maintainers
QA Contact: UMC maintainers
URL:
Keywords:
Depends on:
Blocks: 49837
  Show dependency tree / graph
 
Reported: 2020-01-10 09:26 CET by Christian Völker
Modified: 2024-08-26 16:08 CEST (History)
4 users (show)

See Also:
What kind of report is it?: Feature Request
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?: Yes
School Customer affected?: Yes
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number: 2019112821001245, 2019030521000821, 2019012221000034, 2019032821000752, 2019042521000729, 2019052321000491, 2019061321000757, 2019062921000441, 2019071821000201, 2019081221000399, 2019092421000276, 2019111321000747, 2019111321001102, 2019112121000268,2020
Bug group (optional):
Customer ID: 01727, 09739, 09752, 33632, 49961
Max CVSS v3 score:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Völker univentionstaff 2020-01-10 09:26:45 CET 
The DHCP configuration causes a high load of support tickets as the customers are having severe difficulties in configuring the service through UMC.
I am fully aware the UMC follows the LDAP rules from ISC DHCP but shouldn't the frontend offer a USEABLE way to configure the service?

Customers expect to configure DHCP (more or less) as follows:

Enable or disable DHCP for a network
Configure Ranges, Gateway, Domain and DNS for every network separately
Easy way to configure static DHCP clients (here I could imagine to match/display entries with the computers-module)

Customers do NOT expect policies to be inherited from an upstream configuration item. For them DHCP networks are all equal rights. Even if then a lower item should be able to overwrite parent rules...

Again, I am aware how DHPC LDAP works. But this is really confusing for customers.
Comment 1 Christian Völker univentionstaff 2020-01-10 09:33:28 CET 
Another example for confusion can be seen in bug #49837
Comment 2 Ingo Steuwer univentionstaff 2020-01-13 14:15:57 CET 
Priorities:

- display DHCP settings from "network" point of view, not the LDAP structure
- remove/hide "pools" (use only "ranges")
- remove/hide "server" objects (create them automatically)
- allow multi-edit, remove/hide policy based settings
Comment 3 Dirk Schnick univentionstaff 2020-06-17 16:16:14 CEST 
A customer complained yesterday in the course of another ticket about the standstill in the processing of the DHCP interface.
Progress in sight?
btw I was not able to add the ticketnumber 2020061721000631 as the field is allready full...
Comment 4 Ingo Steuwer univentionstaff 2020-06-19 10:25:06 CEST 
There is currently no big change planned in the roadmap, this can be done once we are closer to UCS 5.0.

The challenge here is that this Feature Request is very generic. it would be very helpfull to have individual Feature Requests for the various ideas and measure the customer feedback there.

A general remark: we made bad experiences in "hiding" the real data structure in the frontend, because users won't understand why there are some behaviours, defaults or constraints. To ease the management we should also change the data structure.
Comment 5 Christian Völker univentionstaff 2020-06-23 13:27:38 CEST 
(In reply to Ingo Steuwer from comment #4)
> 
> The challenge here is that this Feature Request is very generic. it would be
> very helpfull to have individual Feature Requests for the various ideas and
> measure the customer feedback there.
I do not see why (and how!) this can be split in several feature requests. There are a lot of customers having issues with this structure. Is the number of tickets attached not enough measurement from customer point of view? Why (and how?) another metric?

 
> A general remark: we made bad experiences in "hiding" the real data
> structure in the frontend, because users won't understand why there are some
> behaviours, defaults or constraints. To ease the management we should also
> change the data structure.

Currently most of the uses (I would say 90%) do *NOT* know the LDAP structure of ISC-DHCP. So implementing a frontend which behaves similar to 99% of all DHCP frontends (including MS) on the market should match the customers expectations.

I am well used to DHCP and troubleshooting but up to this bug I had no clue about the LDAP structure behind it.  When using text files as backend you simply add clients to a network and that's it....
Comment 6 Ingo Steuwer univentionstaff 2020-06-29 16:24:58 CEST 
example usecase that confuses: creating a new network which has free IP ranges - this needs currently several LDAP Objects
Comment 7 Ingo Steuwer univentionstaff 2024-08-26 16:07:27 CEST 
The bad usability is partly due to a confusing mix of ISC DHCPD config file structures and UDM LDAP policies. As we have to replace ISC DHCPD in the near future (it has been deprecated upstream) I propose we are not going to fix this for ISC DHCPD but will have a new implementation for a new DHCPD.