Skip to content

Commit

Permalink
Browse files Browse the repository at this point in the history
  • Loading branch information
OpenStackKen committed Oct 22, 2024
2 parents d31e2a2 + cdb9863 commit d385e17
Show file tree
Hide file tree
Showing 19 changed files with 191 additions and 414 deletions.
2 changes: 1 addition & 1 deletion .github/workflows/mkdocs.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -29,7 +29,7 @@ jobs:
with:
python-version: 3.x
- run: pip install -r doc-requirements.txt
- run: mkdocs build
- run: mkdocs build --strict
- uses: actions/upload-pages-artifact@v2
with:
path: site/
Expand Down
4 changes: 2 additions & 2 deletions base-helm-configs/magnum/magnum-helm-overrides.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -413,7 +413,7 @@ endpoints:
name: barbican
hosts:
default: barbican-api
public: barbican
public: barbican-api
host_fqdn_override:
default: null
path:
Expand All @@ -423,7 +423,7 @@ endpoints:
port:
api:
default: 9311
public: 80
public: 9311
orchestration:
name: heat
hosts:
Expand Down
4 changes: 2 additions & 2 deletions base-kustomize/skyline/base/deployment-apiserver.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -317,7 +317,7 @@ spec:
key: prometheus_endpoint
optional: true
- name: skyline-apiserver-db-migrate
image: "ghcr.io/rackerlabs/skyline-rxt:master-ubuntu_jammy-1728361249"
image: "ghcr.io/rackerlabs/skyline-rxt:master-ubuntu_jammy-1729251422"
imagePullPolicy: IfNotPresent
resources:
requests:
Expand All @@ -340,7 +340,7 @@ spec:
readOnly: true
containers:
- name: skyline-apiserver
image: "ghcr.io/rackerlabs/skyline-rxt:master-ubuntu_jammy-1728361249"
image: "ghcr.io/rackerlabs/skyline-rxt:master-ubuntu_jammy-1729251422"
imagePullPolicy: IfNotPresent
resources:
limits:
Expand Down
45 changes: 0 additions & 45 deletions docs/alertmanager-encore.md

This file was deleted.

Binary file modified docs/assets/images/diagram-genestack.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
187 changes: 0 additions & 187 deletions docs/assets/images/genstack-local-arch-k8s-flex.svg

This file was deleted.

Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file modified docs/assets/images/source/Logical-Architecture.graffle
Binary file not shown.
115 changes: 55 additions & 60 deletions docs/genestack-components.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,67 +2,62 @@

The following components are part of the initial product release
and largely deployed with Helm+Kustomize against the K8s API (v1.28 and up).
Some components are intially only installed with the public cloud based,
OpenStack Flex, service, while OpenStack Enterprise naturally provides a larger
variety of services:

