You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
AIP-216 suggests that all state transitions should be modeled as custom methods. It sustains this reasoning with "should not have side effects" which I see as a reference to starting and stopping. E.g "One should not have to update a VM instance metadata to start the VM. Instead one should call the custom method instance:start"
Custom methods should only be used when absolutely necessary as they make APIs more difficult to understand and to map to declarative actuators such as terraform, ansible, chef etc.
Balancing both of these issues, I suggest the following update: AIP-216 should say only use custom methods for state transitions that deal with true lifecycle status e.g "start, stop, pause, etc". States indicating external process recording (e.g 'approved', 'reviewed', etc) should be modeled through update.
Thoughts?
The text was updated successfully, but these errors were encountered:
AIP-216 suggests that all state transitions should be modeled as custom methods. It sustains this reasoning with "should not have side effects" which I see as a reference to starting and stopping. E.g "One should not have to update a VM instance metadata to start the VM. Instead one should call the custom method instance:start"
Custom methods should only be used when absolutely necessary as they make APIs more difficult to understand and to map to declarative actuators such as terraform, ansible, chef etc.
Balancing both of these issues, I suggest the following update:
AIP-216 should say only use custom methods for state transitions that deal with true lifecycle status e.g "start, stop, pause, etc". States indicating external process recording (e.g 'approved', 'reviewed', etc) should be modeled through update.
Thoughts?
The text was updated successfully, but these errors were encountered: