seaneagan

Changelog

Enhancements:

• #387 [CI] Add a non-voting job to zuul, that would check if the commit is linked to github issue
• #383 Enable airship-airshipctl-gate-script-runner during gating process
• #380 Add support for custom kubeconfig contexts for clusters
• #376 Add clusterapi name and namespaces to clustermap
• #373 CI: Replace deprecated GitHub authentication method

seaneagan

Title: Armada: Store manifest application metadata

Description: In order for armada to know about manifest applications it has completed. it must store this somewhere, likely in kubernetes ConfigMaps or CRDs.

Acceptance Criteria:

• Ability to retrieve the helm release names/versions from the last application of a manifest with a given metadata.name. Potentially also from previous applications, and the armada manifest/sub-documents and start/end timestamps of the applications. An actual armada API however may come in a later story.

Custom Resource Definitions

seaneagan

Armada: Analysis of helm upgrade/rollback --force/--recreate-pods

What do the flags do

Both rollback and upgrade are moving to a different version of the release, just old vs new, so these flags have same behavior for both rollback and upgrade.

--force

Does 2 things:

seaneagan

# Copyright 2018 The OpenStack-Helm Authors.
#
# 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
# distributed under the License is distributed on an "AS IS" BASIS,

seaneagan

def apply_chart(wait, wait_timeout, test, max_test_tries, test_timeout, test_interval):
  success = False
  if wait:
    helm install/upgrade --wait --timeout <wait_timeout> ...
    success = <succeeded?>
  else:
    helm install/upgrade ...

  if test:
    test_tries := 0

seaneagan

The main utility of chart groups seems to be specifying the order in which to install/upgrade/delete charts.  Armada chart configs already allow specifying dependencies.  The only thing that should really matter about the order is that dependencies are installed/upgraded before dependents, and the reverse for a delete.  Thus it should be possible to topologically sort the dependency graph to determine this order, with some tie breaker e.g. alphabitical order by chart or release name.  This chart order could then be further segmented into (unsequenced) chart groups whose members have no dependencies on each other, and thus whose charts can potentially be installed/upgrade/deleted in parallel.

This could all be exposed in a backward compatible way via a new "auto" value for the "chart_groups" key in the armada manifest, or by defaulting to this when "chart_groups" is omitted.

seaneagan

Analysis: Replacing Armada gRPC calls with helm cli calls

Aramda gRPC usage by command

Most commands are in armada CLI and API, and behave similarly.

apply

seaneagan

FROM ubuntu:16.04
RUN apt-get update && apt-get install -y \
        curl
RUN curl -Lo /usr/local/bin/kubernetes-entrypoint https://raw.githubusercontent.com/seaneagan/kubernetes-entrypoint/pod_dependencies/kubernetes-entrypoint \
  && chmod 755 /usr/local/bin/kubernetes-entrypoint
CMD /usr/local/bin/kubernetes-entrypoint

seaneagan

/// See http://dartbug.com/22036
library has_permission;

import 'dart:io';

enum FilePermission { READ, WRITE, EXECUTE, SET_UID, SET_GID, STICKY }
enum FilePermissionRole { WORLD, GROUP, USER }

bool hasPermission(FileStat stat, FilePermission permission, {FilePermissionRole role: FilePermissionRole.WORLD}) {

seaneagan

import 'package:yaml/yaml.dart';

main() {
  var node = loadYamlNode(yaml);
  var actualFooEnd = node.nodes['c'].nodes['x'].span.end.offset;
  var expectedFooEnd = yaml.indexOf('foo') + 'foo'.length;
  print('actual foo end: $actualFooEnd');
  print('expected foo end: $expectedFooEnd');
  assert(actualFooEnd == expectedFooEnd);
}