| Group | Component | OpenStack Flex | OpenStack Enterprise |
|------------|----------------------|----------------|----------------------|
| Kubernetes | Kubernetes | Required | Required |
| Kubernetes | Kubernetes Dashboard | Required | Required |
| Kubernetes | Cert-Manager | Required | Required |
| Kubernetes | MetaLB (L2/L3) | Required | Required |
| Kubernetes | Core DNS | Required | Required |
| Kubernetes | Ingress Controller (Nginx) | Required | Required |
| Kubernetes | Kube-Proxy (IPVS) | Required | Required |
| Kubernetes | Calico | Optional | Required |
| Kubernetes | Kube-OVN | Required | Optional |
| Kubernetes | Helm | Required | Required |
| Kubernetes | Kustomize | Required | Required |
| OpenStack | openVswitch (Helm) | Optional | Required |
| OpenStack | Galera (Operator) | Required | Required |
| OpenStack | rabbitMQ (Operator) | Required | Required |
| OpenStack | memcacheD (Operator) | Required | Required |
| OpenStack | Ceph Rook | Optional | Required |
| OpenStack | iscsi/tgtd | Required | Optional |
| OpenStack | Keystone (Helm) | Required | Required |
| OpenStack | Glance (Helm) | Required | Required |
| OpenStack | Cinder (Helm) | Required | Required |
| OpenStack | Nova (Helm) | Required | Required |
| OpenStack | Neutron (Helm) | Required | Required |
| OpenStack | Placement (Helm) | Required | Required |
| OpenStack | Horizon (Helm) | Required | Required |
| OpenStack | Skyline (Helm) | Optional | Optional |
| OpenStack | Heat (Helm) | Required | Required |
| OpenStack | Designate (Helm) | Optional | Required |
| OpenStack | Barbican (Helm) | Required | Required |
| OpenStack | Octavia (Helm) | Required | Required |
| OpenStack | Ironic (Helm) | Optional | Required |
| OpenStack | metal3.io | Optional | Required |
| Group | Component | Status |
|------------|-----------------------|----------|
| Kubernetes | Kubernetes | Included |
| Kubernetes | Kubernetes Dashboard | Included |
| Kubernetes | Cert-Manager | Included |
| Kubernetes | MetaLB (L2/L3) | Included |
| Kubernetes | Core DNS | Included |
| Kubernetes | Nginx Gateway API | Included |
| Kubernetes | Kube-Proxy (IPVS) | Included |
| Kubernetes | Calico | Optional |
| Kubernetes | Kube-OVN | Included |
| Kubernetes | Helm | Included |
| Kubernetes | Kustomize | Included |
| Kubernetes | ArgoCD | Optional |
| OpenStack | openVswitch (Helm) | Optional |
| OpenStack | mariaDB (Operator) | Included |
| OpenStack | rabbitMQ (Operator) | Included |
| OpenStack | memcacheD (Operator) | Included |
| OpenStack | Ceph Rook | Optional |
| OpenStack | iscsi/tgtd | Included |
| OpenStack | Aodh (Helm) | Optional |
| OpenStack | Ceilometer (Helm) | Optional |
| OpenStack | Keystone (Helm) | Included |
| OpenStack | Glance (Helm) | Included |
| OpenStack | Cinder (Helm) | Included |
| OpenStack | Nova (Helm) | Included |
| OpenStack | Neutron (Helm) | Included |
| OpenStack | Placement (Helm) | Included |
| OpenStack | Horizon (Helm) | Included |
| OpenStack | Skyline (Helm) | Optional |
| OpenStack | Heat (Helm) | Included |
| OpenStack | Designate (Helm) | Optional |
| OpenStack | Barbican (Helm) | Included |
| OpenStack | Octavia (Helm) | Included |
| OpenStack | Ironic (Helm) | Optional |
| OpenStack | Magnum (Helm) | Optional |
| OpenStack | Masakari (Helm) | Optional |
| OpenStack | Blazar (Helm) | Optional |
| OpenStack | metal3.io | Planned |
| OpenStack | PostgreSQL (Operator) | Included |
| OpenStack | Consul | Planned |

Initial monitoring components consists of the following projects

| Group | Component | OpenStack Flex | OpenStack Enterprise |
|------------|--------------------|----------------|----------------------|
| Kubernetes | Prometheus | Required | Required |
| Kubernetes | Alertmanager | Required | Required |
| Kubernetes | Grafana | Required | Required |
| Kubernetes | Node Exporter | Required | Required |
| Kubernetes | Kube State Metrics | Required | Required |
| Kubernetes | redfish Exporter | Required | Required |
| OpenStack | OpenStack Exporter | Required | Required |
| OpenStack | RabbitMQ Exporter | Required | Required |
| OpenStack | Mysql Exporter | Required | Required |
| OpenStack | Memcached Exporter | Required | Required |
| OpenStack | Postgres Exporter | Required | Required |

At a later stage these components will be added

| Group | Component | OpenStack Flex | OpenStack Enterprise |
|------------|-------------------|----------------|----------------------|
| Kubernetes | Thanos/Cortex | Optional | Required |
| OpenStack | PostgreSQL | Required | Required |
| OpenStack | Aodh (Helm) | Optional | Required |
| OpenStack | Consul | Optional | Required |
| OpenStack | Ceilometer (Helm) | Optional | Required |
| OpenStack | Masakari (Helm) | Optional | Required |
| Group | Component | Status |
|------------|--------------------|----------|
| Kubernetes | Prometheus | Included |
| Kubernetes | Alertmanager | Included |
| Kubernetes | Grafana | Included |
| Kubernetes | Node Exporter | Included |
| Kubernetes | Kube State Metrics | Included |
| Kubernetes | redfish Exporter | Included |
| OpenStack | OpenStack Exporter | Included |
| OpenStack | RabbitMQ Exporter | Included |
| OpenStack | Mysql Exporter | Included |
| OpenStack | memcacheD Exporter | Included |
| OpenStack | Postgres Exporter | Included |
| Kubernetes | Thanos | Optional |
2 changes: 1 addition & 1 deletion docs/infrastructure-overview.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# Infrastructure Deployment Demo

