airship
/
airship-in-a-bottle
Code Issues Proposed changes

Cleanup Airship verbiage in docs 

This change attempts to move the airship-in-a-bottle documentation
closer to a target state for Airship by removing references to the
Undercloud Platform. This triggered the reformating of some paragraphs,
but this change does not attempt to correct all of the information -
much more a syntactical change of the documentation than a semantic
change. Requests to correct information in any significant way will be
deferred to subsequent work.

Some completely outdated pages were removed completely, as they provided
more distraction than benefit.

Documents that were "under development" since their inception (and
nothing more than "under development") have been eliminated and may be
re-instantiated if anyone ever has anything to say about the topics, but
for now, removed the clutter.

Change-Id: Ida72b3706c894771888d8b694e1cf95d6cf810ed
This commit is contained in:
Bryan Strassner 2018-08-15 13:47:51 -05:00
parent e8f9764936
commit 44b38244c4
15 changed files with 73 additions and 340 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
README.md
View File

@ -1,12 +1,12 @@
# Airship in a Bottle
Airship is a new name for the project, formerly known as UCP. References to
'UCP' or 'Undercloud Platform' will be corrected in time.
Airship is a broad integration of several components
enabling an automated, resilient Kubernetes-based infrastructure for hosting
Helm-deployed containerized workloads.
Airship is the name for the project formerly known as UCP or the Undercloud
Platform.
To get started, run the following in a fresh Ubuntu 16.04 VM
(minimum 4vCPU/20GB RAM/32GB disk). This will deploy Airship and Openstack Helm
(OSH):

21
doc/source/alarming-conditions.rst
View File

@ -1,21 +0,0 @@
..
Copyright 2017 AT&T Intellectual Property.
All Rights Reserved.
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, WITHOUT
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
License for the specific language governing permissions and limitations
under the License.
.. _alarming-conditions:
UCP Alarms and Alert Conditions
===============================
Under Development

56
doc/source/api-conventions.rst
View File

