Tags: benjaminws/orca
Tags
refactor(core): Change type to Instant (spinnaker#2091) * refactor(core): Change type to Instant
fix(queue): Fix execution type based clouddriver routing (spinnaker#2089 )
feat(orca-kayenta): move canaryExecutionRequest and application to to… …p-level (spinnaker#2084)
fix(after stages): Allow for just-in-time planning of after stages This is a bridge to the 6.5.x branch of Orca where after stages are _always_ planned just in time. During deployment this can be an issue if a 6.5.x instance starts a stage (and does not plan after stages) and a 6.4.x instance tries to complete the stage (finding no before stages or tasks and no planned after stages).
fix(resize): Support both 'asgName' and 'serverGroupName' (spinnaker#… …2071) Noticed the inconsistency when investigating a recent `orca` issue. It would be nice to standardize on `serverGroupName` but we still have operations (like this one!) expecting `asgName`.
refactor(persistence): Unify Jedis/Dynomite Repos (spinnaker#2070) Having separate Jedis vs. Dynomite execution repositories posed a number of problems around live migrations in a dual repository configuration. This was partially due to the Dynomite repository using a different scheme for key names, in order to utilize Dynomite hash sets, I.e. [pipeline:abc-123, pipeline:abc-123:stageIndex] turns into [{pipeline:abc-123}, {pipeline:abc-123}:stageIndex]. To support live migrations, we need to be able to find executions in either the current or previous store regardless of type or key names. This implements that logic, as well as the ability to generate key names based on the class type of each configured RedisClientDelegate. This should enable Redis <---> Dynomite migrations in either direction.
PreviousNext