att-comdev/armada

This project has moved to OpenStack.

Armada

Armada is a tool for managing multiple Helm charts with dependencies by centralizing all configurations in a single Armada YAML and providing life-cycle hooks for all Helm releases.

Find more documentation for Armada on Read The Docs.

Overview

The Armada Python library and command line tool provide a way to synchronize a Helm (Tiller) target with an operator's intended state, consisting of several charts, dependencies, and overrides using a single file or directory with a collection of files. This allows operators to define many charts, potentially with different namespaces for those releases, and their overrides in a central place. With a single command, deploy and/or upgrade them where applicable.

Armada also supports fetching Helm chart source and then building charts from source from various local and remote locations, such as Git endpoints, tarballs or local directories.

It will also give the operator some indication of what is about to change by assisting with diffs for both values, values overrides, and actual template changes.

Its functionality extends beyond Helm, assisting in interacting with Kubernetes directly to perform basic pre- and post-steps, such as removing completed or failed jobs, running backup jobs, blocking on chart readiness, or deleting resources that do not support upgrades. However, primarily, it is an interface to support orchestrating Helm.

Components

Armada consists of two separate but complementary components:

1. CLI component (mandatory) which interfaces directly with Tiller.
2. API component (optional) which services user requests through a wsgi server (which in turn communicates with the Tiller server) and provides the following additional functionality:
   • Role-Based Access Control.
   • Limiting projects to specific Tiller functionality by leveraging project-scoping provided by Keystone.

Roadmap

Detailed roadmap can be viewed here.

Issues can be reported on GitHub.

Installation

Quick Start (via Container)

Armada can be most easily installed as a container, which requires Docker to be executed. To install Docker, please reference the following install guide.

Afterward, you can launch the Armada container by executing:

$ sudo docker run -d --net host -p 8000:8000 --name armada \
    -v ~/.kube/config:/armada/.kube/config \
    -v $(pwd)/examples/:/examples quay.io/attcomdev/armada:latest

Manual Installation

For a comprehensive manual installation guide, please see Manual Install Guide.

Usage

To run Armada, simply supply it with your YAML-based intention for any number of charts:

$ armada apply examples/openstack-helm.yaml [ --debug ]

Which should output something like this:

$ armada apply examples/openstack-helm.yaml 2017-02-10 09:42:36,753

  armada INFO Cloning git:
  ...

For more information on how to install and use Armada, please reference: Armada Quickstart.

Integration Points

Armada CLI component has the following integration points:

• Tiller manages Armada chart installations.
• Deckhand supplies storage and management of site designs and secrets.

In addition, Armada's API component has the following integration points:

