schema: Enlarge Command Argument and Environment Key #792
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
From the beginning, the Icinga DB schema allowed 64 characters for both
the command arguments and environment variable names[0]. In particular,
this affects CheckCommand, EventCommand and NotificationCommand Icinga 2
objects.
But if a command with either an argument key or an environment variable
that is longer than 64 characters was defined in Icinga 2, Icinga DB
will try to insert it into the database and may end up crashing.
Although it may seem large enough, it is sometimes exceeded.
After evaluating that there was no technical limitation[1], the limit
was increased to 255 characters. This limit was chosen over the wider
text type as it allows indexes in the future and requires less space.
For example, the following CheckCommand was not possible before:
> object CheckCommand "icingadb-i791" {
> import "plugin-check-command"
> command = [ "/bin/true" ]
> env = {
> "THAT_ARE_64_AS_WOW_AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" = "huhu"
> }
> arguments = {
> "java.class.that.was.used.as.an.argument.that.was.eighty.seven.characters.long.and.broke" = {
> value = "F"
> }
> }
> }
Another thing was a type difference between the MySQL and PostgreSQL
schemas. While the MySQL schema defined argument_key_override as
varchar(64), in PostgreSQL it was a citext. So it was changed to
varchar(255) in MySQL and kept as it was in PostgreSQL.
Closes #791.
[0]: 05d5e97
[1]: #791 (comment)
oxzi
force-pushed
the
command-args-envs-len-i791
branch
from
e122ceb
to
091388d
Compare
lippserd
approved these changes
Aug 26, 2024
yhabteab
added a commit
that referenced
this pull request
Nov 15, 2024
PR #792 mistakenly added a `NOT NULL` clause to a nullable columns. This PR corrects that by dropping that clause and adding a `DEFAULT NULL` clause, making it consistent the actual schema file.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
From the beginning, the Icinga DB schema allowed 64 characters for both the command arguments and environment variable names. In particular, this affects
CheckCommand,EventCommandandNotificationCommandIcinga 2 objects.But if a command with either an argument key or an environment variable that is longer than 64 characters was defined in Icinga 2, Icinga DB will try to insert it into the database and may end up crashing. Although it may seem large enough, it is sometimes exceeded.
After evaluating that there was no technical limitation, the limit was increased to 255 characters. This limit was chosen over the wider
texttype as it allows indexes in the future and requires less space.For example, the following
CheckCommandwas not possible before:Another thing was a type difference between the MySQL and PostgreSQL schemas. While the MySQL schema defined
argument_key_overrideasvarchar(64), in PostgreSQL it was acitext. So it was changed tovarchar(255)in MySQL and kept as it was in PostgreSQL.Closes #791.