Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
53 changes: 53 additions & 0 deletions pkg/resource/db_cluster_parameter_group/hooks.go
Original file line number Diff line number Diff line change
Expand Up @@ -242,6 +242,59 @@ func (rm *resourceManager) syncParameters(
desiredOverrides, latestOverrides,
)

// Filter out parameters that are already pending reboot from both toModify and toDelete.
// When a parameter is reset or modified, it remains as a user override with pending-reboot
// status until the DB cluster is rebooted. Attempting to modify or reset it again
// would cause a reconciliation loop. We skip modifying/resetting parameters that are
// already pending reboot until after the reboot completes.
Comment on lines +245 to +249
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Q: When a parameter is pending-reboot can it not still have its value modified/reset? For example if I modify a static parameter to have value "x" and can I still change the value to "y" before rebooting? If we can, I think filtering the parameter from the toModify/toDelete will prevent that update.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

below is manifest used to turn the binary logging/reboot and can see binary logging log_bin is ON.All good.
However on portal see binlog_format=none, and log_bin=off and pending reboot, so ack is continuously trying to reconcile/apply and goes into pending reboot and aws events show the parameter group updates, every 2 hours.
In addition, I have tested another use case where I tried to change the dynamic parameter, with earlier applied static parameters in manifest, the ack is re applying it and goes into pending reboot.Goal here is to have both static/dynamic parameters applied once via manifest (not via portal ) and after reboot, ack know its state.

for your question , yes it depends on the parameter but yes we can change from x to y before reboot.but after reboot we dont want ack to go into a loop.

dbClusterParameterGroup:
  name: "testdbclusterparametergroup"
  description: "test cluster parameters"
  family: "aurora-mysql8.0"
  parameterOverrides:
    binlog_format: "ROW"
    read_only: "{TrueIfClusterReplica}"
dbParameterGroup:
  name: "testdbclusterparametergroup-instance"
  description: "test Instance Parameters"
  family: "aurora-mysql8.0"
  parameterOverrides:
    max_allowed_packet: "1073741824"
    max_execution_time: "600000"
    slow_query_log: "1"
    long_query_time: "2"

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes agree in above comment Filtering all pending-reboot parameters from toModify might blocks legitimate updates. so may be this change is not needed or need tested.

if latest != nil && latest.ko.Status.ParameterOverrideStatuses != nil {
pendingRebootParams := make(map[string]bool)

// Build a map of parameters that are pending reboot
for _, status := range latest.ko.Status.ParameterOverrideStatuses {
if status.ParameterName != nil && status.ApplyMethod != nil {
if *status.ApplyMethod == "pending-reboot" {
pendingRebootParams[*status.ParameterName] = true
}
}
}

// Filter toDelete: skip parameters that are pending reboot
if len(toDelete) > 0 {
filteredToDelete := util.Parameters{}
for paramName, paramValue := range toDelete {
if !pendingRebootParams[paramName] {
filteredToDelete[paramName] = paramValue
} else {
rlog.Debug(
"skipping reset of parameter already pending reboot",
"parameter", paramName,
)
}
}
toDelete = filteredToDelete
}

// Filter toModify: skip parameters that are pending reboot
// This prevents trying to modify parameters that are in a transitional state
// after reboot but before the status is updated
if len(toModify) > 0 {
filteredToModify := util.Parameters{}
for paramName, paramValue := range toModify {
if !pendingRebootParams[paramName] {
filteredToModify[paramName] = paramValue
} else {
rlog.Debug(
"skipping modify of parameter already pending reboot",
"parameter", paramName,
"desired_value", paramValue,
)
}
}
toModify = filteredToModify
}
}

if len(toDelete) > 0 {
err = rm.resetParameters(ctx, family, groupName, toDelete)
if err != nil {
Expand Down
53 changes: 53 additions & 0 deletions pkg/resource/db_parameter_group/hooks.go
Original file line number Diff line number Diff line change
Expand Up @@ -230,6 +230,59 @@ func (rm *resourceManager) syncParameters(
desiredOverrides, latestOverrides,
)

// Filter out parameters that are already pending reboot from both toModify and toDelete.
// When a parameter is reset or modified, it remains as a user override with pending-reboot
// status until the DB instance is rebooted. Attempting to modify or reset it again
// would cause a reconciliation loop. We skip modifying/resetting parameters that are
// already pending reboot until after the reboot completes.
if latest != nil && latest.ko.Status.ParameterOverrideStatuses != nil {
pendingRebootParams := make(map[string]bool)

// Build a map of parameters that are pending reboot
for _, status := range latest.ko.Status.ParameterOverrideStatuses {
if status.ParameterName != nil && status.ApplyMethod != nil {
if *status.ApplyMethod == "pending-reboot" {
pendingRebootParams[*status.ParameterName] = true
}
}
}

// Filter toDelete: skip parameters that are pending reboot
if len(toDelete) > 0 {
filteredToDelete := util.Parameters{}
for paramName, paramValue := range toDelete {
if !pendingRebootParams[paramName] {
filteredToDelete[paramName] = paramValue
} else {
rlog.Debug(
"skipping reset of parameter already pending reboot",
"parameter", paramName,
)
}
}
toDelete = filteredToDelete
}

// Filter toModify: skip parameters that are pending reboot
// This prevents trying to modify parameters that are in a transitional state
// after reboot but before the status is updated
if len(toModify) > 0 {
filteredToModify := util.Parameters{}
for paramName, paramValue := range toModify {
if !pendingRebootParams[paramName] {
filteredToModify[paramName] = paramValue
} else {
rlog.Debug(
"skipping modify of parameter already pending reboot",
"parameter", paramName,
"desired_value", paramValue,
)
}
}
toModify = filteredToModify
}
}

// NOTE(jaypipes): ResetDBParameterGroup and ModifyDBParameterGroup only
// accept 20 parameters at a time, which is why we "chunk" both the deleted
// and modified parameter sets.
Expand Down