• Keystone (OpenStack's identity service) provides authentication and support for role-based authorization.

Further Reading

Undercloud Platform (UCP).

armada's Issues

feat: api - improve endpoint definitions

Is this a bug report or feature request? (choose one): feat

Python Version (output of python --version): 2.7

Development or Deployment Environment?:

Release Tag or Master:

Expected Behavior:

What Actually Happened:

How to Reproduce the Issue (as minimally as possible):

Any Additional Comments:

improve the api

feat: logging - imporve format and methond to log armada

Is this a bug report or feature request? (choose one): feat

Python Version (output of python --version): 2.7

The logging for the armada tool needs to be better structure and configurable via a logging.cfg

• if logging file not present default the loggging
• if logging is present, then override the logging format as provided
• we need to make sure that logging can be displayed via docker logs
• provide proper levels of logging

feat: configure - manage Armada via a configuration file

As our settings grow we want to make user that we manage these via a armada.conf file.

Things to manage:

• ssh key path
• logs
• kubernetes config path

docs: detailed workflow document

Armada should have a document that provides a thorough description of how it executes a deployment. This document (or maybe a different document) should also have a detailed, non-trivial YAML and walk the reader through the end-to-end workflow of a deployment and upgrade.

Feat: Values - Add support for yaml path

Is this a bug report or feature request? (choose one): feature

Python Version (output of python --version): 2.7

Development or Deployment Environment?:

Release Tag or Master:

Expected Behavior:

What Actually Happened:

How to Reproduce the Issue (as minimally as possible):

Any Additional Comments: We would like to support values that are able to accept a path to a yaml file that can be used to override chart values.

feat: cmd - check status of tiller services

As a user before i run my armada -c i want to make sure that the tiller services running.

armada --tiller-status

• cmd that uses k8s lib to get tiller state

feat: chartbuilder - clone repos via branches define in yaml

in the git section of the armada yaml we want to be able to clone not only master, but any branch specified git section in the yaml.

Tiller Pod Missing causes Unhandled Exception

Using the armada:latest container, if tiller is not running at all, the following exception results:

root@csolabAIC-80:~/demo# ./armada_push.sh base.yaml --debug
2017-06-17 15:59:05.372 1 ERROR armada [-] 'NoneType' object has no attribute 'status': AttributeError: 'NoneType' object has no attribute 'status'
2017-06-17 15:59:05.372 1 ERROR armada Traceback (most recent call last):
2017-06-17 15:59:05.372 1 ERROR armada   File "/usr/local/lib/python2.7/dist-packages/cliff/app.py", line 400, in run_subcommand
2017-06-17 15:59:05.372 1 ERROR armada     result = cmd.run(parsed_args)
2017-06-17 15:59:05.372 1 ERROR armada   File "/usr/local/lib/python2.7/dist-packages/cliff/command.py", line 97, in run
2017-06-17 15:59:05.372 1 ERROR armada     return self.take_action(parsed_args) or 0
2017-06-17 15:59:05.372 1 ERROR armada   File "/root/armada/armada/cli/apply.py", line 53, in take_action
2017-06-17 15:59:05.372 1 ERROR armada     applyCharts(parsed_args)
2017-06-17 15:59:05.372 1 ERROR armada   File "/root/armada/armada/cli/apply.py", line 30, in applyCharts
2017-06-17 15:59:05.372 1 ERROR armada     args.dry_run)
2017-06-17 15:59:05.372 1 ERROR armada   File "/root/armada/armada/handlers/armada.py", line 60, in __init__
2017-06-17 15:59:05.372 1 ERROR armada     self.tiller = Tiller()
2017-06-17 15:59:05.372 1 ERROR armada   File "/root/armada/armada/handlers/tiller.py", line 51, in __init__
2017-06-17 15:59:05.372 1 ERROR armada     self.channel = self.get_channel()
2017-06-17 15:59:05.372 1 ERROR armada   File "/root/armada/armada/handlers/tiller.py", line 69, in get_channel
2017-06-17 15:59:05.372 1 ERROR armada     tiller_ip = self._get_tiller_ip()
2017-06-17 15:59:05.372 1 ERROR armada   File "/root/armada/armada/handlers/tiller.py", line 88, in _get_tiller_ip
2017-06-17 15:59:05.372 1 ERROR armada     return pod.status.pod_ip
2017-06-17 15:59:05.372 1 ERROR armada AttributeError: 'NoneType' object has no attribute 'status'
2017-06-17 15:59:05.372 1 ERROR armada
2017-06-17 15:59:05.375 1 CRITICAL armada [-] Unhandled error: AttributeError: 'NoneType' object has no attribute 'status'
2017-06-17 15:59:05.375 1 ERROR armada Traceback (most recent call last):
2017-06-17 15:59:05.375 1 ERROR armada   File "/usr/local/bin/armada", line 10, in <module>
2017-06-17 15:59:05.375 1 ERROR armada     sys.exit(main())
2017-06-17 15:59:05.375 1 ERROR armada   File "/root/armada/armada/shell.py", line 43, in main
2017-06-17 15:59:05.375 1 ERROR armada     return ArmadaApp().run(argv)
2017-06-17 15:59:05.375 1 ERROR armada   File "/usr/local/lib/python2.7/dist-packages/cliff/app.py", line 279, in run
2017-06-17 15:59:05.375 1 ERROR armada     result = self.run_subcommand(remainder)
2017-06-17 15:59:05.375 1 ERROR armada   File "/usr/local/lib/python2.7/dist-packages/cliff/app.py", line 400, in run_subcommand
2017-06-17 15:59:05.375 1 ERROR armada     result = cmd.run(parsed_args)
2017-06-17 15:59:05.375 1 ERROR armada   File "/usr/local/lib/python2.7/dist-packages/cliff/command.py", line 97, in run
2017-06-17 15:59:05.375 1 ERROR armada     return self.take_action(parsed_args) or 0
2017-06-17 15:59:05.375 1 ERROR armada   File "/root/armada/armada/cli/apply.py", line 53, in take_action
2017-06-17 15:59:05.375 1 ERROR armada     applyCharts(parsed_args)
2017-06-17 15:59:05.375 1 ERROR armada   File "/root/armada/armada/cli/apply.py", line 30, in applyCharts
2017-06-17 15:59:05.375 1 ERROR armada     args.dry_run)
2017-06-17 15:59:05.375 1 ERROR armada   File "/root/armada/armada/handlers/armada.py", line 60, in __init__
2017-06-17 15:59:05.375 1 ERROR armada     self.tiller = Tiller()
2017-06-17 15:59:05.375 1 ERROR armada   File "/root/armada/armada/handlers/tiller.py", line 51, in __init__
2017-06-17 15:59:05.375 1 ERROR armada     self.channel = self.get_channel()
2017-06-17 15:59:05.375 1 ERROR armada   File "/root/armada/armada/handlers/tiller.py", line 69, in get_channel
2017-06-17 15:59:05.375 1 ERROR armada     tiller_ip = self._get_tiller_ip()
2017-06-17 15:59:05.375 1 ERROR armada   File "/root/armada/armada/handlers/tiller.py", line 88, in _get_tiller_ip
2017-06-17 15:59:05.375 1 ERROR armada     return pod.status.pod_ip
2017-06-17 15:59:05.375 1 ERROR armada AttributeError: 'NoneType' object has no attribute 'status'
2017-06-17 15:59:05.375 1 ERROR armada

