robzienert

package com.netflix.temporal.config

import com.fasterxml.jackson.databind.ObjectMapper
import com.netflix.grpc.metatron.NettyMetatronSslContext
import com.netflix.temporal.config.customizers.WorkerFactoryOptionsCustomizer
import com.netflix.temporal.config.customizers.WorkflowClientOptionsCustomizer
import com.netflix.temporal.config.customizers.WorkflowServiceStubsOptionsCustomizer
import com.netflix.temporal.core.WorkerFactoryVisitor
import com.netflix.temporal.spring.ClusterAwareWorkflowClient
import com.netflix.temporal.spring.ClusterAwareWorkflowServiceStubs

robzienert

Our current Temporal dashboards, which uses Atlas Stack Language and Lumen.

There are two dashboards here:

1. temporal-dash.json is our Temporal service dashboard. Each Temporal service is broken down into its own section with its own views.
2. temporal-service-client.json is a reusable component that Temporal workers can include in their application dashboards which gives insight into the SDK.
3. temporal-service-go.json reusable component for the Temporal services themselves to expose Go metrics.
4. temporal-internal-client.json reusable component for each Temporal service's clients to other Temporal services. Just an overview.

robzienert

/*
 * Copyright 2021 Netflix, Inc.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *    http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software

robzienert

standardized app config schema

# following convention of how Spring has nested everything under "spring", we should look to do the same.
spring: ...

spinnaker:
  common: ...
  kork:
 storage:

robzienert

interface JenkinsServiceFactory {
  fun build(jenkinsHostId: String, 
            jenkinsClient: JenkinsClient, 
            csrf: Boolean): JenkinsService
}

interface JenkinsClientFactory {
  fun build(): JenkinsClient
}

robzienert

@Component
class AbortStageHandler(
  override val queue: Queue,
  override val eventRepository: ExecutionEventRepository,
  @Qualifier("queueEventPublisher") private val publisher: ApplicationEventPublisher,
  private val clock: Clock
) : OrcaMessageHandler<AbortStage> {

  override fun handle(message: AbortStage) {
    message.withStage { stage ->

robzienert

kind: NetworkInterface
spec:
  name: "helloworld"
  securityGroups: []
  # ... Stuff

# Displays allowed use of SpEL; in this case NetworkInterface allows an iterable spec interface.
# `${ loop.count }` and other loop vars are made available automatically by `IterableSpec`
# `NetworkInterfacePoolSpec : NetworkInterfaceSpec, IterableSpec<NetworkInterfaceSpec>`. The

robzienert

local s = import "v1.jsonnetlib";
local spinnakerTeam = import "spinnaker://spinnakerTeam.jsonnetlib";
local spin = s.intent.SpinnakerFileType;
local application = s.intent.ApplicationType;
local pipeline = s.intent.PipelineType;
local notification = s.intent.NotificationType;
local cluster = s.intent.ClusterType;
local promotion = s.intent.PromotionWorkflowType;
local securityGroup = s.intent.aws.AwsSecurityGroupType;
local loadBalancer = s.intent.aws.AwsClassicLoadBalancerType;

robzienert

{
  "pipelines": []
}

robzienert

DCD

Spinnaker File

A few different concepts I've been kicking around.

Plugin, YAML manifest

I really like the flexibility and terseness of this one. As far as structure of the spec goes, it's really simple and defers almost all of its meat and potatoes