What does VPC.Update scheduled mean?

[mwaag]

Hi,

when editing a vpc via webinterface there is a field to define a source nat ip adress for that vpc which is empty by default:

Even when leaving this field empty and confirming with OK, there is a VPC.UPDATE scheduled:

What exactly does that mean?
When will this update happen and does this possibly change the source nat ip even if the user leaves this field empty?

For info, we recently upgraded from 4.18.2.4 to 4.20.3.0 and wasn't aware of this field before. Was this introduced in 4.19/4.20?

(For background: One of our clients experienced a sudden change of source nat ip and the event log shows a scheduled vpc.update followed by a completed router.stop and we are now investigating the root cause:

[DaanHoogland]

@mwaag , was the updateVpc API called? this should not happen automatically through any kind of schedule. The field was added to the API in 4.19, in #6442.

[mwaag]

No, in my testcase i used the 'Edit VPC'-function via webinterface as shown in my first screenshot.
(iam aware that this trigger in fact an api-call in background, but webinterface was what I used).

This triggered only a schedule vpc.update up to now (but did not execute the update itself). Do you now, when it will be executed? Can i trigger its execution somehow?

[weizhouapache]

No, in my testcase i used the 'Edit VPC'-function via webinterface as shown in my first screenshot. (iam aware that this trigger in fact an api-call in background, but webinterface was what I used).

This triggered only a schedule vpc.update up to now (but did not execute the update itself). Do you now, when it will be executed? Can i trigger its execution somehow?

it is executed immediately.

[DaanHoogland]

@mwaag , did you verify that the changes were not applied? It is executed immediately, but there is a no wait for the result. The confusion might be the message. The event is called VPC.UPDATE and the mech is reporting it like that. That could do with some improvement, unless you can assert that no update is executed, in which case we have another issue.

[mwaag]

@DaanHoogland Yes. In my testcase no changes were applied (as it should be). I just assumpted that this vpc.update was responsible for the source nat ip change, and i took the chance to get more understanding of what happens, if you edit a vpc this way.

To fix the client problem, we were able to re-acquire the old source-nat-ip for this vpc and assign it via edit-function. Leaving us still clueless what triggered the original change, but as the environment is functional again, i think we do not investigate this further.

Thanks for your help!