feat: framework - using a cmd library/framework to handle app execution

As developers, i want use libraries like cliff, click, ect. This will allow for a standardization of how to create future command and will help improve flag handling.

feat: oslo_config: add tiller version into config

Is this a bug report or feature request? (choose one): feat

Python Version (output of python --version): 3.5

As we update the various tiller version we define the tiller version on the armada/handler/tiller.py. We should store the Tiller version in the armada/config/default.py to be sure to use the correct version executing the GRPC call.

feat: create armada docker container for stability

Python Version (output of python --version): N/A

Development or Deployment Environment?: N/A

Release Tag or Master: N/A

Expected Behavior: N/A

What Actually Happened: N/A

How to Reproduce the Issue (as minimally as possible): N/A

Any Additional Comments: N/A

This is a feature:
I want a Dockerfile/image for Armada that can be referenced in documentation. I also want to find a reason for not just using this stable container, as I personally have run into a lot of issues running Armada directly on various hosts (OSX and Ubuntu 16.10). Maybe this is the only way to run Armada, but if that is our goal we need to test it thoroughly.

• create an Armada Docker container based on Ubuntu 16.04
• test functionality
• document in the Armada readme

bug: fix linting issues for pep8 complient

Is this a bug report or feature request? (choose one): bug

Python Version (output of python --version): 2.7

Development or Deployment Environment?: virtualenv

Release Tag or Master: master

Expected Behavior:
Expect to be pep8 compliant

What Actually Happened:
we are failing linting test

How to Reproduce the Issue (as minimally as possible):

1. pip install -r test-requirements.txt
2. flake8

Any Additional Comments:

feat: travisci - updated job to use bash file

In the .travis.yaml we are currently executing the libgit install in the yaml. We should be using the bash file to libgit in the ./tools/

• remove libgit install in .travis.yaml
• execute the bash file under tools tools

feat: wait - deploy charts and watch them complete

Armada when it receives this flag will only complete when containers will be in a running state.

It will no longer be the default behavior of deploy and forget when the flag is provided.

This will be in the api and the cli.

(support --block-timeout=X)

bug: osx - logutil does not register /dev/log

Is this a bug report or feature request? (choose one):

Python Version (output of python --version): 2.7.13

Development or Deployment Environment?: Development

Release Tag or Master: master

Expected Behavior:
Logging should not throw exception of due to dir

What Actually Happened:
when we instantiate our sysloghandler, the address passed /dev/log does not exist in osx.

How to Reproduce the Issue (as minimally as possible):