![Genestack Infra](assets/images/genstack-local-arch-k8s-flex.svg)
![Genestack Infra](assets/images/genstack-local-arch-k8s.svg)

## Infrastructure Overview

Expand Down
2 changes: 1 addition & 1 deletion docs/magnum-kubernetes-cluster-setup-guide.md
Original file line number Diff line number Diff line change
Expand Up @@ -27,7 +27,7 @@ openstack subnet create public-subnet --network public --subnet-range 192.168.1.
To create a magnum cluster, you need a keypair which will be passed in all compute instances of the cluster. If you don’t have a keypair in your project, create one.

``` shell
openstack keypair create --public-key ~/.ssh/id_rsa.pub mykey
openstack keypair create mykey > mykey.pem
```

## ClusterTemplate
Expand Down
27 changes: 0 additions & 27 deletions docs/openstack-cloud-design-az.md
Original file line number Diff line number Diff line change
@@ -1,27 +0,0 @@
# Availability Zones

Availability Zones are the most arbitrary domain in a cloud. In a large-scale cloud, they could be mutliple datacenters in the same geographical area, while in a smaller cloud they could be separate data halls in the same datacenter or separate racks in the same data hall.

Ultimately, because it has no real physical analogue, an Availability Zone is a fancy way of defining a failure domain. What this allows you to do in your cloud design is define an Availability Zone to best suit how you want to separate resources for failure.

## Designing Services for Multiple Available Zones

!!! info "To Do"

Describe how to implement multiple AZs with the following OpenStack Services:

- Nova
- Neutron
- Cinder


## Sharing Services Across Availability Zones

!!! info "To Do"

Describe how to implement cross-AZ services with the following OpenStack Services:

- Keystone
- Glance

...
16 changes: 16 additions & 0 deletions docs/openstack-cloud-design-ha.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,16 @@
## Host Aggregates

Host Aggregates are a way of grouping hosts in an OpenStack cloud. This allows you to create groups of certain types of hosts and then steer certain classes of VM instances to them.


## Designing Host Aggregates in OpenStack

!!! info "To Do"

Describe how to implement Host Aggregates using the following OpenStack Services:

- Nova
- Placement
- Glance

...
14 changes: 6 additions & 8 deletions docs/openstack-cloud-design-overview.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# Overview

When building a cloud, the design of the cloud will not only reflect the type of services you are looking to provide but also inform the way that users of your cloud work to accomplish their goals.
When building a cloud, the design of the cloud will not only reflect the type of services you are looking to provide but also inform the way that users of your cloud work to accomplish their goals.