@ -19,7 +19,7 @@
API Conventions
===============
A collection of conventions that components of the UnderCloud Platform (UCP)
A collection of conventions that components of Airship
utilize for their REST APIs
Resource path naming
@ -32,7 +32,7 @@ Resource path naming
node of the path for that resource using v#.# format.
- By default and unless otherwise noted, the API will be namespaced by /api
before the version. For the purposes of documentation, this will not be
specified in each of the resource paths below. In more complex APIs, UCP
specified in each of the resource paths below. In more complex APIs, Airship
components may use values other than /api to be more specific to point to a
particular service.
@ -50,9 +50,9 @@ Status responses
Status responses, and more specifically error responses (HTTP response body
accompanying 4xx and 5xx series responses where possible) are a customized
version of the `Kubernetes standard for error representation`_. UCP utilizes
the details field in a more formalized way to represent multiple messages
related to a status response, as follows:
version of the `Kubernetes standard for error representation`_. Airship
utilizes the details field in a more formalized way to represent multiple
messages related to a status response, as follows:
::
@ -121,17 +121,17 @@ X-Context-Marker
Validation API
--------------
All UCP components that participate in validation of the design supplied to a
site implement a common resource to perform document validations. Document
All Airship components that participate in validation of the design supplied to
a site implement a common resource to perform document validations. Document
validations are synchronous.
Because of the different sources of documents that should be supported, a
flexible input descriptor is used to indicate from where a UCP component will
retrieve the documents to be validated.
flexible input descriptor is used to indicate from where an Airship component
will retrieve the documents to be validated.
POST /v1.0/validatedesign
~~~~~~~~~~~~~~~~~~~~~~~~~
Invokes a UCP component to perform validations against the documents specified
by the input structure. Synchronous.
Invokes an Airship component to perform validations against the documents
specified by the input structure. Synchronous.
Input structure
^^^^^^^^^^^^^^^
@ -161,7 +161,7 @@ Failure message example using a ValidationMessage kind for the messageList::
"apiVersion": "v1.0",
"metadata": {},
"status": "Failure",
"message": "{{UCP Component Name}} validations failed",
"message": "{{Component Name}} validations failed",
"reason": "Validation",
"details": {
"errorCount": {{n}},
@ -191,7 +191,7 @@ Success message example::
"apiVersion": "v1.0",
"metadata": {},
"status": "Success",
"message": "{{UCP Component Name}} validations succeeded",
"message": "{{Component Name}} validations succeeded",
"reason": "Validation",
"details": {
"errorCount": 0,
@ -235,31 +235,31 @@ ValidationMessage:
Health Check API
----------------
Each UCP component shall expose an endpoint that allows other components
Each Airship component shall expose an endpoint that allows other components
to access and validate its health status. Clients of the health check should
wait up to 30 seconds for a health check response from each component.
GET /v1.0/health
~~~~~~~~~~~~~~~~
Invokes a UCP component to return its health status. This endpoint is intended
to be unauthenticated, and must not return any information beyond the noted
204 or 503 status response. The component invoked is expected to return a
Invokes an Airship component to return its health status. This endpoint is
intended to be unauthenticated, and must not return any information beyond the
noted 204 or 503 status response. The component invoked is expected to return a
response in less than 30 seconds.
Health Check Output
^^^^^^^^^^^^^^^^^^^
The current design will be for the UCP component to return an empty response
to show that it is alive and healthy. This means that the UCP component that
The current design will be for the component to return an empty response
to show that it is alive and healthy. This means that the component that
is performing the query will receive HTTP response code 204.
HTTP response code 503 with a generic response status or an empty message body
will be returned if the UCP component determines it is in a non-healthy state,
will be returned if the component determines it is in a non-healthy state,
or is unable to reach another component it is dependent upon.
GET /v1.0/health/extended
~~~~~~~~~~~~~~~~~~~~~~~~~
UCP components may provide an extended health check. This request invokes a
UCP component to return its detailed health status. Authentication is required
Airship components may provide an extended health check. This request invokes a
component to return its detailed health status. Authentication is required
to invoke this API call.
Extended Health Check Output
@ -277,7 +277,7 @@ Failure message example::
"apiVersion": "v1.0",
"metadata": {},
"status": "Failure",
"message": "{{UCP Component Name}} failed to respond",
"message": "{{Component Name}} failed to respond",
"reason": "HealthCheck",
"details": {
"errorCount": {{n}},
@ -309,19 +309,19 @@ Success message example::
Versions API
------------
Each UCP component shall expose an endpoint that allows other components to
Each Airship component shall expose an endpoint that allows other components to
discover its different API versions. This endpoint is not prefixed by /api
or a version.
GET /versions
~~~~~~~~~~~~~
Invokes a UCP component to return its list of API versions. This endpoint is
intended to be unauthenticated, and must not return any information beyond the
output noted below.
Invokes an Airship component to return its list of API versions. This endpoint
is intended to be unauthenticated, and must not return any information beyond
the output noted below.
Versions output
^^^^^^^^^^^^^^^
Each UCP component shall return a list of its different API versions. The
Each Airship component shall return a list of its different API versions. The
response body shall be keyed with the name of each API version, with
accompanying information pertaining to the version's `path` and `status`. The
`status` field shall be an enum which accepts the values `stable` and `beta`,

21
doc/source/client-software.rst
View File

@ -1,21 +0,0 @@
..
Copyright 2017 AT&T Intellectual Property.
All Rights Reserved.
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, WITHOUT
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
License for the specific language governing permissions and limitations
under the License.
.. _client-software:
UCP Client Software Conventions
===============================
Under Development

12
doc/source/code-conventions.rst
View File

@ -19,7 +19,7 @@
Code and Project Conventions
============================
Conventions and standards that guide the development and arrangement of UCP
Conventions and standards that guide the development and arrangement of Airship
component projects.
Project Structure
@ -92,10 +92,10 @@ the root of the project.
Linting and Formatting Standards
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Code in the UCP components should follow the prevalent linting and formatting
standards for the language being implemented. In lieu of industry accepted
code formatting standards for a target language, strive for readability and
maintainability.
Code in the Airship components should follow the prevalent linting and
formatting standards for the language being implemented. In lieu of industry
accepted code formatting standards for a target language, strive for
readability and maintainability.
=============== ======================================
Known Standards
@ -105,7 +105,7 @@ Language Uses
Python PEP-8
=============== ======================================
UCP components must provide for automated checking of their formatting
Airship components must provide for automated checking of their formatting
standards, such as the lint step noted above in the makefile. Components may
provide automated reformatting.

18
doc/source/conf.py
View File

@ -50,9 +50,9 @@ source_suffix = '.rst'
master_doc = 'index'
# General information about the project.
project = u'UCP Integration'
project = u'Airship'
copyright = u'2017 AT&T Intellectual Property.'
author = u'Undercloud Authors'
author = u'Airship Authors'
# The version info for the project you're documenting, acts as replacement for
# |version| and |release|, also used in various other places throughout the
@ -105,7 +105,7 @@ html_static_path = []
# -- Options for HTMLHelp output ------------------------------------------
# Output file base name for HTML help builder.
htmlhelp_basename = 'ucpintdoc'
htmlhelp_basename = 'airshipdoc'
# -- Options for LaTeX output ---------------------------------------------
@ -132,8 +132,8 @@ latex_elements = {
# (source start file, target name, title,
# author, documentclass [howto, manual, or own class]).
latex_documents = [
(master_doc, 'ucpint.tex', u'UCP Integration Documentation',
u'Undercloud Authors', 'manual'),
(master_doc, 'airship.tex', u'Airship Documentation',
u'Airship Authors', 'manual'),
]
@ -142,7 +142,7 @@ latex_documents = [
# One entry per manual page. List of tuples
# (source start file, name, description, authors, manual section).
man_pages = [
(master_doc, 'UCPIntegration', u'UCP Integration Documentation',
(master_doc, 'Airship', u'Airship Documentation',
[author], 1)
]
@ -153,8 +153,8 @@ man_pages = [
# (source start file, target name, title, author,
# dir menu entry, description, category)
texinfo_documents = [
(master_doc, 'UCP Integration', u'UCP Integration Documentation',
author, 'UCP Integration',
'Undercloud Platform Integration documentation',
(master_doc, 'Airship', u'Airship Documentation',
author, 'Airship',
'Airship documentation',
'Miscellaneous'),
]

10
doc/source/conventions.rst
View File

@ -16,9 +16,9 @@
.. _conventions:
Undercloud Platform Conventions
===============================
Undercloud Platform components conform to a minimal set of of conventions to
Airship Conventions
===================
Airship components conform to a minimal set of of conventions to
provide for reasonable levels of consistency.
Language
@ -38,13 +38,9 @@ Conventions and Standards
.. toctree::
:maxdepth: 2
alarming-conditions
api-conventions
rbac-conventions
client-software
code-conventions
documentation-conventions
service-logging-conventions
security-conventions
.. _RFC 2119: https://www.ietf.org/rfc/rfc2119.txt

24
doc/source/documentation-conventions.rst
View File

@ -18,7 +18,7 @@
Documentation
=============
Each UCP component will maintain documentation addressing two audiences:
Each Airship component will maintain documentation addressing two audiences:
#. Consumer documentation
#. Developer documentation
@ -51,9 +51,9 @@ the following topics:
Format
------
There are multiple means by which consumers and developers will read the
documentation for UCP components. The two common places for UCP components are
`Github`_ in the form of README and code-based documentation, and
`Readthedocs`_ for more complete/formatted documentation.
documentation for Airship components. The two common places for Airship
components are `Github`_ in the form of README and code-based documentation,
and `Readthedocs`_ for more complete/formatted documentation.
Documentation that is expected to be read in Github must exist and may use
either `reStructuredText`_ or `Markdown`_. This generally would be limited to
@ -66,20 +66,22 @@ provide a `Sphinx`_ build of the documentation.
Finding Treasuremap
-------------------
`Treasuremap`_ is a project that serves as a starting point for the larger
Containerized Cloud Platform, and provides context for the Undercloud Platform
component projects.
Containerized Cloud Platform, and provides context for the Airship component
projects.
Undercloud component projects should include the following at the top of the
Airship component projects should include the following at the top of the
main/index page of their `Readthedocs`_ documentation:
.. tip::
{{component name}} is part of the containerized Local Control Plane (cLCP).
More details may be found by using the `Treasuremap`_
{{component name}} is part of Airship, a collection of components that
coordinate to form a means of configuring, deploying and maintaining a
Kubernetes environment using a declarative set of yaml documents. More
details on using Airship may be found by using the `Treasuremap`_
.. _reStructuredText: http://www.sphinx-doc.org/en/stable/rest.html
.. _Markdown: https://daringfireball.net/projects/markdown/syntax
.. _Readthedocs: https://readthedocs.org/
.. _Readthedocs: https://airshipit.readthedocs.org/
.. _Github: https://github.com
.. _Sphinx: http://www.sphinx-doc.org/en/stable/index.html
.. _Treasuremap: https://github.com/att-comdev/treasuremap
.. _Treasuremap: https://github.com/openstack/airship-treasuremap

12
doc/source/index.rst
View File

@ -14,11 +14,6 @@
License for the specific language governing permissions and limitations
under the License.
.. tip::
The Undercloud Platform is part of the containerized Local Control Plane
(cLCP). More details may be found by using the `Treasuremap`_
.. note::
These documents will be reworked to reflect the changes associated with
@ -30,7 +25,8 @@ Airship
Airship is a collection of components that coordinate to form a means of
configuring, deploying and maintaining a `Kubernetes`_ environment using a
declarative set of `yaml`_ documents.
declarative set of `yaml`_ documents. More details on using parts of Airship
may be found by using the `Treasuremap`_
Approach
--------
@ -60,14 +56,12 @@ Conventions and Standards
conventions
security/guide
dev-getting-started
ucp-basic-deployment
.. _airshipit.org: https://airshipit.org
.. _Helm: https://helm.sh/
.. _Kubernetes: https://kubernetes.io/
.. _Openstack: https://www.openstack.org/
.. _Openstack-Helm: https://docs.openstack.org/openstack-helm/latest/
.. _Treasuremap: https://github.com/att-comdev/treasuremap
.. _Treasuremap: https://github.com/openstack/airship-treasuremap
.. _yaml: http://yaml.org/
.. _specifications: /projects/specs

21
doc/source/rbac-conventions.rst
View File

@ -1,21 +0,0 @@
..
Copyright 2017 AT&T Intellectual Property.
All Rights Reserved.
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, WITHOUT
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
License for the specific language governing permissions and limitations
under the License.
.. _rbac-conventions:
RBAC Conventions
================
Under Development

21
doc/source/security-conventions.rst
View File

@ -1,21 +0,0 @@
..
Copyright 2017 AT&T Intellectual Property.
All Rights Reserved.
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, WITHOUT
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
License for the specific language governing permissions and limitations
under the License.
.. _security-conventions:
UCP Security Conventions
========================
Under Development

10
doc/source/service-logging-conventions.rst
View File

@ -18,14 +18,14 @@
Service Logging Conventions
===========================
UCP services must provide logging, should conform to a standard logging format,
and may utilize shared code to do so.
Airship services must provide logging, should conform to a standard logging
format, and may utilize shared code to do so.
Standard Logging Format
-----------------------
The following is the intended format to be used when logging from UCP services.
When logging from those parts that are no services, a close reasonable
approximation is desired.
The following is the intended format to be used when logging from Airship
services. When logging from those parts that are no services, a close
reasonable approximation is desired.
::

175
doc/source/ucp-basic-deployment.rst
View File

@ -1,175 +0,0 @@
..
Copyright 2017 AT&T Intellectual Property.
All Rights Reserved.
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, WITHOUT
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
License for the specific language governing permissions and limitations
under the License.
.. _ucp-basic-deployment:
Deployment Guide
----------------
.. note::
The Undercloud Platform is still under active development and this
guide will evolve along the way
The current deployment makes use of the `ucp-integration`_ repository to set up
the underlaying Kubernetes infrastructure, Ceph and UCP components. This
approach sets up an 'All-In-One' UCP environment that allows developers to
bring up the UCP components on a single Ubuntu 16.04 Virtual Machine.
.. note::
Note that the minimum recommended size of the VM is 4 vCPUs, 16GB of RAM with
64GB disk space
Pre-Deployment Preparations
~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. todo::
Update these to use env vars as input to the UCP basic process instead of
sed.
1. Set up `etc/hosts` on a freshly installed Ubuntu 16.04 Virtual Machine such
that the local IP address is referenced by the hostname.
E.g. `127.0.0.1 host1`
::
HOST_IFACE=$(ip route | grep "^default" | head -1 | awk '{ print $5 }')
LOCAL_IP=$(ip addr | awk "/inet/ && /${HOST_IFACE}/{sub(/\/.*$/,\"\",\$2); print \$2}")
cat << EOF | sudo tee -a /etc/hosts
${LOCAL_IP} $(hostname)
EOF
2. Clone the `ucp-integration` repository.
::
git clone https://github.com/att-comdev/ucp-integration.git
Deployment
~~~~~~~~~~
This deploys UCP in a production-like mode using the basic_ucp deployment.
Setup for specific components in a development mode may require some additional
setup prior to these steps.
1. Switch to root user after performing the steps in the `Pre-Deployment
Preparations`_ section.
::
sudo -i
cd /home/ubuntu/ucp-integration/manifests/basic_ucp/
2. Source the set-env.sh script
::
source set-env.sh
3. Export/override the variables that are unique to the environment. For
instance, we can do the following to update the environment variables for a
VM that is assigned an IP of `30.30.30.4` on interface `ens3`
(network `30.30.30.0/24`):
::
export CEPH_CLUSTER_NET=30.30.30.0/24
export CEPH_PUBLIC_NET=30.30.30.0/24
export GENESIS_NODE_IP=30.30.30.4
export NODE_NET_IFACE=ens3
export GENESIS_NODE_NAME=$(hostname)
.. note::
These may be overridden directly in the set-env.sh instead of
exporting these as a separate step.
4. Start the UCP deployment
::
./deploy_ucp.sh
Post Deployment
~~~~~~~~~~~~~~~
1. The deployment is fully automated and can take a while to complete (it can
take 30 minutes to an hour for a full deployment to complete)
2. The environment should resemble the following after executing the required
steps:
::
# sudo kubectl get pods -n ucp
NAME READY STATUS RESTARTS AGE
airflow-flower-6cdc6f9cb4-5r62v 1/1 Running 0 3h
airflow-scheduler-6d54445bf8-6ldrd 1/1 Running 0 3h
airflow-web-7bd69d857d-qlptj 1/1 Running 0 3h
airflow-worker-666696d6c5-vffpg 1/1 Running 0 3h
armada-api-84df5b7fc9-4nxp5 1/1 Running 0 4h
barbican-api-85c956c84f-p4q7h 1/1 Running 0 4h
deckhand-5468d59455-2mcqd 1/1 Running 0 4h
drydock-api-f9897cf44-csbc8 1/1 Running 0 4h
drydock-api-f9897cf44-jgv4q 1/1 Running 0 4h
etcd-5bcbbd679c-rb5rf 1/1 Running 0 4h
ingress-api-xvkzx 1/1 Running 0 4h
ingress-error-pages-5d79688f6c-9b8xc 1/1 Running 0 4h
keystone-api-6bc85c98-886mg 1/1 Running 0 4h
maas-rack-5d4b84c4d5-dt87j 1/1 Running 0 4h
maas-region-0 1/1 Running 0 4h
mariadb-0 1/1 Running 0 4h
mariadb-1 1/1 Running 0 4h
mariadb-2 1/1 Running 0 4h
memcached-5bf49657db-kq6qh 1/1 Running 0 4h
postgresql-0 1/1 Running 0 4h
rabbitmq-f68649644-pnw6p 1/1 Running 0 4h
shipyard-6f4c7765d-n2kx6 1/1 Running 0 3h
To check that all relevant helm charts have been deployed:
::
# sudo helm ls
NAME REVISION UPDATED STATUS CHART NAMESPACE
ucp-armada 1 Fri Dec 1 10:03:44 2017 DEPLOYED armada-0.1.0 ucp
ucp-barbican 1 Fri Dec 1 10:03:47 2017 DEPLOYED barbican-0.1.0 ucp
ucp-calico 1 Fri Dec 1 10:00:05 2017 DEPLOYED calico-0.1.0 kube-system
ucp-calico-etcd 1 Fri Dec 1 09:59:28 2017 DEPLOYED etcd-0.1.0 kube-system
ucp-ceph 1 Fri Dec 1 10:00:58 2017 DEPLOYED ceph-0.1.0 ceph
ucp-coredns 1 Fri Dec 1 10:00:26 2017 DEPLOYED coredns-0.1.0 kube-system
ucp-deckhand 1 Fri Dec 1 10:03:39 2017 DEPLOYED deckhand-0.1.0 ucp
ucp-drydock 1 Fri Dec 1 10:03:37 2017 DEPLOYED drydock-0.1.0 ucp
ucp-etcd-rabbitmq 1 Fri Dec 1 10:02:44 2017 DEPLOYED etcd-0.1.0 ucp
ucp-ingress 1 Fri Dec 1 10:02:45 2017 DEPLOYED ingress-0.1.0 ucp
ucp-keystone 1 Fri Dec 1 10:03:45 2017 DEPLOYED keystone-0.1.0 ucp
ucp-kubernetes-apiserver 1 Fri Dec 1 10:00:32 2017 DEPLOYED apiserver-0.1.0 kube-system
ucp-kubernetes-controller-manager 1 Fri Dec 1 10:00:33 2017 DEPLOYED controller_manager-0.1.0 kube-system
ucp-kubernetes-etcd 1 Fri Dec 1 10:00:31 2017 DEPLOYED etcd-0.1.0 kube-system
ucp-kubernetes-proxy 1 Fri Dec 1 09:58:46 2017 DEPLOYED proxy-0.1.0 kube-system
ucp-kubernetes-scheduler 1 Fri Dec 1 10:00:34 2017 DEPLOYED scheduler-0.1.0 kube-system
ucp-maas 1 Fri Dec 1 10:03:36 2017 DEPLOYED maas-0.1.0 ucp
ucp-maas-postgresql 1 Fri Dec 1 10:02:44 2017 DEPLOYED postgresql-0.1.0 ucp
ucp-rabbitmq 1 Fri Dec 1 10:02:45 2017 DEPLOYED rabbitmq-0.1.0 ucp
ucp-rbac 1 Fri Dec 1 10:00:44 2017 DEPLOYED rbac-0.1.0 kube-system
ucp-shipyard 1 Fri Dec 1 10:38:08 2017 DEPLOYED shipyard-0.1.0 ucp
ucp-ucp-ceph-config 1 Fri Dec 1 10:02:40 2017 DEPLOYED ceph-0.1.0 ucp
ucp-ucp-mariadb 1 Fri Dec 1 10:02:43 2017 DEPLOYED mariadb-0.1.0 ucp
ucp-ucp-memcached 1 Fri Dec 1 10:02:44 2017 DEPLOYED memcached-0.1.0 ucp
.. _ucp-integration: https://github.com/att-comdev/ucp-integration

4
manifests/dev_minimal/set-env.sh
View File

@ -33,8 +33,8 @@ export HOSTCIDR=10.0.0.0/24
export NODE_NET_IFACE=ens3
# Repositories
# export UCP_INTEGRATION_REPO="https://git.openstack.org/openstack/airship-in-a-bottle"
# export UCP_INTEGRATION_REFSPEC=""
# export AIRSHIP_IN_A_BOTTLE_REPO="https://git.openstack.org/openstack/airship-in-a-bottle"
# export AIRSHIP_IN_A_BOTTLE_REFSPEC=""
# export PEGLEG_REPO="https://git.openstack.org/openstack/airship-pegleg.git"
# export PEGLEG_REFSPEC=""
# export SHIPYARD_REPO="https://git.openstack.org/openstack/airship-shipyard.git"

2
manifests/dev_single_node/airship-in-a-bottle.sh
View File

@ -16,7 +16,7 @@
###############################################################################
# #
# Set up and deploy a Airship environment for demonstration purposes. #
# Set up and deploy an Airship environment for demonstration purposes. #
# Many of the defaults and sources used here are NOT production ready, and #
# this should not be used as a copy/paste source for any production use. #
# #