1. install armada in osx
2. run armada -c file.yaml

Any Additional Comments:
The logging piece needs a conditional to handle the various systems. switching the value to /var/run/syslog seems to fix the issue with osx.

bug: missing return or pass

Is this a bug report or feature request? (choose one): bug

Python Version (output of python --version): 2.7

Development or Deployment Environment?: virtualenv

Release Tag or Master: master

Expected Behavior:

• return or pass at the end
  -or-
• remove function

What Actually Happened:
missing return/pass keyword

How to Reproduce the Issue (as minimally as possible):

1. go to https://github.com/att-comdev/armada/blob/master/armada/tiller.py#L96

Any Additional Comments:

feat: dependecies - wait dep chats to be complete

Is this a bug report or feature request? (choose one): feat

Python Version (output of python --version): 2.7

Development or Deployment Environment?:

Release Tag or Master:

Expected Behavior:

any chart that is deployed make sure that we wait until deps are finished before we continue

What Actually Happened:

How to Reproduce the Issue (as minimally as possible):

Any Additional Comments:

• charts:
  • description: lil group of charts (1)
    sequenced: true
    chart_block: [.... looks like what we have today...]
  • description: another lil group of charts (1)
    Sequenced: false
    chart_block: [....openstack-helm stuff...]

feat: upgarde - upgrading tiller releases

we want to be able to upgrade armada deployed services.

Issues with pointing armada at a YAML with changes will function correctly and it will intelligently upgrade where necessary and install where necessary. It will not upgrade if there not any actual changes.

• if update has no diff then don't release

Missing pre field exception lacking detail

When using a manifest missing the pre field entirely (and presumably post), the error message to the user is not intuitive. Presumably this (and other YAML validation) could be caught pre-flight, before processing the charts.

Also, can't these be optional? I may have upgrade options to pass to tiller but no request for pre and post k8s actions.

# armada apply mitaka.yaml 
06-16 14:29 armada.handlers.armada INFO     Performing Checking Pre Flight Tasks
06-16 14:29 armada.handlers.chartbuilder INFO     Building dependency chart helm-toolkit for release mariadb
06-16 14:29 armada.handlers.armada INFO     Upgrading release mariadb
06-16 14:29 armada       ERROR    'pre'

feat: delete - charts provided in an armada yaml

As we can deploy multiple charts at once, we should be able to mark charts for delete or delete all charts in the yaml.

Functionality will delete charts that are no longer in the Release. They will not be in the armada yaml. Armada should identify the chart that is missing from the declaration, and remove it.

feat: add option to wait for chart groups

Is this a bug report or feature request? (choose one): feature

It would be useful to be able to wait for groups of charts now that they are available. This would be faster in cases where it is safe to spin up several charts at once that must be collectively ready before another group is deployed, but do not depend on one another directly.

This is related to #74

bug: delete - after job deletion also delete respective pods

When armada deletes jobs as part of the upgrade workflow, depending on when the job is deleted, pods which were created by Kubernetes to fulfill the job can be left behind -- the usual case for this is rapidly running armada right after a large run which creates many releases. If the second run triggers lots of upgrade workflow while many jobs are still in flight, job pods will get left behind (even though the jobs themselves are gone). This results in essentially duplicate jobs.

The correct behavior should be to augment the cleanup to also find all pods with the label (in the target namespace), for example:

job-name=nova-db-init

from the following describe:

$ kubectl describe pods/nova-db-init-6nzvj  -n openstack
Name:		nova-db-init-6nzvj
Namespace:	openstack
Node:		clcp-demo-2/
Labels:		controller-uid=82afdb8f-52ac-11e7-9768-5c838fe14e68
		**job-name=nova-db-init**
...

and delete those as well.

Armada does not process non-template files as part of chart upload

This relates to #13 as well as it should respect .helmignore.

Per https://github.com/att-comdev/armada/blob/master/armada/handlers/chartbuilder.py#L123-L129 this functionality is TBD. This is required as many charts leverage Files.Get, Files.* and these do not function properly as the files are not uploaded (since they are not technically templates).

feat: services - execute armada lib via API calls

We want to make armada a tool that will be able to apply armada.yaml via a REST api calls
using a lightweight REST api pecan, web.py, flask