Availability is one of the key aspects of deploying applications in the cloud. Whether you are building a [twelve-factor](https://12factor.net/){:target="_blank"} cloud-native application or running a more traditional stateful application, in order for an application to maximize availability, it needs to have resiliance against failures, and that means understanding what failure domains the cloud infrastructure has.

Expand All @@ -14,10 +14,9 @@ These are typically arranged as in a hierarchy, with each incresing lower layer

![Cloud Hierarchy](assets/images/cloud-hierarchy.png)

## Clouds

# Clouds

At the highest level, a cloud is a unique set of services that operates completely independedntly. We can define a cloud as having its own set of resources and services that are not dependent on any other cloud.
At the highest level, a cloud is a unique set of services that operates completely independedntly. We can define a cloud as having its own set of resources and services that are not dependent on any other cloud.

Having multiple clouds gives you the most coarse-grained failure domain organization possible. There are several advantages to having multiple clouds:

Expand All @@ -32,22 +31,21 @@ While simplistic, this is an entirely valid design pattern. If there is a need

The major disadvantage of this pattern is that any replication of data or services between clouds is the responsibility of your users, and any shared services that your users want to use across multiple clouds will have to be external to the clouds they want to use.

# Regions
## Regions

Regions can be defined as a high-level cloud construct where there is some sort of geographical separation of services. In most cases, there may be some supporting services are shared between them; however, the general principle is that each region should be as self-sufficient as possible.

Depending on the scale of the cloud being built, geographical separation could be completely separate datacenters for very large clouds, or it could just mean separate data halls for smaller clouds. Regardless of the scale of separation, the operational resources should be kept as independent as possible with respect to power, networking, cooling, etc.

In addition to the physical geographical separation, there also needs to be logical separation of most services. Most storage, compute, and execution services[^2] should be separate and have the ability to operate independently from those same services deployed in other regions. This is key to ensure that users can depend on any region-level failure to be isolated and not bleed into other regions and harm the availability of their deployments. Any kind of fault or failure at the Region-level should be able to be mitigated by the cloud user having deployments in mulitple regions to provide high-availability.

# Availability Zones
## Availability Zones

Availability Zones are another logical grouping for sets of closely related resources and servces. In a large-scale cloud, an Availability Zone may comprise of multiple datacenters. For smaller clouds, they may be more modest in scale such as a data hall or even as small as row of racks. Ultimately, Availability Zones are rather arbitrary -- they essentially are a way to classify a cloud "failure domain" in less severe language.

Generally, no two Availability zones share the same core set of compute and storage resources. Each availabilty zone is able to operate self-sufficiently and operation should be as self-contained and physically isolated from other Availability Zones as possible in the same region to provide additional fault tolerance and resiliency.


[^1]:
[^1]:
The various clouds themselves should be completely independent, but they might rely on a shared backend service like LDAP for authentication.

[^2]:
Expand Down
2 changes: 1 addition & 1 deletion docs/openstack-cloud-design-regions.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# Regions

Regions are separate physical locations served by a single cloud.
Regions are separate physical locations served by a single cloud. In OpenStack, a Region is defined as an independently deployed cloud excepting Keystone and Horizon or Skyline.


## Designing Services for Multiple Available Zones
Expand Down
8 changes: 4 additions & 4 deletions docs/ovn-monitoring-introduction.md
Original file line number Diff line number Diff line change
Expand Up @@ -191,7 +191,7 @@ bindings between ovs and ovn-sb" and provides no additional information.
However, in _Genestack_, you find ovn metadata 'localport' types in the NB that
don't need an SB binding, which increases this count. _Kube-OVN_'s OVN itself
often gets used for k8s alone and would in that case often have a 0 count here,
but _Genestack_ (Flex, not Enterprise) uses _OpenStack Neutron_ as a second CMS
for _Kube-OVN_'s OVN installation, resulting in the existence of ports that
increase this count but don't indicate a problem, so _Genestack_ will generally
have a significant count for each compute node for this metric.
but _Genestack_ uses _OpenStack Neutron_ as a second CMS for _Kube-OVN_'s OVN
installation, resulting in the existence of ports that increase this count but
don't indicate a problem, so _Genestack_ will generally have a significant
count for each compute node for this metric.
6 changes: 3 additions & 3 deletions mkdocs.yml
Original file line number Diff line number Diff line change
Expand Up @@ -134,8 +134,9 @@ nav:
- Swift Object Storage: openstack-object-storage-swift.md
- Cloud Design:
- Overview: openstack-cloud-design-overview.md
- Regions: openstack-cloud-design-regions.md
- Availability Zones: openstack-cloud-design-az.md
- Regions in OpenStack: openstack-cloud-design-regions.md
- Availability Zones in OpenStack: openstack-cloud-design-az.md
- Host Aggregates in OpenStack: openstack-cloud-design-ha.md
- Deployment Guide:
- What is Genestack?: deployment-guide-welcome.md
- Getting Started:
Expand Down Expand Up @@ -215,7 +216,6 @@ nav:
- Pushgateway: prometheus-pushgateway.md
- Custom Node Metrics: prometheus-custom-node-metrics.md
- Alert Manager Examples:
- alertmanager-encore.md
- alertmanager-slack.md
- Operational Guide:
- Supporting multi-region Genestack: multi-region-support.md
Expand Down
16 changes: 16 additions & 0 deletions openstack-cloud-design-ha.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,16 @@
## Host Aggregates

Host Aggregates are a way of grouping hosts in an OpenStack cloud. This allows you to create groups of certain types of hosts and then steer certain classes of VM instances to them.


## Designing Host Aggregates in OpenStack

!!! info "To Do"

Describe how to implement Host Aggregates using the following OpenStack Services:

- Nova
- Placement
- Glance

...
17 changes: 17 additions & 0 deletions openstack-cloud-design-regions.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,17 @@
# Regions

Regions are separate physical locations served by a single cloud. In OpenStack, a Region is defined as an independently deployed cloud excepting Keystone and Horizon or Skyline.

## Designing Services for Multiple Available Zones

!!! info "To Do"

Describe how to implement a multi-region cloud with the following OpenStack services:

- Keystone
- Nova
- Neutron
- Cinder
- Glance

...

0 comments on commit d385e17

Please sign in to comment.