Closed K0nne closed 3 years ago
By RFC 1035 section 2.3.4 "size limits" the limit for a hostname is 255 octets, removing one for termination and another one for the trailing dot 253 would be the real limit. So increasing the length of the varchar would be correct as the limit is to low.
Not a friend of modifying the generic object table for this. I fear the performance impact with the created index. Leaving this decision to @lippserd.
But service name can be longer than 128 characters, this just happened to me:
service name was:
control-02.dev-01.cloud.abc.ab.abcde/check_disk_/var/lib/kubelet/pods/4037e38c-decf-11e9-b96c-005056a73435/volume-subpaths/system-config/fluent-bit/10
but in icinga_objects.name2 there was
control-02.dev-01.cloud.abc.ab.abcde/check_disk_/var/lib/kubelet/pods/4037e38c-decf-11e9-b96c-005056a73435/volume-subpaths/syste
and it was not unique because specific part was cut out.
There's work underway with the new IcingaDB backend where these shortcomings are tackled. Therefore I don't think it is a good idea to change the IDO schema at this point, with unforseeable problems.
Can we expect the new IcingaDB backend with 2.12.0?
@K0nne Icinga 2.12.0 RC1 has been released about a week ago. Icinga DB supports names up to 255 characters. Though I think we can safely increase name1 and name2 to 255 characters for the IDO as well.
Are there any updates on this? Right now I ran into this issue again.
It is scheduled for version 2.13.
Is your feature request related to a problem? Please describe.
In our cloud environment we have a challenge with long hostnames. We found out that icinga supports only hosts with a length of max. 128 characters.
Manual check execution for such hosts lead to the following error because the field name1 in icinga_objects is too short.
Describe the solution you'd like
Please support hosts with hostnames >128 characters.
Describe alternatives you've considered
I have tried to change the type of name1 in icinga_objects to varchar(256). after a restart the hosts were inserted correctly, but I reverted it at this point because we need a futureproof solution.
Tested with Icinga 2.10.5 and IcingaWeb2 2.7.1 on RHEL7.