• version API calls
• set of API's to deploy, update, etc

*needs to be better defined

docs: update any common chart reference to helm-toolkit

Making sure that all any documentation does not use common chart, it was deprecated in earlier versions of OSH

bug: requirements -missing-requests-dep

Is this a bug report or feature request? (choose one): bug

Python Version (output of python --version): 2.7

Development or Deployment Environment?: development

Release Tag or Master: master

Expected Behavior: armada should deploy charts

What Actually Happened: ImportError: no module named Requests
Requests is missing from requirements.txt

How to Reproduce the Issue (as minimally as possible):

Any Additional Comments:

ci: add Travis-CI to armada repo

add simple CI and potential unit test to this repo:

• add .travis.yml to the repo
• use instructions included in main README.md to get unit test/gating in place

@gardlt is this something you would want to pick up? seems to be right in your wheelhouse. if so...i can assign it to you.

feat: docs - generate github pages via sphinx generated pages

As our documention will grow I want to be able to generate sphinx pages and push them into the gh-pages branch.

feat: add new repo items

we need the following items included in this repo:

• OWNERS
• templates for issues/pull requests

we want to get this repo in line with openstack-helm and the other repositories for consistency. @gardlt this one too?

feat: apply - exectue armada yaml via a URL

Is this a bug report or feature request? (choose one): feat

Python Version (output of python --version): 2.7

Release Tag or Master: master

Expected Behavior:
We would like to deploy armada manifest from a https request that holds the armada manifest. we should also be able to execute the armada manifest via the local path.

AC:

• armada apply FILE | URL

feat: bootstrap tiller with host network

Is this a bug report or feature request? (choose one): feature request

I would like to use Armada to bootstrap and manage tiller. This means writing a tiller chart, which controls a deployment and service account/RBAC credentials for tiller.

Additionally, since I would like to manage CNI via a chart, I would like the ability to create the initial tiller pod with host networking mode. Smooth bootstrap will probably require faking the pod spec hash label/annotation that kubernetes applies to deployment managed pods.

feat: pre/post - actions to improve/secure lifecycle

ARMADA should be able to support arbitrary action inside k8s as part of the workflow (delete/etc)
Pre/post requirements during the chart deployment life cycle, This is not implemented

install:
         no_hooks: false
        upgrade:
          no_hooks: false
          pre:
            delete:
                   - name: keystone-db-sync
                      type: 'job'
                   - name: keystone-db-init
                      type: 'job'

bug: Cannot communicate with Minikube SSL endpoint

Is this a bug report or feature request? (choose one):

Python Version (output of python --version): 2.7.9

Development or Deployment Environment?: MacOS

Release Tag or Master: Master

Expected Behavior: Armada works per README.md

What Actually Happened: Exception when using Minikube

How to Reproduce the Issue (as minimally as possible):

Follow README.md. Several steps such as installing required libraries via brew are missing.

Finally, when using Minikube, which is not necessarily MacOS specific but typical for these users, the following exception occurs (because of SSL issues with the Minikube API endpoint):

$ ~/armada-env/bin/armada -c ~/Workbench/att/armada/examples/armada.yaml
2017-02-27 07:46:40,659 ERROR Certificate did not match expected hostname: 192.168.99.100. Certificate: {'subjectAltName': (('DNS', 'kubernetes.default.svc.cluster.local'), ('DNS', 'kubernetes.default.svc'), ('DNS', 'kubernetes.default'), ('DNS', 'kubernetes'), ('IP Address', '192.168.99.100'), ('IP Address', '10.0.0.1')), 'notBefore': u'Feb 20 13:34:13 2017 GMT', 'serialNumber': u'02', 'notAfter': 'Feb 20 13:34:13 2018 GMT', 'version': 3L, 'subject': ((('commonName', u'minikube'),),), 'issuer': ((('commonName', u'minikubeCA'),),)}
2017-02-27 07:46:40,659 urllib3.connection ERROR    Certificate did not match expected hostname: 192.168.99.100. Certificate: {'subjectAltName': (('DNS', 'kubernetes.default.svc.cluster.local'), ('DNS', 'kubernetes.default.svc'), ('DNS', 'kubernetes.default'), ('DNS', 'kubernetes'), ('IP Address', '192.168.99.100'), ('IP Address', '10.0.0.1')), 'notBefore': u'Feb 20 13:34:13 2017 GMT', 'serialNumber': u'02', 'notAfter': 'Feb 20 13:34:13 2018 GMT', 'version': 3L, 'subject': ((('commonName', u'minikube'),),), 'issuer': ((('commonName', u'minikubeCA'),),)}
Traceback (most recent call last):
  File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/logging/handlers.py", line 861, in emit
    self.socket.send(msg)
