Tags: dvropsmx/clouddriver
Tags
fix(ha): Fix deploying RO clouddriver with Halyard (spinnaker#4567) (s… …pinnaker#4568) My recent change to push the -ro config for clouddriver down to the base config breaks deploying RO clouddriver with Halyard because it sets the redis endpoint to redisRo.baseUrl, which is not set by Halyard. This should default to redis.baseUrl to handle this case. (cherry picked from commit b5fc7d8) Co-authored-by: Eric Zimanyi <ezimanyi@google.com>
fix(provider/cf): Ensure up-to-date data in server group caching agen… …t and force cache (bp spinnaker#4560) (spinnaker#4561)
fix(provider/cf): Ensure up-to-date data in server group caching agen… …t and force cache (spinnaker#4560) (spinnaker#4562) (cherry picked from commit 359411f) Co-authored-by: Nicolas Cohen <ncknt@users.noreply.github.com>
refactor(google): Convert GoogleCommonSafeRetry to java (spinnaker#4538) * refactor(google): Convert GoogleCommonSafeRetry to java In addition to converting this to Java, this commit also allows updates the bare types to be generic, so that the methods return something more strongly-typed than an object, which is very useful for strongly-typing any downstream code without casts. It also updates the class to no longer be a superclass of the places that use it; it instead encapsulates its logic and consumers can create one and store it as an instance variable. As part of this change, instead of having consumers inject in an exception factory, this class just throws a GoogleAPIException, which consumers can then wrap as they see fit. (I came across this while fixing a bug in front50 that uses this, unfortunately by importing clouddriver as a library, and was unable to do so in a typesafe way without this change.) This class is pretty robustly tested, as the GCE and appengine operations all run through this class and often assert that the right type of exception is thrown (in addition to the tests directly on this class). For example, when I had a bug in the ResourceInUseException code, it was caught by a GCE test. There are two changes to the tests on this class that are worth noting: * In one case, the exception type is changed from IllegalStateException to GoogleAPIException. This was just because the tests was using IllegalStateException in its factory. * In another case we've changed from returning GoogleJsonResponseException to a GoogleAPIException. I'm fairly certain this was originally a bug as we were incorrectly throwing that exception instead of storing it and processing it through the logic to decide what to return. From reading the places this function is called, it doesn't look like we are catching a GoogleJsonResponseException anywhere so I don't think this should affect any consumers. Finally, the isRetryable method has not been used in ~2 years; at some point a refactor removed the call to it (and its logic to retry all 5xx errors). As I don't want to re-introduce that now without a reason, I just removed the function and its tests. * refactor(appengine): Remove success field from appengine Ideally the retry logic would not accept a list of statuses to consider success, as this means that we need it to be nullable because if we get one of those statuses we need to return but don't have anything to return. (This might be more resonable if we had separate calls for operations that returned a value and operations that didn't; in that case the ones that don't return a value could more reasonably accept this parameter.) As this isn't actually used anywhere in appengine, let's just delete it to clean up the code a bit. * style(clouddriver): Address PR review comments Co-Authored-By: Maggie Neterval <mneterval@google.com> Co-Authored-By: Michael Plump <plumpy@gmail.com> * refactor(google): Move GoogleAPIException to top level Particularly as this starts having subclasses for particular exception types, it makes sense for it to be at the top level, not nested in the GoogleCommonSafeRetry. * refactor(google): Clean up handling of error details The fromGoogleJsonException method was doing two things: (1) parsing out the details on the exception to figure out what we know about it (2) deciding what type of GoogleApiException to throw This was alredy a bit complicated but I'm about to add another subclass of GoogleApiException so things are going to get out of hand if we don't fix it. Create and ErrorDetails private class that figures out what we know about an exception and puts it in a standard format, then let fromGoogleJsonException base its decision on this class. * refactor(google): Return NotFoundException from API calls The code in front50 that uses GoogleCommonSafeRetry was relying on getting back the raw GoogleJSONResposeException, but only because it was digging into the exception to figure out if it was a 404 to respond differently. Let's instead encapsulate this and return a GoogleApiException.NotFoundException in this case so we can catch that. * refactor(google): Make GoogleApiException checked This might be controversial, and definitely interested in feedback on this one, but the expectation at this point is that all callers are catching this and wrapping it in something that describes what they were doing when the exception happened. Because we're expecting them to catch it, having this be a checked exception actually makes it easier to ensure we didn't miss a place...but I also could see the point that there's not much you can do about this beyond wrap it so maybe it shouldn't be checked. * fix(google): Fix null-safety bug We should guarantee in the constructor that we always set non-null values for the strings. Co-authored-by: Maggie Neterval <mneterval@google.com> Co-authored-by: Michael Plump <plumpy@gmail.com>
fix(aws): Resolve BasicAmazonDeployDescription NPE when returning nam… …es of loadBalancers, targetGroups, and securityGroupNames (spinnaker#4537)
fix(plugins): add an option for strict plugin loading (spinnaker#4485)
fix(saga): Remove import of EventSourceAutoConfiguration on SagaAutoC… …onfiguration (spinnaker#4477)
chore(dependencies): Autobump korkVersion (spinnaker#4474) Co-authored-by: runner <runner@fv-az51.internal.cloudapp.net>
fix(core): Only log relevant details of description (spinnaker#4456) (s… …pinnaker#4457) When we encounter a description that should have application restrictions but doesn't, we log a warning including the full description JSON. In some cases (ex: Kubernetes) this description may contain sensitive information that ideally wouldn't be logged. Ideally really sensitive values would come from artifacts so they aren't in the pipeline JSON at all, but let's nonetheless cut back on how much we are logging here to reduce the chance of sensitive information ending up in the logs. In particular, it's not clear how much the full description would help in debugging, as generally what is important is the class of the description (to check whether it implements ApplicationNameable or ResourcesNameable) and and the account, both of which will still be logged after this change. Co-authored-by: Eric Zimanyi <ezimanyi@google.com>
fix(core): Only log relevant details of description (spinnaker#4456) (s… …pinnaker#4458) When we encounter a description that should have application restrictions but doesn't, we log a warning including the full description JSON. In some cases (ex: Kubernetes) this description may contain sensitive information that ideally wouldn't be logged. Ideally really sensitive values would come from artifacts so they aren't in the pipeline JSON at all, but let's nonetheless cut back on how much we are logging here to reduce the chance of sensitive information ending up in the logs. In particular, it's not clear how much the full description would help in debugging, as generally what is important is the class of the description (to check whether it implements ApplicationNameable or ResourcesNameable) and and the account, both of which will still be logged after this change. Co-authored-by: Eric Zimanyi <ezimanyi@google.com>
PreviousNext