Tags: sofam/clouddriver
Tags
fix(ecs): Improve debug messaging for task health (spinnaker#4431) (s… …pinnaker#4432) Co-authored-by: allisaurus <34254888+allisaurus@users.noreply.github.com>
fix(ecs): Improve debug messaging for task health (spinnaker#4431) (s… …pinnaker#4433) Co-authored-by: allisaurus <34254888+allisaurus@users.noreply.github.com>
fix(aws): fix more extraAttributes renaming spots that were missed (s… …pinnaker#4401) (spinnaker#4403) Co-authored-by: Cameron Fieber <cfieber@netflix.com>
fix(repository): Enforce serialization order for JedisTask (spinnaker… …#4394) (spinnaker#4397) * test(repository): Add tests to JedisTask Before making a minor change to JedisTask, add some tests of the serialization logic. * fix(repository): Enforce serialization order for JedisTask There have been a number of end-to-end test failures recently due to race conditions where orca fetches a task status from clouddriver and receives a status of complete, but incomplete task results. The fields of the task are computed on-demand by querying the repository. This means that the serialized task may not be internally consistent; each field will reflect the state of the task in the repository at the time that field's accessor was called during serialization. This is in general a difficult problem to solve with redis, which does not support atomic reads of multiple keys, but has been solved in the SQL repository by fetching all data in a single query. As a workaround, we'll instruct Jackson to serialize the status first. The reason is that consumers tend to use the status field to check if a task is complete, and expect the other fields to be filled out if it is. If there is an inconsistency between the status and other fields, we'd rather return a stale value in the status field than in other fields. In general, returning an older status (ie, still running) and newer other fields will just cause clients to poll again until they see the updated status. Returning a newer status (ie, completed or failed) but stale values in other fields will in general cause clients to use these stale values, leading to bugs. * test(repository): Add comment to explain test rationale Co-Authored-By: Michael Plump <plumpy@gmail.com> Co-authored-by: Michael Plump <plumpy@gmail.com> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com> Co-authored-by: Eric Zimanyi <ezimanyi@google.com> Co-authored-by: Michael Plump <plumpy@gmail.com> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
fix(repository): Enforce serialization order for JedisTask (spinnaker… …#4394) (spinnaker#4398) * test(repository): Add tests to JedisTask Before making a minor change to JedisTask, add some tests of the serialization logic. * fix(repository): Enforce serialization order for JedisTask There have been a number of end-to-end test failures recently due to race conditions where orca fetches a task status from clouddriver and receives a status of complete, but incomplete task results. The fields of the task are computed on-demand by querying the repository. This means that the serialized task may not be internally consistent; each field will reflect the state of the task in the repository at the time that field's accessor was called during serialization. This is in general a difficult problem to solve with redis, which does not support atomic reads of multiple keys, but has been solved in the SQL repository by fetching all data in a single query. As a workaround, we'll instruct Jackson to serialize the status first. The reason is that consumers tend to use the status field to check if a task is complete, and expect the other fields to be filled out if it is. If there is an inconsistency between the status and other fields, we'd rather return a stale value in the status field than in other fields. In general, returning an older status (ie, still running) and newer other fields will just cause clients to poll again until they see the updated status. Returning a newer status (ie, completed or failed) but stale values in other fields will in general cause clients to use these stale values, leading to bugs. * test(repository): Add comment to explain test rationale Co-Authored-By: Michael Plump <plumpy@gmail.com> Co-authored-by: Michael Plump <plumpy@gmail.com> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com> Co-authored-by: Eric Zimanyi <ezimanyi@google.com> Co-authored-by: Michael Plump <plumpy@gmail.com> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>