error: [Errno 40] Message too long
Logged from file armada, line 42
2017-02-27 07:46:40,659 armada       ERROR    (0)
Reason: SSLError
hostname '192.168.99.100' doesn't match either of 'kubernetes.default.svc.cluster.local', 'kubernetes.default.svc', 'kubernetes.default', 'kubernetes', '192.168.99.100', '10.0.0.1'
Traceback (most recent call last):
  File "/Users/alan/armada-env/lib/python2.7/site-packages/armada-0.1.0-py2.7.egg/EGG-INFO/scripts/armada", line 39, in <module>
  File "/Users/alan/armada-env/lib/python2.7/site-packages/armada-0.1.0-py2.7.egg/EGG-INFO/scripts/armada", line 29, in run
  File "build/bdist.macosx-10.10-x86_64/egg/armada/armada.py", line 25, in __init__
    self.tiller = Tiller()
  File "build/bdist.macosx-10.10-x86_64/egg/armada/tiller.py", line 23, in __init__
    self.channel = self.get_channel()
  File "build/bdist.macosx-10.10-x86_64/egg/armada/tiller.py", line 43, in get_channel
    tiller_ip = self._get_tiller_ip()
  File "build/bdist.macosx-10.10-x86_64/egg/armada/tiller.py", line 63, in _get_tiller_ip
    pod = self._get_tiller_pod()
  File "build/bdist.macosx-10.10-x86_64/egg/armada/tiller.py", line 52, in _get_tiller_pod
    ret = self.k8s.client.list_pod_for_all_namespaces()
  File "/Users/alan/armada-env/lib/python2.7/site-packages/kubernetes/client/apis/core_v1_api.py", line 13586, in list_pod_for_all_namespaces
    (data) = self.list_pod_for_all_namespaces_with_http_info(**kwargs)
  File "/Users/alan/armada-env/lib/python2.7/site-packages/kubernetes/client/apis/core_v1_api.py", line 13679, in list_pod_for_all_namespaces_with_http_info
    collection_formats=collection_formats)
  File "/Users/alan/armada-env/lib/python2.7/site-packages/kubernetes/client/api_client.py", line 328, in call_api
    _return_http_data_only, collection_formats, _preload_content, _request_timeout)
  File "/Users/alan/armada-env/lib/python2.7/site-packages/kubernetes/client/api_client.py", line 152, in __call_api
    _request_timeout=_request_timeout)
  File "/Users/alan/armada-env/lib/python2.7/site-packages/kubernetes/client/api_client.py", line 351, in request
    headers=headers)
  File "/Users/alan/armada-env/lib/python2.7/site-packages/kubernetes/client/rest.py", line 233, in GET
    query_params=query_params)
  File "/Users/alan/armada-env/lib/python2.7/site-packages/kubernetes/client/rest.py", line 210, in request
    raise ApiException(status=0, reason=msg)
ApiException: (0)
Reason: SSLError
hostname '192.168.99.100' doesn't match either of 'kubernetes.default.svc.cluster.local', 'kubernetes.default.svc', 'kubernetes.default', 'kubernetes', '192.168.99.100', '10.0.0.1'

Any Additional Comments:

This bug report presumes the following patches are in place allowing Armada to run on MacOS (separate issue):

$ git diff
diff --git a/armada/logutil.py b/armada/logutil.py
index abe1422..e9a509e 100644
--- a/armada/logutil.py
+++ b/armada/logutil.py
@@ -11,7 +11,7 @@ LOG_DATE = '%m-%d %H:%M'
 def setup_logging(args):
     level = logging.DEBUG if args.debug else logging.INFO
     logging.basicConfig(level=level, format=LOG_FORMAT, date_fmt=LOG_DATE)
