Tags: phanikumarp/orca
Tags
fix(titus): use labels as override only for titus health providers (s… …pinnaker#3221) Today, when determining health providers on Titus, we look at the labels on the source server group. For AWS, we look at front50 if the app has the platform only override set. Make Titus work similarly but allow the labels to be used as override (if they exist)
fix(pipelines): Fixed interpretation of missing startTime during inst… ( spinnaker#2820) * fix(pipelines): Fixed interpretation of missing startTime during instrumentation Fixes spinnaker/spinnaker#4244 There are conditions in which CompleteStageHandler can be called without having a startTime set. Often this is because an exception was thrown before the startTime was set, but there are various guards within StartStageHandler as well. Previously when this happened, a StartTime of 0 was used. This is particularly bad because the 40-years worth of nanoseconds that is spit out of spectator is beyond the resolution of "double" for metric stores that use double for time. This fix changes the assumption to be the end time, resulting in assuming 0 time. Not that this could possibly be a different type of issue if the underlying problem was something else, such as StartStageHandler not even being called for some reason. In addition I set the startTime at the beginning of the try block where exceptions may be thrown in order to ensure there is a startTime when going through that control flow. I think this might be messy depending on how time and state are used because it has a startTime but is not in the RUNNING state. There does not seem to be an appropriate state definition for this particular phase and am not sure the implications of adding one. I also dont know if moving the startTime so it includes this extra check has other implications. If so then the startTime could be reset where it is currently set. * defer RUNNING status until after the extra initial store. Being in the RUNNING state affected the handler guard checking for NOT_STARTED (line 71) causing it to be ignored. I dont really understand the control flow here, and could not follow along in a debugger because kotlin/mockito jumps all over the place making it impossible for me to grok that way. I suspect there is a better fix and could involve adding another status between NOT_STARTED and RUNNING but that is beyond my level of intimacy with the model here. fixed tests to accomodate the second storeStage call.
chore(core): Adding stage.toString() (spinnaker#3209) * chore(core): Adding stage.toString() - added a toString method with the stage id & execution id * - PR feedback
fix(rollback): pass authentication context and consider errors fatal This avoids a potentially dangerous scenario where we roll back to a server group of size 0 and fail to look it up for some reason, e.g. if it is in a restricted account and we fail to pass the credentials along to clouddriver.
feat(tasks): attach notifications to execution (spinnaker#3206)
fix(monitored deploy): send complete notification on failure & add sh… …rink cluster (spinnaker#3199) * fix(monitored deploy): send complete notification on failure When deploy fails we need to sent completion notification to the deployment monitor * fix(monitored deploy): add shrink cluster ability Added ability to shrink cluster at the end of deploy (same as red/black, with `maxRemainingAsgs` param)
fix(RRB & MD): pin and unpin the correct server group (spinnaker#3197) During rolling redblack (or monitored deploy), use the determined source server group to pin/unpin. This used to live in the deploy preprocessor, but the deploy preprocessor runs too early to be useful (it runs before we run determineSourceServerGroup task). This means it can pick the wrong ASG to pin! in the following scenario: ``` ASG v2 - being deployed ASG v1 - Disabled ASG v0 - Enabled ``` before this change, we would pin/unpin `v1` which is clearly wrong ASG to pin. NOTE: currently the code is duplicated in RRB and MD strategies. I will do another PR with a refactor to make them share code (it's proving harder than anticipated to make this refactor actually nice)
fix(monitored deploy): make reason singular (spinnaker#3195) there is no point having an array of reasons from deployment monitor, making it a single object
PreviousNext