-    handler = SysLogHandler(address='/dev/log')
+    handler = SysLogHandler(address='/var/run/syslog')
     syslog_formatter = logging.Formatter('%(name)s: %(levelname)s %(message)s')
     handler.setFormatter(syslog_formatter)
-    LOG.addHandler(handler)
\ No newline at end of file
+    LOG.addHandler(handler)
diff --git a/requirements.txt b/requirements.txt
index 127ba24..43b6e7f 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -3,5 +3,5 @@ grpc
 pyyaml
 grpcio
 grpcio-tools
-kubernetes
-pygit2==0.24.0
+kubernetes==1.0.0b1
+pygit2==0.25.0

Cannot verify the existence of internal openstack-helm repo

Is this a bug report or feature request? (choose one):

Python Version (output of python --version): 2.7

Development or Deployment Environment?:

Release Tag or Master: master

Expected Behavior: Armada should be able to clone openstack components from git://git.openstack.org/openstack/openstack-helm

What Actually Happened: Armada uses the requests module to ping the repo url (with git:// replaced by http://) and checks the status code returned. This works with github but returns 404 when pinging the internal openstack-helm repo.

How to Reproduce the Issue (as minimally as possible): pass Armada a yaml with the internal openstack-helm repo as the chart source url

Any Additional Comments:
@gardlt

docs: armada - troubleshoot - guide of known or common issues with tool

With the various unexpected problems one could face, we need to create a troubleshooting.rst to cover scenarios which document some solutions/fixes/workarounds. An example is the pygit2 library.

Expect:

• in the docs sub dir create a troubleshooting.rst to cover these scenarios

Known Troubleshooting:
ALL:

• install of the google.protobuf, to where you python packages are install and make sure the google root dir has a __init__.py else python will not recognize it as a package
  OS X:
• when using the python Kubenetes lib your python ssl lib should be >=1.0.0

feat: vagrantfile -development enviroment for armada

we want to make the development for armada to be easy, and vagrant is the tool to do it. I want to use the opentack-helm vagrantfile, since it will provide a kubeadm-aio.

docs: developers getting-started guide

Python Version (output of python --version): 2.7.*

Development or Deployment Environment?: Any

Release Tag or Master: master

Expected Behavior:
We need to generate docs on how to set up the an armada environment.

• create docs dir
• create development dir with a file getting-started.rst
• add a section for development with virtualenv

feat: chartbuilder - cloning repos using ssh keys

When using armada.yamls we want to be able to use ssh-keys depending on the repos.

• allow to pass --ssh-key <path> via cmd
• if path not set default to ~/.ssh/*
• it the flag is not set and repo require keys fail safely

docs: development - remove run command from build

Is this a bug report or feature request? (choose one): bug

Python Version (output of python --version): 2.7

Development or Deployment Environment?:

Release Tag or Master:

Expected Behavior:
in doc/source/development/getting-started.rst, instructions to build images should not have run commands.

What Actually Happened:

in docs/source/development/getting-started.rst, build is structions have run command

How to Reproduce the Issue (as minimally as possible):
remove -p 8000:8000 -v ${HOME}/.kube/config:/root/.kube/config from build in docs/source/development/getting-started.rst
Any Additional Comments:

docs: update any common to helm-toolkit

Is this a bug report or feature request? (choose one): bug

Python Version (output of python --version): 2.7.*

Development or Deployment Environment?:

Release Tag or Master: master

Expected Behavior:

Any reference to the common helm chart is replaced to with helm-toolkit

What Actually Happened:
There are some references to a still to an non-existing chart common.

How to Reproduce the Issue (as minimally as possible):

Any Additional Comments:

[Feat] Cmd - Implement Openstack Cookiecutter

Is this a bug report or feature request? (choose one): feature

Python Version (output of python --version): 2.7

Development or Deployment Environment?: All

Release Tag or Master: 0.4

Expected Behavior: Leverage the Oslo config library alongside the cookiecutter scaffolding tool from Openstack

Any Additional Comments: @gardlt

https://github.com/openstack-dev/cookiecutter

bug: Armada cannot run on MacOS

Is this a bug report or feature request? (choose one):

Python Version (output of python --version): 2.7.9

Development or Deployment Environment?: MacOS

Release Tag or Master: master

Expected Behavior: Armada functions as per README.md

What Actually Happened: Exception

How to Reproduce the Issue (as minimally as possible):

Follow README steps.

The log mechanisms leverage /dev/log which do not exist on MacOS.

The following "hack" was necessary to get it functioning, however the proper solution needs to work for both Linux and MacOS, instead of the simple swap below.

There were also requirements.txt processing issues that behaved differently on MacOS. The pygit2 library needed to be at version 0.25 to match the libgit version on MacOS. The kubernetes version needed to be explicitly set as auto discovering the latest version--likely due to the unique version scheme of these packages--was failing for a 2.7.9 virtual environment on MacOS.

diff --git a/armada/logutil.py b/armada/logutil.py
index abe1422..e9a509e 100644
--- a/armada/logutil.py
+++ b/armada/logutil.py
@@ -11,7 +11,7 @@ LOG_DATE = '%m-%d %H:%M'
 def setup_logging(args):
     level = logging.DEBUG if args.debug else logging.INFO
     logging.basicConfig(level=level, format=LOG_FORMAT, date_fmt=LOG_DATE)
-    handler = SysLogHandler(address='/dev/log')
+    handler = SysLogHandler(address='/var/run/syslog')
     syslog_formatter = logging.Formatter('%(name)s: %(levelname)s %(message)s')
     handler.setFormatter(syslog_formatter)
-    LOG.addHandler(handler)
\ No newline at end of file
+    LOG.addHandler(handler)
diff --git a/requirements.txt b/requirements.txt
index 127ba24..43b6e7f 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -3,5 +3,5 @@ grpc
 pyyaml
 grpcio
 grpcio-tools
-kubernetes
-pygit2==0.24.0
+kubernetes==1.0.0b1
+pygit2==0.25.0

feat: determine a release schedule and roadmap for armada

Any Additional Comments:

we need to start forming a release schedule/roadmap with defined features in armada. priority one is resolving issues that prevent people from using armada. this is before any of the golang conversion should occur.

feat: deploy - tiller w/ armada cmd or api

Since armada is dependent on the tiller service, it makes sense that we should be able to deploy it.

• deploy tiller via api & cmd

docs: Milestone v0.1.0 demo

At the end of the iteration, we should create a demo of usage.

feat: docstrings - change from single quote to double quote

Is this a bug report or feature request? (choose one): feat

Python Version (output of python --version):

Development or Deployment Environment?:

Release Tag or Master:

Expected Behavior:
we need """ docstrings

What Actually Happened:
we are using ''' docstrings

How to Reproduce the Issue (as minimally as possible):

Any Additional Comments:

Armada 'delete' command: purge all charts in yaml

Is this a bug report or feature request? (choose one): feat

In armada, we would like to have the ability to delete all the charts that the armada manifest created. As so we should create a command armada delete FILE to delete the deployed manifest. this should be similar to the helm delete --purge command in which we can purge individual releases or all releases

• armada delete manfiest FILE
• armada delete release <chart-name>

feat: cmd - lint - validate generated yamls

Before we deploy or prior to deploy we want to make sure that our inputted yamls follow our rules. Hence we need to create a cmd that will lint the yamls. We should also have it prior to a install.

armada validate -f <path>

armada doesn't ignore files listed in .helmignore

Is this a bug report or feature request? (choose one):
bug report

Python Version (output of python --version):
python --version
Python 2.7.12

Development or Deployment Environment?:
development
Release Tag or Master:
master

Expected Behavior:
Files listed in .helmignore would be ignored

What Actually Happened:
armada errored out due to unterminated quote in an rst file that should be ignored

How to Reproduce the Issue (as minimally as possible):
point armada at kolla-kubernetes/helm/kolla-common

Any Additional Comments:

feat: pygit2/libgit2 - create a script to install this library

The pygit/libgit2 is an integral part of the armada code base in order to provide independent installation of the tool we need to automate/script this library install.

• remove the pygit2 from the requirements.txt
• crate a script that will install pygit2/libgit2
• Required Environments Ubuntu 14.04, Ubuntu 16.04

Nice to have: OS X Sierra