diff --git a/base-kustomize/glance/base/client-settings.yaml b/Containerfiles/these_will_be_moved_to_genestack_images.txt similarity index 100% rename from base-kustomize/glance/base/client-settings.yaml rename to Containerfiles/these_will_be_moved_to_genestack_images.txt diff --git a/ansible-collection-requirements.yml b/ansible-collection-requirements.yml index 0698a0c6e..6c55d4d28 100644 --- a/ansible-collection-requirements.yml +++ b/ansible-collection-requirements.yml @@ -1,7 +1,4 @@ collections: - - name: https://opendev.org/openstack/ansible-collections-openstack - version: 2.2.0 - type: git - name: https://github.com/ansible-collections/ansible.posix version: 1.5.4 type: git diff --git a/ansible/playbooks/deploy-cinder-netapp-volumes-reference.yaml b/apps/openstack/ansible/playbooks/deploy-cinder-netapp-volumes-reference.yaml similarity index 100% rename from ansible/playbooks/deploy-cinder-netapp-volumes-reference.yaml rename to apps/openstack/ansible/playbooks/deploy-cinder-netapp-volumes-reference.yaml diff --git a/ansible/playbooks/deploy-cinder-volumes-reference.yaml b/apps/openstack/ansible/playbooks/deploy-cinder-volumes-reference.yaml similarity index 100% rename from ansible/playbooks/deploy-cinder-volumes-reference.yaml rename to apps/openstack/ansible/playbooks/deploy-cinder-volumes-reference.yaml diff --git a/ansible/playbooks/monitor-setup.yml b/apps/openstack/ansible/playbooks/monitor-setup.yml similarity index 100% rename from ansible/playbooks/monitor-setup.yml rename to apps/openstack/ansible/playbooks/monitor-setup.yml diff --git a/ansible/playbooks/octavia-preconf-main.yaml b/apps/openstack/ansible/playbooks/octavia-preconf-main.yaml similarity index 100% rename from ansible/playbooks/octavia-preconf-main.yaml rename to apps/openstack/ansible/playbooks/octavia-preconf-main.yaml diff --git a/ansible/roles/monitor_setup/defaults/main.yml b/apps/openstack/ansible/roles/monitor_setup/defaults/main.yml similarity index 100% rename from ansible/roles/monitor_setup/defaults/main.yml rename to apps/openstack/ansible/roles/monitor_setup/defaults/main.yml diff --git a/ansible/roles/monitor_setup/files/mpctl b/apps/openstack/ansible/roles/monitor_setup/files/mpctl similarity index 100% rename from ansible/roles/monitor_setup/files/mpctl rename to apps/openstack/ansible/roles/monitor_setup/files/mpctl diff --git a/ansible/roles/monitor_setup/handlers/main.yml b/apps/openstack/ansible/roles/monitor_setup/handlers/main.yml similarity index 100% rename from ansible/roles/monitor_setup/handlers/main.yml rename to apps/openstack/ansible/roles/monitor_setup/handlers/main.yml diff --git a/ansible/roles/monitor_setup/tasks/main.yml b/apps/openstack/ansible/roles/monitor_setup/tasks/main.yml similarity index 100% rename from ansible/roles/monitor_setup/tasks/main.yml rename to apps/openstack/ansible/roles/monitor_setup/tasks/main.yml diff --git a/ansible/roles/monitor_setup/tasks/monitor_compute.yml b/apps/openstack/ansible/roles/monitor_setup/tasks/monitor_compute.yml similarity index 100% rename from ansible/roles/monitor_setup/tasks/monitor_compute.yml rename to apps/openstack/ansible/roles/monitor_setup/tasks/monitor_compute.yml diff --git a/ansible/roles/monitor_setup/tasks/monitor_storage.yml b/apps/openstack/ansible/roles/monitor_setup/tasks/monitor_storage.yml similarity index 100% rename from ansible/roles/monitor_setup/tasks/monitor_storage.yml rename to apps/openstack/ansible/roles/monitor_setup/tasks/monitor_storage.yml diff --git a/ansible/roles/monitor_setup/templates/mpctl.yml.j2 b/apps/openstack/ansible/roles/monitor_setup/templates/mpctl.yml.j2 similarity index 100% rename from ansible/roles/monitor_setup/templates/mpctl.yml.j2 rename to apps/openstack/ansible/roles/monitor_setup/templates/mpctl.yml.j2 diff --git a/ansible/roles/monitor_setup/vars/main.yml b/apps/openstack/ansible/roles/monitor_setup/vars/main.yml similarity index 100% rename from ansible/roles/monitor_setup/vars/main.yml rename to apps/openstack/ansible/roles/monitor_setup/vars/main.yml diff --git a/ansible/roles/octavia_preconf/README.md b/apps/openstack/ansible/roles/octavia_preconf/README.md similarity index 100% rename from ansible/roles/octavia_preconf/README.md rename to apps/openstack/ansible/roles/octavia_preconf/README.md diff --git a/ansible/roles/octavia_preconf/defaults/main.yml b/apps/openstack/ansible/roles/octavia_preconf/defaults/main.yml similarity index 100% rename from ansible/roles/octavia_preconf/defaults/main.yml rename to apps/openstack/ansible/roles/octavia_preconf/defaults/main.yml diff --git a/ansible/roles/octavia_preconf/files/create_health_mgr_ports.sh b/apps/openstack/ansible/roles/octavia_preconf/files/create_health_mgr_ports.sh similarity index 100% rename from ansible/roles/octavia_preconf/files/create_health_mgr_ports.sh rename to apps/openstack/ansible/roles/octavia_preconf/files/create_health_mgr_ports.sh diff --git a/ansible/roles/octavia_preconf/files/create_k8s_secret.sh b/apps/openstack/ansible/roles/octavia_preconf/files/create_k8s_secret.sh similarity index 100% rename from ansible/roles/octavia_preconf/files/create_k8s_secret.sh rename to apps/openstack/ansible/roles/octavia_preconf/files/create_k8s_secret.sh diff --git a/ansible/roles/octavia_preconf/handlers/main.yml b/apps/openstack/ansible/roles/octavia_preconf/handlers/main.yml similarity index 100% rename from ansible/roles/octavia_preconf/handlers/main.yml rename to apps/openstack/ansible/roles/octavia_preconf/handlers/main.yml diff --git a/ansible/roles/octavia_preconf/meta/main.yml b/apps/openstack/ansible/roles/octavia_preconf/meta/main.yml similarity index 100% rename from ansible/roles/octavia_preconf/meta/main.yml rename to apps/openstack/ansible/roles/octavia_preconf/meta/main.yml diff --git a/ansible/roles/octavia_preconf/tasks/admin_tenant_quota_setup.yml b/apps/openstack/ansible/roles/octavia_preconf/tasks/admin_tenant_quota_setup.yml similarity index 100% rename from ansible/roles/octavia_preconf/tasks/admin_tenant_quota_setup.yml rename to apps/openstack/ansible/roles/octavia_preconf/tasks/admin_tenant_quota_setup.yml diff --git a/ansible/roles/octavia_preconf/tasks/main.yml b/apps/openstack/ansible/roles/octavia_preconf/tasks/main.yml similarity index 100% rename from ansible/roles/octavia_preconf/tasks/main.yml rename to apps/openstack/ansible/roles/octavia_preconf/tasks/main.yml diff --git a/ansible/roles/octavia_preconf/tasks/octavia_amphora_keypair_image_flavor.yml b/apps/openstack/ansible/roles/octavia_preconf/tasks/octavia_amphora_keypair_image_flavor.yml similarity index 100% rename from ansible/roles/octavia_preconf/tasks/octavia_amphora_keypair_image_flavor.yml rename to apps/openstack/ansible/roles/octavia_preconf/tasks/octavia_amphora_keypair_image_flavor.yml diff --git a/ansible/roles/octavia_preconf/tasks/octavia_cert.yml b/apps/openstack/ansible/roles/octavia_preconf/tasks/octavia_cert.yml similarity index 100% rename from ansible/roles/octavia_preconf/tasks/octavia_cert.yml rename to apps/openstack/ansible/roles/octavia_preconf/tasks/octavia_cert.yml diff --git a/ansible/roles/octavia_preconf/tasks/octavia_cert_dir_setup.yml b/apps/openstack/ansible/roles/octavia_preconf/tasks/octavia_cert_dir_setup.yml similarity index 100% rename from ansible/roles/octavia_preconf/tasks/octavia_cert_dir_setup.yml rename to apps/openstack/ansible/roles/octavia_preconf/tasks/octavia_cert_dir_setup.yml diff --git a/ansible/roles/octavia_preconf/tasks/octavia_health_mgr_ports.yml b/apps/openstack/ansible/roles/octavia_preconf/tasks/octavia_health_mgr_ports.yml similarity index 100% rename from ansible/roles/octavia_preconf/tasks/octavia_health_mgr_ports.yml rename to apps/openstack/ansible/roles/octavia_preconf/tasks/octavia_health_mgr_ports.yml diff --git a/ansible/roles/octavia_preconf/tasks/octavia_helm_amphorae_values.yml b/apps/openstack/ansible/roles/octavia_preconf/tasks/octavia_helm_amphorae_values.yml similarity index 100% rename from ansible/roles/octavia_preconf/tasks/octavia_helm_amphorae_values.yml rename to apps/openstack/ansible/roles/octavia_preconf/tasks/octavia_helm_amphorae_values.yml diff --git a/ansible/roles/octavia_preconf/tasks/octavia_lb_net_setup.yml b/apps/openstack/ansible/roles/octavia_preconf/tasks/octavia_lb_net_setup.yml similarity index 100% rename from ansible/roles/octavia_preconf/tasks/octavia_lb_net_setup.yml rename to apps/openstack/ansible/roles/octavia_preconf/tasks/octavia_lb_net_setup.yml diff --git a/ansible/roles/octavia_preconf/tasks/octavia_sec_group.yml b/apps/openstack/ansible/roles/octavia_preconf/tasks/octavia_sec_group.yml similarity index 100% rename from ansible/roles/octavia_preconf/tasks/octavia_sec_group.yml rename to apps/openstack/ansible/roles/octavia_preconf/tasks/octavia_sec_group.yml diff --git a/ansible/roles/octavia_preconf/templates/octavia_amphora_provider.yaml.j2 b/apps/openstack/ansible/roles/octavia_preconf/templates/octavia_amphora_provider.yaml.j2 similarity index 100% rename from ansible/roles/octavia_preconf/templates/octavia_amphora_provider.yaml.j2 rename to apps/openstack/ansible/roles/octavia_preconf/templates/octavia_amphora_provider.yaml.j2 diff --git a/ansible/roles/octavia_preconf/templates/openssl.cnf.j2 b/apps/openstack/ansible/roles/octavia_preconf/templates/openssl.cnf.j2 similarity index 100% rename from ansible/roles/octavia_preconf/templates/openssl.cnf.j2 rename to apps/openstack/ansible/roles/octavia_preconf/templates/openssl.cnf.j2 diff --git a/ansible/roles/octavia_preconf/vars/main.yml b/apps/openstack/ansible/roles/octavia_preconf/vars/main.yml similarity index 100% rename from ansible/roles/octavia_preconf/vars/main.yml rename to apps/openstack/ansible/roles/octavia_preconf/vars/main.yml diff --git a/ansible/playbooks/templates/cinder-backup.service b/apps/openstack/ansible/templates/cinder-backup.service similarity index 100% rename from ansible/playbooks/templates/cinder-backup.service rename to apps/openstack/ansible/templates/cinder-backup.service diff --git a/ansible/playbooks/templates/cinder-volume-netapp.service b/apps/openstack/ansible/templates/cinder-volume-netapp.service similarity index 100% rename from ansible/playbooks/templates/cinder-volume-netapp.service rename to apps/openstack/ansible/templates/cinder-volume-netapp.service diff --git a/ansible/playbooks/templates/cinder-volume-usage-audit.service b/apps/openstack/ansible/templates/cinder-volume-usage-audit.service similarity index 100% rename from ansible/playbooks/templates/cinder-volume-usage-audit.service rename to apps/openstack/ansible/templates/cinder-volume-usage-audit.service diff --git a/ansible/playbooks/templates/cinder-volume-usage-audit.timer b/apps/openstack/ansible/templates/cinder-volume-usage-audit.timer similarity index 100% rename from ansible/playbooks/templates/cinder-volume-usage-audit.timer rename to apps/openstack/ansible/templates/cinder-volume-usage-audit.timer diff --git a/ansible/playbooks/templates/cinder-volume.service b/apps/openstack/ansible/templates/cinder-volume.service similarity index 100% rename from ansible/playbooks/templates/cinder-volume.service rename to apps/openstack/ansible/templates/cinder-volume.service diff --git a/ansible/playbooks/templates/genestack-multipath.conf b/apps/openstack/ansible/templates/openstack-compute-multipath.conf similarity index 100% rename from ansible/playbooks/templates/genestack-multipath.conf rename to apps/openstack/ansible/templates/openstack-compute-multipath.conf diff --git a/base-helm-configs/barbican/barbican-helm-overrides.yaml b/apps/openstack/base-helm-configs/barbican/barbican-helm-overrides.yaml similarity index 100% rename from base-helm-configs/barbican/barbican-helm-overrides.yaml rename to apps/openstack/base-helm-configs/barbican/barbican-helm-overrides.yaml diff --git a/base-helm-configs/ceilometer/ceilometer-helm-overrides.yaml b/apps/openstack/base-helm-configs/ceilometer/ceilometer-helm-overrides.yaml similarity index 100% rename from base-helm-configs/ceilometer/ceilometer-helm-overrides.yaml rename to apps/openstack/base-helm-configs/ceilometer/ceilometer-helm-overrides.yaml diff --git a/base-helm-configs/cinder/cinder-helm-overrides.yaml b/apps/openstack/base-helm-configs/cinder/cinder-helm-overrides.yaml similarity index 100% rename from base-helm-configs/cinder/cinder-helm-overrides.yaml rename to apps/openstack/base-helm-configs/cinder/cinder-helm-overrides.yaml diff --git a/base-helm-configs/designate/designate-helm-overrides.yaml b/apps/openstack/base-helm-configs/designate/designate-helm-overrides.yaml similarity index 100% rename from base-helm-configs/designate/designate-helm-overrides.yaml rename to apps/openstack/base-helm-configs/designate/designate-helm-overrides.yaml diff --git a/base-helm-configs/glance/glance-helm-overrides.yaml b/apps/openstack/base-helm-configs/glance/glance-helm-overrides.yaml similarity index 100% rename from base-helm-configs/glance/glance-helm-overrides.yaml rename to apps/openstack/base-helm-configs/glance/glance-helm-overrides.yaml diff --git a/base-helm-configs/gnocchi/gnocchi-helm-overrides.yaml b/apps/openstack/base-helm-configs/gnocchi/gnocchi-helm-overrides.yaml similarity index 100% rename from base-helm-configs/gnocchi/gnocchi-helm-overrides.yaml rename to apps/openstack/base-helm-configs/gnocchi/gnocchi-helm-overrides.yaml diff --git a/base-helm-configs/heat/heat-helm-overrides.yaml b/apps/openstack/base-helm-configs/heat/heat-helm-overrides.yaml similarity index 100% rename from base-helm-configs/heat/heat-helm-overrides.yaml rename to apps/openstack/base-helm-configs/heat/heat-helm-overrides.yaml diff --git a/base-helm-configs/horizon/horizon-helm-overrides.yaml b/apps/openstack/base-helm-configs/horizon/horizon-helm-overrides.yaml similarity index 100% rename from base-helm-configs/horizon/horizon-helm-overrides.yaml rename to apps/openstack/base-helm-configs/horizon/horizon-helm-overrides.yaml diff --git a/base-helm-configs/ironic/ironic-helm-overrides.yaml b/apps/openstack/base-helm-configs/ironic/ironic-helm-overrides.yaml similarity index 100% rename from base-helm-configs/ironic/ironic-helm-overrides.yaml rename to apps/openstack/base-helm-configs/ironic/ironic-helm-overrides.yaml diff --git a/base-helm-configs/keystone/keystone-helm-overrides.yaml b/apps/openstack/base-helm-configs/keystone/keystone-helm-overrides.yaml similarity index 100% rename from base-helm-configs/keystone/keystone-helm-overrides.yaml rename to apps/openstack/base-helm-configs/keystone/keystone-helm-overrides.yaml diff --git a/base-helm-configs/libvirt/libvirt-helm-overrides.yaml b/apps/openstack/base-helm-configs/libvirt/libvirt-helm-overrides.yaml similarity index 100% rename from base-helm-configs/libvirt/libvirt-helm-overrides.yaml rename to apps/openstack/base-helm-configs/libvirt/libvirt-helm-overrides.yaml diff --git a/base-helm-configs/magnum/magnum-helm-overrides.yaml b/apps/openstack/base-helm-configs/magnum/magnum-helm-overrides.yaml similarity index 100% rename from base-helm-configs/magnum/magnum-helm-overrides.yaml rename to apps/openstack/base-helm-configs/magnum/magnum-helm-overrides.yaml diff --git a/base-helm-configs/neutron/neutron-helm-overrides.yaml b/apps/openstack/base-helm-configs/neutron/neutron-helm-overrides.yaml similarity index 100% rename from base-helm-configs/neutron/neutron-helm-overrides.yaml rename to apps/openstack/base-helm-configs/neutron/neutron-helm-overrides.yaml diff --git a/base-helm-configs/nova/nova-helm-overrides.yaml b/apps/openstack/base-helm-configs/nova/nova-helm-overrides.yaml similarity index 100% rename from base-helm-configs/nova/nova-helm-overrides.yaml rename to apps/openstack/base-helm-configs/nova/nova-helm-overrides.yaml diff --git a/base-helm-configs/octavia/octavia-helm-overrides.yaml b/apps/openstack/base-helm-configs/octavia/octavia-helm-overrides.yaml similarity index 100% rename from base-helm-configs/octavia/octavia-helm-overrides.yaml rename to apps/openstack/base-helm-configs/octavia/octavia-helm-overrides.yaml diff --git a/base-helm-configs/monitoring/openstack-metrics-exporter/clouds-yaml b/apps/openstack/base-helm-configs/openstack-metrics-exporter/clouds-yaml similarity index 100% rename from base-helm-configs/monitoring/openstack-metrics-exporter/clouds-yaml rename to apps/openstack/base-helm-configs/openstack-metrics-exporter/clouds-yaml diff --git a/base-helm-configs/monitoring/openstack-metrics-exporter/openstack-metrics-exporter-helm-overrides.yaml b/apps/openstack/base-helm-configs/openstack-metrics-exporter/openstack-metrics-exporter-helm-overrides.yaml similarity index 100% rename from base-helm-configs/monitoring/openstack-metrics-exporter/openstack-metrics-exporter-helm-overrides.yaml rename to apps/openstack/base-helm-configs/openstack-metrics-exporter/openstack-metrics-exporter-helm-overrides.yaml diff --git a/base-helm-configs/placement/placement-helm-overrides.yaml b/apps/openstack/base-helm-configs/placement/placement-helm-overrides.yaml similarity index 100% rename from base-helm-configs/placement/placement-helm-overrides.yaml rename to apps/openstack/base-helm-configs/placement/placement-helm-overrides.yaml diff --git a/base-helm-configs/prometheus-blackbox-exporter/probe_targets.yaml b/apps/openstack/base-helm-configs/prometheus-blackbox-exporter/probe_targets.yaml similarity index 100% rename from base-helm-configs/prometheus-blackbox-exporter/probe_targets.yaml rename to apps/openstack/base-helm-configs/prometheus-blackbox-exporter/probe_targets.yaml diff --git a/base-helm-configs/prometheus-blackbox-exporter/values.yaml b/apps/openstack/base-helm-configs/prometheus-blackbox-exporter/values.yaml similarity index 100% rename from base-helm-configs/prometheus-blackbox-exporter/values.yaml rename to apps/openstack/base-helm-configs/prometheus-blackbox-exporter/values.yaml diff --git a/base-helm-configs/prometheus-snmp-exporter/values.yaml b/apps/openstack/base-helm-configs/prometheus-snmp-exporter/values.yaml similarity index 100% rename from base-helm-configs/prometheus-snmp-exporter/values.yaml rename to apps/openstack/base-helm-configs/prometheus-snmp-exporter/values.yaml diff --git a/base-kustomize/barbican/aio/kustomization.yaml b/apps/openstack/base-kustomize/barbican/aio/kustomization.yaml similarity index 100% rename from base-kustomize/barbican/aio/kustomization.yaml rename to apps/openstack/base-kustomize/barbican/aio/kustomization.yaml diff --git a/base-kustomize/barbican/base/barbican-mariadb-database.yaml b/apps/openstack/base-kustomize/barbican/base/barbican-mariadb-database.yaml similarity index 100% rename from base-kustomize/barbican/base/barbican-mariadb-database.yaml rename to apps/openstack/base-kustomize/barbican/base/barbican-mariadb-database.yaml diff --git a/base-kustomize/barbican/base/barbican-rabbitmq-queue.yaml b/apps/openstack/base-kustomize/barbican/base/barbican-rabbitmq-queue.yaml similarity index 100% rename from base-kustomize/barbican/base/barbican-rabbitmq-queue.yaml rename to apps/openstack/base-kustomize/barbican/base/barbican-rabbitmq-queue.yaml diff --git a/base-kustomize/barbican/base/hpa-barbican-api.yaml b/apps/openstack/base-kustomize/barbican/base/hpa-barbican-api.yaml similarity index 100% rename from base-kustomize/barbican/base/hpa-barbican-api.yaml rename to apps/openstack/base-kustomize/barbican/base/hpa-barbican-api.yaml diff --git a/base-kustomize/barbican/base/kustomization.yaml b/apps/openstack/base-kustomize/barbican/base/kustomization.yaml similarity index 100% rename from base-kustomize/barbican/base/kustomization.yaml rename to apps/openstack/base-kustomize/barbican/base/kustomization.yaml diff --git a/base-kustomize/barbican/base/policies.yaml b/apps/openstack/base-kustomize/barbican/base/policies.yaml similarity index 100% rename from base-kustomize/barbican/base/policies.yaml rename to apps/openstack/base-kustomize/barbican/base/policies.yaml diff --git a/base-kustomize/ceilometer/aio/kustomization.yaml b/apps/openstack/base-kustomize/ceilometer/aio/kustomization.yaml similarity index 100% rename from base-kustomize/ceilometer/aio/kustomization.yaml rename to apps/openstack/base-kustomize/ceilometer/aio/kustomization.yaml diff --git a/base-kustomize/ceilometer/base/ceilometer-rabbitmq-queue.yaml b/apps/openstack/base-kustomize/ceilometer/base/ceilometer-rabbitmq-queue.yaml similarity index 100% rename from base-kustomize/ceilometer/base/ceilometer-rabbitmq-queue.yaml rename to apps/openstack/base-kustomize/ceilometer/base/ceilometer-rabbitmq-queue.yaml diff --git a/base-kustomize/ceilometer/base/hpa-ceilometer-notification.yaml b/apps/openstack/base-kustomize/ceilometer/base/hpa-ceilometer-notification.yaml similarity index 100% rename from base-kustomize/ceilometer/base/hpa-ceilometer-notification.yaml rename to apps/openstack/base-kustomize/ceilometer/base/hpa-ceilometer-notification.yaml diff --git a/base-kustomize/ceilometer/base/kustomization.yaml b/apps/openstack/base-kustomize/ceilometer/base/kustomization.yaml similarity index 100% rename from base-kustomize/ceilometer/base/kustomization.yaml rename to apps/openstack/base-kustomize/ceilometer/base/kustomization.yaml diff --git a/base-kustomize/ceilometer/base/policies.yaml b/apps/openstack/base-kustomize/ceilometer/base/policies.yaml similarity index 100% rename from base-kustomize/ceilometer/base/policies.yaml rename to apps/openstack/base-kustomize/ceilometer/base/policies.yaml diff --git a/base-kustomize/cinder/aio/kustomization.yaml b/apps/openstack/base-kustomize/cinder/aio/kustomization.yaml similarity index 100% rename from base-kustomize/cinder/aio/kustomization.yaml rename to apps/openstack/base-kustomize/cinder/aio/kustomization.yaml diff --git a/base-kustomize/cinder/base/cinder-mariadb-database.yaml b/apps/openstack/base-kustomize/cinder/base/cinder-mariadb-database.yaml similarity index 100% rename from base-kustomize/cinder/base/cinder-mariadb-database.yaml rename to apps/openstack/base-kustomize/cinder/base/cinder-mariadb-database.yaml diff --git a/base-kustomize/cinder/base/cinder-rabbitmq-queue.yaml b/apps/openstack/base-kustomize/cinder/base/cinder-rabbitmq-queue.yaml similarity index 100% rename from base-kustomize/cinder/base/cinder-rabbitmq-queue.yaml rename to apps/openstack/base-kustomize/cinder/base/cinder-rabbitmq-queue.yaml diff --git a/base-kustomize/cinder/base/hpa-cinder-api.yaml b/apps/openstack/base-kustomize/cinder/base/hpa-cinder-api.yaml similarity index 100% rename from base-kustomize/cinder/base/hpa-cinder-api.yaml rename to apps/openstack/base-kustomize/cinder/base/hpa-cinder-api.yaml diff --git a/base-kustomize/cinder/base/hpa-cinder-scheduler.yaml b/apps/openstack/base-kustomize/cinder/base/hpa-cinder-scheduler.yaml similarity index 100% rename from base-kustomize/cinder/base/hpa-cinder-scheduler.yaml rename to apps/openstack/base-kustomize/cinder/base/hpa-cinder-scheduler.yaml diff --git a/base-kustomize/cinder/base/kustomization.yaml b/apps/openstack/base-kustomize/cinder/base/kustomization.yaml similarity index 100% rename from base-kustomize/cinder/base/kustomization.yaml rename to apps/openstack/base-kustomize/cinder/base/kustomization.yaml diff --git a/base-kustomize/cinder/base/policies.yaml b/apps/openstack/base-kustomize/cinder/base/policies.yaml similarity index 100% rename from base-kustomize/cinder/base/policies.yaml rename to apps/openstack/base-kustomize/cinder/base/policies.yaml diff --git a/base-kustomize/cinder/netapp/configmap-etc.yaml b/apps/openstack/base-kustomize/cinder/netapp/configmap-etc.yaml similarity index 100% rename from base-kustomize/cinder/netapp/configmap-etc.yaml rename to apps/openstack/base-kustomize/cinder/netapp/configmap-etc.yaml diff --git a/base-kustomize/cinder/netapp/deploy-volume-netapp.yaml b/apps/openstack/base-kustomize/cinder/netapp/deploy-volume-netapp.yaml similarity index 100% rename from base-kustomize/cinder/netapp/deploy-volume-netapp.yaml rename to apps/openstack/base-kustomize/cinder/netapp/deploy-volume-netapp.yaml diff --git a/base-kustomize/cinder/netapp/hpa-cinder-volume-netapp.yaml b/apps/openstack/base-kustomize/cinder/netapp/hpa-cinder-volume-netapp.yaml similarity index 100% rename from base-kustomize/cinder/netapp/hpa-cinder-volume-netapp.yaml rename to apps/openstack/base-kustomize/cinder/netapp/hpa-cinder-volume-netapp.yaml diff --git a/base-kustomize/cinder/netapp/kustomization.yaml b/apps/openstack/base-kustomize/cinder/netapp/kustomization.yaml similarity index 100% rename from base-kustomize/cinder/netapp/kustomization.yaml rename to apps/openstack/base-kustomize/cinder/netapp/kustomization.yaml diff --git a/base-kustomize/designate/aio/kustomization.yaml b/apps/openstack/base-kustomize/designate/aio/kustomization.yaml similarity index 100% rename from base-kustomize/designate/aio/kustomization.yaml rename to apps/openstack/base-kustomize/designate/aio/kustomization.yaml diff --git a/base-kustomize/designate/base/designate-mariadb-database.yaml b/apps/openstack/base-kustomize/designate/base/designate-mariadb-database.yaml similarity index 100% rename from base-kustomize/designate/base/designate-mariadb-database.yaml rename to apps/openstack/base-kustomize/designate/base/designate-mariadb-database.yaml diff --git a/base-kustomize/designate/base/designate-rabbitmq-queue.yaml b/apps/openstack/base-kustomize/designate/base/designate-rabbitmq-queue.yaml similarity index 100% rename from base-kustomize/designate/base/designate-rabbitmq-queue.yaml rename to apps/openstack/base-kustomize/designate/base/designate-rabbitmq-queue.yaml diff --git a/base-kustomize/designate/base/hpa-designate-api.yaml b/apps/openstack/base-kustomize/designate/base/hpa-designate-api.yaml similarity index 100% rename from base-kustomize/designate/base/hpa-designate-api.yaml rename to apps/openstack/base-kustomize/designate/base/hpa-designate-api.yaml diff --git a/base-kustomize/designate/base/kustomization.yaml b/apps/openstack/base-kustomize/designate/base/kustomization.yaml similarity index 100% rename from base-kustomize/designate/base/kustomization.yaml rename to apps/openstack/base-kustomize/designate/base/kustomization.yaml diff --git a/base-kustomize/designate/base/policies.yaml b/apps/openstack/base-kustomize/designate/base/policies.yaml similarity index 100% rename from base-kustomize/designate/base/policies.yaml rename to apps/openstack/base-kustomize/designate/base/policies.yaml diff --git a/base-kustomize/glance/aio/kustomization.yaml b/apps/openstack/base-kustomize/glance/aio/kustomization.yaml similarity index 100% rename from base-kustomize/glance/aio/kustomization.yaml rename to apps/openstack/base-kustomize/glance/aio/kustomization.yaml diff --git a/cve/requirements.txt b/apps/openstack/base-kustomize/glance/base/client-settings.yaml similarity index 100% rename from cve/requirements.txt rename to apps/openstack/base-kustomize/glance/base/client-settings.yaml diff --git a/base-kustomize/glance/base/glance-mariadb-database.yaml b/apps/openstack/base-kustomize/glance/base/glance-mariadb-database.yaml similarity index 100% rename from base-kustomize/glance/base/glance-mariadb-database.yaml rename to apps/openstack/base-kustomize/glance/base/glance-mariadb-database.yaml diff --git a/base-kustomize/glance/base/glance-rabbitmq-queue.yaml b/apps/openstack/base-kustomize/glance/base/glance-rabbitmq-queue.yaml similarity index 100% rename from base-kustomize/glance/base/glance-rabbitmq-queue.yaml rename to apps/openstack/base-kustomize/glance/base/glance-rabbitmq-queue.yaml diff --git a/base-kustomize/glance/base/hpa-glance-api.yaml b/apps/openstack/base-kustomize/glance/base/hpa-glance-api.yaml similarity index 100% rename from base-kustomize/glance/base/hpa-glance-api.yaml rename to apps/openstack/base-kustomize/glance/base/hpa-glance-api.yaml diff --git a/base-kustomize/glance/base/kustomization.yaml b/apps/openstack/base-kustomize/glance/base/kustomization.yaml similarity index 100% rename from base-kustomize/glance/base/kustomization.yaml rename to apps/openstack/base-kustomize/glance/base/kustomization.yaml diff --git a/base-kustomize/glance/base/patch-glance-bin.yaml b/apps/openstack/base-kustomize/glance/base/patch-glance-bin.yaml similarity index 100% rename from base-kustomize/glance/base/patch-glance-bin.yaml rename to apps/openstack/base-kustomize/glance/base/patch-glance-bin.yaml diff --git a/base-kustomize/glance/base/policies.yaml b/apps/openstack/base-kustomize/glance/base/policies.yaml similarity index 100% rename from base-kustomize/glance/base/policies.yaml rename to apps/openstack/base-kustomize/glance/base/policies.yaml diff --git a/base-kustomize/gnocchi/aio/kustomization.yaml b/apps/openstack/base-kustomize/gnocchi/aio/kustomization.yaml similarity index 100% rename from base-kustomize/gnocchi/aio/kustomization.yaml rename to apps/openstack/base-kustomize/gnocchi/aio/kustomization.yaml diff --git a/base-kustomize/gnocchi/base/configmap-bin.yaml b/apps/openstack/base-kustomize/gnocchi/base/configmap-bin.yaml similarity index 100% rename from base-kustomize/gnocchi/base/configmap-bin.yaml rename to apps/openstack/base-kustomize/gnocchi/base/configmap-bin.yaml diff --git a/base-kustomize/gnocchi/base/gnocchi-temp-keyring.yaml b/apps/openstack/base-kustomize/gnocchi/base/gnocchi-temp-keyring.yaml similarity index 100% rename from base-kustomize/gnocchi/base/gnocchi-temp-keyring.yaml rename to apps/openstack/base-kustomize/gnocchi/base/gnocchi-temp-keyring.yaml diff --git a/base-kustomize/gnocchi/base/hpa-gnocchi-api.yaml b/apps/openstack/base-kustomize/gnocchi/base/hpa-gnocchi-api.yaml similarity index 100% rename from base-kustomize/gnocchi/base/hpa-gnocchi-api.yaml rename to apps/openstack/base-kustomize/gnocchi/base/hpa-gnocchi-api.yaml diff --git a/base-kustomize/gnocchi/base/kustomization.yaml b/apps/openstack/base-kustomize/gnocchi/base/kustomization.yaml similarity index 100% rename from base-kustomize/gnocchi/base/kustomization.yaml rename to apps/openstack/base-kustomize/gnocchi/base/kustomization.yaml diff --git a/base-kustomize/heat/aio/kustomization.yaml b/apps/openstack/base-kustomize/heat/aio/kustomization.yaml similarity index 100% rename from base-kustomize/heat/aio/kustomization.yaml rename to apps/openstack/base-kustomize/heat/aio/kustomization.yaml diff --git a/base-kustomize/heat/base/heat-mariadb-database.yaml b/apps/openstack/base-kustomize/heat/base/heat-mariadb-database.yaml similarity index 100% rename from base-kustomize/heat/base/heat-mariadb-database.yaml rename to apps/openstack/base-kustomize/heat/base/heat-mariadb-database.yaml diff --git a/base-kustomize/heat/base/heat-rabbitmq-queue.yaml b/apps/openstack/base-kustomize/heat/base/heat-rabbitmq-queue.yaml similarity index 100% rename from base-kustomize/heat/base/heat-rabbitmq-queue.yaml rename to apps/openstack/base-kustomize/heat/base/heat-rabbitmq-queue.yaml diff --git a/base-kustomize/heat/base/hpa-heat-api.yaml b/apps/openstack/base-kustomize/heat/base/hpa-heat-api.yaml similarity index 100% rename from base-kustomize/heat/base/hpa-heat-api.yaml rename to apps/openstack/base-kustomize/heat/base/hpa-heat-api.yaml diff --git a/base-kustomize/heat/base/hpa-heat-cfn.yaml b/apps/openstack/base-kustomize/heat/base/hpa-heat-cfn.yaml similarity index 100% rename from base-kustomize/heat/base/hpa-heat-cfn.yaml rename to apps/openstack/base-kustomize/heat/base/hpa-heat-cfn.yaml diff --git a/base-kustomize/heat/base/hpa-heat-engine.yaml b/apps/openstack/base-kustomize/heat/base/hpa-heat-engine.yaml similarity index 100% rename from base-kustomize/heat/base/hpa-heat-engine.yaml rename to apps/openstack/base-kustomize/heat/base/hpa-heat-engine.yaml diff --git a/base-kustomize/heat/base/kustomization.yaml b/apps/openstack/base-kustomize/heat/base/kustomization.yaml similarity index 100% rename from base-kustomize/heat/base/kustomization.yaml rename to apps/openstack/base-kustomize/heat/base/kustomization.yaml diff --git a/base-kustomize/heat/base/policies.yaml b/apps/openstack/base-kustomize/heat/base/policies.yaml similarity index 100% rename from base-kustomize/heat/base/policies.yaml rename to apps/openstack/base-kustomize/heat/base/policies.yaml diff --git a/base-kustomize/horizon/aio/kustomization.yaml b/apps/openstack/base-kustomize/horizon/aio/kustomization.yaml similarity index 100% rename from base-kustomize/horizon/aio/kustomization.yaml rename to apps/openstack/base-kustomize/horizon/aio/kustomization.yaml diff --git a/base-kustomize/horizon/base/horizon-mariadb-database.yaml b/apps/openstack/base-kustomize/horizon/base/horizon-mariadb-database.yaml similarity index 100% rename from base-kustomize/horizon/base/horizon-mariadb-database.yaml rename to apps/openstack/base-kustomize/horizon/base/horizon-mariadb-database.yaml diff --git a/base-kustomize/horizon/base/hpa-horizon-api.yaml b/apps/openstack/base-kustomize/horizon/base/hpa-horizon-api.yaml similarity index 100% rename from base-kustomize/horizon/base/hpa-horizon-api.yaml rename to apps/openstack/base-kustomize/horizon/base/hpa-horizon-api.yaml diff --git a/base-kustomize/horizon/base/kustomization.yaml b/apps/openstack/base-kustomize/horizon/base/kustomization.yaml similarity index 100% rename from base-kustomize/horizon/base/kustomization.yaml rename to apps/openstack/base-kustomize/horizon/base/kustomization.yaml diff --git a/base-kustomize/ironic/aoi/kustomization.yaml b/apps/openstack/base-kustomize/ironic/aoi/kustomization.yaml similarity index 100% rename from base-kustomize/ironic/aoi/kustomization.yaml rename to apps/openstack/base-kustomize/ironic/aoi/kustomization.yaml diff --git a/base-kustomize/ironic/base/hpa-iconic-conductor.yaml b/apps/openstack/base-kustomize/ironic/base/hpa-iconic-conductor.yaml similarity index 100% rename from base-kustomize/ironic/base/hpa-iconic-conductor.yaml rename to apps/openstack/base-kustomize/ironic/base/hpa-iconic-conductor.yaml diff --git a/base-kustomize/ironic/base/hpa-ironic-api.yaml b/apps/openstack/base-kustomize/ironic/base/hpa-ironic-api.yaml similarity index 100% rename from base-kustomize/ironic/base/hpa-ironic-api.yaml rename to apps/openstack/base-kustomize/ironic/base/hpa-ironic-api.yaml diff --git a/base-kustomize/ironic/base/ironic-mariadb-database.yaml b/apps/openstack/base-kustomize/ironic/base/ironic-mariadb-database.yaml similarity index 100% rename from base-kustomize/ironic/base/ironic-mariadb-database.yaml rename to apps/openstack/base-kustomize/ironic/base/ironic-mariadb-database.yaml diff --git a/base-kustomize/ironic/base/ironic-rabbitmq-queue.yaml b/apps/openstack/base-kustomize/ironic/base/ironic-rabbitmq-queue.yaml similarity index 100% rename from base-kustomize/ironic/base/ironic-rabbitmq-queue.yaml rename to apps/openstack/base-kustomize/ironic/base/ironic-rabbitmq-queue.yaml diff --git a/base-kustomize/ironic/base/kustomization.yaml b/apps/openstack/base-kustomize/ironic/base/kustomization.yaml similarity index 100% rename from base-kustomize/ironic/base/kustomization.yaml rename to apps/openstack/base-kustomize/ironic/base/kustomization.yaml diff --git a/base-kustomize/ironic/base/policies.yaml b/apps/openstack/base-kustomize/ironic/base/policies.yaml similarity index 100% rename from base-kustomize/ironic/base/policies.yaml rename to apps/openstack/base-kustomize/ironic/base/policies.yaml diff --git a/base-kustomize/keystone/aio/kustomization.yaml b/apps/openstack/base-kustomize/keystone/aio/kustomization.yaml similarity index 100% rename from base-kustomize/keystone/aio/kustomization.yaml rename to apps/openstack/base-kustomize/keystone/aio/kustomization.yaml diff --git a/base-kustomize/keystone/base/hpa-keystone-api.yaml b/apps/openstack/base-kustomize/keystone/base/hpa-keystone-api.yaml similarity index 100% rename from base-kustomize/keystone/base/hpa-keystone-api.yaml rename to apps/openstack/base-kustomize/keystone/base/hpa-keystone-api.yaml diff --git a/base-kustomize/keystone/base/keystone-mariadb-database.yaml b/apps/openstack/base-kustomize/keystone/base/keystone-mariadb-database.yaml similarity index 100% rename from base-kustomize/keystone/base/keystone-mariadb-database.yaml rename to apps/openstack/base-kustomize/keystone/base/keystone-mariadb-database.yaml diff --git a/base-kustomize/keystone/base/keystone-rabbitmq-queue.yaml b/apps/openstack/base-kustomize/keystone/base/keystone-rabbitmq-queue.yaml similarity index 100% rename from base-kustomize/keystone/base/keystone-rabbitmq-queue.yaml rename to apps/openstack/base-kustomize/keystone/base/keystone-rabbitmq-queue.yaml diff --git a/base-kustomize/keystone/base/kustomization.yaml b/apps/openstack/base-kustomize/keystone/base/kustomization.yaml similarity index 100% rename from base-kustomize/keystone/base/kustomization.yaml rename to apps/openstack/base-kustomize/keystone/base/kustomization.yaml diff --git a/base-kustomize/keystone/base/policies.yaml b/apps/openstack/base-kustomize/keystone/base/policies.yaml similarity index 100% rename from base-kustomize/keystone/base/policies.yaml rename to apps/openstack/base-kustomize/keystone/base/policies.yaml diff --git a/base-kustomize/magnum/aio/kustomization.yaml b/apps/openstack/base-kustomize/magnum/aio/kustomization.yaml similarity index 100% rename from base-kustomize/magnum/aio/kustomization.yaml rename to apps/openstack/base-kustomize/magnum/aio/kustomization.yaml diff --git a/base-kustomize/magnum/base/hpa-magnum-api.yaml b/apps/openstack/base-kustomize/magnum/base/hpa-magnum-api.yaml similarity index 100% rename from base-kustomize/magnum/base/hpa-magnum-api.yaml rename to apps/openstack/base-kustomize/magnum/base/hpa-magnum-api.yaml diff --git a/base-kustomize/magnum/base/hpa-magnum-conductor.yaml b/apps/openstack/base-kustomize/magnum/base/hpa-magnum-conductor.yaml similarity index 100% rename from base-kustomize/magnum/base/hpa-magnum-conductor.yaml rename to apps/openstack/base-kustomize/magnum/base/hpa-magnum-conductor.yaml diff --git a/base-kustomize/magnum/base/kustomization.yaml b/apps/openstack/base-kustomize/magnum/base/kustomization.yaml similarity index 100% rename from base-kustomize/magnum/base/kustomization.yaml rename to apps/openstack/base-kustomize/magnum/base/kustomization.yaml diff --git a/base-kustomize/magnum/base/magnum-mariadb-database.yaml b/apps/openstack/base-kustomize/magnum/base/magnum-mariadb-database.yaml similarity index 100% rename from base-kustomize/magnum/base/magnum-mariadb-database.yaml rename to apps/openstack/base-kustomize/magnum/base/magnum-mariadb-database.yaml diff --git a/base-kustomize/magnum/base/magnum-rabbitmq-queue.yaml b/apps/openstack/base-kustomize/magnum/base/magnum-rabbitmq-queue.yaml similarity index 100% rename from base-kustomize/magnum/base/magnum-rabbitmq-queue.yaml rename to apps/openstack/base-kustomize/magnum/base/magnum-rabbitmq-queue.yaml diff --git a/base-kustomize/magnum/base/policies.yaml b/apps/openstack/base-kustomize/magnum/base/policies.yaml similarity index 100% rename from base-kustomize/magnum/base/policies.yaml rename to apps/openstack/base-kustomize/magnum/base/policies.yaml diff --git a/base-kustomize/mariadb-cluster/aio/kustomization.yaml b/apps/openstack/base-kustomize/mariadb-cluster/aio/kustomization.yaml similarity index 100% rename from base-kustomize/mariadb-cluster/aio/kustomization.yaml rename to apps/openstack/base-kustomize/mariadb-cluster/aio/kustomization.yaml diff --git a/base-kustomize/mariadb-cluster/base/kustomization.yaml b/apps/openstack/base-kustomize/mariadb-cluster/base/kustomization.yaml similarity index 100% rename from base-kustomize/mariadb-cluster/base/kustomization.yaml rename to apps/openstack/base-kustomize/mariadb-cluster/base/kustomization.yaml diff --git a/base-kustomize/mariadb-cluster/base/mariadb-backup.yaml b/apps/openstack/base-kustomize/mariadb-cluster/base/mariadb-backup.yaml similarity index 100% rename from base-kustomize/mariadb-cluster/base/mariadb-backup.yaml rename to apps/openstack/base-kustomize/mariadb-cluster/base/mariadb-backup.yaml diff --git a/base-kustomize/mariadb-cluster/base/mariadb-configmap.yaml b/apps/openstack/base-kustomize/mariadb-cluster/base/mariadb-configmap.yaml similarity index 100% rename from base-kustomize/mariadb-cluster/base/mariadb-configmap.yaml rename to apps/openstack/base-kustomize/mariadb-cluster/base/mariadb-configmap.yaml diff --git a/base-kustomize/mariadb-cluster/base/mariadb-replication.yaml b/apps/openstack/base-kustomize/mariadb-cluster/base/mariadb-replication.yaml similarity index 100% rename from base-kustomize/mariadb-cluster/base/mariadb-replication.yaml rename to apps/openstack/base-kustomize/mariadb-cluster/base/mariadb-replication.yaml diff --git a/base-kustomize/mariadb-cluster/galera/kustomization.yaml b/apps/openstack/base-kustomize/mariadb-cluster/galera/kustomization.yaml similarity index 100% rename from base-kustomize/mariadb-cluster/galera/kustomization.yaml rename to apps/openstack/base-kustomize/mariadb-cluster/galera/kustomization.yaml diff --git a/base-kustomize/memcached/aio/kustomization.yaml b/apps/openstack/base-kustomize/memcached/aio/kustomization.yaml similarity index 100% rename from base-kustomize/memcached/aio/kustomization.yaml rename to apps/openstack/base-kustomize/memcached/aio/kustomization.yaml diff --git a/base-kustomize/memcached/base/hpa.yaml b/apps/openstack/base-kustomize/memcached/base/hpa.yaml similarity index 100% rename from base-kustomize/memcached/base/hpa.yaml rename to apps/openstack/base-kustomize/memcached/base/hpa.yaml diff --git a/base-kustomize/memcached/base/kustomization.yaml b/apps/openstack/base-kustomize/memcached/base/kustomization.yaml similarity index 100% rename from base-kustomize/memcached/base/kustomization.yaml rename to apps/openstack/base-kustomize/memcached/base/kustomization.yaml diff --git a/base-kustomize/neutron/aio/kustomization.yaml b/apps/openstack/base-kustomize/neutron/aio/kustomization.yaml similarity index 100% rename from base-kustomize/neutron/aio/kustomization.yaml rename to apps/openstack/base-kustomize/neutron/aio/kustomization.yaml diff --git a/base-kustomize/neutron/base/hpa-neutron-rpc-server.yaml b/apps/openstack/base-kustomize/neutron/base/hpa-neutron-rpc-server.yaml similarity index 100% rename from base-kustomize/neutron/base/hpa-neutron-rpc-server.yaml rename to apps/openstack/base-kustomize/neutron/base/hpa-neutron-rpc-server.yaml diff --git a/base-kustomize/neutron/base/hpa-neutron-server.yaml b/apps/openstack/base-kustomize/neutron/base/hpa-neutron-server.yaml similarity index 100% rename from base-kustomize/neutron/base/hpa-neutron-server.yaml rename to apps/openstack/base-kustomize/neutron/base/hpa-neutron-server.yaml diff --git a/base-kustomize/neutron/base/kustomization.yaml b/apps/openstack/base-kustomize/neutron/base/kustomization.yaml similarity index 100% rename from base-kustomize/neutron/base/kustomization.yaml rename to apps/openstack/base-kustomize/neutron/base/kustomization.yaml diff --git a/base-kustomize/neutron/base/neutron-mariadb-database.yaml b/apps/openstack/base-kustomize/neutron/base/neutron-mariadb-database.yaml similarity index 100% rename from base-kustomize/neutron/base/neutron-mariadb-database.yaml rename to apps/openstack/base-kustomize/neutron/base/neutron-mariadb-database.yaml diff --git a/base-kustomize/neutron/base/neutron-rabbitmq-queue.yaml b/apps/openstack/base-kustomize/neutron/base/neutron-rabbitmq-queue.yaml similarity index 100% rename from base-kustomize/neutron/base/neutron-rabbitmq-queue.yaml rename to apps/openstack/base-kustomize/neutron/base/neutron-rabbitmq-queue.yaml diff --git a/base-kustomize/neutron/base/policies.yaml b/apps/openstack/base-kustomize/neutron/base/policies.yaml similarity index 100% rename from base-kustomize/neutron/base/policies.yaml rename to apps/openstack/base-kustomize/neutron/base/policies.yaml diff --git a/base-kustomize/nova/aio/kustomization.yaml b/apps/openstack/base-kustomize/nova/aio/kustomization.yaml similarity index 100% rename from base-kustomize/nova/aio/kustomization.yaml rename to apps/openstack/base-kustomize/nova/aio/kustomization.yaml diff --git a/base-kustomize/nova/base/hpa-nova-api-metadata.yaml b/apps/openstack/base-kustomize/nova/base/hpa-nova-api-metadata.yaml similarity index 100% rename from base-kustomize/nova/base/hpa-nova-api-metadata.yaml rename to apps/openstack/base-kustomize/nova/base/hpa-nova-api-metadata.yaml diff --git a/base-kustomize/nova/base/hpa-nova-api-osapi.yaml b/apps/openstack/base-kustomize/nova/base/hpa-nova-api-osapi.yaml similarity index 100% rename from base-kustomize/nova/base/hpa-nova-api-osapi.yaml rename to apps/openstack/base-kustomize/nova/base/hpa-nova-api-osapi.yaml diff --git a/base-kustomize/nova/base/hpa-nova-conductor.yaml b/apps/openstack/base-kustomize/nova/base/hpa-nova-conductor.yaml similarity index 100% rename from base-kustomize/nova/base/hpa-nova-conductor.yaml rename to apps/openstack/base-kustomize/nova/base/hpa-nova-conductor.yaml diff --git a/base-kustomize/nova/base/hpa-nova-novncproxy.yaml b/apps/openstack/base-kustomize/nova/base/hpa-nova-novncproxy.yaml similarity index 100% rename from base-kustomize/nova/base/hpa-nova-novncproxy.yaml rename to apps/openstack/base-kustomize/nova/base/hpa-nova-novncproxy.yaml diff --git a/base-kustomize/nova/base/hpa-nova-scheduler.yaml b/apps/openstack/base-kustomize/nova/base/hpa-nova-scheduler.yaml similarity index 100% rename from base-kustomize/nova/base/hpa-nova-scheduler.yaml rename to apps/openstack/base-kustomize/nova/base/hpa-nova-scheduler.yaml diff --git a/base-kustomize/nova/base/kustomization.yaml b/apps/openstack/base-kustomize/nova/base/kustomization.yaml similarity index 100% rename from base-kustomize/nova/base/kustomization.yaml rename to apps/openstack/base-kustomize/nova/base/kustomization.yaml diff --git a/base-kustomize/nova/base/nova-mariadb-database.yaml b/apps/openstack/base-kustomize/nova/base/nova-mariadb-database.yaml similarity index 100% rename from base-kustomize/nova/base/nova-mariadb-database.yaml rename to apps/openstack/base-kustomize/nova/base/nova-mariadb-database.yaml diff --git a/base-kustomize/nova/base/nova-rabbitmq-queue.yaml b/apps/openstack/base-kustomize/nova/base/nova-rabbitmq-queue.yaml similarity index 100% rename from base-kustomize/nova/base/nova-rabbitmq-queue.yaml rename to apps/openstack/base-kustomize/nova/base/nova-rabbitmq-queue.yaml diff --git a/base-kustomize/nova/base/policies.yaml b/apps/openstack/base-kustomize/nova/base/policies.yaml similarity index 100% rename from base-kustomize/nova/base/policies.yaml rename to apps/openstack/base-kustomize/nova/base/policies.yaml diff --git a/base-kustomize/octavia/aio/kustomization.yaml b/apps/openstack/base-kustomize/octavia/aio/kustomization.yaml similarity index 100% rename from base-kustomize/octavia/aio/kustomization.yaml rename to apps/openstack/base-kustomize/octavia/aio/kustomization.yaml diff --git a/base-kustomize/octavia/base/hpa-octavia-api.yaml b/apps/openstack/base-kustomize/octavia/base/hpa-octavia-api.yaml similarity index 100% rename from base-kustomize/octavia/base/hpa-octavia-api.yaml rename to apps/openstack/base-kustomize/octavia/base/hpa-octavia-api.yaml diff --git a/base-kustomize/octavia/base/hpa-octavia-worker.yaml b/apps/openstack/base-kustomize/octavia/base/hpa-octavia-worker.yaml similarity index 100% rename from base-kustomize/octavia/base/hpa-octavia-worker.yaml rename to apps/openstack/base-kustomize/octavia/base/hpa-octavia-worker.yaml diff --git a/base-kustomize/octavia/base/kustomization.yaml b/apps/openstack/base-kustomize/octavia/base/kustomization.yaml similarity index 100% rename from base-kustomize/octavia/base/kustomization.yaml rename to apps/openstack/base-kustomize/octavia/base/kustomization.yaml diff --git a/base-kustomize/octavia/base/octavia-agent.yaml b/apps/openstack/base-kustomize/octavia/base/octavia-agent.yaml similarity index 100% rename from base-kustomize/octavia/base/octavia-agent.yaml rename to apps/openstack/base-kustomize/octavia/base/octavia-agent.yaml diff --git a/base-kustomize/octavia/base/octavia-mariadb-database.yaml b/apps/openstack/base-kustomize/octavia/base/octavia-mariadb-database.yaml similarity index 100% rename from base-kustomize/octavia/base/octavia-mariadb-database.yaml rename to apps/openstack/base-kustomize/octavia/base/octavia-mariadb-database.yaml diff --git a/base-kustomize/octavia/base/octavia-rabbitmq-queue.yaml b/apps/openstack/base-kustomize/octavia/base/octavia-rabbitmq-queue.yaml similarity index 100% rename from base-kustomize/octavia/base/octavia-rabbitmq-queue.yaml rename to apps/openstack/base-kustomize/octavia/base/octavia-rabbitmq-queue.yaml diff --git a/base-kustomize/octavia/base/policies.yaml b/apps/openstack/base-kustomize/octavia/base/policies.yaml similarity index 100% rename from base-kustomize/octavia/base/policies.yaml rename to apps/openstack/base-kustomize/octavia/base/policies.yaml diff --git a/base-kustomize/openstack/base/issuer-kube-system-selfsigned.yaml b/apps/openstack/base-kustomize/openstack/base/issuer-kube-system-selfsigned.yaml similarity index 100% rename from base-kustomize/openstack/base/issuer-kube-system-selfsigned.yaml rename to apps/openstack/base-kustomize/openstack/base/issuer-kube-system-selfsigned.yaml diff --git a/base-kustomize/openstack/base/kustomization.yaml b/apps/openstack/base-kustomize/openstack/base/kustomization.yaml similarity index 100% rename from base-kustomize/openstack/base/kustomization.yaml rename to apps/openstack/base-kustomize/openstack/base/kustomization.yaml diff --git a/base-kustomize/openstack/base/ns-openstack.yaml b/apps/openstack/base-kustomize/openstack/base/ns-openstack.yaml similarity index 100% rename from base-kustomize/openstack/base/ns-openstack.yaml rename to apps/openstack/base-kustomize/openstack/base/ns-openstack.yaml diff --git a/base-kustomize/placement/aio/kustomization.yaml b/apps/openstack/base-kustomize/placement/aio/kustomization.yaml similarity index 100% rename from base-kustomize/placement/aio/kustomization.yaml rename to apps/openstack/base-kustomize/placement/aio/kustomization.yaml diff --git a/base-kustomize/placement/base/hpa-placement-api.yaml b/apps/openstack/base-kustomize/placement/base/hpa-placement-api.yaml similarity index 100% rename from base-kustomize/placement/base/hpa-placement-api.yaml rename to apps/openstack/base-kustomize/placement/base/hpa-placement-api.yaml diff --git a/base-kustomize/placement/base/kustomization.yaml b/apps/openstack/base-kustomize/placement/base/kustomization.yaml similarity index 100% rename from base-kustomize/placement/base/kustomization.yaml rename to apps/openstack/base-kustomize/placement/base/kustomization.yaml diff --git a/base-kustomize/placement/base/placement-mariadb-database.yaml b/apps/openstack/base-kustomize/placement/base/placement-mariadb-database.yaml similarity index 100% rename from base-kustomize/placement/base/placement-mariadb-database.yaml rename to apps/openstack/base-kustomize/placement/base/placement-mariadb-database.yaml diff --git a/base-kustomize/placement/base/policies.yaml b/apps/openstack/base-kustomize/placement/base/policies.yaml similarity index 100% rename from base-kustomize/placement/base/policies.yaml rename to apps/openstack/base-kustomize/placement/base/policies.yaml diff --git a/base-kustomize/prometheus-blackbox-exporter/base/kustomization.yaml b/apps/openstack/base-kustomize/prometheus-blackbox-exporter/base/kustomization.yaml similarity index 100% rename from base-kustomize/prometheus-blackbox-exporter/base/kustomization.yaml rename to apps/openstack/base-kustomize/prometheus-blackbox-exporter/base/kustomization.yaml diff --git a/base-kustomize/rabbitmq-cluster/aio/kustomization.yaml b/apps/openstack/base-kustomize/rabbitmq-cluster/aio/kustomization.yaml similarity index 100% rename from base-kustomize/rabbitmq-cluster/aio/kustomization.yaml rename to apps/openstack/base-kustomize/rabbitmq-cluster/aio/kustomization.yaml diff --git a/base-kustomize/rabbitmq-cluster/base/kustomization.yaml b/apps/openstack/base-kustomize/rabbitmq-cluster/base/kustomization.yaml similarity index 100% rename from base-kustomize/rabbitmq-cluster/base/kustomization.yaml rename to apps/openstack/base-kustomize/rabbitmq-cluster/base/kustomization.yaml diff --git a/base-kustomize/rabbitmq-cluster/base/rabbitmq-cluster.yaml b/apps/openstack/base-kustomize/rabbitmq-cluster/base/rabbitmq-cluster.yaml similarity index 100% rename from base-kustomize/rabbitmq-cluster/base/rabbitmq-cluster.yaml rename to apps/openstack/base-kustomize/rabbitmq-cluster/base/rabbitmq-cluster.yaml diff --git a/apps/openstack/bin/backup-mariadb.sh b/apps/openstack/bin/backup-mariadb.sh new file mode 100755 index 000000000..e8e02773e --- /dev/null +++ b/apps/openstack/bin/backup-mariadb.sh @@ -0,0 +1,46 @@ +#!/bin/bash +# shellcheck disable=SC2124,SC2145,SC2294,SC2086 + +# The script is used to backup the mariadb database in the openstack namespace +# The script will create a backup directory in the HOME directory with the current timestamp +# The script will dump all the databases except the performance_schema and information_schema +# The script will use the root password from the mariadb secret to connect to the database +# The script will use the clusterIP of the mariadb-cluster service to connect to the database +# The script will use the --column-statistics=0 option if available in the mysqldump command +# The script will create a separate dump file for each database + +set -e +set -o pipefail + +BACKUP_DIR="${HOME}/backup/mariadb/$(date +%s)" +MYSQL_PASSWORD="$(kubectl --namespace openstack get secret mariadb -o jsonpath='{.data.root-password}' | base64 -d)" +MYSQL_HOST=$(kubectl -n openstack get service mariadb-cluster -o jsonpath='{.spec.clusterIP}') + +if mysqldump --help | grep -q column-statistics; then + MYSQL_DUMP_COLLUMN_STATISTICS="--column-statistics=0" +else + MYSQL_DUMP_COLLUMN_STATISTICS="" +fi + +mkdir -p "${BACKUP_DIR}" + +pushd "${BACKUP_DIR}" + mysql -h ${MYSQL_HOST} \ + -u root \ + -p${MYSQL_PASSWORD} \ + -e 'show databases;' \ + --column-names=false \ + --vertical | \ + awk '/[:alnum:]/ && ! /performance_schema/ && ! /information_schema/' | \ + xargs -i mysqldump --host=${MYSQL_HOST} ${MYSQL_DUMP_COLLUMN_STATISTICS} \ + --user=root \ + --password=${MYSQL_PASSWORD} \ + --single-transaction \ + --routines \ + --triggers \ + --events \ + --result-file={} \ + {} +popd + +echo -e "backup complete and available at ${BACKUP_DIR}" diff --git a/bin/chart-install-meta.yaml b/apps/openstack/bin/chart-install-meta.yaml similarity index 100% rename from bin/chart-install-meta.yaml rename to apps/openstack/bin/chart-install-meta.yaml diff --git a/bin/create-secrets.sh b/apps/openstack/bin/create-secrets.sh similarity index 100% rename from bin/create-secrets.sh rename to apps/openstack/bin/create-secrets.sh diff --git a/bin/install-barbican.sh b/apps/openstack/bin/install-barbican.sh similarity index 100% rename from bin/install-barbican.sh rename to apps/openstack/bin/install-barbican.sh diff --git a/bin/install-ceilometer.sh b/apps/openstack/bin/install-ceilometer.sh similarity index 100% rename from bin/install-ceilometer.sh rename to apps/openstack/bin/install-ceilometer.sh diff --git a/bin/install-chart.sh b/apps/openstack/bin/install-chart.sh similarity index 100% rename from bin/install-chart.sh rename to apps/openstack/bin/install-chart.sh diff --git a/bin/install-cinder.sh b/apps/openstack/bin/install-cinder.sh similarity index 100% rename from bin/install-cinder.sh rename to apps/openstack/bin/install-cinder.sh diff --git a/bin/install-glance.sh b/apps/openstack/bin/install-glance.sh similarity index 100% rename from bin/install-glance.sh rename to apps/openstack/bin/install-glance.sh diff --git a/bin/install-gnocchi.sh b/apps/openstack/bin/install-gnocchi.sh similarity index 100% rename from bin/install-gnocchi.sh rename to apps/openstack/bin/install-gnocchi.sh diff --git a/bin/install-grafana.sh b/apps/openstack/bin/install-grafana.sh similarity index 100% rename from bin/install-grafana.sh rename to apps/openstack/bin/install-grafana.sh diff --git a/bin/install-heat.sh b/apps/openstack/bin/install-heat.sh similarity index 100% rename from bin/install-heat.sh rename to apps/openstack/bin/install-heat.sh diff --git a/bin/install-horizon.sh b/apps/openstack/bin/install-horizon.sh similarity index 100% rename from bin/install-horizon.sh rename to apps/openstack/bin/install-horizon.sh diff --git a/bin/install-ironic.sh b/apps/openstack/bin/install-ironic.sh similarity index 100% rename from bin/install-ironic.sh rename to apps/openstack/bin/install-ironic.sh diff --git a/bin/install-keystone.sh b/apps/openstack/bin/install-keystone.sh similarity index 100% rename from bin/install-keystone.sh rename to apps/openstack/bin/install-keystone.sh diff --git a/bin/install-libvirt.sh b/apps/openstack/bin/install-libvirt.sh similarity index 100% rename from bin/install-libvirt.sh rename to apps/openstack/bin/install-libvirt.sh diff --git a/bin/install-magnum.sh b/apps/openstack/bin/install-magnum.sh similarity index 100% rename from bin/install-magnum.sh rename to apps/openstack/bin/install-magnum.sh diff --git a/bin/install-memcached.sh b/apps/openstack/bin/install-memcached.sh similarity index 100% rename from bin/install-memcached.sh rename to apps/openstack/bin/install-memcached.sh diff --git a/bin/install-metallb.sh b/apps/openstack/bin/install-metallb.sh similarity index 100% rename from bin/install-metallb.sh rename to apps/openstack/bin/install-metallb.sh diff --git a/bin/install-neutron.sh b/apps/openstack/bin/install-neutron.sh similarity index 100% rename from bin/install-neutron.sh rename to apps/openstack/bin/install-neutron.sh diff --git a/bin/install-nova.sh b/apps/openstack/bin/install-nova.sh similarity index 100% rename from bin/install-nova.sh rename to apps/openstack/bin/install-nova.sh diff --git a/bin/install-octavia.sh b/apps/openstack/bin/install-octavia.sh similarity index 100% rename from bin/install-octavia.sh rename to apps/openstack/bin/install-octavia.sh diff --git a/bin/install-placement.sh b/apps/openstack/bin/install-placement.sh similarity index 100% rename from bin/install-placement.sh rename to apps/openstack/bin/install-placement.sh diff --git a/bin/install-skyline.sh b/apps/openstack/bin/install-skyline.sh similarity index 100% rename from bin/install-skyline.sh rename to apps/openstack/bin/install-skyline.sh diff --git a/bin/label-nodes.sh b/apps/openstack/bin/label-nodes.sh similarity index 100% rename from bin/label-nodes.sh rename to apps/openstack/bin/label-nodes.sh diff --git a/bin/setup-infrastructure.sh b/apps/openstack/bin/setup-infrastructure.sh similarity index 100% rename from bin/setup-infrastructure.sh rename to apps/openstack/bin/setup-infrastructure.sh diff --git a/bin/setup-openstack-rc.sh b/apps/openstack/bin/setup-openstack-rc.sh similarity index 100% rename from bin/setup-openstack-rc.sh rename to apps/openstack/bin/setup-openstack-rc.sh diff --git a/bin/setup-openstack.sh b/apps/openstack/bin/setup-openstack.sh similarity index 100% rename from bin/setup-openstack.sh rename to apps/openstack/bin/setup-openstack.sh diff --git a/bin/yamlparse.py b/apps/openstack/bin/yamlparse.py similarity index 100% rename from bin/yamlparse.py rename to apps/openstack/bin/yamlparse.py diff --git a/etc/keystone/mapping.json b/apps/openstack/configs/keystone/mapping.json similarity index 100% rename from etc/keystone/mapping.json rename to apps/openstack/configs/keystone/mapping.json diff --git a/etc/gateway-api/listeners/barbican-https.json b/apps/openstack/gateway-api/listeners/barbican-https.json similarity index 100% rename from etc/gateway-api/listeners/barbican-https.json rename to apps/openstack/gateway-api/listeners/barbican-https.json diff --git a/etc/gateway-api/listeners/cinder-https.json b/apps/openstack/gateway-api/listeners/cinder-https.json similarity index 100% rename from etc/gateway-api/listeners/cinder-https.json rename to apps/openstack/gateway-api/listeners/cinder-https.json diff --git a/etc/gateway-api/listeners/cloudformation-https.json b/apps/openstack/gateway-api/listeners/cloudformation-https.json similarity index 100% rename from etc/gateway-api/listeners/cloudformation-https.json rename to apps/openstack/gateway-api/listeners/cloudformation-https.json diff --git a/etc/gateway-api/listeners/glance-https.json b/apps/openstack/gateway-api/listeners/glance-https.json similarity index 100% rename from etc/gateway-api/listeners/glance-https.json rename to apps/openstack/gateway-api/listeners/glance-https.json diff --git a/etc/gateway-api/listeners/gnocchi-https.json b/apps/openstack/gateway-api/listeners/gnocchi-https.json similarity index 100% rename from etc/gateway-api/listeners/gnocchi-https.json rename to apps/openstack/gateway-api/listeners/gnocchi-https.json diff --git a/etc/gateway-api/listeners/grafana-https.json b/apps/openstack/gateway-api/listeners/grafana-https.json similarity index 100% rename from etc/gateway-api/listeners/grafana-https.json rename to apps/openstack/gateway-api/listeners/grafana-https.json diff --git a/etc/gateway-api/listeners/heat-https.json b/apps/openstack/gateway-api/listeners/heat-https.json similarity index 100% rename from etc/gateway-api/listeners/heat-https.json rename to apps/openstack/gateway-api/listeners/heat-https.json diff --git a/etc/gateway-api/listeners/keystone-https.json b/apps/openstack/gateway-api/listeners/keystone-https.json similarity index 100% rename from etc/gateway-api/listeners/keystone-https.json rename to apps/openstack/gateway-api/listeners/keystone-https.json diff --git a/etc/gateway-api/listeners/loki-https.json b/apps/openstack/gateway-api/listeners/loki-https.json similarity index 100% rename from etc/gateway-api/listeners/loki-https.json rename to apps/openstack/gateway-api/listeners/loki-https.json diff --git a/etc/gateway-api/listeners/magnum-https.json b/apps/openstack/gateway-api/listeners/magnum-https.json similarity index 100% rename from etc/gateway-api/listeners/magnum-https.json rename to apps/openstack/gateway-api/listeners/magnum-https.json diff --git a/etc/gateway-api/listeners/metadata-https.json b/apps/openstack/gateway-api/listeners/metadata-https.json similarity index 100% rename from etc/gateway-api/listeners/metadata-https.json rename to apps/openstack/gateway-api/listeners/metadata-https.json diff --git a/etc/gateway-api/listeners/neutron-https.json b/apps/openstack/gateway-api/listeners/neutron-https.json similarity index 100% rename from etc/gateway-api/listeners/neutron-https.json rename to apps/openstack/gateway-api/listeners/neutron-https.json diff --git a/etc/gateway-api/listeners/nova-https.json b/apps/openstack/gateway-api/listeners/nova-https.json similarity index 100% rename from etc/gateway-api/listeners/nova-https.json rename to apps/openstack/gateway-api/listeners/nova-https.json diff --git a/etc/gateway-api/listeners/novnc-https.json b/apps/openstack/gateway-api/listeners/novnc-https.json similarity index 100% rename from etc/gateway-api/listeners/novnc-https.json rename to apps/openstack/gateway-api/listeners/novnc-https.json diff --git a/etc/gateway-api/listeners/octavia-https.json b/apps/openstack/gateway-api/listeners/octavia-https.json similarity index 100% rename from etc/gateway-api/listeners/octavia-https.json rename to apps/openstack/gateway-api/listeners/octavia-https.json diff --git a/etc/gateway-api/listeners/placement-https.json b/apps/openstack/gateway-api/listeners/placement-https.json similarity index 100% rename from etc/gateway-api/listeners/placement-https.json rename to apps/openstack/gateway-api/listeners/placement-https.json diff --git a/etc/gateway-api/listeners/skyline-https.json b/apps/openstack/gateway-api/listeners/skyline-https.json similarity index 100% rename from etc/gateway-api/listeners/skyline-https.json rename to apps/openstack/gateway-api/listeners/skyline-https.json diff --git a/etc/gateway-api/routes/custom-alertmanager-routes.yaml b/apps/openstack/gateway-api/routes/custom-alertmanager-routes.yaml similarity index 100% rename from etc/gateway-api/routes/custom-alertmanager-routes.yaml rename to apps/openstack/gateway-api/routes/custom-alertmanager-routes.yaml diff --git a/etc/gateway-api/routes/custom-barbican-gateway-route.yaml b/apps/openstack/gateway-api/routes/custom-barbican-gateway-route.yaml similarity index 100% rename from etc/gateway-api/routes/custom-barbican-gateway-route.yaml rename to apps/openstack/gateway-api/routes/custom-barbican-gateway-route.yaml diff --git a/etc/gateway-api/routes/custom-cinder-gateway-route.yaml b/apps/openstack/gateway-api/routes/custom-cinder-gateway-route.yaml similarity index 100% rename from etc/gateway-api/routes/custom-cinder-gateway-route.yaml rename to apps/openstack/gateway-api/routes/custom-cinder-gateway-route.yaml diff --git a/etc/gateway-api/routes/custom-cloudformation-gateway-route.yaml b/apps/openstack/gateway-api/routes/custom-cloudformation-gateway-route.yaml similarity index 100% rename from etc/gateway-api/routes/custom-cloudformation-gateway-route.yaml rename to apps/openstack/gateway-api/routes/custom-cloudformation-gateway-route.yaml diff --git a/etc/gateway-api/routes/custom-glance-gateway-route.yaml b/apps/openstack/gateway-api/routes/custom-glance-gateway-route.yaml similarity index 100% rename from etc/gateway-api/routes/custom-glance-gateway-route.yaml rename to apps/openstack/gateway-api/routes/custom-glance-gateway-route.yaml diff --git a/etc/gateway-api/routes/custom-gnocchi-gateway-route.yaml b/apps/openstack/gateway-api/routes/custom-gnocchi-gateway-route.yaml similarity index 100% rename from etc/gateway-api/routes/custom-gnocchi-gateway-route.yaml rename to apps/openstack/gateway-api/routes/custom-gnocchi-gateway-route.yaml diff --git a/etc/gateway-api/routes/custom-grafana-routes.yaml b/apps/openstack/gateway-api/routes/custom-grafana-routes.yaml similarity index 100% rename from etc/gateway-api/routes/custom-grafana-routes.yaml rename to apps/openstack/gateway-api/routes/custom-grafana-routes.yaml diff --git a/etc/gateway-api/routes/custom-heat-gateway-route.yaml b/apps/openstack/gateway-api/routes/custom-heat-gateway-route.yaml similarity index 100% rename from etc/gateway-api/routes/custom-heat-gateway-route.yaml rename to apps/openstack/gateway-api/routes/custom-heat-gateway-route.yaml diff --git a/etc/gateway-api/routes/custom-keystone-gateway-route.yaml b/apps/openstack/gateway-api/routes/custom-keystone-gateway-route.yaml similarity index 100% rename from etc/gateway-api/routes/custom-keystone-gateway-route.yaml rename to apps/openstack/gateway-api/routes/custom-keystone-gateway-route.yaml diff --git a/etc/gateway-api/routes/custom-loki-internal-routes.yaml b/apps/openstack/gateway-api/routes/custom-loki-internal-routes.yaml similarity index 100% rename from etc/gateway-api/routes/custom-loki-internal-routes.yaml rename to apps/openstack/gateway-api/routes/custom-loki-internal-routes.yaml diff --git a/etc/gateway-api/routes/custom-magnum-gateway-route.yaml b/apps/openstack/gateway-api/routes/custom-magnum-gateway-route.yaml similarity index 100% rename from etc/gateway-api/routes/custom-magnum-gateway-route.yaml rename to apps/openstack/gateway-api/routes/custom-magnum-gateway-route.yaml diff --git a/etc/gateway-api/routes/custom-metadata-gateway-route.yaml b/apps/openstack/gateway-api/routes/custom-metadata-gateway-route.yaml similarity index 100% rename from etc/gateway-api/routes/custom-metadata-gateway-route.yaml rename to apps/openstack/gateway-api/routes/custom-metadata-gateway-route.yaml diff --git a/etc/gateway-api/routes/custom-neutron-gateway-route.yaml b/apps/openstack/gateway-api/routes/custom-neutron-gateway-route.yaml similarity index 100% rename from etc/gateway-api/routes/custom-neutron-gateway-route.yaml rename to apps/openstack/gateway-api/routes/custom-neutron-gateway-route.yaml diff --git a/etc/gateway-api/routes/custom-nova-gateway-route.yaml b/apps/openstack/gateway-api/routes/custom-nova-gateway-route.yaml similarity index 100% rename from etc/gateway-api/routes/custom-nova-gateway-route.yaml rename to apps/openstack/gateway-api/routes/custom-nova-gateway-route.yaml diff --git a/etc/gateway-api/routes/custom-novnc-gateway-route.yaml b/apps/openstack/gateway-api/routes/custom-novnc-gateway-route.yaml similarity index 100% rename from etc/gateway-api/routes/custom-novnc-gateway-route.yaml rename to apps/openstack/gateway-api/routes/custom-novnc-gateway-route.yaml diff --git a/etc/gateway-api/routes/custom-octavia-gateway-route.yaml b/apps/openstack/gateway-api/routes/custom-octavia-gateway-route.yaml similarity index 100% rename from etc/gateway-api/routes/custom-octavia-gateway-route.yaml rename to apps/openstack/gateway-api/routes/custom-octavia-gateway-route.yaml diff --git a/etc/gateway-api/routes/custom-placement-gateway-route.yaml b/apps/openstack/gateway-api/routes/custom-placement-gateway-route.yaml similarity index 100% rename from etc/gateway-api/routes/custom-placement-gateway-route.yaml rename to apps/openstack/gateway-api/routes/custom-placement-gateway-route.yaml diff --git a/etc/gateway-api/routes/custom-prometheus-gateway-route.yaml b/apps/openstack/gateway-api/routes/custom-prometheus-gateway-route.yaml similarity index 100% rename from etc/gateway-api/routes/custom-prometheus-gateway-route.yaml rename to apps/openstack/gateway-api/routes/custom-prometheus-gateway-route.yaml diff --git a/etc/gateway-api/routes/custom-skyline-gateway-route.yaml b/apps/openstack/gateway-api/routes/custom-skyline-gateway-route.yaml similarity index 100% rename from etc/gateway-api/routes/custom-skyline-gateway-route.yaml rename to apps/openstack/gateway-api/routes/custom-skyline-gateway-route.yaml diff --git a/etc/gateway-api/routes/http-wildcard-listener.yaml b/apps/openstack/gateway-api/routes/http-wildcard-listener.yaml similarity index 100% rename from etc/gateway-api/routes/http-wildcard-listener.yaml rename to apps/openstack/gateway-api/routes/http-wildcard-listener.yaml diff --git a/manifests/metallb/metallb-openstack-service-lb.yml b/apps/openstack/manifests/metallb-openstack-service-lb.yml similarity index 100% rename from manifests/metallb/metallb-openstack-service-lb.yml rename to apps/openstack/manifests/metallb-openstack-service-lb.yml diff --git a/manifests/utils/utils-openstack-client-admin.yaml b/apps/openstack/manifests/utils-openstack-client-admin.yaml similarity index 100% rename from manifests/utils/utils-openstack-client-admin.yaml rename to apps/openstack/manifests/utils-openstack-client-admin.yaml diff --git a/apps/openstack/requirements.txt b/apps/openstack/requirements.txt new file mode 100644 index 000000000..7a1538248 --- /dev/null +++ b/apps/openstack/requirements.txt @@ -0,0 +1,14 @@ +ansible>9.0,<10.0 +ansible-core<2.17.0 +cryptography==43.0.1 +jinja2==3.1.5 +jmespath==1.0.1 +jsonschema<=4.23.0 +MarkupSafe==2.1.3 +netaddr==0.9.0 +pbr==5.11.1 +ruamel.yaml==0.18.6 +ruamel.yaml.clib==0.2.8 +kubernetes>=24.2.0 +openstacksdk>=1.0.0 +python-openstackclient==7.4.0 diff --git a/apps/openstack/requirements.yml b/apps/openstack/requirements.yml new file mode 100644 index 000000000..0698a0c6e --- /dev/null +++ b/apps/openstack/requirements.yml @@ -0,0 +1,13 @@ +collections: + - name: https://opendev.org/openstack/ansible-collections-openstack + version: 2.2.0 + type: git + - name: https://github.com/ansible-collections/ansible.posix + version: 1.5.4 + type: git + - name: https://github.com/ansible-collections/community.general + version: 8.2.0 + type: git + - name: https://github.com/ansible-collections/kubernetes.core + version: 3.2.0 + type: git diff --git a/base-helm-configs/grafana/azure-overrides.yaml.example b/base-helm-configs/grafana-operator/azure-overrides.yaml.example similarity index 100% rename from base-helm-configs/grafana/azure-overrides.yaml.example rename to base-helm-configs/grafana-operator/azure-overrides.yaml.example diff --git a/base-helm-configs/grafana/grafana-helm-overrides.yaml b/base-helm-configs/grafana-operator/grafana-helm-overrides.yaml similarity index 100% rename from base-helm-configs/grafana/grafana-helm-overrides.yaml rename to base-helm-configs/grafana-operator/grafana-helm-overrides.yaml diff --git a/base-helm-configs/memcached/memcached-helm-overrides.yaml b/base-helm-configs/memcached-operator/memcached-helm-overrides.yaml similarity index 100% rename from base-helm-configs/memcached/memcached-helm-overrides.yaml rename to base-helm-configs/memcached-operator/memcached-helm-overrides.yaml diff --git a/base-helm-configs/prometheus/alertmanager_config.yaml b/base-helm-configs/prometheus-operator/alertmanager_config.yaml similarity index 100% rename from base-helm-configs/prometheus/alertmanager_config.yaml rename to base-helm-configs/prometheus-operator/alertmanager_config.yaml diff --git a/base-helm-configs/prometheus/prometheus-helm-overrides.yaml b/base-helm-configs/prometheus-operator/prometheus-helm-overrides.yaml similarity index 100% rename from base-helm-configs/prometheus/prometheus-helm-overrides.yaml rename to base-helm-configs/prometheus-operator/prometheus-helm-overrides.yaml diff --git a/base-helm-configs/prometheus/rules/alerting_rules.yaml b/base-helm-configs/prometheus-operator/rules/alerting_rules.yaml similarity index 100% rename from base-helm-configs/prometheus/rules/alerting_rules.yaml rename to base-helm-configs/prometheus-operator/rules/alerting_rules.yaml diff --git a/base-helm-configs/prometheus/rules/mariadb_alerting_rules.yaml b/base-helm-configs/prometheus-operator/rules/mariadb_alerting_rules.yaml similarity index 100% rename from base-helm-configs/prometheus/rules/mariadb_alerting_rules.yaml rename to base-helm-configs/prometheus-operator/rules/mariadb_alerting_rules.yaml diff --git a/base-helm-configs/prometheus/rules/pod_alerting_rules.yaml b/base-helm-configs/prometheus-operator/rules/pod_alerting_rules.yaml similarity index 100% rename from base-helm-configs/prometheus/rules/pod_alerting_rules.yaml rename to base-helm-configs/prometheus-operator/rules/pod_alerting_rules.yaml diff --git a/base-helm-configs/prometheus/rules/rabbitmq_alerting_rules.yaml b/base-helm-configs/prometheus-operator/rules/rabbitmq_alerting_rules.yaml similarity index 100% rename from base-helm-configs/prometheus/rules/rabbitmq_alerting_rules.yaml rename to base-helm-configs/prometheus-operator/rules/rabbitmq_alerting_rules.yaml diff --git a/base-kustomize/backups/base/etcd/etcd-backup.yaml b/base-kustomize/etcd-backup/base/etcd/etcd-backup.yaml similarity index 100% rename from base-kustomize/backups/base/etcd/etcd-backup.yaml rename to base-kustomize/etcd-backup/base/etcd/etcd-backup.yaml diff --git a/base-kustomize/backups/base/kustomization.yaml b/base-kustomize/etcd-backup/base/kustomization.yaml similarity index 100% rename from base-kustomize/backups/base/kustomization.yaml rename to base-kustomize/etcd-backup/base/kustomization.yaml diff --git a/cve/filter.py b/cve/filter.py deleted file mode 100644 index a9f4f3ffe..000000000 --- a/cve/filter.py +++ /dev/null @@ -1,36 +0,0 @@ -import json - -try: - with open("installed.json") as f: - # Only store package names for comparison, ignore versions - installed = {pkg["name"].lower() for pkg in json.load(f)} -except (json.JSONDecodeError, FileNotFoundError): - installed = set() - -print("Installed packages:") -print("\n".join(sorted(installed)) if installed else "No installed packages found") -print("\n" + "=" * 50 + "\n") - -with open("cve/requirements.txt") as f: - requirements = [ - line.strip() for line in f if line.strip() and not line.startswith("#") - ] - -print("Requirements from requirements.txt:") -print("\n".join(requirements) if requirements else "No requirements found") -print("\n" + "=" * 50 + "\n") - -filtered = [] -for req in requirements: - # Only get package name for comparison - pkg_name = req.split("==")[0].strip().lower() - if pkg_name in installed: - # Add the full original requirement (including version) - filtered.append(req) - -print("Filtered requirements (matching installed packages):") -print("\n".join(filtered) if filtered else "No matching packages found") -print("\n" + "=" * 50 + "\n") - -with open("filtered-requirements.txt", "w") as f: - f.write("\n".join(filtered)) diff --git a/doc-requirements.txt b/doc-requirements.txt deleted file mode 100644 index eab5d839c..000000000 --- a/doc-requirements.txt +++ /dev/null @@ -1,7 +0,0 @@ -mkdocs -mkdocs-material -mkdocs-material-adr -mkdocs-swagger-ui-tag -mkdocs-glightbox -markdown-exec -reno diff --git a/docs/accelerated-computing-infrastructure.md b/docs/accelerated-computing-infrastructure.md deleted file mode 100644 index c15a10000..000000000 --- a/docs/accelerated-computing-infrastructure.md +++ /dev/null @@ -1,286 +0,0 @@ -# How does Rackspace implement Accelerated Computing? - -![Rackspace OpenStack Flex Software](assets/images/ospc_flex_logo_red.svg){ align=left : style="max-width:175px" } - -Rackspace integrates high-performance networking, computing, and security solutions to meet the evolving needs of modern cloud environments. By leveraging advanced switches, scalable servers, and next-generation security, we enable accelerated computing with high availability, low-latency connectivity, and optimal performance across global infrastructures. These technologies work seamlessly together to address the unique challenges of today's cloud environments. - -## High-Speed Network Switches - -The high-performance, fixed-port switches are designed to meet the demands of modern data center environments, enterprise networks, and high-traffic workloads. These switches offer advanced features that make them ideal for cloud environments, multi-tenant data centers, and complex hybrid cloud architectures. They support high-speed, low-latency connectivity, programmability, and scalability, ensuring efficient traffic handling, seamless integration into Software-Defined Networking (SDN) environments, and robust security measures. Key features include: - - 1. **High-Speed Connectivity**: Offers flexible port configurations (1G to 100G Ethernet) for high-density access and uplink, - supporting rapid data transmission across diverse networks. - - 2. **Low Latency & High Performance**: With up to 3.6 Tbps throughput, these switches provide low-latency operation, ideal for - high-frequency trading, real-time analytics, media streaming, and large-scale storage. - - 3. **Layer 2 & Layer 3 Features**: Includes essential network functions like VLANs, VXLAN, OSPF, BGP, and multicast for - efficient routing, network segmentation, and virtualized environments in dynamic data centers. - - 4. **Programmability & Automation**: Native support for automation tools and APIs integrates seamlessly with SDN frameworks like - Cisco ACI, enabling simplified network management, real-time telemetry, and automated operations for large-scale networks. - - 5. **Security & Policy Management**: Equipped with robust security features such as MACsec encryption, role-based access control - (RBAC), DAI, and IP ACLs, these switches ensure secure, policy-driven management in multi-tenant and regulated environments. - - 6. **Scalability & High Availability**: Built for scalability, these switches feature modular designs with redundant power - supplies, hot-swappable components, and flexible cooling options, ensuring high availability and reliability in large - deployments. - - 7. **Quality of Service (QoS)**: Advanced QoS capabilities, including priority flow control and dynamic buffer allocation, - ensure optimal performance for latency-sensitive applications such as voice and video communication. - - 8. **Energy Efficiency**: Designed with energy-efficient components and Cisco EnergyWise support, these switches help reduce - operational costs while minimizing environmental impact, critical for large data centers and sustainability initiatives. - - 9. **Intelligent Traffic Distribution**: Intelligent traffic management and load balancing optimize network resource - utilization, ensuring high performance and availability in cloud, storage, and compute-intensive environments. - - 10. **IPv6 Support**: Full IPv6 compatibility ensures that these switches can handle the growing number of IP addresses - necessary for modern, next-generation networks. - -**Key Use Cases**: - - 1. **High-Density Data Center Access**: For data centers needing flexible port speeds (1G to 100G) to connect virtualized - servers, storage, and applications. - - 2. **Spine-Leaf Architectures**: Ideal for scalable data centers that can expand by adding leaf switches as workloads grow. - - 3. **SDN and Cisco ACI Deployments**: Suited for enterprises or data centers seeking simplified, policy-driven network - management and automation. - - 4. **Edge Computing and IoT with PoE**: Best for IoT or industrial applications needing both power and network connectivity at - the edge via Power over Ethernet. - - 5. **Secure Segmentation and Multitenancy**: Perfect for cloud and hosting providers requiring network segmentation for - multi-department or multi-tenant environments. - - 6. **Virtualized and Hybrid Cloud**: For enterprises using hybrid cloud models or heavy virtualization, ensuring scalability and - performance for on-premises and cloud workloads. - - 7. **Latency-Sensitive Applications**: Designed for industries like finance, healthcare, and research requiring low-latency, - high-throughput for real-time data processing and simulations. - - 8. **Automated and Centralized Management**: Ideal for enterprises with complex network infrastructures aiming to reduce manual - tasks through automation and centralized management. - - 9. **Enhanced Security**: Suitable for industries with stringent security requirements (e.g., finance, healthcare) to protect - sensitive data and ensure compliance. - - 10. **Load Balancing and High Availability**: Perfect for e-commerce, web hosting, and content delivery networks that need - efficient traffic management and high availability for critical applications. - -## High-Performance Computing Servers - -These high-performance computing (HPC) servers are designed to handle the most demanding workloads, including AI/ML, big data analytics, high-performance computing, and data-intensive applications. Built for scalability, flexibility, and robust processing power, they are ideal for environments requiring large-scale parallel processing, GPU acceleration, substantial memory, and extensive storage capacity. Key features include: - - 1. **High-Core Processors**: - * AMD EPYC processors with up to 128 cores or Intel Xeon processors with up to 44 cores, enabling - parallel processing for AI model training, simulations, and large-scale data analytics. - * **Dual-Socket Support**: Intel Xeon E5-2600 v3/v4 processors support up to 44 cores, making them ideal for multi-threaded - workloads. - - 2. **Massive Memory Capacity**: - * Systems can support up to 12TB of DDR5 memory (in some models) or up to 3TB of DDR4 memory (24 DIMM slots), optimized for - memory-intensive workloads like scientific computing, AI/ML, and big data analytics. - * **High Memory Capacity**: Specifically, the HPE ProLiant DL380 Gen9 offers up to 3TB of DDR4 RAM, ideal for virtualized - environments and memory-heavy applications. - - 3. **Scalability and Performance**: - * The servers offer high scalability for both compute and memory, ensuring long-term flexibility for expanding workloads in - AI, HPC, and data analytics. - * **Enhanced Compute Power**: Intel Xeon and AMD EPYC processors provide highly efficient computing power for modern - enterprise and research applications. - - 4. **Flexible, High-Speed Storage**: - * The servers support up to 100 drives, including NVMe, SAS, and SATA SSDs, allowing for scalable storage options and - high-capacity configurations. - * **HPE Smart Array Controllers**: Advanced storage management, data protection, and RAID functionality are included in some - configurations to improve reliability and fault tolerance. - * **Storage Flexibility**: Configurations can combine high-speed NVMe SSDs for performance and SATA HDDs for capacity, - allowing for optimal storage tiers. - - 5. **GPU and Accelerator Support**: - * These servers can support up to 6 GPUs (including NVIDIA A100 and H100), accelerating deep learning, AI/ML model training, - and high-performance computing simulations. - * GPU support for AI/ML and scientific workloads ensures high parallel processing power, particularly useful for deep - learning and real-time analytics. - * **PCIe Gen 4.0 & Gen 5.0 Expansion**: Multiple PCIe slots for GPUs, FPGAs, and accelerators, ensuring high bandwidth and - minimal latency. - - 6. **Optimized Networking**: - * Multiple 10GbE and 25GbE networking options provide scalable and high-performance connectivity for distributed computing, - data-heavy tasks, and real-time data processing. - * **Networking Expansion**: Embedded 4 x 1GbE ports and support for FlexibleLOM allow for scalable networking and - high-bandwidth connections, important for large-scale data applications. - - 7. **High Availability and Redundancy**: - * **Redundant Power Supplies**: Hot-swappable power supplies ensure uninterrupted operations, even during maintenance. - * **Hot-Plug Fans and Drives**: Maintain and replace hardware without downtime, increasing system availability. - * **RAID Support**: Multiple RAID configurations ensure data redundancy and fault tolerance, crucial for high-availability - environments. - - 8. **Energy Efficiency**: - * The systems feature advanced multi-vector cooling and high-efficiency power supplies, such as 80 PLUS Platinum and - Titanium-rated units, minimizing energy usage. - * **Dynamic Power Capping**: These servers can intelligently manage power consumption, optimizing energy usage without - compromising performance. - - 9. **Security Features**: - * Secure Boot and TPM (Trusted Platform Module) support ensure physical and firmware-level security to protect sensitive data - from boot through runtime. - * **Hardware Root of Trust and System Lockdown**: Provides system integrity and enhanced protection against attacks. - * **Lockable Drive Bays**: Additional physical security features prevent unauthorized tampering. - * **Remote Management**: Tools like HPE iLO 4 and iDRAC9 allow for easy monitoring, management, and firmware updates - remotely. - - 10. **Advanced Management**: - * iLO 4 (HPE) or iDRAC9 (other models) allows remote server management and monitoring. - * Intelligent Provisioning and Active Health System: Simplifies setup and deployment, while providing proactive server - health monitoring. - * OpenManage (Dell) streamlines management for integrating with existing IT systems. - - 11. **Scalability and Customization**: - * These servers offer flexible configurations to meet the needs of various applications from cloud computing to scientific - research. - * **Modular Design**: Tool-free design allows for easy upgrades and future-proofing. - * **Expansion Slots**: Multiple PCIe Gen 3.0/4.0/5.0 slots for additional NICs, HBAs, GPUs, and other expansion cards. - - 12. **OS and Hypervisor Support**: - * These systems are compatible with a wide range of operating systems and hypervisors, including Windows Server, Red Hat, - SUSE, Ubuntu, VMware ESXi, and others, making them versatile for various workloads and environments. - -**Key Use Cases**: - - 1. **AI/ML Model Training and Inference**: For deep learning, real-time AI inference, and AI model training. - - 2. **High-Performance Computing (HPC)**: For scientific research, simulations, and computational-intensive tasks. - - 3. **Big Data Analytics**: For large-scale data processing and analytics, including real-time analytics and big data workloads. - - 4. **Media Streaming and Content Delivery Networks**: For applications requiring massive storage and high throughput. - - 5. **Edge Computing and Low-Latency Applications**: For decentralized data processing, such as edge AI and real-time - decision-making. - - 6. **Cloud Infrastructure and Virtualization**: For cloud providers, virtualization environments, and enterprise data centers. - - 7. **Database Workloads and OLTP**: For handling high-throughput transactional workloads in enterprise environments. - - 8. **Scientific Applications and Research**: For complex scientific simulations, research, and discovery that require high-core - processing and large memory configurations. - - 9. **Backup and Disaster Recovery**: For secure and scalable backup solutions with high data integrity. - - 10. **Software-Defined Storage (SDS) and Hyper-Converged Infrastructure (HCI)**: For next-gen storage solutions that require - both high performance and flexibility. - -## Application Delivery Controllers (ADC) - -The high-performance application delivery and security controller are designed to optimize application traffic, enhance security, and improve user experience for enterprises, service providers, and data centers. Key features include: - - 1. **High Performance**: Offers up to 80 Gbps of L4 throughput and 8 Gbps of SSL/TLS encryption throughput, ideal for handling - high volumes of traffic and complex security requirements. - - 2. **SSL/TLS Offloading**: Dedicated hardware for SSL offloading improves application response times by freeing up server - resources and supporting modern encryption standards like TLS 1.3. - - 3. **Comprehensive Security**: Equipped with Web Application Firewall (WAF), bot protection, DDoS mitigation, IP intelligence, - and threat services to secure web applications from common vulnerabilities and attacks. - - 4. **Traffic Management**: Supports advanced load balancing (GSLB, LTM) and failover capabilities, with customizable traffic - management via iRules scripting for granular control over routing and traffic behavior. - - 5. **Orchestration and Automation**: iApps and iControl REST APIs simplify deployment and integrate with DevOps tools for - streamlined automation, reducing configuration errors. - - 6. **Access Control with APM**: Integrates with Access Policy Manager (APM) for secure access, Single Sign-On (SSO), - Multi-Factor Authentication (MFA), and Zero Trust capabilities. - - 7. **Application Acceleration**: Features like TCP optimization, caching, and compression reduce latency and bandwidth - consumption, enhancing application performance. - - 8. **Programmability**: Customizable with iRules for tailored traffic management and iCall for automating tasks based on events. - - 9. **High Availability**: Supports active-active and active-passive HA modes for continuous uptime, with failover and - synchronization for improved reliability. - - 10. **Scalability**: Modular licensing allows feature expansion without hardware replacement, providing cost savings and - investment protection. - - 11. **Virtualization Support**: Compatible with F5 Virtual Editions (VEs), enabling consistent policies across on-premises and - cloud environments for hybrid or multi-cloud deployments. - - 12. **Network Integration**: Supports IPv6, IPsec, VLANs, and VPNs, with flexible network interface options (1GbE, 10GbE, 25GbE) - for diverse infrastructures. - -**Key Use Cases**: - - 1. **Large Enterprises and Data Centers**: Perfect for organizations needing efficient traffic management, enhanced application - performance, and robust security. - - 2. **Service Providers**: Ideal for managing high traffic volumes with advanced traffic management, scalability, and - comprehensive security. - - 3. **E-commerce and Online Services**: Excellent for protecting e-commerce platforms with Web Application Firewall (WAF), bot - protection, and DDoS mitigation. - - 4. **Hybrid Cloud Environments**: Best for seamless application delivery and security across on-premises and cloud - infrastructures in hybrid or multi-cloud setups. - -## Next-Generation Firewalls (NGFW) - -This next-generation firewall is designed for large-scale environments, including enterprise data centers and service providers. It offers robust security features that protect against advanced threats while maintaining high throughput and seamless integration into high-speed networks. Key features include: - - 1. **High Performance and Throughput**: Delivers up to 72 Gbps of firewall throughput and 32 Gbps of Threat Prevention - throughput, ensuring efficient handling of large traffic volumes and complex security tasks. - - 2. **Advanced Threat Prevention**: Integrates IPS, antivirus, anti-spyware, and sandboxing technology for real-time threat - detection, blocking malware, exploits, and zero-day attacks. - - 3. **Application-Based Traffic Control with App-ID**: Offers granular control over applications regardless of port or protocol, - enhancing visibility and security across the network. - - 4. **User and Content-Based Control with User-ID and Content-ID**: User-ID maps traffic to specific users for policy - enforcement, while Content-ID inspects data for malicious content, URL filtering, and prevents data leakage. - - 5. **SSL Decryption & Inspection**: Capable of decrypting SSL/TLS traffic for deeper inspection of encrypted data, ensuring - protection against hidden threats within secure communications. - - 6. **Integrated WildFire for Advanced Malware Analysis**: Suspicious files are sent for sandboxing to analyze behavior and - detect previously unknown threats. - - 7. **Scalable and Modular Connectivity Options**: Supports 10GbE, 25GbE, and 40GbE interfaces for seamless integration into - high-speed networks, ensuring optimal performance and flexibility. - - 8. **High Availability and Redundancy**: Supports high availability (HA) configurations, ensuring continuous uptime with - automatic failover capabilities. - - 9. **Comprehensive Security Subscriptions**: Includes Threat Prevention, URL Filtering, DNS Security, GlobalProtect, and SD-WAN - for advanced protection and secure remote access. - - 10. **Automation & Centralized Management**: Integrated with centralized firewall management platforms and supports API - integration for automation, enhancing efficiency in security operations and DevOps workflows. - - 11. **Machine Learning for Autonomous Security**: Uses machine learning to enhance threat detection, adapt security protocols, - and proactively defend against emerging threats. - - 12. **Zero Trust Network Security Capabilities**: Enforces least-privilege access and continuous verification of identity, - aligning with Zero Trust security principles. - - 13. **Energy Efficiency and Form Factor**: Designed to deliver high performance while maintaining energy efficiency, reducing - operational costs and minimizing environmental impact. - -**Key Use Cases**: - - 1. **Enterprise Data Centers**: Ideal for large data centers requiring high throughput, threat protection, and efficient traffic - management. - - 2. **Service Providers and Large Enterprises**: Perfect for securing and managing complex, high-traffic networks with - scalability and performance. - - 3. **Cloud and Hybrid Environments**: Suited for hybrid and multi-cloud setups, ensuring consistent security across on-premises - and cloud infrastructures. - - 4. **High-Risk Sectors**: Beneficial for industries like finance, healthcare, and government, requiring advanced security - features such as threat detection and SSL inspection. diff --git a/docs/accelerated-computing-overview.md b/docs/accelerated-computing-overview.md deleted file mode 100644 index 34d7aadb8..000000000 --- a/docs/accelerated-computing-overview.md +++ /dev/null @@ -1,183 +0,0 @@ -# What is Accelerated Computing? - -![Rackspace OpenStack Software](assets/images/ospc_flex_logo_red.svg){ align=left : style="max-width:175px" } - -## Overview - -Accelerated computing uses specialized hardware called accelerators, such as the following: - -* Graphics Processing Units ([GPUs](https://en.wikipedia.org/wiki/Graphics_processing_unit)) -* Neural Processing Units ([NPUs](https://support.microsoft.com/en-us/windows/all-about-neural-processing-units-npus-e77a5637-7705-4915-96c8-0c6a975f9db4)) -* Smart Network Interface Cards([Smart NICs](https://codilime.com/blog/what-are-smartnics-the-different-types-and-features/)) -* Tensor Processing Units ([TPUs](https://en.wikipedia.org/wiki/Tensor_Processing_Unit)) -* Field Programmable Gate Arrays ([FPGAs](https://en.wikipedia.org/wiki/Field-programmable_gate_array)) - -These accelerators are used to perform computations faster than traditional CPUs alone because they are designed to handle highly parallel, complex, or data-intensive tasks more efficiently. This makes them ideal for applications like machine learning, scientific simulations, graphics rendering, and big data processing. - -## Benefits - -* **Parallel Processing**: Accelerators can perform multiple calculations simultaneously. For example, GPUs have thousands of - cores, allowing them to execute many tasks at once, which is ideal for matrix calculations common in machine learning. - -* **Optimized Architectures**: Each type of accelerator is tailored to specific tasks. GPUs are optimized for floating-point - operations, making them well-suited for image processing and deep learning. TPUs are specifically designed by Google for - neural network computations, while FPGAs can be customized to accelerate a variety of applications. - -* **Energy and Cost Efficiency**: Accelerators can reduce energy usage and costs by performing computations faster, which is - particularly important in data centers and high-performance computing environments. - -* **Enhanced Performance in AI and Data-Intensive Workloads**: Accelerated computing has become foundational for AI and machine - learning, where training models on large datasets can take days or weeks without specialized hardware. - -### GPUs - -GPUs are widely used as accelerators for a variety of tasks, especially those involving high-performance computing, artificial intelligence, and deep learning. Originally designed for rendering graphics in video games and multimedia applications, GPUs have evolved into versatile accelerators due to their highly parallel architecture. Here’s how GPUs act as effective accelerators: - - 1. **Massively Parallel Architecture**: With thousands of cores, GPUs excel in parallel tasks, such as training neural networks, - which require numerous simultaneous operations like matrix multiplications. - - 2. **High Throughput for Large Data**: GPUs deliver superior throughput for processing large datasets, making them ideal for - applications in image/video processing, data analytics, and simulations (e.g., climate modeling). - - 3. **Efficient for Deep Learning and AI**: GPUs handle deep learning tasks, especially matrix calculations, much faster than - CPUs. Popular frameworks like TensorFlow and PyTorch offer GPU support for both training and inference. - - 4. **Real-Time Processing**: GPUs enable low-latency processing for time-sensitive applications like autonomous driving and - real-time video analysis, where rapid decision-making is crucial. - - 5. **Accelerating Scientific Computing**: In scientific research, GPUs speed up computations for complex simulations in fields - like molecular dynamics, astrophysics, and genomics. - - 6. **AI Model Inference and Deployment**: Post-training, GPUs accelerate AI model inference for real-time predictions across - industries like healthcare, finance, and security. - - 7. **Software Ecosystem**: NVIDIA GPUs benefit from a robust ecosystem (e.g., CUDA, cuDNN) that supports AI, machine learning, - and scientific computing, enabling developers to fully harness GPU power. - -In summary, GPUs function as accelerators by leveraging their parallel processing capabilities and high computational power to speed up a range of data-intensive tasks. They are versatile tools, widely used across industries for tasks that require rapid, efficient processing of large volumes of data. - -### NPUs - -NPUs are specialized accelerators designed specifically to handle AI and deep learning tasks, especially neural network computations. They’re highly optimized for the types of mathematical operations used in AI, such as matrix multiplications and convolutions, making them particularly effective for tasks like image recognition, natural language processing, and other machine learning applications. Here’s how NPUs function as powerful accelerators: - - 1. **Optimized for Neural Network Operations**: NPUs excel at tensor operations and matrix multiplications, which are central to - neural networks, providing greater efficiency than CPUs or GPUs. - - 2. **Parallelized Processing**: With multiple cores optimized for parallel tasks, NPUs handle large datasets and complex - computations simultaneously, making them ideal for deep learning applications. - - 3. **Low Power Consumption**: NPUs are energy-efficient, making them well-suited for mobile and edge devices, such as - smartphones and IoT sensors, where power is limited. - - 4. **Faster Inference for Real-Time Apps**: NPUs accelerate AI model inference, enabling real-time applications like facial - recognition, voice assistants, and autonomous driving. - - 5. **Offloading from CPUs and GPUs**: By offloading neural network tasks, NPUs reduce the burden on CPUs and GPUs, improving - overall system performance, especially in multi-process environments. - - 6. **Wide Device Integration**: NPUs are increasingly integrated into various devices, from mobile phones (e.g., Apple’s Neural - Engine) to data centers (e.g., Google’s TPU), enabling AI in low-power and resource-constrained environments. - -In summary, NPUs are specialized accelerators that enhance AI processing efficiency, enabling faster and more accessible AI applications across a wide range of devices. - -### Smart NICs - -Smart NICs act as accelerators by offloading and accelerating network-related tasks, helping to improve the performance of servers in data centers, cloud environments, and high-performance computing applications. Unlike traditional NICs that only handle basic data transfer, Smart NICs have onboard processing capabilities, often including dedicated CPUs, FPGAs, or even GPUs, which enable them to process data directly on the card. Here’s how they function as powerful accelerators: - - 1. **Offloading Network Tasks**: Smart NICs offload tasks like packet processing, encryption, load balancing, and firewall - management, freeing the CPU to focus on application-specific computations. - - 2. **Accelerating Data Processing**: With built-in processing capabilities, Smart NICs handle tasks such as data encryption, - compression, and analysis, crucial for data-intensive environments like data centers. - - 3. **Programmable Logic (FPGA-Based NICs)**: Many Smart NICs use FPGAs, which can be reprogrammed for specific networking - functions, offering flexibility and adaptability to evolving network protocols. - - 4. **Enhanced Performance with RDMA**: By supporting Remote Direct Memory Access (RDMA), Smart NICs enable direct - memory-to-memory data transfers, reducing latency and improving throughput for latency-sensitive applications. - - 5. **Security Acceleration**: Smart NICs offload security functions like encryption, firewall management, and intrusion - detection, processing them in real-time to enhance network security without compromising performance. - - 6. **Data Center and Cloud Optimization**: In virtualized environments, Smart NICs offload and accelerate virtual network - functions (VNFs), reducing CPU load and improving resource utilization for cloud and data center applications. - - 7. **Accelerating Storage Networking**: Smart NICs accelerate storage networking tasks, such as NVMe-oF, for faster remote - storage access and improved performance in data-heavy applications. - - 8. **Edge Computing and IoT**: Smart NICs process data locally in edge devices, performing tasks like filtering, aggregation, - and compression to reduce latency and optimize data transfer. - -In summary, Smart NICs enhance system performance by offloading network and data processing tasks, enabling higher efficiency, lower latency, and improved scalability in data-intensive environments. - -### TPUs - -TPUs are specialized accelerators developed by Google to optimize and accelerate machine learning workloads, particularly for deep learning and neural network computations. Unlike general-purpose processors, TPUs are custom-designed to efficiently handle the massive amounts of matrix operations and tensor computations commonly required by machine learning algorithms, especially deep neural networks. Here’s how TPUs function as powerful accelerators: - - 1. **Matrix Multiplication Optimization**: TPUs accelerate matrix multiplications, essential for deep learning models, making - them much faster than CPUs or GPUs. - - 2. **Parallel Processing**: With a large number of cores, TPUs enable high levels of parallelism, allowing them to process - complex neural networks quickly. - - 3. **Energy Efficiency**: Designed to consume less power than CPUs and GPUs, TPUs reduce energy costs, making them ideal for - large-scale data centers. - - 4. **High-Speed Memory Access**: TPUs use high-bandwidth memory (HBM) to quickly feed data to processing units, speeding up - training and inference. - - 5. **Performance for Training and Inference**: TPUs deliver low-latency performance for both model training and real-time - inference, critical for AI applications. - - 6. **TensorFlow Integration**: TPUs are tightly integrated with TensorFlow, offering optimized tools and functions for seamless - use within the framework. - - 7. **Scalability with TPU Pods**: TPU Pods in Google Cloud allow scaling processing power for massive datasets and - enterprise-level machine learning models. - - 8. **Optimized Data Types**: Using BFloat16, TPUs enable faster computation while maintaining model accuracy, reducing memory - and processing demands. - - 9. **Edge TPUs for IoT**: Edge TPUs provide low-power machine learning capabilities for edge and IoT devices, supporting - real-time AI tasks like image recognition. - -In summary, TPUs are custom-designed accelerators that significantly enhance the speed, efficiency, and scalability of machine learning tasks, particularly in large-scale and real-time AI applications. - -### FPGAs - -FPGAs are highly customizable accelerators that offer unique advantages for specialized computing tasks, especially in data-intensive fields such as machine learning, financial trading, telecommunications, and scientific research. FPGAs are programmable hardware that can be configured to perform specific functions with high efficiency, making them very versatile. Here’s how FPGAs function as powerful accelerators: - - 1. **Customizable Hardware**: Unlike fixed accelerators, FPGAs can be reprogrammed for specific tasks, allowing optimization for - workloads like data encryption, compression, or AI inference. - - 2. **High Parallelism**: FPGAs feature thousands of independent logic blocks, enabling parallel data processing, ideal for - applications like real-time signal processing and genomics. - - 3. **Low Latency & Predictability**: FPGAs provide extremely low latency and deterministic performance, crucial for real-time - applications like high-frequency trading. - - 4. **Energy Efficiency**: FPGAs are energy-efficient by utilizing only the necessary hardware resources for a task, making them - suitable for energy-sensitive environments like edge devices. - - 5. **Flexibility**: Reprogrammability allows FPGAs to adapt to evolving standards and algorithms, such as new networking - protocols or machine learning models. - - 6. **Machine Learning Inference**: FPGAs excel at AI inference tasks, providing low-latency, efficient processing for - applications like object detection and speech recognition. - - 7. **Custom Data Types**: FPGAs can handle specialized data formats to optimize memory and processing speed, ideal for - applications like AI with reduced-precision data. - - 8. **Hardware-Level Security**: FPGAs can implement custom cryptographic algorithms for secure communications or sensitive data - handling. - - 9. **Real-Time Signal Processing**: FPGAs are used in industries like telecommunications and aerospace for high-speed, real-time - signal processing in applications like radar and 5G. - - 10. **Edge Computing & IoT**: FPGAs are deployed in edge devices to perform local computations, such as sensor data processing - or on-device AI inference, reducing reliance on the cloud. - - 11. **Integration with Other Accelerators**: FPGAs can complement CPUs and GPUs in heterogeneous computing environments, - handling tasks like preprocessing or data compression while other accelerators manage complex workloads. - -In summary, FPGAs are versatile accelerators, offering customizable, energy-efficient hardware for high-speed, low-latency processing across various specialized applications, from signal processing to machine learning. diff --git a/docs/adding-new-node.md b/docs/adding-new-node.md deleted file mode 100644 index d0e92435f..000000000 --- a/docs/adding-new-node.md +++ /dev/null @@ -1,112 +0,0 @@ -# Adding New Worker Node - -## Adding the node in k8s - -In order to add a new worker node, we follow the steps as outlined by the kubespray project. -Lets assume we are adding one new worker node: `computegpu001.p40.example.com` and add to relevant sections. - -1. Add the node to your ansible inventory file - -```shell - vim /etc/genestack/inventory/inventory.yaml -``` - -2. Ensure hostname is correctly set and hosts file has 127.0.0.1 entry - -3. Run scale.yaml to add the node to your cluster - -```shell - source /opt/genestack/scripts/genestack.rc - ansible-playbook scale.yml --limit compute-12481.rackerlabs.dev.local --become -``` - -Once step 3 competes succesfully, validate that the node is up and running in the cluster - -```shell - kubectl get nodes | grep compute-12481.rackerlabs.dev.local -``` - -### PreferNoSchedule Taint - -`PreferNoSchedule` is a preference or "soft" version of `NoSchedule`. The -control plane will try to avoid placing a Pod that does not tolerate the taint -on the node, but it is not guaranteed. This is useful if you want to herd -pods away from specific nodes without preventing them from being scheduled -on entirely. For example, tainting compute nodes is generally recommended so -there is less opportunity for competition of system resources between local -pods and the Nova VMs therein. - -!!! tip "Setting this is a matter of architerural preference:" - - ```shell - kubectl taint nodes compute-12481.rackerlabs.dev.local key1=value1:PreferNoSchedule - ``` - -## Adding the node in openstack - -Once the node is added in k8s cluster, adding the node to openstack service is simply a matter of labeling the node with the right -labels and annotations. - -1. Export the nodes to add - -```shell - export NODES='compute-12481.rackerlabs.dev.local' -``` - -2. For compute node add the following labels - -```shell - # Label the openstack compute nodes - kubectl label node compute-12481.rackerlabs.dev.local openstack-compute-node=enabled - - # With OVN we need the compute nodes to be "network" nodes as well. While they will be configured for networking, they wont be gateways. - kubectl label node compute-12481.rackerlabs.dev.local openstack-network-node=enabled -``` - -3. Add the right annotations to the node - -```shell - kubectl annotate \ - nodes \ - ${NODES} \ - ovn.openstack.org/int_bridge='br-int' - - kubectl annotate \ - nodes \ - ${NODES} \ - ovn.openstack.org/bridges='br-ex' - - kubectl annotate \ - nodes \ - ${NODES} \ - ovn.openstack.org/ports='br-ex:bond1' - - kubectl annotate \ - nodes \ - ${NODES} \ - ovn.openstack.org/mappings='physnet1:br-ex' - - kubectl annotate \ - nodes \ - ${NODES} \ - ovn.openstack.org/availability_zones='az1' -``` - -4. Verify all the services are up and running - -```shell - kubectl get pods -n openstack -o wide | grep "computegpu" -``` - -At this point the compute node should be up and running and your `openstack` cli command should list the compute node under hosts. - -## For PCI passthrough - -If you are adding a new node to be a PCI passthrough compute, say for exposing GPU to the vm, at this stage you will have to -setup your PCI Passthrough configuration. Follow steps from: [Configuring PCI Passthrough in OpenStack](openstack-pci-passthrough.md) - -Once the PCI setup is complete follow the instructions from: [Adding Host Aggregates](openstack-host-aggregates.md) to setup host -aggregates for the group of PCI devices. This helps us control the image/flavor/tennant build restriction on a given aggregate to -better use underlying GPU resources. - -Once the host aggregate is setup follow the instructions from: [Genestack flavor documentation](openstack-flavors.md) to setup the right flavor. diff --git a/docs/admonition-test.md b/docs/admonition-test.md deleted file mode 100644 index e3846d8da..000000000 --- a/docs/admonition-test.md +++ /dev/null @@ -1,15 +0,0 @@ -# Custom Genestack Admonition - -There is now a 'genestack' admonition type: - -``` -!!! genestack - [Genestack](https://github.com/rackerlabs/genestack){:target="_blank"} - is a cool new project! -``` - -It renders like this: - -!!! genestack - [Genestack](https://github.com/rackerlabs/genestack){:target="_blank"} - is a cool new project! diff --git a/docs/alerting-info.md b/docs/alerting-info.md deleted file mode 100644 index c79944dc7..000000000 --- a/docs/alerting-info.md +++ /dev/null @@ -1,91 +0,0 @@ -# Genestack Alerting - -Genestack is made up of a vast array of components working away to provide a Kubernetes and OpenStack cloud infrastructure -to serve our needs. Here we'll discuss in a bit more detail about how we configure and make use of our alerting mechanisms -to maintain the health of our systems. - -## Overview - -In this document we'll dive a bit deeper into the alerting components and how they're configured and used to maintain the health of our genestack. -Please take a look at the [Monitoring Information Doc](monitoring-info.md) for more information regarding how the metrics and stats are collected in order to make use of our alerting mechanisms. - -## Prometheus Alerting - -As noted in the [Monitoring Information Doc](monitoring-info.md) we make heavy use of [Prometheus](https://prometheus.io) and within the Genestack workflow specifically we deploy the [kube-prometheus-stack](https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack) which handles deployment of the Prometheus servers, operators, alertmanager and various other components. -Genestack uses Prometheus for metrics and stats collection and overall monitoring of its systems that are described in the [Monitoring Information Doc](monitoring-info.md). -With the metrics and stats collected we can now use Prometheus to generate alerts based on those metrics and stats using the Prometheus [Alerting Rules](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). -The Prometheus alerting rules allows us to define conditions we want to escalate using the [Prometheus expression language](https://prometheus.io/docs/prometheus/latest/querying/basics/) which can be visualized and sent to an external notification systems for further action. - -A simple example of an alerting rule would be this RabbitQueueSizeTooLarge -!!! example "RabbitQueueSizeTooLarge Alerting Rule Example" - - ``` yaml - rabbitmq-alerts: - groups: - - name: Prometheus Alerts - rules: - - alert: RabbitQueueSizeTooLarge - expr: rabbitmq_queuesTotal>25 - for: 5m - labels: - severity: critical - annotations: - summary: "Rabbit queue size too large (instance {{ `{{ $labels.instance }}` }} )" - ``` - -In Genestack we have separated the alerting rules config out from the primary helm configuration using the `additionalPrometheusRulesMap` directive to make it a bit easier to maintain. -Doing it this way allows for easier review of new rules, better maintainability, easier updates of the stack and helps with portability for larger deployments. Keeping our configurations separated and checked in to the repo in such a manner is ideal for these reasons. -The alternative is to create the rules within your observability platform, in Genestack's default workflow this would be Grafana. Although the end user is free to make such a choice you end up losing a lot of the benefits we just mentioned while creating additional headaches when deploying to new clusters or even during basic updates. - -You can view the rest of the default alerting rule configurations in the Genestack repo [alerting rules](https://github.com/rackerlabs/genestack/blob/main/base-helm-configs/prometheus/alerting_rules.yaml) yaml file. - -To deploy any new rules you would simply run the [Prometheus Deployment](prometheus.md) and Helm/Prometheus will take care of updating the configurations from there. -!!! example "Run the Prometheus deployment" - - ``` shell - /opt/genestack/bin/install-prometheus.sh - ``` - -## Alert Manager - -The kube-prometheus-stack not only contains our monitoring components such as Prometheus and related CRD's, but it also contains another important features, the [Alert Manager](https://prometheus.io/docs/alerting/latest/alertmanager/). -The Alert Manager is a crucial component in the alerting pipeline as it takes care of grouping, deduplicating and even routing the alerts to the correct receiver integrations. -Prometheus is responsible for generating the alerts based on the [Alerting Rules](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/) we [defined](https://github.com/rackerlabs/genestack/blob/main/base-helm-configs/prometheus/alerting_rules.yaml). -Prometheus then sends these alerts to the [Alert Manager](https://prometheus.io/docs/alerting/latest/alertmanager/) for further processing. - -The below diagram gives a better idea of how the Alert Manager works with Prometheus as a whole. -![Prometheus Architecture](assets/images/prometheus-architecture.png) - -Genestack provides a basic [alertmanager_config](https://github.com/rackerlabs/genestack/blob/main/base-helm-configs/prometheus/alertmanager_config.yaml) that's separated out from the primary Prometheus configurations for similar reasons the [alerting rules](https://github.com/rackerlabs/genestack/blob/main/base-helm-configs/prometheus/alerting_rules.yaml) are. -Here we can see the key components of the Alert Manager config that allows us to group and send our alerts to external services for further action. - -* [Inhibit Rules](https://prometheus.io/docs/alerting/latest/configuration/#inhibition-related-settings) - Inhibition rules allows us to establish dependencies between systems or services so that only the most relevant set of alerts are sent out during an outage -* [Routes](https://prometheus.io/docs/alerting/latest/configuration/#route-related-settings) - Routing-related settings allow configuring how alerts are routed, aggregated, throttled, and muted based on time. -* [Receivers](https://prometheus.io/docs/alerting/latest/configuration/#general-receiver-related-settings) - Receiver settings allow configuring notification destinations for our alerts. - -These are all explained in greater detail in the [Alert Manager Docs](https://prometheus.io/docs/alerting/latest/configuration/#configuration). - -The Alert Manager has various baked-in methods to allow those notifications to be sent to services like [email](https://prometheus.io/docs/alerting/latest/configuration/#email_config), [PagerDuty](https://prometheus.io/docs/alerting/latest/configuration/#pagerduty_config) and [Microsoft Teams](https://prometheus.io/docs/alerting/latest/configuration/#msteams_config). -For a full list and further information view the [receiver information documentation](https://prometheus.io/docs/alerting/latest/configuration/#receiver-integration-settings). - -The following list contains a few examples of these receivers as part of the [alertmanager_config](https://github.com/rackerlabs/genestack/blob/main/base-helm-configs/prometheus/alertmanager_config.yaml) found in Genestack. - -* [Slack Receiver](alertmanager-slack.md) -* [PagerDuty Receiver](alertmanager-pagerduty.md) -* [Microsoft Teams Receiver](alertmanager-msteams.md) - -We can now take all this information and build out an alerting workflow that suits our needs! - -## Genestack alerts - -This section contains some information on individual Genestack alert. - -### MariaDB backup alert - -Based on a schedule of 6 hours by default, it allows 1 hour to upload and -alerts when MySQL doesn't successfully complete a backup. - -It alerts at warning level the first time this happens, and at critical level the second time this happens. diff --git a/docs/alertmanager-msteams.md b/docs/alertmanager-msteams.md deleted file mode 100644 index 4b41fb2cb..000000000 --- a/docs/alertmanager-msteams.md +++ /dev/null @@ -1,54 +0,0 @@ -# Microsoft Teams Alerts - -The following example describes configuration options to send alerts via alertmanager to Microsoft Teams. - -``` yaml -alertmanager: - - ## Alertmanager configuration directives - ## ref: https://prometheus.io/docs/alerting/configuration/#configuration-file - ## https://prometheus.io/webtools/alerting/routing-tree-editor/ - ## - config: - global: - resolve_timeout: 5m - inhibit_rules: - - source_matchers: - - 'severity = critical' - target_matchers: - - 'severity =~ warning|info' - equal: - - 'namespace' - - 'alertname' - - source_matchers: - - 'severity = warning' - target_matchers: - - 'severity = info' - equal: - - 'namespace' - - 'alertname' - - source_matchers: - - 'alertname = InfoInhibitor' - target_matchers: - - 'severity = info' - equal: - - 'namespace' - - target_matchers: - - 'alertname = InfoInhibitor' - route: - group_by: ['namespace'] - group_wait: 30s - group_interval: 5m - repeat_interval: 12h - receiver: msteams_config - routes: - - receiver: 'null' - matchers: - - alertname = "Watchdog" - receivers: - - name: 'null' - - name: 'msteams_config' - msteams_configs: - - send_resolved: true - webhook_url: https://msteams.webhook_url.example -``` diff --git a/docs/alertmanager-pagerduty.md b/docs/alertmanager-pagerduty.md deleted file mode 100644 index f9782516f..000000000 --- a/docs/alertmanager-pagerduty.md +++ /dev/null @@ -1,55 +0,0 @@ -# PagerDuty Alerts - -The following example describes configuration options to send alerts via alertmanager to PagerDuty. - -``` yaml -alertmanager: - - ## Alertmanager configuration directives - ## ref: https://prometheus.io/docs/alerting/configuration/#configuration-file - ## https://prometheus.io/webtools/alerting/routing-tree-editor/ - ## - config: - global: - resolve_timeout: 5m - pagerduty_url: 'https://events.pagerduty.com/v2/enqueue' - inhibit_rules: - - source_matchers: - - 'severity = critical' - target_matchers: - - 'severity =~ warning|info' - equal: - - 'namespace' - - 'alertname' - - source_matchers: - - 'severity = warning' - target_matchers: - - 'severity = info' - equal: - - 'namespace' - - 'alertname' - - source_matchers: - - 'alertname = InfoInhibitor' - target_matchers: - - 'severity = info' - equal: - - 'namespace' - - target_matchers: - - 'alertname = InfoInhibitor' - route: - group_by: ['namespace'] - group_wait: 30s - group_interval: 5m - repeat_interval: 12h - receiver: 'pagerduty-notifications' - routes: - - receiver: 'null' - matchers: - - alertname = "Watchdog" - receivers: - - name: 'null' - - name: 'pagerduty-notifications' - pagerduty_configs: - - service_key: 0c1cc665a594419b6d215e81f4e38f7 - send_resolved: true -``` diff --git a/docs/alertmanager-slack.md b/docs/alertmanager-slack.md deleted file mode 100644 index eafc3147e..000000000 --- a/docs/alertmanager-slack.md +++ /dev/null @@ -1,46 +0,0 @@ -# Slack Alerts - -The following example describes configuration options to send alerts via alertmanager to slack -using a slack hook. - -``` yaml -alertmanager: - alertmanagerSpec: - image: - repository: docker.io/prom/alertmanager:v0.20.0 - config: - global: - resolve_timeout: 5m - receivers: - - name: default-receiver - - name: watchman-webhook - - name: warning-alert-manager-handler - slack_configs: - - api_url: https://hooks.slack.com/services/ - channel: '#' - send_resolved: true - text: >- - {{- if .CommonAnnotations.summary -}} - *Summary*: {{- .CommonAnnotations.summary -}}{{- "\n" -}} - {{- else if .CommonAnnotations.description -}} - *Description*: {{- .CommonAnnotations.description -}}{{- "\n" -}} - {{- else if .CommonAnnotations.message -}} - *Message*: {{- .CommonAnnotations.message -}}{{- "\n" -}} - {{- end -}} - *Cluster*: {{ .GroupLabels.cluster }} - *Wiki*: https://desired.wiki.page/{{ .GroupLabels.alertname }} - route: - group_by: - - alertname - - severity - - cluster - - region - group_interval: 5m - group_wait: 10s - receiver: watchman-webhook - repeat_interval: 12h - routes: - - match_re: - severity: critical - receiver: warning-alert-manager-handler -``` diff --git a/docs/api-status.md b/docs/api-status.md deleted file mode 100644 index 2ac3e4bef..000000000 --- a/docs/api-status.md +++ /dev/null @@ -1,47 +0,0 @@ - - -# Rackspace OpenStack Flex - -Clouds Without Borders. Rackspace OpenStack Private Goes __Public__. - -## Power Innovation Worldwide with One OpenStack Platform - -![Rackspace OpenStack Software](assets/images/cloud-anywhere.png){ align=left : style="width:100%;max-width:500px" } - -The ability to scale across geographies, meet strict data sovereignty requirements, and maintain rigorous security -is paramount. With Rackspace, you can tap into any of our available regions, all running on a unified OpenStack -platform—so you stay agile, compliant, and equipped to evolve in a fast-paced world. - -And it doesn’t stop there. Our incredible team of experts is committed to delivering Fanatical support every step -of the way, ensuring you have the guidance and confidence to take your technology stack further than ever before. - -[Create a new account](https://cart.rackspace.com/cloud) or [reach out](https://www.rackspace.com/cloud/openstack/private). -When you’re ready to shape the future of your organization, we’ll be here, ready to help you build an extraordinary -platform on our open ecosystem. - -
- -## Rackspace Solutions - -
- -- :material-ab-testing:{ .lg } __Game Changing Solutions__ - - Tap into unprecedented scalability expertise, including over one billion server hours managing - and scaling OpenStack clouds for many of the world’s largest and most recognized companies. - -- :material-account-wrench:{ .xl .middle } - __A Partner in your Success__ - - Rackspace solutions deliver the capability, scalability and reliability of an enterprise-grade - cloud platform at a fraction of the cost, enabling you to focus on innovation rather than - infrastructure. - -- :material-amplifier:{ .xl .middle } __Rackspace Cloud Solutions__ - - Grow profitably with predictable cloud costs - -- :material-api:{ .lg } __Simple Solutions__ - - At Rackspace, our industry-leading performance drives up your ROI. - -
diff --git a/docs/assets/images/CNCF_deploy.jpg b/docs/assets/images/CNCF_deploy.jpg deleted file mode 100644 index 64b332544..000000000 Binary files a/docs/assets/images/CNCF_deploy.jpg and /dev/null differ diff --git a/docs/assets/images/CNCF_develop.jpg b/docs/assets/images/CNCF_develop.jpg deleted file mode 100644 index 149e2a707..000000000 Binary files a/docs/assets/images/CNCF_develop.jpg and /dev/null differ diff --git a/docs/assets/images/CNCF_distribute.jpg b/docs/assets/images/CNCF_distribute.jpg deleted file mode 100644 index d3f546613..000000000 Binary files a/docs/assets/images/CNCF_distribute.jpg and /dev/null differ diff --git a/docs/assets/images/CNCF_runtime.jpg b/docs/assets/images/CNCF_runtime.jpg deleted file mode 100644 index 14fbb97d9..000000000 Binary files a/docs/assets/images/CNCF_runtime.jpg and /dev/null differ diff --git a/docs/assets/images/Host-Aggregates.png b/docs/assets/images/Host-Aggregates.png deleted file mode 100644 index b49d3af23..000000000 Binary files a/docs/assets/images/Host-Aggregates.png and /dev/null differ diff --git a/docs/assets/images/Multiple-Host-Aggregates.png b/docs/assets/images/Multiple-Host-Aggregates.png deleted file mode 100644 index 937893cf9..000000000 Binary files a/docs/assets/images/Multiple-Host-Aggregates.png and /dev/null differ diff --git a/docs/assets/images/OpenStack-Logo-Vertical.svg b/docs/assets/images/OpenStack-Logo-Vertical.svg deleted file mode 100644 index 003be44f8..000000000 --- a/docs/assets/images/OpenStack-Logo-Vertical.svg +++ /dev/null @@ -1 +0,0 @@ -OpenStack_Logo_Vertical diff --git a/docs/assets/images/SkylineHomeQuota.png b/docs/assets/images/SkylineHomeQuota.png deleted file mode 100644 index a7b364fc6..000000000 Binary files a/docs/assets/images/SkylineHomeQuota.png and /dev/null differ diff --git a/docs/assets/images/cloud-anywhere.png b/docs/assets/images/cloud-anywhere.png deleted file mode 100644 index 2b31526b7..000000000 Binary files a/docs/assets/images/cloud-anywhere.png and /dev/null differ diff --git a/docs/assets/images/cloud-hierarchy-az.png b/docs/assets/images/cloud-hierarchy-az.png deleted file mode 100644 index 36c714a36..000000000 Binary files a/docs/assets/images/cloud-hierarchy-az.png and /dev/null differ diff --git a/docs/assets/images/cloud-hierarchy-region.png b/docs/assets/images/cloud-hierarchy-region.png deleted file mode 100644 index 673d33fff..000000000 Binary files a/docs/assets/images/cloud-hierarchy-region.png and /dev/null differ diff --git a/docs/assets/images/cloud-hierarchy.png b/docs/assets/images/cloud-hierarchy.png deleted file mode 100644 index 3f4906683..000000000 Binary files a/docs/assets/images/cloud-hierarchy.png and /dev/null differ diff --git a/docs/assets/images/diagram-genestack.png b/docs/assets/images/diagram-genestack.png deleted file mode 100644 index dc37a35e0..000000000 Binary files a/docs/assets/images/diagram-genestack.png and /dev/null differ diff --git a/docs/assets/images/favicon.ico b/docs/assets/images/favicon.ico deleted file mode 100644 index 2591855f3..000000000 Binary files a/docs/assets/images/favicon.ico and /dev/null differ diff --git a/docs/assets/images/flexingress.png b/docs/assets/images/flexingress.png deleted file mode 100644 index 68fa6baf2..000000000 Binary files a/docs/assets/images/flexingress.png and /dev/null differ diff --git a/docs/assets/images/genestack-cropped-small.png b/docs/assets/images/genestack-cropped-small.png deleted file mode 100644 index fe235ef02..000000000 Binary files a/docs/assets/images/genestack-cropped-small.png and /dev/null differ diff --git a/docs/assets/images/genestack-logo-mono.png b/docs/assets/images/genestack-logo-mono.png deleted file mode 100644 index bcec425c9..000000000 Binary files a/docs/assets/images/genestack-logo-mono.png and /dev/null differ diff --git a/docs/assets/images/genestack-logo.png b/docs/assets/images/genestack-logo.png deleted file mode 100644 index cb23ceffe..000000000 Binary files a/docs/assets/images/genestack-logo.png and /dev/null differ diff --git a/docs/assets/images/genestack-mono.svg b/docs/assets/images/genestack-mono.svg deleted file mode 100644 index 8dc4582c6..000000000 --- a/docs/assets/images/genestack-mono.svg +++ /dev/null @@ -1,196 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/docs/assets/images/genestack.png b/docs/assets/images/genestack.png deleted file mode 100644 index fad451e1e..000000000 Binary files a/docs/assets/images/genestack.png and /dev/null differ diff --git a/docs/assets/images/genestack.svg b/docs/assets/images/genestack.svg deleted file mode 100644 index 1215afa0f..000000000 --- a/docs/assets/images/genestack.svg +++ /dev/null @@ -1,5850 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - \ No newline at end of file diff --git a/docs/assets/images/genstack-local-arch-k8s.svg b/docs/assets/images/genstack-local-arch-k8s.svg deleted file mode 100644 index e70ab0b9a..000000000 --- a/docs/assets/images/genstack-local-arch-k8s.svg +++ /dev/null @@ -1,188 +0,0 @@ - - - - - - - - - - - - - - - - - Enterprise K8s Components - - Layer 1 - - - - - Operating System - - - - - - - CNI - Calico/KubeOVN - - - - - - - containerd - - - - - - - kubelet - - - - - - - Exposed - Kubernetes API - - - - - - - LoadBalancer / MetalLB - - - - - - - etcd - - - - - - - CNCF Kubernetes and Operators - - - - - - - Local Path - Provisioner - - - - - - - CSI: Ceph - - - - - - - - Kubernetes API components - - - - - - - Prometheus - [Thanos] - - - - - - - Nginx - Gateway Ctrl - - - - - - - coredns - - - - - - - kube - proxy - - - - - - - kube - apiserver - - - - - - - Helm - - - - - - - Metal3.io - CRD - - - - - - - Calico - Controller - - - - - - - - registry - - - - - - - Cert- - Manager - - - - - - - Intel/AMD x86 64Bit Platforms - - - - - diff --git a/docs/assets/images/gnocchi-architecture.svg b/docs/assets/images/gnocchi-architecture.svg deleted file mode 100644 index 1b651c792..000000000 --- a/docs/assets/images/gnocchi-architecture.svg +++ /dev/null @@ -1,3 +0,0 @@ - - - diff --git a/docs/assets/images/grafana-explore.png b/docs/assets/images/grafana-explore.png deleted file mode 100644 index 1db146620..000000000 Binary files a/docs/assets/images/grafana-explore.png and /dev/null differ diff --git a/docs/assets/images/grafana-search.png b/docs/assets/images/grafana-search.png deleted file mode 100644 index e814962f8..000000000 Binary files a/docs/assets/images/grafana-search.png and /dev/null differ diff --git a/docs/assets/images/ironic-architecture.png b/docs/assets/images/ironic-architecture.png deleted file mode 100644 index dc3bda98e..000000000 Binary files a/docs/assets/images/ironic-architecture.png and /dev/null differ diff --git a/docs/assets/images/kubernetes-stacked-color.svg b/docs/assets/images/kubernetes-stacked-color.svg deleted file mode 100644 index a16970c16..000000000 --- a/docs/assets/images/kubernetes-stacked-color.svg +++ /dev/null @@ -1 +0,0 @@ - diff --git a/docs/assets/images/lab-diagram.png b/docs/assets/images/lab-diagram.png deleted file mode 100644 index 9f4123934..000000000 Binary files a/docs/assets/images/lab-diagram.png and /dev/null differ diff --git a/docs/assets/images/leaf-spline.png b/docs/assets/images/leaf-spline.png deleted file mode 100644 index 8545d1ec4..000000000 Binary files a/docs/assets/images/leaf-spline.png and /dev/null differ diff --git a/docs/assets/images/limits_show.png b/docs/assets/images/limits_show.png deleted file mode 100644 index d0aac4835..000000000 Binary files a/docs/assets/images/limits_show.png and /dev/null differ diff --git a/docs/assets/images/loki-alerting-rules-example.png b/docs/assets/images/loki-alerting-rules-example.png deleted file mode 100644 index 4636e2462..000000000 Binary files a/docs/assets/images/loki-alerting-rules-example.png and /dev/null differ diff --git a/docs/assets/images/metering-ceilometer.png b/docs/assets/images/metering-ceilometer.png deleted file mode 100644 index 3cfa87012..000000000 Binary files a/docs/assets/images/metering-ceilometer.png and /dev/null differ diff --git a/docs/assets/images/metering-overview.svg b/docs/assets/images/metering-overview.svg deleted file mode 100644 index 6c1827aa0..000000000 --- a/docs/assets/images/metering-overview.svg +++ /dev/null @@ -1,3 +0,0 @@ - - -
OpenStack Service APIs (Nova, Cinder, Neutron, etc)
OpenStack Service APIs (Nova, Cinder, Neutron, etc)
Notification Bus (RabbitMQ)
Notification Bus (RabbitMQ)
Ceilometer
Ceilometer
Polling Agents
Polling Agents
Notification Agents
Notification Agen...
Agent1
Agent1
Agent2
Agent2
AgentN
AgentN
Agent1
Agent1
Agent2
Agent2
AgentN
AgentN
Gnocchi
Gnocchi
Metrics API
Metrics API
PostgreSQL

(Index Storage)
PostgreSQL...
Ceph

(Metric Storage)
Ceph...
Metric Clients
Metric Clients
Billing
Billing
Monitoring
Monitoring
Auditing
AuditingViewer does not support full SVG 1.1 diff --git a/docs/assets/images/openstack-dysto-tall.png b/docs/assets/images/openstack-dysto-tall.png deleted file mode 100644 index 4d78e31eb..000000000 Binary files a/docs/assets/images/openstack-dysto-tall.png and /dev/null differ diff --git a/docs/assets/images/openstack-dysto.jpg b/docs/assets/images/openstack-dysto.jpg deleted file mode 100644 index 5e44e7ab4..000000000 Binary files a/docs/assets/images/openstack-dysto.jpg and /dev/null differ diff --git a/docs/assets/images/ospc_flex_logo_red.svg b/docs/assets/images/ospc_flex_logo_red.svg deleted file mode 100644 index d2770bc4b..000000000 --- a/docs/assets/images/ospc_flex_logo_red.svg +++ /dev/null @@ -1,43 +0,0 @@ - - - - - - diff --git a/docs/assets/images/ospc_flex_logo_white.svg b/docs/assets/images/ospc_flex_logo_white.svg deleted file mode 100644 index 314ae2c10..000000000 --- a/docs/assets/images/ospc_flex_logo_white.svg +++ /dev/null @@ -1,43 +0,0 @@ - - - - - - diff --git a/docs/assets/images/pngegg.png b/docs/assets/images/pngegg.png deleted file mode 100644 index 132b8467d..000000000 Binary files a/docs/assets/images/pngegg.png and /dev/null differ diff --git a/docs/assets/images/project-lookup-example.png b/docs/assets/images/project-lookup-example.png deleted file mode 100644 index 64fd6d14c..000000000 Binary files a/docs/assets/images/project-lookup-example.png and /dev/null differ diff --git a/docs/assets/images/prometheus-architecture.png b/docs/assets/images/prometheus-architecture.png deleted file mode 100644 index 1610bc024..000000000 Binary files a/docs/assets/images/prometheus-architecture.png and /dev/null differ diff --git a/docs/assets/images/prometheus-monitoring.png b/docs/assets/images/prometheus-monitoring.png deleted file mode 100755 index 96c5eec6c..000000000 Binary files a/docs/assets/images/prometheus-monitoring.png and /dev/null differ diff --git a/docs/assets/images/quota_show.png b/docs/assets/images/quota_show.png deleted file mode 100644 index 2f81b2996..000000000 Binary files a/docs/assets/images/quota_show.png and /dev/null differ diff --git a/docs/assets/images/r-Icon-RGB-Red.svg b/docs/assets/images/r-Icon-RGB-Red.svg deleted file mode 100644 index 3727460d5..000000000 --- a/docs/assets/images/r-Icon-RGB-Red.svg +++ /dev/null @@ -1 +0,0 @@ - diff --git a/docs/assets/images/rackspace_logo-white.svg b/docs/assets/images/rackspace_logo-white.svg deleted file mode 100644 index ac56c8a41..000000000 --- a/docs/assets/images/rackspace_logo-white.svg +++ /dev/null @@ -1 +0,0 @@ - diff --git a/docs/assets/images/rackspace_logo.png b/docs/assets/images/rackspace_logo.png deleted file mode 100644 index 7e2b9f751..000000000 Binary files a/docs/assets/images/rackspace_logo.png and /dev/null differ diff --git a/docs/assets/images/rackspace_logo.svg b/docs/assets/images/rackspace_logo.svg deleted file mode 100644 index 753d956b7..000000000 --- a/docs/assets/images/rackspace_logo.svg +++ /dev/null @@ -1,35 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/docs/assets/images/sdlc.png b/docs/assets/images/sdlc.png deleted file mode 100644 index 89a89fdbc..000000000 Binary files a/docs/assets/images/sdlc.png and /dev/null differ diff --git a/docs/assets/images/source/Aggregates.graffle b/docs/assets/images/source/Aggregates.graffle deleted file mode 100644 index 310e18ea5..000000000 Binary files a/docs/assets/images/source/Aggregates.graffle and /dev/null differ diff --git a/docs/assets/images/source/Cloud-Hierarchy.graffle b/docs/assets/images/source/Cloud-Hierarchy.graffle deleted file mode 100644 index aef85bcfc..000000000 Binary files a/docs/assets/images/source/Cloud-Hierarchy.graffle and /dev/null differ diff --git a/docs/assets/images/source/Ironic-Architecture.graffle b/docs/assets/images/source/Ironic-Architecture.graffle deleted file mode 100644 index 9fda59b84..000000000 Binary files a/docs/assets/images/source/Ironic-Architecture.graffle and /dev/null differ diff --git a/docs/assets/images/source/Logical-Architecture.graffle b/docs/assets/images/source/Logical-Architecture.graffle deleted file mode 100644 index 759c3a71b..000000000 Binary files a/docs/assets/images/source/Logical-Architecture.graffle and /dev/null differ diff --git a/docs/assets/images/storage-object-store-skyline-gui-01-navigate.png b/docs/assets/images/storage-object-store-skyline-gui-01-navigate.png deleted file mode 100644 index 78a0495c4..000000000 Binary files a/docs/assets/images/storage-object-store-skyline-gui-01-navigate.png and /dev/null differ diff --git a/docs/assets/images/storage-object-store-skyline-gui-02-create-dialog.png b/docs/assets/images/storage-object-store-skyline-gui-02-create-dialog.png deleted file mode 100644 index 5f815725a..000000000 Binary files a/docs/assets/images/storage-object-store-skyline-gui-02-create-dialog.png and /dev/null differ diff --git a/docs/assets/images/storage-object-store-skyline-gui-03-container-list.png b/docs/assets/images/storage-object-store-skyline-gui-03-container-list.png deleted file mode 100644 index d2692818d..000000000 Binary files a/docs/assets/images/storage-object-store-skyline-gui-03-container-list.png and /dev/null differ diff --git a/docs/assets/images/storage-object-store-skyline-gui-04-in-container.png b/docs/assets/images/storage-object-store-skyline-gui-04-in-container.png deleted file mode 100644 index fb70b258c..000000000 Binary files a/docs/assets/images/storage-object-store-skyline-gui-04-in-container.png and /dev/null differ diff --git a/docs/assets/images/storage-object-store-skyline-gui-05-file-list.png b/docs/assets/images/storage-object-store-skyline-gui-05-file-list.png deleted file mode 100644 index 4df7baa81..000000000 Binary files a/docs/assets/images/storage-object-store-skyline-gui-05-file-list.png and /dev/null differ diff --git a/docs/build-test-envs.md b/docs/build-test-envs.md deleted file mode 100644 index 06fb17fe1..000000000 --- a/docs/build-test-envs.md +++ /dev/null @@ -1,115 +0,0 @@ -# Quick Start Guide - -This guide will walk you through the process of deploying a test environment for Genestack. This is a great way to get started -with the platform and to familiarize yourself with the deployment process. The following steps will guide you through the process -of deploying a test environment on an OpenStack cloud in a simple three node configuration that is hyper-converged. - -## Build Script - -The following script will deploy a hyperconverged lab environment on an OpenStack cloud. The script can be found at -[`scripts/hyperconverged-lab.sh`](https://raw.githubusercontent.com/rackerlabs/genestack/refs/heads/main/scripts/hyperconverged-lab.sh). - -??? "View the Hyper-converged Lab Script" - - ``` shell - --8<-- "scripts/hyperconverged-lab.sh" - ``` - -The build script is interactive and will prompt you for the following information - -|
Variable
| Description |
Default
| -|----------|-------------|---------| -| `ACME_EMAIL` | Email address for Let's Encrypt. If an email address is defined and a real domain is used, the deployment will attempt to pull production certificates. | "" | -| `GATEWAY_DOMAIN` | Domain name used for routes within the gateway API. If a valid domain is used, it will be associated with the gateway routes. | "cluster.local" | -| `OS_CLOUD` | OpenStack cloud name. | "default" | -| `OS_FLAVOR` | OpenStack instance flavor, this will automatically select a flavor with < 24GiB of RAM. | "gp.X.8.16" | -| `OS_IMAGE` | OpenStack image name. | "Ubuntu 24.04" | -| `HYPERCONVERGED_DEV` | enable hyperconverged development mode. This will attempt to sync a local copy of Genestack to the development environment. | `false` | -| `LAB_NAME_PREFIX` | Prefix for the lab environment. Useful when building multiple labs in a single project | "hyperconverged" | - -All of the variables can be defined on the command line using environment variables. - -!!! example "Deploying a Hyper-converged Lab Environment with Environment Variables" - - ``` shell - export ACME_EMAIL="user@domain.com" - export GATEWAY_DOMAIN="cluster.local" - export OS_CLOUD="default" - export OS_FLAVOR="gp.0.8.16" - export OS_IMAGE="Ubuntu 24.04" - export HYPERCONVERGED_DEV="false" - /opt/genestack/scripts/hyperconverged-lab.sh - ``` - -## Overview - -A simple reference architecture for a hyper-converged lab environment is shown below. This environment consists of three nodes -that are connected to a two networks. The networks are connected via a router that provides external connectivity. - -``` mermaid -flowchart TB - %% Define clusters/subgraphs for clarity - subgraph Public_Network - PF["Floating IP
(203.0.113.x)"] - end - - subgraph Router - TR["hyperconverged-router
(with external gateway)"] - end - - subgraph Hyperconverged_Net - TN["hyperconverged-net
(192.168.100.x)"] - end - - subgraph Hyperconverged_Compute_Net - TCN["hyperconverged-compute-net
(192.168.102.x)"] - end - - %% Hyperconverged Nodes - subgraph Node_0 - HPC0["hyperconverged-0"] - end - - subgraph Node_1 - HPC1["hyperconverged-1"] - end - - subgraph Node_2 - HPC2["hyperconverged-2"] - end - - %% Connections - PF --> TR - TR --> TN - - TN -- mgmt port --> HPC0 - TN -- mgmt port --> HPC1 - TN -- mgmt port --> HPC2 - - HPC0 -- compute port --> TCN - HPC1 -- compute port --> TCN - HPC2 -- compute port --> TCN -``` - -## Build Phases - -The deployment script will perform the following steps: - -- Create a new OpenStack router -- Create a new OpenStack networks -- Create a new OpenStack security groups -- Create a new OpenStack ports -- Create a new OpenStack keypair -- Create a new OpenStack instance -- Create a new OpenStack floating IP -- Execute the basic Genestack installation - -## Post Deployment - -After the deployment is complete, the script will output the internal and external floating IP address information. - -With this information, operators can login to the Genestack instance and begin to explore the platform. - -## Demo - -[![asciicast](https://asciinema.org/a/706976.svg)](https://asciinema.org/a/706976) diff --git a/docs/cloud-onboarding-welcome.md b/docs/cloud-onboarding-welcome.md deleted file mode 100644 index 22a8463b4..000000000 --- a/docs/cloud-onboarding-welcome.md +++ /dev/null @@ -1,7 +0,0 @@ -![Rackspace Cloud Software](assets/images/ospc_flex_logo_red.svg){ align=left : style="max-width:175px" } - -# Welcome to Rackspace OpenStack On Boarding - -In this section we will be showing you how to install the Openstack Command Line Tools along with some basic commands that may be helpful to you during your Genestack experience. - -For a full list up of Openstack client commands please visit the [upstream docs](https://docs.openstack.org/python-openstackclient/latest). diff --git a/docs/deployment-guide-welcome.md b/docs/deployment-guide-welcome.md deleted file mode 100644 index 335574c15..000000000 --- a/docs/deployment-guide-welcome.md +++ /dev/null @@ -1,16 +0,0 @@ -![Rackspace Cloud Software](assets/images/ospc_flex_logo_red.svg){ align=left : style="max-width:350px" } - -# What is Genestack? - -Genestack is a complete operations and deployment ecosystem for Kubernetes and OpenStack. The purpose of -this project is to allow hobbyists, operators, and cloud service providers the ability to build, scale, and -leverage Open-Infrastructure in new and exciting ways. - -Genestack’s inner workings are a blend of dark magic — crafted with [Kustomize](https://kustomize.io) and -[Helm](https://helm.sh). It’s like cooking with cloud. Want to spice things up? Tweak the -`kustomization.yaml` files or add those extra 'toppings' using Helm's style overrides. However, the -platform is ready to go with batteries included. - -Genestack is making use of some homegrown solutions, community operators, and OpenStack-Helm. Everything -in Genestack comes together to form cloud in a new and exciting way; all built with Open Source solutions -to manage cloud infrastructure in the way you need it. diff --git a/docs/documentation-standards.md b/docs/documentation-standards.md deleted file mode 100644 index 59baa8455..000000000 --- a/docs/documentation-standards.md +++ /dev/null @@ -1,182 +0,0 @@ ---- -hide: - - navigation ---- - -# Genestack Documentation Standards and Style Guide - -This document is intended to help define some common documentation standards and practices for the [Genestack documentation](https://docs.rackspacecloud.com/){:target="_blank"}. - -## Introduction - -The Genestack documentation is built using [mkdocs-material](https://squidfunk.github.io/mkdocs-material/){:target="_blank"} with the source files located directly in the [docs subdirectory](https://github.com/rackerlabs/genestack/tree/main/docs){:target="_blank"} of the [Genestack project](https://github.com/rackerlabs/genestack){:target="_blank"}. - -This page highlights some of the conventions and standards we strive to use across the Genestack documentation to hopefully provide a consistent reading experience for Genestack users. - -## Page Layout - -Each page should start with a top-level heading (single `#`) with the tile of the page. - -Subsections start with 2nd-level headings (double `##`) and can have various levels nested underneath, 3rd-level (triple `###`), 4th-level (quad `####`), etc... - -## Markdown - -While easy to use, Markdown does have some "gotchas" that make writing documentation interesting. It's easy to make some [common mistakes](https://gist.github.com/OpenStackKen/52d70ef2be6570fbd2603738e02adacc) when writing Markdown that can result in bad, illegible, or unintentionally humorous rendering issues. - -This is mostly due to ambiguous information on how to implement certain edge-cases. CommonMark was one standard put in place to attempt to make this easier for authors. - -Here are some notes on Markdown syntax used in mkdocs: - -### Headings - -The headings (defined by `#`) should follow a natural progression of the hierarchy of the page contents. You cannot have two title headings otherwise they won't show up on the table of contents on the right side of the page: - -```markdown -# Title -## Main heading one -### Sub Heading one -### Sub heading two -## Main heading two -``` - -### Links - -Links should follow this syntax: - -```markdown -[Link](path to link) -``` - -If it is a link to another wiki page it should be a relative path: - -```markdown -[Installation](Installation) -``` - -and not like this: - -```markdown -[Installation](https://github.com/username/repo/wiki/Installation) -``` - -Instead, use that style for external links. Also, for external links, please add `{:target="_blank"}` at the end to have the link open in a new window: - -```markdown -[Google](https://google.com)){:target="_blank"} -``` - -### Code Blocks - -#### Inline - -Inline code blocks are indicated with single backticks: \` - -```markdown -`inline` -``` - -This will render as: `inline` - -#### Code blocks - -Code blocks are _fenced_ with triple backtick fences - -````markdown -``` -# code block -``` -```` - -This will render as: - -```markdown -# code block -``` - -### Bullets - -Bullets are used to denote unordered lists. To have nested layers of bullets, you need to indent by 4 spaces for each nested layer bullet[^1]. - -```markdown -- Bullet - - Sub bullet - - Sub sub bullet -``` - -This will render like this: - -- Bullet - - Sub bullet - - Sub sub bullet - -**NOTE:** [Markdownlint](#markdownlint) will complain, saying that you should _indent by 2_ unless you change or ignore rule [MD007](https://github.com/DavidAnson/markdownlint/blob/main/doc/md007.md){:target="_blank"}. - -### Numbering - -Numbers will only order properly if in a listed sequence. If that sequence is broken by paragraphs then the numbering will restart. - -Numbered lists are formatted as follows: - -```markdown -1. item 1 -2. item 2 -3. item 3 -4. item 4 -``` - -### Symbols/Emojis - -Emojis are not supported with python markdown and should be avoided. Rather important text should be bolded or italicized. - -The following in github: - -```markdown -:exclamation: -``` - -renders to :exclamation: - -but in the generated docs it will show - -```markdown -:exclamation: -``` - -### Markdownlint - -Using [markdownlint](https://github.com/DavidAnson/markdownlint){:target="_blank"} on your files before you check them in can save you a lot of time and hassle. While some of mkdocs - -You can use markdownlint from the CLI, or as a plugin in [Visual Studio Code](https://marketplace.visualstudio.com/items?itemName=DavidAnson.vscode-markdownlint){:target="_blank"}. - -For other editors there are also solutions: - -- For Emacs, there is [markdown mode](https://jblevins.org/projects/markdown-mode){:target="_blank"}. -- For vim, there is a [markdown plugin](https://github.com/preservim/vim-markdown){:target="_blank"} as well as a [markdownlint plugin](https://github.com/fannheyward/coc-markdownlint){:target="_blank"} available. - -## Admonitions - -Admonitions are used to highlight certain information to make it stand-out to readers. - -### Admonition Standards - -It is important to have some documentation standards so that a user can understand how to process the information they read. - -!!! info - The "info" admonition type is to point out something particularly interesting. - -!!! info "To Do" - For "To Do" items, use the "info" admonition with a "To Do" title - ... - -!!! tip - The "tip" admonition type is to show a recommended or preferred way to implement a detail or to address a concern. - -!!! warning - The "warning" admonition type should be use to show when something can have adverse consequences if incorrectly implemented or if certain precautions are not taken. - -### Custom Admonition Types - -!!! genestack - The "genestack" admonition type is for Genestack-specific information or to point how _how_ something is done in Genestack. - -[^1]: This is explained [here](https://python-markdown.github.io/#differences){:target="_blank"} in the python-markdown docmentation. diff --git a/docs/etcd-backup.md b/docs/etcd-backup.md deleted file mode 100644 index ede8814b3..000000000 --- a/docs/etcd-backup.md +++ /dev/null @@ -1,51 +0,0 @@ -# Etcd Backup - -In order to backup etcd we create a backup CronJob resource. This constitues of 3 things: - -1. etcd-backup container image with the etcdctl binary and the python script that uploads -the backup to Ceph S3 endpoint or any S3 compatible endpoint. - -2. The CronJob deployment resource. This job will only be done on the box with label set -matching is-etcd-backup-enabled. - -3. Secrets required for the backup to function. These include the location of the -S3 endpoint, access keys, and etcd certs to access etcd endpoints. - -Label one or more box in the cluster to run the job: - -``` -kubectl label node etcd01.your.domain.tld is-etcd-backup-node=true -``` - -Create the secret: - -!!! note "Information about the secrets used" - - Manual secret generation is only required if you haven't run the create-secrets.sh script located in /opt/genestack/bin. However, you still need to add data to a couple of empty keys that are region-specific. - - ??? example "Example secret generation" - - ``` shell - kubectl --namespace openstack \ - create secret generic etcd-backup-secrets \ - --type Opaque \ - --from-literal=ACCESS_KEY="" \ - --from-literal=SECRET_KEY="" \ - --from-literal=S3_HOST="127.0.0.1" \ - --from-literal=S3_REGION="" \ - --from-literal=ETCDCTL_API="3" \ - --from-literal=ETCDCTL_ENDPOINTS="https://127.0.0.1:2379" \ - --from-literal=ETCDCTL_CACERT="/etc/ssl/etcd/ssl/ca.pem" \ - --from-literal=ETCDCTL_CERT="/etc/ssl/etcd/ssl/member-etcd01.your.domain.tld.pem" \ - --from-literal=ETCDCTL_KEY="/etc/ssl/etcd/ssl/member-etcd01.your.domain.tld-key.pem" - ``` - -!!! note - - Make sure to use the correct values for your region. - -Next, Deploy the backup job: - -``` -kubectl apply -k /etc/genestack/kustomize/backups/base/etcd --namespace openstack -``` diff --git a/docs/genestack-architecture.md b/docs/genestack-architecture.md deleted file mode 100644 index ea92aa55d..000000000 --- a/docs/genestack-architecture.md +++ /dev/null @@ -1,26 +0,0 @@ -# Environment Architecture - -Genestack is making use of some homegrown solutions, community operators, and OpenStack-Helm. Everything -in Genestack comes together to form cloud in a new and exciting way; all built with opensource solutions -to manage cloud infrastructure in the way you need it. - -They say a picture is worth 1000 words, so here's a picture. - -![Genestack Architecture Diagram](assets/images/diagram-genestack.png) - -The idea behind Genestack is simple, build an Open Infrastructure system that unites Public and Private -clouds with a platform that is simple enough for the hobbyist yet capable of exceeding the needs of the -enterprise. - -## Dependencies - -Yes there are dependencies. This project is made up of several submodules which are the component -architecture of the Genestack ecosystem. - -* Kubespray: The bit delivery mechanism for Kubernetes. While we're using Kubespray to deliver a production - grade Kubernetes baremetal solution, we don't really care how Kubernetes gets there. -* MariaDB-Operator: Used to deliver MariaBD clusters -* OpenStack-Helm: The helm charts used to create an OpenStack cluster. -* OpenStack-Helm-Infra: The helm charts used to create infrastructure components for OpenStack. -* Rook: The Ceph storage solution du jour. This is optional component and only needed to manage Ceph - when you want Ceph. diff --git a/docs/genestack-components.md b/docs/genestack-components.md deleted file mode 100644 index 2b25135f9..000000000 --- a/docs/genestack-components.md +++ /dev/null @@ -1,63 +0,0 @@ -# Product Component Matrix - -The following components are part of the initial product release -and largely deployed with Helm+Kustomize against the K8s API (v1.28 and up). - -| 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 | 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 | diff --git a/docs/genestack-getting-started.md b/docs/genestack-getting-started.md deleted file mode 100644 index e59a5af6c..000000000 --- a/docs/genestack-getting-started.md +++ /dev/null @@ -1,27 +0,0 @@ -# Getting the Genestack Repository - -Before you can do anything we need to get the code. Because we've sold our soul to the submodule devil, you're going to need to recursively clone the repo into your location. - -!!! note - - Throughout the all our documentation and examples the genestack code base will be assumed to be in `/opt`. - -``` shell -git clone --recurse-submodules -j4 https://github.com/rackerlabs/genestack /opt/genestack -``` - -## Basic Setup - -The basic setup requires ansible, ansible collection and helm installed to install Kubernetes and OpenStack Helm: - -``` shell -/opt/genestack/bootstrap.sh -``` - -!!! tip - - If running this command with `sudo`, be sure to run with `-E`. `sudo -E /opt/genestack/bootstrap.sh`. This will ensure your active environment is passed into the bootstrap command. - -Once the bootstrap is completed the default Kubernetes provider will be configured inside `/etc/genestack/provider` and currently defaults to kubespray. - -The ansible inventory is expected at `/etc/genestack/inventory` diff --git a/docs/genestack-logging.md b/docs/genestack-logging.md deleted file mode 100644 index 048c047a1..000000000 --- a/docs/genestack-logging.md +++ /dev/null @@ -1,72 +0,0 @@ -# Genestack Logging - -[TOC] - -### Introduction - -Genestack logging is a straight forward system that collects, stores and provides an interface to search and read logs on-demand. The storage backend is open to fit the needs of your deployment, so whether backing up to Openstack Swift, S3, Ceph, or file-share, Genestack logging can fit in your environment. - -Out-of-box Genestack logging is comprised of three separate technologies: - -- [Fluentbit](https://fluentbit.io/), a fast and lightweight telemetry agent for logs, metrics, and traces for Linux, macOS, Windows, and BSD family operating systems. Fluentbit grabs log entries immediately from your Kubernetes application and ships them to Loki for aggregation -- [Loki](https://github.com/grafana/loki), a log aggregation system for Kubernetes that stores logs in a time series database and is often used with Grafana to visualize them. -- [Grafana](https://grafana.com/), enables you to query, visualize, alert on, and explore your metrics, logs, and traces. - -These components are easily replaceable so that implementation in your existing environment is simple as possible. For example, Grafana needs not to be your dashboard if your environment you are licensed for Splunk. - -### Architecture - -![grafan architecture](assets/images/grafana-explore.png) - -### Configuration - -All configurations for Loki and FluentBit are in [genestack/base-helm-configs/loki](https://github.com/rackerlabs/genestack/tree/main/base-helm-configs/loki). Review the default deployment settings and overrides for your needs. - -### FluentBit, Loki, and Storage Operations - -Let's break down the process of how Fluent Bit, Kubernetes, Loki, and OpenStack Swift interact to efficiently collect and store application logs: - -1. Log Generation in Kubernetes: - - Kubernetes applications run within pods, which are the smallest deployable units of computing that contain one or more containers. Applications generate logs as part of their normal operation, recording events, errors, and other relevant information. - -2. Fluent Bit as the Log Collector: - - Fluent Bit is deployed as a **DaemonSet** in Kubernetes, ensuring it runs on every node of the cluster. It acts as a lightweight log collector, efficiently gathering logs from various sources, including application pods. It can parse and enrich logs with additional metadata, such as timestamps, hostnames, and Kubernetes labels. - -3. Sending Logs to Loki: - - Loki is configured as the output destination for Fluent Bit, which sends the collected and enriched logs to Loki which in turn indexes the logs, allowing for efficient querying and searching later. - -4. Loki's Role in Long-Term Storage: - - Loki can retain logs for a specified duration, depending on your configuration. Loki chunks the application logs it has received into large objects which are then sent via HTTP/HTTPS calls to Openstack Swift to reduce long-term storage costs and maintain historical data. - -5. OpenStack Swift as Object Storage: - - OpenStack Swift, or other S3-Compatible storage solutions such Ceph, provides object storage leveraging Swift's durability and scalability to store archived logs for extended periods. - -### Key Benefits of This Architecture - -- Efficient Log Collection: Fluent Bit's lightweight design and efficient data transfer mechanisms ensure timely log collection. -- Scalable Log Aggregation: Loki's distributed architecture can handle large volumes of logs and scale horizontally to meet increasing demands. -- Flexible Log Retention: Loki's ability to archive logs to object storage provides a cost-effective solution for long-term retention. -- Powerful Log Querying: Loki's query language allows for complex log analysis and troubleshooting. -- Secure and Reliable Storage: OpenStack Swift offers durable and secure object storage for critical log data. - -### Accessing Log Information through Grafana - -The logs that Loki stores for us can be searched and read though Grafana. From the left-side menu bars, select 'Explore' to enter queries in Grafana. - -Start by selecting from the '**Label Filter**' drop-down for the application area of logs you want to search from. These are keyed on labels determined in the Kubernetes deployment. For example, the 'application' choice will allow you to choose all Openstack services by name (nova, cinder, etc ). All label filters are defined in base-helm-configs and can be referenced there. Only one selection is allowed per exporession, so you will need to select press the **+** to add more selections for refined searches. Then you enter the text you are searching for with its search qualifier ( line contains, line does not continue, etc). The example here shows searching for a server UUID in Nova: - -![grafana search](assets/images/grafana-search.png) - - Label matching operators are as follows: - -- `=`: exactly equal -- `!=`: not equal -- `=~`: regex matches -- `!~`: regex does not match - -Extensive documentation for query is available in the [Grafana](https://grafana.com/docs/loki/latest/query/) pages. diff --git a/docs/genestack-upgrade.md b/docs/genestack-upgrade.md deleted file mode 100644 index 3497be55e..000000000 --- a/docs/genestack-upgrade.md +++ /dev/null @@ -1,70 +0,0 @@ -# Updating the Genestack - -Running a genestack upgrade is fairly simple and consists of mainly updating the `git` checkout and then running through the needed `helm` charts to deploy updated applications. - -## Change to the genestack directory - -``` shell -cd /opt/genestack -``` - -Fetch the latest checkout from your remote. - -``` shell -git fetch origin -git rebase origin/main -``` - -!!! tip - - You may want to checkout a specific SHA or tag when running a stable environment. - -## Update the submodules - -``` shell -git pull --recurse-submodules -``` - -## Updating the genestack applications - -An update is generally the same as an install. Many of the Genestack applications are governed by operators which include lifecycle management. - -* When needing to run an upgrade for the infrastructure operators, consult the operator documentation to validate the steps required. -* When needing to run an upgrade for the OpenStack components, simply re-run the `helm` charts as documented in the Genestack installation process. - -!!! note "Before running upgrades, make sure cached charts are cleaned up" - - ``` shell - find /etc/genestack/kustomize/ -name charts -type d -exec rm -rf {} \; - ``` - -## Kubernetes Upgrade Notes - -Over the course of normal operations it's likely that a CRD will change versions, names, or something else. In these cases, should an operator or helm chart not gracefully handle an full upgrade, the `kubectl convert` plugin can be used to make some adjustments where needed. - -!!! example "Converting mmontes CRDs to mariadb official ones" - - ``` shell - kubectl get --namespace openstack crd.namespace -o yaml value > /tmp/value.crd.namespace.yaml - kubectl convert -f /tmp/value.crd.namespace.yaml --output-version new-namespace/VERSION - ``` - -!!! example "Cleaning up nova jobs before upgrading" - - ``` shell - kubectl --namespace openstack delete jobs $(kubectl --namespace openstack get jobs --no-headers -o custom-columns=":metadata.name" | grep nova) - ``` - -## Kubernetes Finalizers - -When processing an upgrade there may come a time when a finalizer is stuck, typically something that happens when an operator or an api reference is changed. If this happens one way to resolve the issue is to patch the Finalizers. - -!!! warning - - Patching Finalizers could leave orphaned resources. Before patching a finalizer be sure your "ready." - -!!! example "Patching Finalizers" - - ``` shell - kubectl patch $@ --type='json' -p='[{"op": "remove", "path": "/metadata/finalizers"}]' - ``` diff --git a/docs/grafana.md b/docs/grafana.md deleted file mode 100644 index 8624cbc0f..000000000 --- a/docs/grafana.md +++ /dev/null @@ -1,76 +0,0 @@ -# Grafana - -Grafana is installed with the upstream Helm Chart. Running the installation is simple and can be done with our integration script. - -Before running the script, you will need to create a secret file with your database username and passwords. - -!!! note "Information about the secretes used" - - Manual secret generation is only required if you haven't run the `create-secrets.sh` script located in `/opt/genestack/bin`. - - ??? example "Example secret generation" - - ``` shell - kubectl --namespace grafana \ - create secret generic grafana-db \ - --type Opaque \ - --from-literal=password="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-32};echo;)" \ - --from-literal=root-password="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-32};echo;)" \ - --from-literal=username=grafana - ``` - -## Custom Values - -Before running the deployment script, you must set the `custom_host` value `grafana-helm-overrides.yaml` to the correct FQDN you wish to use within the deployment. - -!!! example "grafana-helm-overrides.yaml" - - ``` yaml - custom_host: grafana.api.your.domain.tld - ``` - -## Installation - -=== "Default" - - The default installation is simple. The `grafana-helm-overrides.yaml` file is located at `/etc/genestack/helm-configs/grafana/` and overrides can be set there to customize the installation. - -=== "Azure Integrated" - - Before running installation when integrating with Azure AD, you must create te `azure-client-secret` - - You can base64 encode your `client_id` and `client_secret` by using the echo and base64 command. - - ``` shell - echo -n "YOUR CLIENT ID OR SECRET" | base64 - ``` - - Apply your base64 encoded values to the `azure-client-secret.yaml` file and apply it to the `grafana` namespace. - - !!! example "azure-client-secret.yaml" - - ``` yaml - --8<-- "manifests/grafana/azure-client-secret.yaml" - ``` - - Once you have created the secret file, update your `grafana-helm-overrides.yaml` file with the Azure AD values. - - !!! example "azure-overrides.yaml" - - ``` yaml - --8<-- "base-helm-configs/grafana/azure-overrides.yaml.example" - ``` - -### Listeners and Routes - -Listeners and Routes should have been configureed when you installed the Gateway API. If so some reason they were not created, please following the install guide here: [Gateway API](infrastructure-gateway-api.md) - -### Deployment - -Run the Grafana deployment Script `/opt/genestack/bin/install-grafana.sh` - -??? example "Run the Grafana deployment Script `/opt/genestack/bin/install-grafana.sh`" - - ``` shell - --8<-- "bin/install-grafana.sh" - ``` diff --git a/docs/index.md b/docs/index.md deleted file mode 100644 index e311ab217..000000000 --- a/docs/index.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -hide: - - navigation - - toc ---- - -# Welcome to the Rackspace OpenStack Documentation - -
-- :material-heart:{ .lg } __A Welcoming Community__ - - [![Rackspace Cloud Software](assets/images/ospc_flex_logo_red.svg){ align=left : style="max-width:125px" :pointer-events: none; }](https://discord.gg/2mN5yZvV3a) - Rackspace would like to welcome you to the home. If you're developing applications, wanting to contribute to OpenStack, or just - looking for a better platform; you're in the right place. - - [:octicons-comment-24: Join the Discord](https://discord.gg/2mN5yZvV3a) - -- :material-alpha:{ .xl .middle } - __Genestack__ __/dʒen.ə.stæk/__ - - 1. The Genesis of your Open-Infrastructure - 2. Your new favorite ecosystem - 3. Enterprise ready - 4. The Rackspace cloud, simplified - 5. Hybrid by design - -- :material-abacus:{ .xl .middle } __Rackspace OpenStack Solutions__ - - Where Kubernetes and OpenStack tango in the cloud. Imagine a waltz between systems that deploy what you need. - Operators play the score, managing the complexity with a flick of their digital batons. They unify the chaos, - making scaling and management a piece of cake. Think of it like a conductor effortlessly guiding a cacophony - into a symphony. - -- :material-cloud:{ .lg } __Simple Solutions__ - - Learn about the components. - - [:octicons-diff-renamed-16: A complete list of Project Components](genestack-components.md) - - --- - - Start building now. - - [:octicons-play-24: Deployment Guide](genestack-getting-started.md) - -
- ---- - -## :octicons-quote-24: Rackspace OpenStack is not merely an alternative; it is a strategic enabler - -Concerns related to vendor lock-in, limited environmental control, and potential performance issues at scale are essential considerations, especially when building an infrastructure expected to provide continual value for the lifetime of the deployment. Rackspace OpenStack is Open-Cloud powered by open-infrastructure has better efficiency and guaranteed business continuity across the public and private cloud landscape. - -[:octicons-reply-24: Learn how we're solving tomorrow's cloud problems today](https://www.rackspace.com/solve/return-openstack) diff --git a/docs/infrastructure-argocd.md b/docs/infrastructure-argocd.md deleted file mode 100644 index e46e7255a..000000000 --- a/docs/infrastructure-argocd.md +++ /dev/null @@ -1,16 +0,0 @@ -# Deploy a argocd - -## Install Argocd - -!!! example "Run the argocd deployment Script `bin/install-argocd.sh`" - - ``` shell - --8<-- "bin/install-argocd.sh" - ``` - - -## Verify readiness with the following command. - -``` shell -kubectl --namespace argocd get horizontalpodautoscaler.autoscaling argocd -w -``` diff --git a/docs/infrastructure-envoy-gateway-api.md b/docs/infrastructure-envoy-gateway-api.md deleted file mode 100644 index 415ff5b5f..000000000 --- a/docs/infrastructure-envoy-gateway-api.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -hide: - - footer ---- - -# Envoy Gateway API - -The [Envoy Gateway](https://gateway.envoyproxy.io/) is an open-source project that provides an implementation -of the Gateway API using Envoyproxy as the data plane. The Gateway API is a set of APIs that allow users to configure -API gateways using a declarative configuration model. - -## Installation - -Run the helm command to install Envoy Gateway. - -??? example "Run the Envoy Gateway deployment Script `/opt/genestack/bin/install-envoy-gateway.sh`" - - ``` shell - --8<-- "bin/install-envoy-gateway.sh" - ``` - -The install script will deploy Envoy Gateway to the `envoy-gateway-system` namespace via Helm. - -## Setup - -??? example "Run the Envoy Gateway setup Script `/opt/genestack/bin/setup-envoy-gateway.sh`" - - ``` shell - --8<-- "bin/setup-envoy-gateway.sh" - ``` - -The setup script will ask the following questions: - -* Enter a valid email address for use with ACME, press enter to skip" -* Enter the domain name for the gateway" - -These values will be used to generate a certificate for the gateway and set the routes used within the flex-gateway, -typically for OpenStack. This script can also be fully automated by providing the required values as arguments. - -!!! example "Run the Envoy Gateway setup Script with arguments" - - ``` shell - ACME_EMAIL="username@your.domain.tld" GATEWAY_DOMAIN="your.domain.tld" /opt/genestack/bin/setup-envoy-gateway.sh - ``` - -## Validation - -At this stage, Envoy Gateway should be operational. To validate the configuration, run the following command. - -``` shell -kubectl -n openstack get httproute -``` - -``` shell -kubectl -n envoy-gateway get gateways.gateway.networking.k8s.io flex-gateway -``` - -## Troubleshooting - -If you encounter any issues, check the logs of the `envoy-gateway` deployment. - -``` shell -kubectl logs -n envoy-gateway-system deployment/envoy-gateway -``` diff --git a/docs/infrastructure-fluentbit.md b/docs/infrastructure-fluentbit.md deleted file mode 100644 index 7918000f2..000000000 --- a/docs/infrastructure-fluentbit.md +++ /dev/null @@ -1,13 +0,0 @@ -# Deploy Fluentbit - -This guide will help you deploy fluentbit to your kubernetes cluster. Fluentbit is a lightweight log shipper that can be used to send logs to loki. - -## Deployment - -Run the Fluent-Bit deployment Script `/opt/genestack/bin/install-fluentbit.sh` - -??? example "Run the Fluent-Bit deployment Script `/opt/genestack/bin/install-fluentbit.sh`" - - ``` shell - --8<-- "bin/install-fluentbit.sh" - ``` diff --git a/docs/infrastructure-gateway-api.md b/docs/infrastructure-gateway-api.md deleted file mode 100644 index a47d03284..000000000 --- a/docs/infrastructure-gateway-api.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -hide: - - footer ---- - -# Gateway API - -Gateway API is L4 and L7 layer routing project in Kubernetes. It represents next generation of k8s Ingress, LB and Service Mesh APIs. -For more information on the project see: [Gateway API SIG.](https://gateway-api.sigs.k8s.io/) - -!!! genestack - - For each externally exposed service, example: keystone endpoint, we have a GatewayAPI resource setup to use listeners on services with matching rules based on - hostname, for example `keystone.your.domain.tld`. When a request comes in to the f5 vip for this the vip is setup to pass the traffic to the Metallb - external vip address. Metallb then forwards the traffic to the appropriate service endpoint for the gateway controller which matches the hostname and passes the - traffic onto the right service. The same applies to internal services. Anything that matches `your.domain.tld` hostname can be considered internal and handled accordingly. - - ``` mermaid - flowchart LR - External --> External_VIP_Address --> MetalLB_VIP_Address --> Gateway_Service - ``` - -The k8s Gateway API is NOT the same an API Gateway. While both sound the same, API Gateway is a more of a general -concept that defines a set of resources that exposes capabilities of a backend service but also provide other -functionalities like traffic management, rate limiting, authentication and more. It is geared towards commercial -API management and monetisation. - -## Cross Namespace Routing - -Gateway API has support for multi-ns and cross namespace routing. Routes can be deployed into different Namespaces and Routes can attach to Gateways across -Namespace boundaries. This allows user access control to be applied differently across Namespaces for Routes and Gateways, effectively segmenting access and -control to different parts of the cluster-wide routing configuration. - -More information on cross namespace routing can be found [here](https://gateway-api.sigs.k8s.io/guides/multiple-ns/). - -## Resource Models in Gateway API - -| Type | Description | -| ---- | ----------- | -| [GatewayClass](https://gateway-api.sigs.k8s.io/api-types/gatewayclass/) | Represents a class of Gateway instances. | -| [Gateway](https://gateway-api.sigs.k8s.io/api-types/gateway/) | Represents a single Gateway instance. | -| [HTTPRoute](https://gateway-api.sigs.k8s.io/api-types/httproute/) | Represents a set of HTTP-specific rules for mapping traffic to a backend. | -| [Listener](https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.Listener) | Represents a network endpoint that can accept incoming traffic. | - -## Choosing a Gateway API Implementation - -Within Genestack, multiple options are available for use as Gateway API implementations. The following table provides a comparison of the available options. - -| Backend Options | Status |
Overview
| -| --------------- | ------ | --------------------------------------- | -| [Envoy](infrastructure-envoy-gateway-api.md) | **Recommended** | Feature rich, large community, recommended for Production environments. | -| [NGINX](infrastructure-nginx-gateway-api.md) | | Stable codebase, simple implementation | diff --git a/docs/infrastructure-kube-ovn-re-ip.md b/docs/infrastructure-kube-ovn-re-ip.md deleted file mode 100644 index 4f9157fe7..000000000 --- a/docs/infrastructure-kube-ovn-re-ip.md +++ /dev/null @@ -1,65 +0,0 @@ -# Re-IP Your Rackspace OpenStack Environment - -When running an OpenStack-based environment, especially one that includes Kubernetes—you may encounter -scenarios where your existing IP space is too small or conflicts with other networks. In these cases, -you can re-IP your cloud by following the steps below. However, be aware that changing a subnet’s CIDR -disrupts existing services and requires Pods (or other components) to be rebuilt. Plan carefully to -minimize impact on production workloads. - -!!! Important - - After changing the subnet CIDR, existing Pods will lose proper network access and must be rebuilt. - We strongly recommend planning downtime or scheduling this operation during a maintenance window to - avoid unexpected disruptions. - - These instructions only cover changing the CIDR for a subnet. If you need to update the Join subnet, - please refer to [Change Join CIDR](https://kubeovn.github.io/docs/stable/en/ops/change-join-subnet) - from the Kube-OVN documentation. - -## Steps & Considerations - -| **Step** | **Description** | -| -------- | --------------- | -| Plan Downtime | Because all existing Pods need to be rebuilt, schedule this change during a maintenance window or a low-traffic period. | -| Validate Services | After your Pods are back up, verify that services and applications are reachable on the new IP range. | -| Monitor & Log | Keep a close eye on logs, performance metrics, and network stability after re-IP to ensure everything returns to optimal functionality. | - -For additional guidance, or if you have more complex networking requirements, contact your **Rackspace** support team. We’re here to help you build a resilient, scalable cloud environment tailored to your needs. - -## Running the Maintenance - -* Use `kubectl edit` to update the subnet’s `cidrBlock`, `gateway`, and `excludeIps`. - -| Field | Description | Type | -| ----- | ----------- | ---- | -| `cidrBlock` | The new CIDR block for the subnet. | STRING | -| `gateway` | The gateway IP address for the subnet. | STRING | -| `excludeIps` | A list of IP addresses that should not be assigned to Pods. | ARRAY | - -``` shell -kubectl edit subnets.kubeovn.io ovn-default -``` - -* Save and exit once you have updated the fields with the new CIDR information. - -### Rebuild All Pods in the Updated Subnet - -This example shows how to delete all Pods that are not using host-networking. - -!!! genestack - - This command will have a significant impact on your environment, impacting all service APIs; however, - none of the data will be lost and all of the dataplane traffic should not be impacted. - -``` shell -for ns in $(kubectl get ns --no-headers -o custom-columns=NAME:.metadata.name); do - for pod in $(kubectl get pod --no-headers -n "$ns" --field-selector spec.restartPolicy=Always -o custom-columns=NAME:.metadata.name,HOST:spec.hostNetwork | awk '{if ($2!="true") print $1}'); do - kubectl delete pod "$pod" -n "$ns" --ignore-not-found --wait=False - done -done -``` - -## Conclusion - -After running the maintenance, your OpenStack environment should be re-IP’d and ready to handle your workloads. -If you encounter any issues or need further assistance, please reach out to your **Rackspace** support team for help. diff --git a/docs/infrastructure-libvirt.md b/docs/infrastructure-libvirt.md deleted file mode 100644 index db2b35537..000000000 --- a/docs/infrastructure-libvirt.md +++ /dev/null @@ -1,17 +0,0 @@ -# Deploy Libvirt - -The first part of the compute kit is Libvirt. - -## Run the package deployment - -!!! example "Run the libvirt deployment Script `bin/install-libvirt.sh`" - - ``` shell - --8<-- "bin/install-libvirt.sh" - ``` - -Once deployed you can validate functionality on your compute hosts with `virsh` - -``` shell -kubectl exec -it $(kubectl get pods -l application=libvirt -o=jsonpath='{.items[0].metadata.name}' -n openstack) -n openstack -- virsh list -``` diff --git a/docs/infrastructure-loki.md b/docs/infrastructure-loki.md deleted file mode 100644 index 3067c03ec..000000000 --- a/docs/infrastructure-loki.md +++ /dev/null @@ -1,53 +0,0 @@ -# Setting up Loki - -Loki is a horizontally-scalable, highly-available, multi-tenant log aggregation system inspired by Prometheus. It is designed to be very cost-effective and easy to operate. It does not index the contents of the logs, but rather a set of labels for each log stream. - -## Add the grafana helm repo - -``` shell -helm repo add grafana https://grafana.github.io/helm-charts -helm repo update -``` - -### Install the helm chart - -ou will need to make changes depending on how you want to configure loki. Example files are included in `genetack/base-helm-configs`. Choose one relevant to your deploy, edit for revelant data, and ensure you copy the file to `/etc/genestack/base-helm/loki-helm-overrides.yaml` - -``` shell -helm upgrade --install \ - --values /etc/genestack/helm-configs/loki/loki-helm-overrides.yaml \ - loki grafana/loki \ - --create-namespace \ - --namespace grafana \ - --version 5.47.2 -``` - -=== "Swift _(Recommended)_" - - !!! abstract - - If you plan on using **Swift** as a backend for log storage see the `loki-helm-swift-overrides-example.yaml` file in the `helm-configs/loki` directory. - - ``` yaml - --8<-- "base-helm-configs/loki/loki-helm-swift-overrides-example.yaml" - ``` - -=== "S3" - - !!! abstract - - If you plan on using **S3** as a backend for log storage see the `loki-helm-s3-overrides-example.yaml` file in the `helm-configs/loki` directory. - - ``` yaml - --8<-- "base-helm-configs/loki/loki-helm-s3-overrides-example.yaml" - ``` - -=== "MinIO" - - !!! abstract - - If you plan on using **Minio** as a backend for log storage see the `loki-helm-s3-overrides-example.yaml` file in the `helm-configs/loki` directory. - - ``` yaml - --8<-- "base-helm-configs/loki/loki-helm-minio-overrides-example.yaml" - ``` diff --git a/docs/infrastructure-mariadb-ops.md b/docs/infrastructure-mariadb-ops.md deleted file mode 100644 index 611a1eb4f..000000000 --- a/docs/infrastructure-mariadb-ops.md +++ /dev/null @@ -1,246 +0,0 @@ -# MariaDB Operations - -Tips and tricks for managing and operating the MariaDB cluster within a Genestack environment. - -## Connect to the database - -Sometimes an operator may need to connect to the database to troubleshoot things or otherwise make modifications to the databases in place. The following command can be used to connect to the database from a node within the cluster. - -``` shell -mysql -h $(kubectl -n openstack get service mariadb-cluster-primary -o jsonpath='{.spec.clusterIP}') \ - -p$(kubectl --namespace openstack get secret mariadb -o jsonpath='{.data.root-password}' | base64 -d) \ - -u root -``` - -!!! info - - The following command will leverage your kube configuration and dynamically source the needed information to connect to the MySQL cluster. You will need to ensure you have installed the mysql client tools on the system you're attempting to connect from. - -## Manually dumping and restoring databases - -When running `mysqldump` or `mariadbdump` the following commands can be useful for generating a quick backup. - -### Individual Database Backups - -``` shell -mysqldump --host=$(kubectl -n openstack get service mariadb-cluster -o jsonpath='{.spec.clusterIP}')\ - --user=root \ - --password=$(kubectl --namespace openstack get secret mariadb -o jsonpath='{.data.root-password}' | base64 -d) \ - --single-transaction \ - --routines \ - --triggers \ - --events \ - --column-statistics=0 \ - ${DATABASE_NAME} \ - --result-file=/tmp/${DATABASE_NAME}-$(date +%s).sql -``` - -!!! tip "Column Statistics" - - With some versions of `mysqldump` the `--column-statistics=0` flag maybe be required. If required the following error will be thrown: - - ``` sql - Unknown table 'COLUMN_STATISTICS' in information_schema (1109) - ``` - -### All Databases Backup - -Run the `/opt/genestack/bin/backup-mariadb.sh` script to dump all databases as individual files in `~/backup/mariadb/$(date +%s)`. - -??? example "Database Backup Script: `/opt/genestack/bin/backup-mariadb.sh`" - - ``` shell - --8<-- "bin/backup-mariadb.sh" - ``` - -### Individual Database Restores - -!!! tip "Ensure the destination database exists" - - The destination database must exist prior to restoring individual SQL - backups. If it does not already exist, it's important to create the - database with the correct charset and collate values. Failing to do so can - result in errors such as `Foreign Key Constraint is Incorrectly Formed` - during DB upgrades. - - ``` - CREATE DATABASE ${DATABASE_NAME} DEFAULT CHARSET=utf8mb3 COLLATE=utf8mb3_general_ci; - ``` - -!!! example "Restoring a database" - - ``` shell - mysql -h $(kubectl -n openstack get service mariadb-cluster-primary -o jsonpath='{.spec.clusterIP}') \ - -u root \ - -p$(kubectl --namespace openstack get secret mariadb -o jsonpath='{.data.root-password}' | base64 -d) \ - ${DATABASE_NAME} < /tmp/${DATABASE_FILE} - ``` - -## Restore using the MariaDB CRD - -To restore the most recent successful backup, create the following resource -to spawn a job that will mount the same storage as the backup and apply the -dump to your MariaDB database. - -Refer to the mariadb-operator [restore documentation](https://github.com/mariadb-operator/mariadb-operator/blob/main/docs/BACKUP.md#restore) -for more information. - -!!! tip "Operator Restore Tips" - - 1. If you have multiple backups available, the operator is able to infer - which backup to restore based on the `spec.targetRecoveryTime` field - discussed in the operator documentation [here](https://github.com/mariadb-operator/mariadb-operator/blob/main/docs/BACKUP.md#target-recovery-time). - 2. The referred database (db1 in the example below) must previously exist - for the Restore to succeed. - 3. The mariadb CLI invoked by the operator under the hood only supports - selecting a single database to restore via the `--one-database` option, - restoration of multiple specific databases is not supported. - -### Restore All Databases - -!!! danger "The following command may lead to data loss" - - ``` shell - cat < /tmp/mariadb-cluster-1.sql - ``` - -2. Copy the backup off of the pod, onto your machine - - ``` shell - kubectl -n openstack cp mariadb-cluster-1:/tmp/mariadb-cluster-1.sql /home/ubuntu/backups/mariadb-cluster-1.sql - ``` - -3. Copy the backup to the broken slave, mariadb-cluster-0 - - ``` shell - kubectl -n openstack cp /home/ubuntu/backups/mariadb-cluster-1.sql mariadb-cluster-0:/tmp/mariadb-cluster-1.sql - ``` - -4. Restore the backup, depending on its contents it may take a while, be - patient. - - ``` shell - mariadb -u root -p$MARIADB_ROOT_PASSWORD < /tmp/mariadb-cluster-1.sql - ``` - -### Stop and Reset the Slave - -Execute on the broken slave pod, mariadb-cluster-0: - -``` shell -STOP SLAVE; RESET SLAVE ALL; STOP SLAVE 'mariadb-operator'; RESET SLAVE 'mariadb-operator' ALL; -``` - -### Find Master Log and Position - -Identify master log file and position from the backup file: - -``` shell -[SJC3] ubuntu@bastion:~/backups$ grep "CHANGE MASTER TO MASTER_LOG_FILE='mariadb-cluster-bin." mariadb-cluster-1.sql --- CHANGE MASTER TO MASTER_LOG_FILE='mariadb-cluster-bin.000206', MASTER_LOG_POS=405; -``` - -### Update and Restart Slave - -1. Change the values in the following command to include the master log file - and position from your previous grep result, making sure to also replace the - master password value with the one from your cluster along with the real - MASTER_HOST from your environment, then execute it on the broken slave - pod (in our example, that is mariadb-cluster-0). - - ``` shell - CHANGE MASTER TO MASTER_HOST='mariadb-cluster-1.mariadb-cluster-internal.openstack.svc.cluster.local', MASTER_USER='repl', MASTER_PASSWORD='', MASTER_LOG_FILE='mariadb-cluster-bin.000206', MASTER_LOG_POS=405; - ``` - - !!! tip "If `CHANGE MASTER` fails..." - - If the previous command to CHANGE MASTER fails, one may need to - `FLUSH PRIVILEGES;` first. - -2. Start the slave process again - - ``` shell - START SLAVE; - ``` - -3. Verify replication status is OK - - ``` shell - SHOW ALL REPLICAS STATUS\G - ``` - -4. Wait for replication to be caught up, then kill the slave pod. We are - doing this to ensure it comes back online as expected (the operator should - automatically execute CHANGE MASTER for mariadb-operator on the slave). - When the pod has started; logs should contain something like the following: - - ``` text - 2025-01-28 22:22:55 61 [Note] Master connection name: 'mariadb-operator' Master_info_file: 'master-mariadb@002doperator.info' Relay_info_file: 'relay-log-mariadb@002doperator.info' - 2025-01-28 22:22:55 61 [Note] 'CHANGE MASTER TO executed'. Previous state master_host='', master_port='3306', master_log_file='', master_log_pos='4'. New state master_host='mariadb-cluster-1.mariadb-cluster-internal.openstack.svc.cluster.local', master_port='3306', master_log_file='', master_log_pos='4'. - 2025-01-28 22:22:55 61 [Note] Previous Using_Gtid=Slave_Pos. New Using_Gtid=Current_Pos - 2025-01-28 22:22:55 63 [Note] Master 'mariadb-operator': Slave I/O thread: Start semi-sync replication to master 'repl@mariadb-cluster-1.mariadb-cluster-internal.openstack.svc.cluster.local:3306' in log '' at position 4 - 2025-01-28 22:22:55 64 [Note] Master 'mariadb-operator': Slave SQL thread initialized, starting replication in log 'FIRST' at position 4, relay log './mariadb-cluster-relay-bin-mariadb@002doperator.000001' position: 4; GTID position '0-11-638858622' - 2025-01-28 22:22:55 63 [Note] Master 'mariadb-operator': Slave I/O thread: connected to master 'repl@mariadb-cluster-1.mariadb-cluster-internal.openstack.svc.cluster.local:3306',replication starts at GTID position '0-11-638858622' - ``` diff --git a/docs/infrastructure-mariadb.md b/docs/infrastructure-mariadb.md deleted file mode 100644 index aeadd3f86..000000000 --- a/docs/infrastructure-mariadb.md +++ /dev/null @@ -1,68 +0,0 @@ -# Deploy the MariaDB Operator and Mariadb Cluster - -## Create secret - -!!! note "Information about the secretes used" - - Manual secret generation is only required if you haven't run the `create-secrets.sh` script located in `/opt/genestack/bin`. - - ??? example "Example secret generation" - - ``` shell - kubectl --namespace openstack \ - create secret generic mariadb \ - --type Opaque \ - --from-literal=root-password="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-32};echo;)" \ - --from-literal=password="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-32};echo;)" - ``` - -## Deploy the mariadb operator - -``` -cluster_name=`kubectl config view --minify -o jsonpath='{.clusters[0].name}'` -echo $cluster_name -``` - -If `cluster_name` was anything other than `cluster.local` you should pass that as a parameter to the installer - -!!! example "Run the mariadb-operator deployment Script `bin/install-mariadb-operator.sh` You can include cluster_name paramater. No paramaters deploys with `cluster.local` cluster name." - - ``` shell - --8<-- "bin/install-mariadb-operator.sh" - ``` - -!!! info - - The operator may take a minute to get ready, before deploying the Galera cluster, wait until the webhook is online. - -``` shell -kubectl --namespace mariadb-system get pods -w -``` - -## Deploy the MariaDB Cluster - -!!! note - - MariaDB has a base configuration which is HA and production ready. If you're deploying on a small cluster the `aio` configuration may better suit the needs of the environment. - -=== "Replication _(Recommended)_" - - Replication in MariaDB involves synchronizing data between a primary database and one or more replicas, enabling continuous data availability even in the event of hardware failures or outages. By using MariaDB replication, OpenStack deployments can achieve improved fault tolerance and load balancing, ensuring that critical cloud services remain operational and performant at all times. - - ``` shell - kubectl --namespace openstack apply -k /etc/genestack/kustomize/mariadb-cluster/overlay - ``` - -=== "AIO" - - In some OpenStack deployments, a single MariaDB server is used to manage the database needs of the cloud environment. While this setup is simpler and easier to manage than clustered solutions, it is typically suited for smaller environments or use cases where high availability and fault tolerance are not critical. A single MariaDB server provides a centralized database service for storing and managing the operational data of OpenStack components, ensuring consistent performance and straightforward management. However, it is important to recognize that this configuration presents a single point of failure, making it less resilient to outages or hardware failures compared to more robust, multi-node setups. - - ``` shell - kubectl --namespace openstack apply -k /etc/genestack/kustomize/mariadb-cluster/aio - ``` - -## Verify readiness with the following command - -``` shell -kubectl --namespace openstack get mariadbs -w -``` diff --git a/docs/infrastructure-memcached.md b/docs/infrastructure-memcached.md deleted file mode 100644 index 4e839bb7a..000000000 --- a/docs/infrastructure-memcached.md +++ /dev/null @@ -1,40 +0,0 @@ -# Deploy a Memcached - -## Deploy the Memcached Cluster - -!!! example "Run the memcached deployment Script `bin/install-memcached.sh` You can include paramaters to deploy aio or base-monitoring. No paramaters deploys base" - - ``` shell - --8<-- "bin/install-memcached.sh" - ``` - -!!! note - - Memcached has a base configuration which is HA and production ready. If you're deploying on a small cluster the `aio` configuration may better suit the needs of the environment. - -### Alternative - Deploy the Memcached Cluster With Monitoring Enabled - -View the [memcached exporter](prometheus-memcached-exporter.md) instructions to install a HA ready memcached cluster with monitoring and metric collection enabled. - -## Verify readiness with the following command - -``` shell -kubectl --namespace openstack get horizontalpodautoscaler.autoscaling memcached -w -``` - -### Create shared os-memcached secret - -``` shell -kubectl --namespace openstack \ - create secret generic os-memcached \ - --type Opaque \ - --from-literal=memcache_secret_key="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-32};echo;)" -``` - -!!! Note - - This is a shared secret that is distributed to all services that require it. Rotating this value means updating all services. - -!!! Genestack - - For more information on how to enable memcached monitoring with prometheus, see the [memcached exporter](prometheus-monitoring-overview.md) documentation. diff --git a/docs/infrastructure-metallb.md b/docs/infrastructure-metallb.md deleted file mode 100644 index 508cddfab..000000000 --- a/docs/infrastructure-metallb.md +++ /dev/null @@ -1,50 +0,0 @@ -# Setup the MetalLB Loadbalancer - -The MetalLb loadbalancer can be setup by editing the following file `metallb-openstack-service-lb.yml`, You will need to add -your "external" VIP(s) to the loadbalancer so that they can be used within services. These IP addresses are unique and will -need to be customized to meet the needs of your environment. - -## Create the MetalLB namespace - -``` shell -kubectl apply -f /etc/genestack/manifests/metallb/metallb-namespace.yaml -``` - -## Install MetalLB - -!!! example "Run the MetalLB deployment Script `/opt/genestack/bin/install-metallb.sh` You can include paramaters to deploy aio or base-monitoring. No paramaters deploys base" - - ``` shell - --8<-- "bin/install-metallb.sh" - ``` - -## Example LB manifest - -??? abstract "Example for `metallb-openstack-service-lb.yml` file." - - ``` yaml - --8<-- "manifests/metallb/metallb-openstack-service-lb.yml" - ``` - -!!! tip - - It is recommended that you modify the file locally so that your changes are not impacted by the git tree. - - ``` shell - mkdir -p /etc/genestack/manifests/metallb/ - cp /etc/genestack/manifests/metallb/metallb-openstack-service-lb.yml /etc/genestack/manifests/metallb/metallb-openstack-service-lb.yml - ``` - - Edit the `metallb-openstack-service-lb.yml` file following the comment instructions with the details of your cluster. - -Verify the deployment of MetalLB by checking the pods in the `metallb-system` namespace. - -``` shell -kubectl --namespace metallb-system get deployment.apps/metallb-controller -``` - -Once MetalLB is operatoinal, apply the metallb service manifest. - -``` shell -kubectl apply -f /etc/genestack/manifests/metallb/metallb-openstack-service-lb.yml -``` diff --git a/docs/infrastructure-namespace.md b/docs/infrastructure-namespace.md deleted file mode 100644 index aa3046cbd..000000000 --- a/docs/infrastructure-namespace.md +++ /dev/null @@ -1,28 +0,0 @@ -# Create our basic OpenStack namespace - -The following command will generate our OpenStack namespace and ensure we have everything needed to proceed with the deployment. - -``` shell -kubectl apply -k /etc/genestack/kustomize/openstack/base -``` - -Then you can create all needed secrets by running the create-secrets.sh command located in /opt/genestack/bin - -!!! tip "Optional --region param" - - Note that the `create-secrets.sh` script by default creates a secret - with a default region of RegionOne. This can be overridden with the - `--region` parameter to specify your custom region name in Keystone. - > Usage: ./create-secrets.sh [--region default: RegionOne] - -``` shell -/opt/genestack/bin/create-secrets.sh -``` - -That will create a kubesecrets.yaml file located in /etc/genestack - -You can then apply it to kubernetes with the following command: - -``` shell -kubectl create -f /etc/genestack/kubesecrets.yaml -``` diff --git a/docs/infrastructure-nginx-gateway-api-ca-issuer.md b/docs/infrastructure-nginx-gateway-api-ca-issuer.md deleted file mode 100644 index f5e95d5fd..000000000 --- a/docs/infrastructure-nginx-gateway-api-ca-issuer.md +++ /dev/null @@ -1,110 +0,0 @@ -# NGINX Creating a CA issuer for Gateway API - -By default in Genestack the selfSigned issuer is used to issue certificates to Gateway API listeners. This is a fairly simple issuer to create and requires a very simple yaml manifest. Although the main purpose of the selfSigned issuer to create a local PKI i.e bootstrap a local self-signed CA which can then be used to issue certificates as required. This is helpful for test environments. The selfSigned issuer itself doesn't represent a certificate authority by rather indicates that the certificates will sign themselves. - -Below we'll discuss on how to create a self-signed CA certicate and create a CA clusterissuer to issue certificates to Gateway API listeners - -## Overview - -Firstly, we'll note that Gateway API in Genestack is currently utilizing selfSigned issuer: - -``` shell -cat internal-gateway-issuer.yaml -apiVersion: cert-manager.io/v1 -kind: ClusterIssuer -metadata: - name: flex-gateway-issuer - namespace: nginx-gateway -spec: - selfSigned: {} - -cat internal-gateway-api.yaml -apiVersion: gateway.networking.k8s.io/v1 -kind: Gateway -metadata: - name: flex-gateway - namespace: nginx-gateway - annotations: # This is the name of the ClusterIssuer created in the previous step - cert-manager.io/cluster-issuer: flex-gateway-issuer - acme.cert-manager.io/http01-edit-in-place: "true" -.... -``` - -with the selfSigned issuer being used to issue certificates; every certificate issued to Gateway API listeners is a CA certificate - -A more suitable approach would be to use selfSigned issuer to create a CA issuer and that's what we will discuss below - -## Create the CA certificate and a CA clusterissuer - -For this example workflow we'll edit `internal-gateway-issuer.yaml` file to create a CA certificate and then create a CA clusterissuer: - -The structure may look something like: - -!!! example -``` -cat internal-gateway-issuer.yaml -apiVersion: cert-manager.io/v1 -kind: ClusterIssuer -metadata: - name: flex-gateway-issuer - namespace: nginx-gateway -spec: - selfSigned: {} ---- -apiVersion: cert-manager.io/v1 -kind: Certificate -metadata: - name: public-endpoint-ca-cert - namespace: cert-manager -spec: - isCA: true - commonName: public-endpoint-ca - secretName: public-endpoint-ca-secret - privateKey: - algorithm: ECDSA - size: 256 - issuerRef: - name: flex-gateway-issuer - kind: ClusterIssuer - group: cert-manager.io ---- -apiVersion: cert-manager.io/v1 -kind: ClusterIssuer -metadata: - name: public-endpoint-issuer - namespace: nginx-gateway -spec: - ca: - secretName: public-endpoint-ca-secret -``` - -!!! note - The namespace for the certificate resoruce must be cert-manager - -#### Use the CA ClusterIssuer for Gateway API - -It is pretty straightforward to use the CA created above for Gateway API; just modify the annotation on the flex-gateway resource: - -``` shell -cat internal-gateway-api.yaml -apiVersion: gateway.networking.k8s.io/v1 -kind: Gateway -metadata: - name: flex-gateway - namespace: nginx-gateway - annotations: # This is the name of the ClusterIssuer created in the previous step - cert-manager.io/cluster-issuer: public-endpoint-issuer - acme.cert-manager.io/http01-edit-in-place: "true" -.... -``` - -The CA certificate created above can be obainted with: - -``` shell -kubectl get secret -n cert-manager public-endpoint-ca-secret -o jsonpath='{.data.tls\.crt}' | base64 -d -``` - -This is a simple example on how to create CA certificates with selfSigned issuers and use them for issuing certificates - -!!! note - It is not recommend to use self-singed certificates in production environments. diff --git a/docs/infrastructure-nginx-gateway-api-custom.md b/docs/infrastructure-nginx-gateway-api-custom.md deleted file mode 100644 index 04a8f2d7f..000000000 --- a/docs/infrastructure-nginx-gateway-api-custom.md +++ /dev/null @@ -1,59 +0,0 @@ -# Custom Listeners - -!!! note "This step is not needed if all listeners were applied when the Gateway API was deployed" - -??? abstract "Example listener patch file found in `/opt/genestack/etc/gateway-api/listeners`" - - ``` yaml - --8<-- "etc/gateway-api/listeners/-https.json" - ``` - -## Modify the Listener Patch - -This example changes the placeholder domain to ``. Review the [gateway documentation](https://gateway-api.sigs.k8s.io/api-types/gateway) -for more information on listener types. - -``` shell -mkdir -p /etc/genestack/gateway-api/listeners -sed 's/your.domain.tld//g' \ - /opt/genestack/etc/gateway-api/listeners/-https.json \ - > /etc/genestack/gateway-api/listeners/-https.json -``` - -## Apply the Listener Patch - -``` shell -kubectl patch -n nginx-gateway gateway flex-gateway \ - --type='json' \ - --patch-file /etc/genestack/gateway-api/listeners/-https.json -``` - -## Custom Routes - -!!! note "This step is not needed if all routes were applied when the Gateway API was deployed" - -A custom gateway route can be used when setting up the service. The custom route make it possible for a domain like `your.domain.tld` to be used. - -??? abstract "Example routes file found in `/opt/genestack/etc/gateway-api/routes`" - - ``` yaml - --8<-- "etc/gateway-api/routes/custom--gateway-route.yaml" - ``` - -## Modify the Route - -This example changes the placeholder domain to ``. Review the [gateway route documentation](https://gateway-api.sigs.k8s.io/api-types/httproute) -for more information on route types. - -``` shell -mkdir -p /etc/genestack/gateway-api/routes -sed 's/your.domain.tld//g' \ - /opt/genestack/etc/gateway-api/routes/custom--gateway-route.yaml \ - > /etc/genestack/gateway-api/routes/custom--gateway-route.yaml -``` - -#### Apply the Route - -``` shell -kubectl --namespace openstack apply -f /etc/genestack/gateway-api/routes/custom--gateway-route.yaml -``` diff --git a/docs/infrastructure-nginx-gateway-api.md b/docs/infrastructure-nginx-gateway-api.md deleted file mode 100644 index e107a316d..000000000 --- a/docs/infrastructure-nginx-gateway-api.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -hide: - - footer ---- - -# NGINX Gateway API - -The [NGINX Gateway Fabric](https://github.com/nginxinc/nginx-gateway-fabric) is an open-source project that provides an -implementation of the Gateway API using NGINX as the data plane. - -## Installation - -Run the helm command to install NGINX Gateway. - -??? example "Run the NGINX Gateway deployment Script `/opt/genestack/bin/install-nginx-gateway.sh`" - - ``` shell - --8<-- "bin/install-nginx-gateway.sh" - ``` - -The install script will deploy NGINX Gateway to the `nginx-gateway` namespace via Helm. - -## Setup - -??? example "Run the NGINX Gateway setup Script `/opt/genestack/bin/setup-nginx-gateway.sh`" - - ``` shell - --8<-- "bin/setup-nginx-gateway.sh" - ``` - -The setup script will ask the following questions: - -* Enter a valid email address for use with ACME, press enter to skip" -* Enter the domain name for the gateway" - -These values will be used to generate a certificate for the gateway and set the routes used within the flex-gateway, -typically for OpenStack. This script can also be fully automated by providing the required values as arguments. - -!!! example "Run the NGINX Gateway setup Script with arguments" - - ``` shell - ACME_EMAIL="username@your.domain.tld" GATEWAY_DOMAIN="your.domain.tld" /opt/genestack/bin/setup-nginx-gateway.sh - ``` - -## Validation - -At this point, flex-gateway has a listener pointed to the port 80 matching *.your.domain.tld hostname. The -HTTPRoute resource configures routes for this gateway. Here, we match all path and simply pass any request -from the matching hostname to kube-prometheus-stack-prometheus backend service. - -``` shell -kubectl -n openstack get httproute -``` - -``` shell -kubectl -n nginx-gateway get gateways.gateway.networking.k8s.io flex-gateway -``` diff --git a/docs/infrastructure-overview.md b/docs/infrastructure-overview.md deleted file mode 100644 index c2b0af96e..000000000 --- a/docs/infrastructure-overview.md +++ /dev/null @@ -1,22 +0,0 @@ -# Infrastructure Deployment Demo - -![Genestack Infra](assets/images/genstack-local-arch-k8s.svg) - -## Infrastructure Overview - -The full scale Genestack infrastructure is bound to change over time, however, the idea is to keep things simple and transparent. The above graphic highlights how we deploy our environments and what the overall makeup of our platforms are expected to look like. - -!!! tip - - The infrastructure deployment can almost all be run in parallel. The above demo does everything serially to keep things consistent and easy to understand but if you just need to get things done, feel free to do it all at once. - -## Deployment choices - -When you're building the cloud, many of the underlying infrastructure components have a deployment choice of `base` or `aio`. - -* `base` creates a production-ready environment that ensures an HA system is deployed across the hardware available in your cloud. -* `aio` creates a minimal cloud environment which is suitable for test, which may have low resources. - -## Demo - -[![asciicast](https://asciinema.org/a/629790.svg)](https://asciinema.org/a/629790) diff --git a/docs/infrastructure-ovn-db-backup.md b/docs/infrastructure-ovn-db-backup.md deleted file mode 100644 index 06cdbbc67..000000000 --- a/docs/infrastructure-ovn-db-backup.md +++ /dev/null @@ -1,121 +0,0 @@ -# Background - -By default, _Genestack_ creates a pod that runs _OVN_ snapshots daily in the `kube-system` namespace where you find other centralized _OVN_ things. These get stored on a persistent storage volume associated with the `ovndb-backup` _PersistentVolumeClaim_. Snapshots older than 30 days get deleted. - -You should primarily follow the [Kube-OVN documentation on backup and recovery](https://kubeovn.github.io/docs/stable/en/ops/recover-db/) and consider the information here supplementary. - -## Backup - -A default _Genestack_ installation creates a _k8s_ _CronJob_ in the `kube-system` namespace along side the other central OVN components that will store snapshots of the OVN NB and SB in the _PersistentVolume_ for the _PersistentVolumeClaim_ named `ovndb-backup`. Storing these on the persistent volume like this matches the conventions for _MariaDB_ in _Genestack_. - -## Restoration and recovery - -You may wish to implement shipping these off of the cluster to a permanent location, as you might have cluster problems that could interfere with your ability to get these off of the _PersistentVolume_ when you need these backups. - -### Recovering when a majority of OVN DB nodes work fine - -If you have a majority of _k8s_ nodes running `ovn-central` working fine, you can just follow the directions in the _Kube-OVN_ documentation for kicking a node out. Things mostly work normally when you have a majority because OVSDB HA uses a raft algorithm which only requires a majority of the nodes for full functionality, so you don't have to do anything too strange or extreme to recover. You essentially kick the bad node out and let it recover. - -### Recovering from a majority of OVN DB node failures or a total cluster failure - -**You probably shouldn't use this section if you don't have a majority OVN DB node failure. Just kick out the minority of bad nodes as indicated above instead**. Use this section to recover from a failure of the **majority** of nodes. - -As a first step, you will need to get database files to run the recovery. You can try to use files on your nodes as described below, or use one of the backup snapshots. - -#### Trying to use _OVN_ DB files in `/etc/origin/ovn` on the _k8s_ nodes - -You can use the information in this section to try to get the files to use for your recovery from your running _k8s_ nodes. - -The _Kube-OVN_ shows trying to use _OVN_ DB files from `/etc/origin/ovn` on the _k8s_ nodes. You can try this, or skip this section and use a backup snapshot as shown below if you have one. However, you can probably try to use the files on the nodes as described here first, and then switch to the latest snapshot backup from the `CronJob` later if trying to use the files on the _k8s_ nodes doesn't seem to work, since restoring from the snapshot backup fully rebuilds the database. - -The directions in the _Kube-OVN_ documentation use `docker run` to get a working `ovsdb-tool` to try to work with the OVN DB files on the nodes, but _k8s_ installations mostly use `CRI-O`, `containerd`, or other container runtimes, so you probably can't pull the image and run it with `docker` as shown. I will cover this and some alternatives below. - -##### Finding the first node - -The _Kube-OVN_ documentation directs you to pick the node running the `ovn-central` pod associated with the first IP of the `NODE_IPS` environment variable. You should find the `NODE_IPS` environment variable defined on an `ovn-central` pod or the `ovn-central` _Deployment_. Assuming you can run the `kubectl` commands, the following example gets the node IPs off of one of the the deployment: - -``` shell -kubectl get deployment -n kube-system ovn-central -o yaml | grep -A1 'name: NODE_IPS' - - - name: NODE_IPS - value: 10.130.140.246,10.130.140.250,10.130.140.252 -``` - -Then find the _k8s_ node with the first IP. You can see your _k8s_ nodes and their IPs with the command `kubectl get node -o wide`: - -``` shell -kubectl get node -o wide | grep 10.130.140.246 - -k8s-controller01 Ready control-plane 3d17h v1.28.6 10.130.140.246 Ubuntu 22.04.3 LTS 6.5.0-17-generic containerd://1.7.11 -root@k8s-controller01:~# -``` - -##### Trying to create a pod for `ovsdb-tool` - -As an alternative to `docker run` since your _k8s_ cluster probably doesn't use _Docker_ itself, you can **possibly** try to create a pod instead of running a container directly, but you should **try it before scaling your _OVN_ replicas down to 0**, as not having `ovn-central` available should interfere with pod creation. The broken `ovn-central` might still prevent _k8s_ from creating the pod even if you haven't scaled your replicas down, however. - -**Read below the pod manifest for edits you may need to make** - -``` yaml -apiVersion: v1 -kind: Pod -metadata: - name: ovn-central-kubectl - namespace: kube-system -spec: - serviceAccount: "ovn" - serviceAccountName: "ovn" - nodeName: - tolerations: - - key: node-role.kubernetes.io/control-plane - operator: "Exists" - effect: "NoSchedule" - volumes: - - name: host-config-ovn - hostPath: - path: /etc/origin/ovn - type: "" - - name: backup - persistentVolumeClaim: - claimName: ovndb-backup - containers: - - name: ovn-central-kubectl - command: - - "/usr/bin/sleep" - args: - - "infinity" - image: docker.io/kubeovn/kube-ovn:v1.12.30 - volumeMounts: - - mountPath: /etc/ovn - name: host-config-ovn - - mountPath: /backup - name: backup -``` - -You also have to make sure to get the pod on the _k8s_ node with the first IP of `NODE_IPS` from your `ovn-central` installation, as the _Kube-OVN_ documentation indicates, so see the section on "finding the first node" above to fill in `` in the example pod manifest above. - -You can save this to a YAML file, and `kubectl apply -f `. - -You may need to delete the `backup` stuff under `.spec.volumes` and `.spec.containers[].volumeMounts` if you don't have that volume (although a default _Genestack_ installation does the scheduled snapshots there) or trying to use it causes problems, but if it works, you can possibly `kubectl cp` a previous backup off it to restore. - -Additionally, you may need to delete the tolerations in the manifest if you untainted your controllers. - -To reiterate, if you reached this step, this pod creation may not work because of your `ovn-central` problems, but a default `Genestack` can't `docker run` the container directly as shown in the `Kube-OVN` documentation because it probably uses _containerd_ instead of _Docker_. I tried creating a pod like this with `ovn-central` scaled to 0 pods, and the pod stays in `ContainerCreating` status. - -If creating this pod worked, **scale your replicas to 0**, use `ovsdb-tool` to make the files you will use for restore (both north and south DB), then jump to _Full Recovery_ as described below here and in the _Kube-OVN_ documentation. - -##### `ovsdb-tool` from your Linux distribution's packaging system - -As an alternative to the `docker run`, which may not work on your cluster, and the pod creation, which may not work because of your broken OVN, if you still want to try to use the OVN DB files on your _k8s_ nodes instead of going to one of your snapshot backups, you can try to install your distribution's package with the `ovsdb-tool`, `openvswitch-common` on Ubuntu, although you risk (and will probably have) a slight version mismatch with the OVS version within your normal `ovn-central` pods. OVSDB has a stable format and this likely will not cause any problems, although you should probably restore a previously saved snapshot in preference to using an `ovsdb-tool` with a slightly mismatched version, but you may consider using the mismatch version if you don't have other options. - -##### Conclusion of using the OVN DB files on your _k8s_ nodes - -The entire section on using the OVN DB files from your nodes just gives you an alternative way to a planned snapshot backup to try to get something to restore the database from. From here forward, the directions converge with full recovery as described below and in the full _Kube-OVN_ documentation. - -#### Full recovery - -You start here when you have north database and south database files you want to use to run your recovery, whether you retrieved it from one of your _k8s_ nodes as described above, or got it from one of your snapshots. Technically, the south database should get rebuilt with only the north database, but if you have the two that go together, you can save the time it would take for a full rebuild by also restoring the south DB. It also avoids relying on the ability to rebuild the south DB in case something goes wrong. - -If you just have your _PersistentVolume_ with the snapshots, you can try to create a pod as shown in the example manifest above with the _PersistentVolume_ mounted and `kubectl cp` the files off. - -However you got the files, full recovery from here forward works exactly as described in the _Kube-OVN_ documentation, which at a high level, starts with you scaling your replicas down to 0. diff --git a/docs/infrastructure-ovn-setup.md b/docs/infrastructure-ovn-setup.md deleted file mode 100644 index 7229669e7..000000000 --- a/docs/infrastructure-ovn-setup.md +++ /dev/null @@ -1,162 +0,0 @@ -# Deploy Open vSwitch OVN - -!!! note - - We're not deploying Openvswitch, however, we are using it. The implementation on Genestack is assumed to be done with Kubespray which deploys OVN as its networking solution. Because those components are handled by our infrastructure there's nothing for us to manage / deploy in this environment. OpenStack will leverage OVN within Kubernetes following the scaling/maintenance/management practices of kube-ovn. - -## Configure OVN for OpenStack - -Post deployment we need to setup neutron to work with our integrated OVN environment. To make that work we have to annotate or nodes. Within the following commands we'll use a lookup to label all of our nodes the same way, however, the power of this system is the ability to customize how our machines are labeled and therefore what type of hardware layout our machines will have. This gives us the ability to use different hardware in different machines, in different availability zones. While this example is simple your cloud deployment doesn't have to be. - -## OVN Annotations - -|
key
| type |
value
| notes | -|:-----|--|:----------------:|:------| -| **ovn.openstack.org/int_bridge** | str | `br-int` | The name of the integration bridge that will be used. | -| **ovn.openstack.org/bridges** | str | `br-ex` | Comma separated list of bridges that will be created and plugged into OVS for a given node. | -| **ovn.openstack.org/ports** | str | `br-ex:bond1` | Comma separated list of bridge mappings. Maps values from the **bridges** annotation to physical devices on a given node. | -| **ovn.openstack.org/mappings** | str | `physnet1:br-ex` | Comma separated list of neutron mappings. Maps a value that will be used in neutron to a value found in the **ports** annotation. Every provider network name listed in this annotation will have a unique mac address generated per-host. | -| **ovn.openstack.org/availability_zones** | str | `az1` | Colon separated list of Availability Zones a given node will serve. | -| **ovn.openstack.org/gateway** | str| `enabled` | If set to `enabled`, the node will be marked as a gateway. | - -### Gather the network enabled nodes - -Set the annotations needed within the environment to meet the needs of your workloads on the hardware you have. - -!!! tip "Post Deployment" - - Review the OVN Operations Guide for more information on how to manage your OVN environment post deployment. The guide can be found [here](ovn-kube-ovn-openstack.md). The guide will help you understand how to manage your OVN environment and how to troubleshoot issues that may arise. - -### Set `ovn.openstack.org/int_bridge` - -Set the name of the OVS integration bridge we'll use. In general, this should be **br-int**, and while this setting is implicitly configured we're explicitly defining what the bridge will be on these nodes. - -``` shell -kubectl annotate \ - nodes \ - -l openstack-compute-node=enabled -l openstack-network-node=enabled \ - ovn.openstack.org/int_bridge='br-int' -``` - -### Set `ovn.openstack.org/bridges` - -Set the name of the OVS bridges we'll use. These are the bridges you will use on your hosts within OVS. The option is a string and comma separated. You can define as many OVS type bridges you need or want for your environment. - -!!! note - - The functional example here annotates all nodes; however, not all nodes have to have the same setup. - -``` shell -kubectl annotate \ - nodes \ - -l openstack-compute-node=enabled -l openstack-network-node=enabled \ - ovn.openstack.org/bridges='br-ex' -``` - -### Set `ovn.openstack.org/ports` - -Set the port mapping for OVS interfaces to a local physical interface on a given machine. This option uses a colon between the OVS bridge and the and the physical interface, `OVS_BRIDGE:PHYSICAL_INTERFACE_NAME`. Multiple bridge mappings can be defined by separating values with a comma. - -``` shell -kubectl annotate \ - nodes \ - -l openstack-compute-node=enabled -l openstack-network-node=enabled \ - ovn.openstack.org/ports='br-ex:bond1' -``` - -### Set `ovn.openstack.org/mappings` - -Set the Neutron bridge mapping. This maps the Neutron interfaces to the ovs bridge names. These are colon delimitated between `NEUTRON_INTERFACE:OVS_BRIDGE`. Multiple bridge mappings can be defined here and are separated by commas. - -!!! note - - Neutron interfaces are string value and can be anything you want. The `NEUTRON_INTERFACE` value defined will be used when you create provider type networks after the cloud is online. - -``` shell -kubectl annotate \ - nodes \ - -l openstack-compute-node=enabled -l openstack-network-node=enabled \ - ovn.openstack.org/mappings='physnet1:br-ex' -``` - -### Set `ovn.openstack.org/availability_zones` - -Set the OVN availability zones which inturn creates neutron availability zones. Multiple network availability zones can be defined and are colon separated which allows us to define all of the availability zones a node will be able to provide for, `nova:az1:az2:az3`. - -``` shell -kubectl annotate \ - nodes \ - -l openstack-compute-node=enabled -l openstack-network-node=enabled \ - ovn.openstack.org/availability_zones='az1' -``` - -!!! note - - Any availability zone defined here should also be defined within your **neutron.conf**. The "az1" availability zone is assumed by Genestack; however, because we're running in a mixed OVN environment, we define where we're allowed to execute OpenStack workloads ensuring we're not running workloads in an environment that doesn't have the network resources to support it. - - Additionally, an availability zone can be used on different nodes and used to define where gateways reside. If you have multiple availability zones, you will need to define where the gateways will reside within your environment. - -### Set `ovn.openstack.org/gateway` - -Define where the gateways nodes will reside. There are many ways to run this, some like every compute node to be a gateway, some like dedicated gateway hardware. Either way you will need at least one gateway node within your environment. - -``` shell -kubectl annotate \ - nodes \ - -l openstack-network-node=enabled \ - ovn.openstack.org/gateway='enabled' -``` - -## Run the OVN integration - -With all of the annotations defined, we can now apply the network policy with the following command. - -``` shell -kubectl apply -k /etc/genestack/kustomize/ovn/base -``` - -After running the setup, nodes will have the label `ovn.openstack.org/configured` with a date stamp when it was configured. -If there's ever a need to reconfigure a node, simply remove the label and the DaemonSet will take care of it automatically. - -!!! tip "Setup your OVN backup" - - To upload backups to Swift with tempauth, edit - /etc/genestack/kustomize/ovn-backup/base/ovn-backup.config to set - `SWIFT_TEMPAUTH_UPLOAD' "true"`, edit the other related options - appropriately (i.e., set the CONTAINER) and fill the ST_AUTH, ST_USER, and - ST_KEY as appropriate for the Swift CLI client in the `swift-tempauth.env` - file and then run: - - ``` shell - kubectl apply -k /etc/genestack/kustomize/ovn-backup/base \ - --prune -l app=ovn-backup \ - --prune-allowlist=core/v1/Secret \ - --prune-allowlist=core/v1/ConfigMap - ``` - - If you need to change variables in the future, you can edit the relevant - files and use `kubectl` with these prune options to avoid accumulating - old ConfigMaps and Secrets from successive `kubectl apply` operations, but - you can omit the pruning options if desired. - -### Centralize `kube-ovn-controller` pods - -By default, _Kubespray_ deploys _Kube-OVN_ allowing [`kube-ovn-controller` pods](https://kubeovn.github.io/docs/stable/en/reference/architecture/#kube-ovn-controller), which play a central role, to distribute across various kinds of cluster nodes. In _Genestack_, this would include compute nodes and other kinds of nodes. By contrast, `ovn-central` pods, which also play a crucial central role, run only on nodes labelled `"kube-ovn/role": "master"`. A _Genestack_ installation will typically have control functions centralized on a small set of nodes, which you may have different resource allocations and different redundancy and uptime requirements for relative to other types of nodes, so you can set the `kube-ovn-controller` pods to run in the same location as [`ovn-central`](https://kubeovn.github.io/docs/stable/en/reference/architecture/#ovn-central) on _Kube-OVN_ master nodes (which most likely simply match your k8s cluster control nodes unless you've customized it): - -``` shell -kubectl -n kube-system patch deployment kube-ovn-controller -p '{ - "spec": { - "template": { - "spec": { - "nodeSelector": { - "kube-ovn/role": "master", - "kubernetes.io/os": "linux" - } - } - } - } -} -' -``` - -This helps keep critical control functions on a known set of nodes. diff --git a/docs/infrastructure-postgresql.md b/docs/infrastructure-postgresql.md deleted file mode 100644 index 0eb72ab48..000000000 --- a/docs/infrastructure-postgresql.md +++ /dev/null @@ -1,65 +0,0 @@ -# Deploy PostgreSQL - -PostgreSQL is used by [Gnocchi](openstack-gnocchi.md) to index the data -collected and sent by [Ceilometer](openstack-ceilometer.md). - -## Install the Postgres Operator - -We are using the [Zalando postgres-operator](https://github. -com/zalando/postgres-operator/) which offers easy to run and -highly-available PostgreSQL clusters on Kubernetes. - -!!! example "Run the postgres-operator deployment Script `bin/install-postgres-operator.sh`" - - ``` shell - --8<-- "bin/install-postgres-operator.sh" - ``` - -## Create the PostgreSQL Cluster - -=== "With kubectl _(Recommended)_" - - !!! info "Customize as needed" - - Be sure to modify the cluster parameters to suit your needs. The below - values should work fine for a small lab or staging envionrment, however - more disk space and other changes may be required in production. - - ```shell - kubectl apply -f - <key | type |
value
| notes | -|:-----|--|:----------------:|:------| -| **kube-ovn/role** | str | `master` | Defines where the Kube-OVN Masters will reside | -| **ovn.kubernetes.io/ovs_dp_type** | str | `kernel` | (Optional) Defines OVS DPDK mode | - -!!! example "Label all controllers as Kube-OVN control plane nodes" - - ``` shell - kubectl label node -l beta.kubernetes.io/os=linux kubernetes.io/os=linux - kubectl label node -l node-role.kubernetes.io/control-plane kube-ovn/role=master - kubectl label node -l ovn.kubernetes.io/ovs_dp_type!=userspace ovn.kubernetes.io/ovs_dp_type=kernel - ``` - -### Fact Gathering - -Before getting started you will need to know a few pieces of information: the network interface used -for the cluster, and the CIDR ranges for the `ovn-default` and `join` networks. - -!!! example "Output" - - You can get the network interface used for the cluster by running the following command. - - ``` shell - kubectl get subnets.kubeovn.io - ``` - - The output will return most everything needed. - - ``` shell - NAME PROVIDER VPC PROTOCOL CIDR PRIVATE NAT DEFAULT GATEWAYTYPE V4USED V4AVAILABLE V6USED V6AVAILABLE EXCLUDEIPS U2OINTERCONNECTIONIP - join ovn ovn-cluster IPv4 100.64.0.0/16 false false false distributed 3 65530 0 0 ["100.64.0.1"] - ovn-default ovn ovn-cluster IPv4 10.236.0.0/14 false true true distributed 111 262030 0 0 ["10.236.0.1"] - ``` - -In this example the following values will be used in the configuration. - -* The gateway address for the join network is `100.64.0.1` and the CIDR range is `100.64.0.0/16` -* The gateway address for the ovn-default network is `10.236.0.1` and the CIDR range is `10.236.0.0/14` - -!!! tip - - If the installation was originally done with Kubespray the required values can typically be found - in the `/etc/genestack/inventory/group_vars/k8s_cluster/k8s-cluster.yml` file or in the inventory. - - * `kube_service_addresses` is used for the Service CIDR - * `kube_pods_subnet` is used for the ovn-default CIDR - * `kube_ovn_node_switch_cidr` is used for the join CIDR - * `kube_ovn_default_interface_name` is used for the VLAN interface - * `kube_ovn_iface` is used for the interface - -With the required information, update the `/etc/genestack/helm-configs/kube-ovn/kube-ovn-helm-overrides.yaml` file -with following content. - -``` yaml -ipv4: - POD_CIDR: "10.236.0.0/14" # ovn-default CIDR - POD_GATEWAY: "10.236.0.1" # ovn-default CIDR - SVC_CIDR: "10.233.0.0/18" # Service CIDR - JOIN_CIDR: "100.64.0.0/16" # join - -networking: - IFACE: "br-overlay" # Interface used for the cluster - vlan: - VLAN_INTERFACE_NAME: "br-overlay" # VLAN Interface used for the cluster -``` - -## Running the Upgrade - -Upgrade the Kube-OVN deployment to a Helm chart is simple and quick. Get it done by running the -`kube-ovn-convert.sh` script. - -??? example "Run the Kube-OVN deployment Script `/opt/genestack/scripts/kube-ovn-convert.sh`." - - ``` shell - --8<-- "scripts/kube-ovn-convert.sh" - ``` - -After converting the Kube-OVN deployment to a Helm chart, you can manage the deployment using Helm commands. -To ensure there's no future conflict with the Kube-OVN deployment, you can reset the network plugin option -deployment options from the `/etc/genestack/inventory/group_vars/k8s_cluster/k8s-cluster.yml` file. - -Set the value `kube_network_plugin` to **`none`**. - -``` diff ---- a/inventory/group_vars/k8s_cluster/k8s-cluster.yml -+++ b/inventory/group_vars/k8s_cluster/k8s-cluster.yml -@@ -67,7 +67,7 @@ credentials_dir: "{{ inventory_dir }}/credentials" - - # Choose network plugin (cilium, calico, kube-ovn, weave, flannel or none. Use cni for generic cni plugin) - # Can also be set to 'cloud', which lets the cloud provider setup appropriate routing --kube_network_plugin: kube-ovn -+kube_network_plugin: none -``` - -This will ensure that any future Kubspray operations will not deploy with a network plugin and not -create a conflict in the Kube-OVN deployment. diff --git a/docs/k8s-cni-kube-ovn.md b/docs/k8s-cni-kube-ovn.md deleted file mode 100644 index 4aa27a103..000000000 --- a/docs/k8s-cni-kube-ovn.md +++ /dev/null @@ -1,94 +0,0 @@ -# Install Kube OVN - -The Kube-OVN project is a Kubernetes Network Plugin that uses OVN as the network provider. It -is a CNI plugin that provides a network solution for Kubernetes. It is a lightweight, scalable, -and easy-to-use network solution for Kubernetes. - -## Prerequisites - -The override values file for Kube-OVN can be found in `/etc/genestack/helm-configs/kube-ovn/kube-ovn-helm-overrides.yaml` -and should be setup-up before running the deployment. In a common production ready setup, the only values that will -likely need to be defined is the network interface that will Kube-OVN will bind to. - -!!! example "Example Kube-OVN Helm Overrides" - - In the example below, the `IFACE` and `VLAN_INTERFACE_NAME` are the only values that need to be defined and - are set to `br-overlay`. If you intend to enable hardware offloading, you will need to set the `IFACE` to the - a physical interface that supports hardware offloading. - - ``` yaml - networking: - IFACE: "br-overlay" - vlan: - VLAN_INTERFACE_NAME: "br-overlay" - ``` - -For a full review of all the available options, see the Kube-OVN base helm overrides file. - -??? example "Example Kube-OVN Helm Overrides" - - ``` yaml - --8<-- "base-helm-configs/kube-ovn/kube-ovn-helm-overrides.yaml" - ``` - -### Label Kube-OVN nodes - -|
key
| type |
value
| notes | -|:-----|--|:----------------:|:------| -| **kube-ovn/role** | str | `master` | Defines where the Kube-OVN Masters will reside | -| **ovn.kubernetes.io/ovs_dp_type** | str | `kernel` | (Optional) Defines OVS DPDK mode | - -!!! example "Label all controllers as Kube-OVN control plane nodes" - - ``` shell - kubectl label node -l beta.kubernetes.io/os=linux kubernetes.io/os=linux - kubectl label node -l node-role.kubernetes.io/control-plane kube-ovn/role=master - kubectl label node -l ovn.kubernetes.io/ovs_dp_type!=userspace ovn.kubernetes.io/ovs_dp_type=kernel - ``` - -## Deployment - -To run the Kube-OVN deployment, run the following command commands or script. - -!!! example "Run the Kube-OVN deployment Script `/opt/genestack/bin/install-kube-ovn.sh`." - - ``` shell - --8<-- "bin/install-kube-ovn.sh" - ``` - -### Deployment Verification - -Once the script has completed, you can verify that the Kube-OVN pods are running by running the following command - -``` shell -kubectl get subnets.kubeovn.io -``` - -!!! example "Output" - - ``` shell - NAME PROVIDER VPC PROTOCOL CIDR PRIVATE NAT DEFAULT GATEWAYTYPE V4USED V4AVAILABLE V6USED V6AVAILABLE EXCLUDEIPS U2OINTERCONNECTIONIP - join ovn ovn-cluster IPv4 100.64.0.0/16 false false false distributed 3 65530 0 0 ["100.64.0.1"] - ovn-default ovn ovn-cluster IPv4 10.236.0.0/14 false true true distributed 111 262030 0 0 ["10.236.0.1"] - ``` - -!!! tip - - After the deployment, and before going into production, it is highly recommended to review the - [Kube-OVN Backup documentation](infrastructure-ovn-db-backup.md), from the operators guide for setting up you backups. - -Upon successful deployment the Kubernetes Nodes should transition into a `Ready` state. Validate the nodes are ready by -running the following command. - -``` shell -kubectl get nodes -``` - -!!! example "Output" - - ``` shell - NAME STATUS ROLES AGE VERSION - compute-0.cloud.cloudnull.dev.local Ready control-plane,worker 24m v1.30.4 - compute-1.cloud.cloudnull.dev.local Ready control-plane,worker 24m v1.30.4 - compute-2.cloud.cloudnull.dev.local Ready control-plane,worker 24m v1.30.4 - ``` diff --git a/docs/k8s-config.md b/docs/k8s-config.md deleted file mode 100644 index 8d2c80a55..000000000 --- a/docs/k8s-config.md +++ /dev/null @@ -1,28 +0,0 @@ -# Retrieve the kube config - -Create the directory where the kube config will be stored. - -``` shell -mkdir -p ~/.kube -``` - -Retrieve the kube config from our first controller. - -!!! note - - In the following example, X.X.X.X is expected to be the first controller and the user is assumed to be Ubuntu. - -``` shell -rsync -e "ssh -F ${HOME}/.ssh/openstack-keypair.config" \ - --rsync-path="sudo rsync" \ - -avz ubuntu@X.X.X.X:/root/.kube/config "${HOME}/.kube/config" -``` - -Edit the kube config to point at the first controller. - -``` shell -sed -i 's@server.*@server: https://X.X.X.X:6443@g' "${HOME}/.kube/config" -``` - -Once you have the kube config and it is pointed at your kubernetes API nodes, -you can use `kubectl` to interact with the Kubernetes cluster. diff --git a/docs/k8s-dashboard.md b/docs/k8s-dashboard.md deleted file mode 100644 index ba10ad982..000000000 --- a/docs/k8s-dashboard.md +++ /dev/null @@ -1,13 +0,0 @@ -# Deploy K8S Dashboard RBAC - -While the dashboard is installed you will have no ability to access it until we setup some basic RBAC. - -``` shell -kubectl apply -k /etc/genestack/kustomize/k8s-dashboard/base -``` - -You can now retrieve a permanent token. - -``` shell -kubectl get secret admin-user -n kube-system -o jsonpath={".data.token"} | base64 -d -``` diff --git a/docs/k8s-kubespray-upgrade.md b/docs/k8s-kubespray-upgrade.md deleted file mode 100644 index f352c0d46..000000000 --- a/docs/k8s-kubespray-upgrade.md +++ /dev/null @@ -1,89 +0,0 @@ -# Kubespray Upgrades - -## Overview - -Upgrades within the Kubernetes ecosystem are plentiful and happen often. While upgrades are not something that we want to process all the time, it is something that we want to be able to confidently process. With our Kubernetes providers, upgrades are handled in a way that maximizes uptime and should mostly not force resources into data-plane downtime. - -### Upgrade Notifications - -Running upgrades with Kubespary is handled by the `upgrade-cluster.yml` playbook. While this playbook works, it does have a couple of caveats. - -1. An upgrade can only handle one major jump. If you're running 1.26 and want to go to 1.28, you'll need to upgrade to 1.27 first and repeat the process until you land on the desired version. - -2. The upgrade playbook will drain and move workloads around to ensure the environment maximizes uptime. While maximizing uptime makes for incredible user experiences, it does mean the process of executing an upgrade can be very long (2+ hours is normal); plan accordingly. - -## Preparing the upgrade - -When running Kubespray using the Genestack submodule, review the [Genestack Update Process](https://docs.rackspacecloud.com/genestack-upgrade) before continuing with the kubespray upgrade and deployment. - -Genestack stores inventory in the `/etc/genestack/inventory` directory. Before running the upgrade, you will need to set the **kube_version** variable to your new target version. This variable is generally found within the `/etc/genestack/inventory/group_vars/k8s_cluster/k8s-cluster.yml` file. - -!!! note - - Review all of the group variables within an environment before running a major upgrade. Things change, and you need to be aware of your environment details before running the upgrade. - -Once the group variables are set, you can proceed with the upgrade execution. - -## Running the upgrade - -Running an upgrade with Kubespray is fairly simple and executed via `ansible-playbook`. - -Before running the playbook be sure to source your environment variables. - -``` shell -source /opt/genestack/scripts/genestack.rc -``` - -Change to the `kubespary` directory. - -``` shell -cd /opt/genestack/submodules/kubespray -``` - -!!! note - - When running an upgrade be sure to set the `kube_version` variable to the desired version number. - -Now run the upgrade. - -``` shell -ansible-playbook upgrade-cluster.yml -e kube_version=${VERSION_NUMBER} -``` - -!!! note - - While the basic command could work, be sure to include any and all flags needed for your environment before running the upgrade. - -### Running an unsafe upgrade - -When running an upgrade, it is possible to force the upgrade by running the cluster playbook with the `upgrade_cluster_setup` flag set to **true**. This option is a lot faster, though does introduce the possibility of service disruption during the upgrade operation. - -``` shell -ansible-playbook cluster.yml -e upgrade_cluster_setup=true -e kube_version=${VERSION_NUMBER} -``` - -### Upgrade Hangs - -There are times when an upgrade will hang, in these cases you may need to use a second terminal to check the status of the upgrade. - -!!! example "Hung Namespace Finalizers" - - If you find that the upgrade is hanging on a namespace, you may need to remove the finalizers from the namespace to allow the upgrade to continue. - - ``` shell - kubectl get namespace "${NAMESPACE}" -o json \ - | tr -d "\n" | sed "s/\"finalizers\": \[[^]]\+\]/\"finalizers\": []/" \ - | kubectl replace --raw "/api/v1/namespaces/${NAMESPACE}/finalize" -f - - ``` - -### Post upgrade operations - -After running the upgrade it's sometimes a good thing to do some spot checks of your nodes and ensure everything is online, operating normally. - -#### Dealing with failure - -If an upgrade failed on the first attempt but succeeded on a subsequent run, you may have a node in a `Ready`, but `SchedulingDisabled` state. If you find yourself in this scenario you may need to `uncordon` the node to get things back to operating normally. - -``` shell -kubectl uncordon $NODE -``` diff --git a/docs/k8s-kubespray.md b/docs/k8s-kubespray.md deleted file mode 100644 index 0b5d88023..000000000 --- a/docs/k8s-kubespray.md +++ /dev/null @@ -1,124 +0,0 @@ -# Deployment Kubespray - -Currently only the k8s provider kubespray is supported and included as submodule into the code base. - -### Before you Deploy - -Kubespray will be using OVN for all of the network functions, as such, you will need to ensure your hosts are ready to receive the deployment at a low level. -While the Kubespray tooling will do a lot of prep and setup work to ensure success, -you will need to prepare your networking infrastructure and basic storage layout before running the playbooks. - -#### Minimum system requirements - -* 2 Network Interfaces - -!!! note - - While we would expect the environment to be running with multiple bonds in a production cloud, two network interfaces is all that's required. This can be achieved with vlan - tagged devices, physical ethernet devices, macvlan, or anything else. Have a look at the netplan example file found - [here](https://github.com/rackerlabs/genestack/blob/main/etc/netplan/default-DHCP.yaml) for an example of how you could setup the network. - -* Ensure we're running kernel 5.17+ - -!!! tip - - While the default kernel on most modern operating systems will work, we recommend running with Kernel 6.2+. - -* Kernel modules - -!!! warning - - The Kubespray tool chain will attempt to deploy a lot of things, one thing is a set of `sysctl` options which will include bridge tunings. Given the tooling will assume bridging is functional, you will need to ensure the `br_netfilter` module is loaded or you're using a kernel that includes that functionality as a built-in. - -* Executable `/tmp` - -!!! warning - - The `/tmp` directory is used as a download and staging location within the environment. You will need to make sure that the `/tmp` is executable. By default, some kick-systems set the mount option **noexec**, if that is defined you should remove it before running the deployment. - -### Create your Inventory - -A default inventory file for kubespray is provided at `/etc/genestack/inventory` and must be modified. - -Checkout the [inventory.yaml.example](https://github.com/rackerlabs/genestack/blob/main/ansible/inventory/genestack/inventory.yaml.example) file for an example of a target environment. - -!!! note - - Before you deploy the kubernetes cluster you should define the `kube_override_hostname` option in your inventory. This variable will set the node name which we will want to be an FQDN. When you define the option, it should have the same suffix defined in our `cluster_name` variable. - -However, any Kubespray compatible inventory will work with this deployment tooling. The official [Kubespray documentation](https://kubespray.io) can be used to better understand the inventory options and requirements. - -### Ensure systems have a proper FQDN Hostname - -Before running the Kubernetes deployment, make sure that all hosts have a properly configured FQDN. - -``` shell -source /opt/genestack/scripts/genestack.rc -ansible -m shell -a 'hostnamectl set-hostname {{ inventory_hostname }}' --become all -ansible -m shell -a "grep 127.0.0.1 /etc/hosts | grep -q {{ inventory_hostname }} || sed -i 's/^127.0.0.1.*/127.0.0.1 {{ inventory_hostname }} localhost.localdomain localhost/' /etc/hosts" --become all -``` - -!!! note - - In the above command I'm assuming the use of `cluster.local` this is the default **cluster_name** as defined in the group_vars k8s_cluster file. If you change that option, make sure to reset your domain name on your hosts accordingly. - - -The ansible inventory is expected at `/etc/genestack/inventory` and automatically loaded once `genestack.rc` is sourced. - -### Prepare hosts for installation - -The `host-setup.yml` playbook draws some values from `group_vars`. Before running the `host-setup.yml` playbook, take a look at default values -provided in `/etc/genestack/inventory/group_vars/all/all.yml` to ensure they are properly defined for your environment. Values can be set as -`host_vars` if appropriate. Then, run the following: - -``` shell -source /opt/genestack/scripts/genestack.rc -cd /opt/genestack/ansible/playbooks -``` - -!!! note - - The rc file sets a number of environment variables that help ansible to run in a more easily to understand way. - -While the `ansible-playbook` command should work as-is with the sourced environment variables, sometimes it's necessary to set some overrides on the command line. -The following example highlights a couple of overrides that are generally useful. - -#### Example host setup playbook - -``` shell -ansible-playbook host-setup.yml -``` - -#### Example host setup playbook with overrides - -Confirm `inventory.yaml` matches what is in `/etc/genestack/inventory`. If it does not match update the command to match the file names. - -``` shell -source /opt/genestack/scripts/genestack.rc -# Example overriding things on the CLI -ansible-playbook host-setup.yml -``` - -!!! note - The RC file sets a number of environment variables that help ansible to run in a more easy to understand way. - -### Run the cluster deployment - -=== "Kubespray Direct _(Recommended)_" - - This is used to deploy kubespray against infra on an OpenStack cloud. If you're deploying on baremetal you will need to setup an inventory that meets your environmental needs. - Change the directory to the kubespray submodule. - - The cluster deployment playbook can also have overrides defined to augment how the playbook is executed. - Confirm openstack-flex-inventory.yaml matches what is in /etc/genestack/inventory. If it does not match update the command to match the file names. - - ``` shell - cd /opt/genestack/submodules/kubespray - ansible-playbook cluster.yml --become - ``` - -!!! tip - - Given the use of a venv, when running with `sudo` be sure to use the full path and pass through your environment variables; `sudo -E /home/ubuntu/.venvs/genestack/bin/ansible-playbook`. - -Once the cluster is online, you can run `kubectl` to interact with the environment. diff --git a/docs/k8s-labels.md b/docs/k8s-labels.md deleted file mode 100644 index 202807c15..000000000 --- a/docs/k8s-labels.md +++ /dev/null @@ -1,58 +0,0 @@ -# Label all of the nodes in the environment - -To use the K8S environment for OpenStack all of the nodes MUST be labeled. The following Labels will be used within your environment. Make sure you label things accordingly. - -!!! note - - The following example assumes the node names can be used to identify their purpose within our environment. - That may not be the case in reality. Adapt the following commands to meet your needs. - -## Genestack Labels - -|
key
| type |
value
| notes | -|:-----|--|:----------------:|:------| -| **openstack-control-plane** | str| `enabled` | Defines which nodes will run the OpenStack Control Plane | -| **openstack-compute-node** | str|`enabled` | Defines which nodes will run OpenStack Compute | -| **openstack-network-node** | str|`enabled` | Defines which nodes will run OpenStack Networking | -| **openstack-storage-node** | str|`enabled` | Defines which nodes will run OpenStack Storage | -| **node-role.kubernetes.io/worker** |str| `worker` | Defines which nodes are designated kubernetes workers | - -!!! example - - Here's an example labeling all of the nodes: the subshell commands are using the node name to identify how to appropriately distribute the workloads throughout the environment. - - ``` shell - # Label the openstack controllers - kubectl label node $(kubectl get nodes | awk '/controller/ {print $1}') openstack-control-plane=enabled - - # Label the openstack compute nodes - kubectl label node $(kubectl get nodes | awk '/compute/ {print $1}') openstack-compute-node=enabled - - # Label the openstack network nodes - kubectl label node $(kubectl get nodes | awk '/network/ {print $1}') openstack-network-node=enabled - - # Label the openstack storage nodes - kubectl label node $(kubectl get nodes | awk '/storage/ {print $1}') openstack-storage-node=enabled - - # With OVN we need the compute nodes to be "network" nodes as well. While they will be configured for networking, they wont be gateways. - kubectl label node $(kubectl get nodes | awk '/compute/ {print $1}') openstack-network-node=enabled - - # Label all workers - Recommended and used when deploying Kubernetes specific services - kubectl label node $(kubectl get nodes | awk '/worker/ {print $1}') node-role.kubernetes.io/worker=worker - ``` - -### Validate node labels - -After labeling everything it's good to check the layout and ensure correctness. - -``` shell -# Verify the nodes are operational and labled. -kubectl get nodes -o wide --show-labels=true -``` - -!!! tip "Make the node layout pretty" - - ``` shell - # Here is a way to make it look a little nicer: - kubectl get nodes -o json | jq '[.items[] | {"NAME": .metadata.name, "LABELS": .metadata.labels}]' - ``` diff --git a/docs/k8s-overview.md b/docs/k8s-overview.md deleted file mode 100644 index 22db453e2..000000000 --- a/docs/k8s-overview.md +++ /dev/null @@ -1,25 +0,0 @@ -# Run The Genestack Kubernetes Deployment - -Genestack assumes Kubernetes is present and available to run workloads on. We don't really -care how your Kubernetes was deployed or what flavor of Kubernetes you're running. For our -purposes, we're using Kubespray, but you do you. - -## Dependencies - -The Genestack Kubernetes deployment platform has a few dependencies that will need to be -accounted for before running the deployment. The following dependencies are required: - -* Kube-OVN -* Persistent Storage - -While the Genestack Kubernetes deployment platform is designed to be flexible and work with -a variety of Kubernetes deployments, it is important to note that the platform is designed -to work with Kube-OVN and some form of persistent Storage. that all said, Genestack does -provide methods to manage the dependencies the platform requires; however, it is -important to understand that there will be some choices to be made. - -## Demo - -For a full end to end demo, see watching the following demonstration. - -[![asciicast](https://asciinema.org/a/629780.svg)](https://asciinema.org/a/629780) diff --git a/docs/k8s-taint.md b/docs/k8s-taint.md deleted file mode 100644 index 5d7d66eb5..000000000 --- a/docs/k8s-taint.md +++ /dev/null @@ -1,11 +0,0 @@ -# Post deployment Operations - -## Remove taint from our Controllers - -In an environment with a limited set of control plane nodes removing the NoSchedule will allow you to converge the -openstack controllers with the k8s controllers. - -``` shell -# Remote taint from control-plane nodes -kubectl taint nodes -l node-role.kubernetes.io/control-plane node-role.kubernetes.io/control-plane:NoSchedule- -``` diff --git a/docs/k8s-tools.md b/docs/k8s-tools.md deleted file mode 100644 index 8f7b88ff6..000000000 --- a/docs/k8s-tools.md +++ /dev/null @@ -1,30 +0,0 @@ -# Install Kubernetes Tools/Plugins - -Once the environment is online, proceed to login to the environment and begin the deployment normally. You'll find the launch node has everything needed, in the places they belong, to get the environment online. - -## Install `kubectl` - -Install the `kubectl` tool. - -``` shell -curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl" -sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl -``` - -### Install the `convert` plugin - -The convert plugin can be used to assist with upgrades. - -``` shell -curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert" -sudo install -o root -g root -m 0755 kubectl-convert /usr/local/bin/kubectl-convert -``` - -### Install the `ko` plugin - -Facilitates daily operations and maintenance, allowing administrators to perform daily operations like: Check OVN database information and status, OVN database backup and restore, OVS related information, tcpdump specific containers, specific link logical topology, network problem diagnosis and performance optimization. - -``` shell -curl -LO https://raw.githubusercontent.com/kubeovn/kube-ovn/release-1.12/dist/images/kubectl-ko -sudo install -o root -g root -m 0755 kubectl-ko /usr/local/bin/kubectl-ko -``` diff --git a/docs/magnum-kubernetes-cluster-setup-guide.md b/docs/magnum-kubernetes-cluster-setup-guide.md deleted file mode 100644 index 7a11f24f7..000000000 --- a/docs/magnum-kubernetes-cluster-setup-guide.md +++ /dev/null @@ -1,102 +0,0 @@ -# Magnum Kubernetes Cluster Setup Guide - -!!! note - - Octavia and Barbican are mandatory components for OpenStack Magnum. Octavia provides advanced load balancing capabilities, which can enhance the availability and distribution of network traffic across your containerized applications. Barbican offers secure management of encryption keys and secrets, which is valuable for maintaining the security of your applications and data. Ensuring these services are integrated into your OpenStack environment is necessary for optimizing the functionality and security of your Magnum-based deployments. - -This document is intended for users who use Magnum to deploy and manage clusters of hosts for a Container Orchestration Engine. It describes the infrastructure that Magnum creates and how to work with them. You can provision clusters made up of virtual machines or baremetal servers. Magnum service uses Cluster Templates to describe how a Cluster is constructed. The process involves creating a Cluster Template for a specific COE and then you will provision a Cluster using the corresponding Cluster Template. Once the cluster is provisioned, you can use the appropriate COE client or endpoint to manage and deploy containers. For more detailed information on cluster creation and management, please refer to the [Magnum User Guide](https://docs.openstack.org/magnum/latest/user/index.html). - -## Create an image - -To create an image required by Magnum, please refer to the [Glance Image Creation Guide](https://docs.rackspacecloud.com/openstack-glance-images/#fedora-coreos-image-required-by-magnum) for detailed instructions on how to set up a Fedora CoreOS image. - -## Create an external network (optional) - -To create a Magnum cluster, you need an external network. If there are no external networks, create one with an appropriate provider based on your usecase. Here is an example command: - -``` shell -openstack network create public --provider-network-type vlan --external --project service -``` - -``` shell -openstack subnet create public-subnet --network public --subnet-range 192.168.1.0/24 --gateway 192.168.1.1 --ip-version 4 -``` - -## Create a keypair (Optional) - -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 mykey > mykey.pem -``` - -## ClusterTemplate - -A ClusterTemplate is a collection of parameters to describe how a cluster can be constructed. Some parameters are relevant to the infrastructure of the cluster, while others are for the particular COE. In a typical workflow, a user would create a ClusterTemplate, then create one or more clusters using the ClusterTemplate. A ClusterTemplate cannot be updated or deleted if a cluster using this ClusterTemplate still exists. - -!!! note "Information about the Default Public Cluster Templates" - - Below cluster templates can be created in the environment and used by anyone to deploy new Kubernetes clusters. To use this template, pass the --cluster-template parameter during cluster creation. - - ??? example "Cluster Templates Creation" - - ``` shell - openstack coe cluster template create k8s-cluster-template-no-lb \ - --image magnum-fedora-coreos-40 \ - --external-network PUBLICNET \ - --dns-nameserver 8.8.8.8 \ - --master-flavor gp.0.4.8 \ - --flavor gp.0.4.8 \ - --network-driver calico \ - --volume-driver cinder \ - --docker-volume-size 10 \ - --coe kubernetes \ - --public - - openstack coe cluster template create k8s-cluster-template-with-lb \ - --image magnum-fedora-coreos-40 \ - --external-network PUBLICNET \ - --dns-nameserver 8.8.8.8 \ - --master-flavor gp.0.4.8 \ - --flavor gp.0.4.8 \ - --network-driver calico \ - --volume-driver cinder \ - --docker-volume-size 10 \ - --coe kubernetes \ - --master-lb-enabled \ - --public - ``` - -### Create a ClusterTemplate - -Create a Kubernetes cluster template using the `magnum-fedora-coreos-40` image with the following configuration: `m1.large` flavor for both master and nodes, `public` as the external network, `8.8.8.8` for the DNS nameserver, `calico` for the network driver, and `cinder` for the volume driver. Below is the example command to create the clustertemplate. For more detailed information about the parameters and labels used in the ClusterTemplate, please refer to the [ClusterTemplate](https://docs.openstack.org/magnum/latest/user/index.html#clustertemplate). - -``` shell -openstack coe cluster template create new-cluster-template \ - --image magnum-fedora-coreos-40 \ - --external-network public \ - --dns-nameserver 8.8.8.8 \ - --master-flavor m1.large \ - --flavor m1.large \ - --network-driver calico \ - --volume-driver cinder \ - --docker-volume-size 10 \ - --coe kubernetes -``` - -## Cluster - -A cluster is an instance of the ClusterTemplate of a COE. Magnum deploys a cluster by referring to the attributes defined in the particular ClusterTemplate as well as a few additional parameters for the cluster. Magnum deploys the orchestration templates provided by the cluster driver to create and configure all the necessary infrastructure. When ready, the cluster is a fully operational COE that can host containers. For details on parameters and labels used in cluster creation, see the [Cluster](https://docs.openstack.org/magnum/latest/user/index.html#cluster) documentation. - -### Provision a Kubernetes cluster - -Create a cluster with `4` nodes and `3` masters using `mykey` as the keypair, using the following command: - -``` shell -openstack coe cluster create new-k8s-cluster \ - --cluster-template new-cluster-template \ - --master-count 3 \ - --node-count 4 \ - --keypair mykey \ - --labels kube_tag=v1.27.8-rancher2,container_runtime=containerd,containerd_version=1.6.28,containerd_tarball_sha256=f70736e52d61e5ad225f4fd21643b5ca1220013ab8b6c380434caeefb572da9b,cloud_provider_tag=v1.27.3,cinder_csi_plugin_tag=v1.27.3,k8s_keystone_auth_tag=v1.27.3,magnum_auto_healer_tag=v1.27.3,octavia_ingress_controller_tag=v1.27.3,calico_tag=v3.26.4,auto_healing_enabled=True,auto_healing_controller=magnum-auto-healer -``` diff --git a/docs/metering-billing.md b/docs/metering-billing.md deleted file mode 100644 index a00afc32a..000000000 --- a/docs/metering-billing.md +++ /dev/null @@ -1,36 +0,0 @@ -# Billing Design - -In a cloud billing system using Gnocchi as the source for metered usage data, -Gnocchi stores and processes time series data related to resource consumption. -Key factors such as instance flavor, volume size and type, network traffic, and -object storage can all be stored in Gnocchi, enabling them to be queried later -for usage-based billing of Genestack tenants. - -## Billing Workflow - -1. **Data Collection**: OpenStack Ceilometer continuously collects telemetry - data from various cloud resources via polling and notification agents. - -2. **Data Aggregation and Storage**: Ceilometer forwards this raw usage data - to Gnocchi. Gnocchi automatically aggregates and stores these metrics in an - optimized, scalable format — ensuring that large volumes of data can be - handled efficiently. - -3. **Querying Usage Data**: The billing system queries the Metrics API to - retrieve pre-aggregated metrics over specified time periods (_e.g., hourly, - daily, or monthly usage_). Gnocchi provides quick access to the stored data, - enabling near real-time billing operations. - -4. **Converting to Atom Events**: The billing system converts the collated - resource usage data into Atom events before submitting them. - -5. **Submitting Events to Cloud Feeds**: Newly created Atom events are sent - via HTTPS to Cloud Feeds. - -6. **Usage Mediation Services**: Our UMS team receives the metered usage - events from the named feed, then does further aggregation before emitting - the usage to be invoiced. - -7. **Billing and Revenue Management**: Finally, the aggregated usage from - UMS is received and processed by BRM to create the usage-based invoice - for each tenant. diff --git a/docs/metering-ceilometer.md b/docs/metering-ceilometer.md deleted file mode 100644 index 08a189143..000000000 --- a/docs/metering-ceilometer.md +++ /dev/null @@ -1,160 +0,0 @@ -# Ceilometer (Metering and Event Collection) - -Ceilometer is the telemetry service in OpenStack responsible for collecting -usage data related to different resources (_e.g., instances, volumes, -and network usage_). It compiles various types of metrics (_referred to as -meters_), such as CPU utilization, disk I/O, and network traffic. It does -this by gathering data from other OpenStack components like Nova (_compute_), -Cinder (_block storage_), and Neutron (_networking_). It also captures event -data such as instance creation and volume attachment via hooks into the message -notification system (_RabbitMQ_). - -![Ceilometer Architecture](assets/images/metering-ceilometer.png) - -
-
Image source: docs.openstack.org
-
- -## Configuration - -Ceilometer’s configuration may initially seem complex due to the extensive -number of event, metric, and resource definitions available. However, these -definitions can be easily modified to adjust the data collected by the polling -and notification agents, allowing users to fine-tune data collection based on -their specific needs. - -### Events - -Events are discrete occurrences, such as the starting or stopping of -instances or attaching a volume which are captured and stored. Ceilometer -builds event data from the messages it receives from other OpenStack -services. Event definitions can be complex. Typically, a given message will -match one or more event definitions that describe what the incoming payload -should be flattened to. See the [telemetry-events][ceilometer-events] -section of Ceilometer's documentation for more information. - -??? example "Example event definitions for cinder volumes" - - ``` - - event_type: ['volume.exists', 'volume.retype', 'volume.create.*', 'volume.delete.*', 'volume.resize.*', 'volume.attach.*', 'volume.detach.*', 'volume.update.*', 'snapshot.exists', 'snapshot.create.*', 'snapshot.delete.*', 'snapshot.update.*', 'volume.transfer.accept.end', 'snapshot.transfer.accept.end'] - traits: &cinder_traits - user_id: - fields: payload.user_id - project_id: - fields: payload.tenant_id - availability_zone: - fields: payload.availability_zone - display_name: - fields: payload.display_name - replication_status: - fields: payload.replication_status - status: - fields: payload.status - created_at: - type: datetime - fields: payload.created_at - image_id: - fields: payload.glance_metadata[?key=image_id].value - instance_id: - fields: payload.volume_attachment[0].instance_uuid - - event_type: ['volume.transfer.*', 'volume.exists', 'volume.retype', 'volume.create.*', 'volume.delete.*', 'volume.resize.*', 'volume.attach.*', 'volume.detach.*', 'volume.update.*', 'snapshot.transfer.accept.end'] - traits: - <<: *cinder_traits - resource_id: - fields: payload.volume_id - host: - fields: payload.host - size: - type: int - fields: payload.size - type: - fields: payload.volume_type - replication_status: - fields: payload.replication_status - ``` - -### Resources - -Gnocchi resource definitions in Ceilometer's configuration define how resources -like instances, volumes, and networks are represented and tracked for -telemetry purposes. Each definition specifies the attributes (_such as project -ID or instance name_) and the metrics (_like CPU usage or network traffic_) -associated with that resource. When Ceilometer collects data from various -OpenStack services, it uses these definitions to map the data to the appropriate -resource type in Gnocchi (_which stores it as time-series data_). This -structure allows for efficient monitoring, aggregation, and analysis of resource -usage over time in a scalable way. - -??? example "Example resource definition for cinder volumes" - - ``` - - resource_type: volume - metrics: - volume: - volume.size: - snapshot.size: - volume.snapshot.size: - volume.backup.size: - backup.size: - volume.manage_existing.start: - volume.manage_existing.end: - volume.manage_existing_snapshot.start: - volume.manage_existing_snapshot.end: - attributes: - display_name: resource_metadata.(display_name|name) - volume_type: resource_metadata.volume_type - image_id: resource_metadata.image_id - instance_id: resource_metadata.instance_id - event_create: - - volume.create.end - event_delete: - - volume.delete.end - - snapshot.delete.end - event_update: - - volume.attach.end - - volume.transfer.accept.end - - snapshot.transfer.accept.end - event_attributes: - id: resource_id - project_id: project_id - image_id: image_id - instance_id: instance_id - ``` - -### Meters - -Meters are quantitative measures like CPU time, memory usage, or disk -operations. Ceilometer provides several useful metrics by default, but new -definitions can be added to suit almost every need. To read more about -measurements and how they are captured, see the [telemetry-measurements][ceilometer-telemetry] -section of Ceilometer documentation. - -??? example "Example metric definition for volume.size" - ``` - - name: 'volume.size' - event_type: - - 'volume.exists' - - 'volume.retype' - - 'volume.create.*' - - 'volume.delete.*' - - 'volume.resize.*' - - 'volume.attach.*' - - 'volume.detach.*' - - 'volume.update.*' - - 'volume.manage.*' - type: 'gauge' - unit: 'GB' - volume: $.payload.size - user_id: $.payload.user_id - project_id: $.payload.tenant_id - resource_id: $.payload.volume_id - metadata: - display_name: $.payload.display_name - volume_type: $.payload.volume_type - image_id: $.payload.glance_metadata[?key=image_id].value - instance_id: $.payload.volume_attachment[0].instance_uuid - ``` - -[ceilometer-telemetry]: https://docs.openstack.org/ceilometer/latest/admin/telemetry-measurements.html "The Telemetry service collects meters within an OpenStack deployment. This section provides a brief summary about meters format, their origin, and also contains the list of available meters." - -[ceilometer-events]: https://docs.openstack.org/ceilometer/latest/admin/telemetry-events.html "In addition to meters, the Telemetry service collects events triggered within an OpenStack environment. This section provides a brief summary of the events format in the Telemetry service." diff --git a/docs/metering-chargebacks.md b/docs/metering-chargebacks.md deleted file mode 100644 index 3970042ee..000000000 --- a/docs/metering-chargebacks.md +++ /dev/null @@ -1,27 +0,0 @@ -# Handling Chargebacks - -Gnocchi is pivotal in tracking and managing resource consumption across projects -within an OpenStack environment. The chargeback process aims to assign the -costs of shared cloud resources to the responsible entity based on their usage. - -## Theoretical Workflow - -1. **Customer Initiates Chargeback or Complaint**: The complaint is received - by the responsible operational team that would handle such a dispute. Usage - can be re-calculated for a specific tenant over a given period of time. - -2. **Querying Usage Data**: The chargeback system queries Gnocchi for usage - metrics that belong only to the specific projects of concern related to the - dispute. Gnocchi provides detailed, pre-aggregated data for each tracked - resource, enabling the system to quickly access and analyze consumption. - -3. **Cost Allocation**: Based on the usage data retrieved from Gnocchi, the - chargeback system could then allocate the costs of the shared cloud - resources to each tenant. Cost allocation models, such as pay-per-use or - fixed rates for specific services (_e.g., $ per GB of storage or flavor_type - $ per hour_), can be applied to determine the charges for each entity. - -4. **Reporting and Transparency**: The chargeback system could be made to - generate reports detailing each project's resource consumption and - associated costs. These reports provide transparency, allowing tenants to - track their resource usage and associated expenses. diff --git a/docs/metering-gnocchi.md b/docs/metering-gnocchi.md deleted file mode 100644 index c6a1f5782..000000000 --- a/docs/metering-gnocchi.md +++ /dev/null @@ -1,89 +0,0 @@ -# Gnocchi (Metric Storage API) - -Gnocchi is an open-source project designed to store and manage time series data. - -It addresses the challenge of efficiently storing and indexing large-scale time -series data, which is crucial in modern cloud environments that are vast, -dynamic, and may serve multiple users. Gnocchi is built with performance, -scalability, and fault-tolerance in mind, without relying on complex storage -systems. - -Unlike traditional time series databases that store raw data points and compute -aggregates (_like averages or minimums_) when queried, Gnocchi simplifies this -by pre-aggregating data during ingestion. This makes retrieving data much -faster since the system only needs to read the already processed results. - -## Architecture - -Gnocchi includes multiple services: an HTTP REST API, an optional -statsd-compatible daemon, and an asynchronous processing daemon -(_gnocchi-metricd_). Data is ingested through the API or statsd daemon, -while `gnocchi-metricd` handles background tasks like statistics computation and -metric cleanup. - -![Gnocchi Architecture](assets/images/gnocchi-architecture.svg) - -
-
Image source: gnocchi.osci.io
-
- -Gnocchi services are stateless thus can be scaled horizontally without much -effort. That being said, we can easily define an HPA (HorizontalPodAutoscaler) -policy to do just that for `ReplicaSet` components such as the `gnocchi-api`. -However, `metricd` and `statsd` components are configured to be -`DaemonSets`, so operators need only label additional nodes with the -configured node-selector key/value of `openstack-control-plane=enabled` to -scale those components up or down. - -## Storage - -As shown in the previous architecture diagram, Gnocchi relies on three key -external components for proper functionality: - - - Storage for incoming measures - - Storage for aggregated metrics - - An index - -### Measures & Aggregates - -Gnocchi supports various storage backends for incoming measures and aggregated -metrics, including: - - - File - - Ceph (_flex default for `incoming` & `storage`_) - - OpenStack Swift - - Amazon S3 - - Redis - -For smaller architectures, using the file driver to store data on disk may be -sufficient. However, S3, Ceph, and Swift offer more scalable storage options, -with Ceph being the recommended choice due to its better consistency. In -larger or busier deployments, a common recommendation is to use Redis for -incoming measure storage and Ceph for aggregate storage. - -### Indexing - -The indexer driver stores the index of all resources, archive policies, and -metrics, along with their definitions, types, and properties. It also handles -the linking of resources to metrics and manages resource relationships. -Supported drivers include the following: - - - PostgreSQL (_flex default_) - - MySQL (_version 5.6.4 or higher_) - -## Resource Types - -The resource types that reside within Gnocchi are created during the Ceilometer -db-sync job which executes `ceilometer-upgrade`. We create the default types -that ship with Ceilometer, they can be modified via the Metrics API post -creation if necessary. - -## REST API Usage - -The Gnocchi REST API is well documented on their website, please see the -[REST API Usage](https://gnocchi.osci.io/rest.html) section for full detail. -Furthermore, there is a community supported Python client and SDK -installable via pip, aptly named [python-gnocchiclient](https://github.com/gnocchixyz/python-gnocchiclient). -It's worth noting, this is a required module for `openstack metric` commands -to function. See [OpenStack Metrics](openstack-metrics.md) for example CLI -usage. diff --git a/docs/metering-overview.md b/docs/metering-overview.md deleted file mode 100644 index adbe0caa1..000000000 --- a/docs/metering-overview.md +++ /dev/null @@ -1,22 +0,0 @@ -# Metering Overview - -Metering in OpenStack involves collecting, tracking, and analyzing the -usage data of various resource types within your cloud environment (_crucial -for billing, monitoring, and performance optimization_). This functionality -is achieved by leveraging the [Ceilometer](metering-ceilometer.md) and -[Gnocchi](metering-gnocchi.md) projects. - -Ceilometer and Gnocchi work together to provide a powerful solution for -resource tracking in environments of all sizes. Their combined importance -lies in their complementary roles such as collecting, storing, and -processing of telemetry data at scale. - -Once processed and stored, these resource data can be queried through Gnocchi, -also known as the Metrics API. This data serves a wide range of use cases, -including auditing, billing, monitoring, and more. - -![Metering Overview](assets/images/metering-overview.svg) - -
-
Metering Architecture - © Luke Repko, Rackspace Technology
-
diff --git a/docs/mkdocs-howto.md b/docs/mkdocs-howto.md deleted file mode 100644 index dac12c1e2..000000000 --- a/docs/mkdocs-howto.md +++ /dev/null @@ -1,20 +0,0 @@ -# Working on docs locally - -To work on documentation locally and preview it while developing, we can use `mkdocs serve` - -Start by installing the requirements for documentation. - -``` shell -pip install -r doc-requirements.txt -``` - -!!! tip - - You may want to first create a virtualenv and install requirements in there. - -Once the installation is done, run the mkdocs server locally to view your changes. - -``` shell -cd genestack/ -mkdocs serve -``` diff --git a/docs/monitoring-getting-started.md b/docs/monitoring-getting-started.md deleted file mode 100644 index 44ddfa4b8..000000000 --- a/docs/monitoring-getting-started.md +++ /dev/null @@ -1,56 +0,0 @@ -# Getting started with genestack monitoring - -In order to begin monitoring your genestack deployment we first need to deploy the core prometheus components - -## Install the Prometheus stack - -Install [Prometheus](prometheus.md) which is part of the kube-prometheus-stack and includes: - -* Prometheus and the Prometheus operator to manage the Prometheus cluster deployment -* AlertManager which allows for alerting configurations to be set in order to notify various services like email or PagerDuty for specified alerting thresholds - -The [Prometheus](prometheus.md) kube-prometheus-stack will also deploy a couple core metric exporters as part of the stack, those include: - -* Node Exporter(Hardware metrics) -* Kube State Exporter(Kubernetes cluster metrics) - -## Install Grafana - -We can then deploy our visualization dashboard Grafana - -* [Install Grafana](grafana.md) - -Grafana is used to visualize various metrics provided by the monitoring system as well as alerts and logs, take a look at the [Grafana](https://grafana.com/) documentation for more information - -## Install the metric exporters and pushgateway - -Now let's deploy our exporters and pushgateway! - -* [Mysql Exporter](prometheus-mysql-exporter.md) -* [RabbitMQ Exporter](prometheus-rabbitmq-exporter.md) -* [Postgres Exporter](prometheus-postgres-exporter.md) -* [Memcached Exporter](prometheus-memcached-exporter.md) -* [Openstack Exporter](prometheus-openstack-metrics-exporter.md) -* [Pushgateway](prometheus-pushgateway.md) - -## Next steps - -### Configure alert manager - -Configure the alert manager to send the specified alerts to slack as an example, see: [Slack Alerts](alertmanager-slack.md) - -... and more ... - -### Update alerting rules - -Within the genestack repo we can update our custom alerting rules via the alerting_rules.yaml to fit our needs - -View alerting_rules.yaml in: - -``` shell -less /etc/genestack/helm-configs/prometheus/alerting_rules.yaml -``` - -However, many opreators comes with ServiceMonitor and PodMonitor services. These services expose, scrape endpoints -out of the box. These operators will also provide alerting rules curated for the specific service. See specific -service install for any monitoring rules. Example: [RabbitMQ Operator Monitoring](infrastructure-rabbitmq.md#rabbitmq-operator-monitoring) diff --git a/docs/monitoring-info.md b/docs/monitoring-info.md deleted file mode 100644 index c2b440e96..000000000 --- a/docs/monitoring-info.md +++ /dev/null @@ -1,188 +0,0 @@ -# Genestack Monitoring - -Genestack is made up of a vast array of components working away to provide a Kubernetes and OpenStack cloud infrastructure -to serve our needs. Here we'll discuss in a bit more detail about how we're monitoring these components and what that -looks like. - -## Overview - -In this document we'll dive a bit deeper into the components and how they're being used, for a quick overview take a look -at the [Monitoring Overview](prometheus-monitoring-overview.md) documentation. - -The following tooling are what was chosen as part of Genestack's default monitoring workflow primarily for their open-sourced nature and ease of integration. -These tools are not an absolute requirement and can easily be replaced by tooling of the end users choice as they see fit. - -## Prometheus - -Prometheus is the heavy lifter in Genestack when it comes to monitoring. We rely on Prometheus to monitor and collect metrics -for everything from the node/host health itself to Kubernetes stats and even OpenStack service metrics and operations. - -Prometheus is an open-source systems monitoring and alerting toolkit built in 2012. It joined the Cloud Native Computing Foundation in 2016 as the second hosted project, after Kubernetes. - -Prometheus is a powerful system that collects and stores its metrics as time series data, i.e. metrics information is stored with the timestamp at which it was recorded, alongside optional key-value pairs called labels. - -To read more about Prometheus from the official source take a look at [Prometheus Docs](https://prometheus.io). - -To install Prometheus within the Genestack workflow we make use of the helm charts found in the kube-prometheus-stack. - -## The Kube Prometheus Stack - -Genestack takes full advantage of [Helm](https://helm.sh/) and [Kustomize maninfests](https://kustomize.io/) to build a production grade Kubernetes and OpenStack Cloud. -When it comes to monitoring Genestack this is no different, Genestack makes use of the [Prometheus Community's](https://github.com/prometheus-community) [kube-prometheus-stack](https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack). - -The kube-prometheus-stack provides an easy to operate end-to-end Kubernetes cluster monitoring system with Prometheus using the [Prometheus Operator](https://github.com/prometheus-operator/prometheus-operator). - -The kube-prometheus-stack offers many components that make monitoring fairly straight forward, scalable and easy to maintain. -In Genestack we have opted to make use of a subset of the components. As our needs change we may make further use of more of the components that the kube-prometheus-stack provides. -At the time of writing the primary components Genestack is not making use of as part of the kube-prometheus-stack are [Thanos](https://thanos.io/), a HA, long term storage Prometheus setup and [Grafana](https://grafana.com/), a metrics and alerting visualization platform. - -Thanos hasn't been a need or priority to setup by default in Genestack but is available to anyone utilizing Genestack by configuring the ThanosService section found in the [prometheus-helm-overrides.yaml](https://github.com/rackerlabs/genestack/blob/main/base-helm-configs/prometheus/prometheus-helm-overrides.yaml) in the Genestack repo. -For configuration documentation of Thanos view the [Thanos Docs](https://thanos.io/tip/thanos/getting-started.md/). - -As for Grafana, we install this separately to fit our needs with datasources, custom routes, auth and certs. To see more information about how we're installing Grafana as part of the Genestack workflow see: [Grafana README](https://github.com/rackerlabs/genestack/blob/main/base-helm-configs/grafana/README.md) and the installation documentation found at [Install Grafana](grafana.md). - -Some of the components that we do take advantage of are the [Prometheus Operator](https://github.com/prometheus-operator/prometheus-operator), [AlertManager](https://prometheus.io/docs/alerting/latest/alertmanager/) -and various custom resource definitions(CRD). These CRD's include the AlertManagerConfig, PrometheusRule and things like the ServiceMonitors, which allows for dynamic service monitoring configured outside the traditional Prometheus configuration methods. -For a more complete list and their definitions view: [Prometheus Operator Design](https://prometheus-operator.dev/docs/getting-started/design/). - -The below diagram gives a good view of how these components are all connected. -![Prometheus Architecture](assets/images/prometheus-architecture.png) - -To install the kube-prometheus-stack as part of Genestack's workflow view the [Installing Prometheus Doc](prometheus.md). - -As for the metrics themselves they are largely provided by 'exporters' which simply export the data exposed by various services we wish to monitor in order for Prometheus to injest them. -The kube-prometheus-stack provides a set of key exporters deployed by default, such as, node-exporter and kube-state-metrics, that Genestack relies on to monitor its infrastructure. - -## Metric Exporters - -Genestack makes heavy use of prometheus exporters as there are many services that require monitoring. Below is the list of exporters Genestack deploys to monitor its systems. - -* ### Node Exporter: -The [node-exporter](https://github.com/prometheus/node_exporter) is geared toward hardware and OS metrics exposed by *NIX kernels. -The node-exporter exposes many important metrics by default such as cpu, hwmon, meminfo, loadavg and many more. For a full list view the [node-exporter README](https://github.com/prometheus/node_exporter?tab=readme-ov-file#collectors). - -* ### Kube State Metrics: -The [kube-state-metrics](https://github.com/kubernetes/kube-state-metrics) service provides metrics regarding the health of Kubernetes objects such as deployments, nodes and pods. -The kube-state-metrics service provides detailed information about the health and state of Kubernetes components and objects such as ConfigMaps, Jobs, Nodes, Deployments and many many more. -View the [kube-state-docs](https://github.com/kubernetes/kube-state-metrics/tree/main/docs) for a complete list and further information. - -Beyond those two highly important ones installed by default are many more equally important metric exporters that we install as part of Genestack's workflow that we'll go over next. - -* ### MariaDB/MySQL Exporter: -Genestack uses a couple different database solutions to run OpenStack or just for general storage capabilities, the most prominent of them is MySQL or more specifically within Genestack MariaDB and Galera. -When installing [MariaDB](infrastructure-mariadb.md) as part of Genestack's workflow it is default to enable metrics which deploys its own service monitor as part of the [mariadb-operator](https://mariadb-operator.github.io/mariadb-operator/latest/) helm charts. -This is great if you have already installed Prometheus, if not the MariaDB deploy will fail and there may be other potential database disrupting issues if you have a need to update metrics settings alone. It is encouraged to install the [Mysql Exporter](prometheus-mysql-exporter.md) as a separate exporter that can be updated without having to run MariaDB deploy/update commands. -The [mysql-exporter](https://github.com/prometheus/mysqld_exporter) is provided by the prometheus organization and is also what's used within the MariaDB Operator. When installed separately via the Genestack [Mysql Exporter](prometheus-mysql-exporter.md) installation instructions the [prometheus-mysql-exporter](https://github.com/prometheus-community/helm-charts/tree/main/charts/prometheus-mysql-exporter) helm charts are used. -The mysql-exporter provides many important metrics related to the overall health and operation of your MariaDB/Galera cluster. You can view more details about what's exported in the [mysqld-exporter README](https://github.com/prometheus/mysqld_exporter?tab=readme-ov-file#mysql-server-exporter-). - -* ### Postgres Exporter: -Genestack also makes use of PostgreSQL for a limited set of services. At the time of writing only [Gnocchi](openstack-gnocchi.md) is making use of it. It's still an important part of the system and requires monitoring. -To do so we make use of the Prometheus community helm charts [prometheus-postgres-exporter](https://github.com/prometheus-community/helm-charts/tree/main/charts/prometheus-postgres-exporter) and it's installed as part of Genestack's workflow by following the [Postgres Exporter](prometheus-postgres-exporter.md). -Further information about the exporter and the metrics it collects and exposes can be found in the [postgres_exporter](https://github.com/prometheus-community/postgres_exporter/blob/master/README.md) documentation. - -* ### RabbitMQ Exporter: -Many OpenStack services require RabbitMQ to operate and is part of Genestack's infrastructure deployment. [RabbitMQ](infrastructure-rabbitmq.md) cluster can be finicky at times and it's important to be able to monitor it. -Genestack makes use of the Prometheus community's [prometheus-rabbitmq-exporter](https://github.com/prometheus-community/helm-charts/tree/main/charts/prometheus-rabbitmq-exporter) helm charts and is installed as part of Genestack's workflow via [RabbitMQ Exporter](prometheus-rabbitmq-exporter.md). -The RabbitMQ exporter provides many detailed metrics such as channels, connections and queues. View a complete list of the metrics exposed in the [RabbitMQ Exporter Docs](https://github.com/kbudde/rabbitmq_exporter/blob/main/metrics.md). - -* ### Memcached Exporter: -Many OpenStack services make use of Memcached as a caching layer which is part of Genestack's infrastructure deployment found in the [Memcached Deployment Doc](infrastructure-memcached.md). -We monitor Memcached utilizing Prometheus community's helm chart for the [prometheus-memcached-exporter](https://github.com/prometheus-community/helm-charts/tree/main/charts/prometheus-memcached-exporter). -The memcached-exporter offers many metrics for things like uptime, connections and limits. For a full list view the [Memcached Exporter Docs](https://github.com/prometheus/memcached_exporter/blob/master/README.md#collectors). - -* ### BlackBox Exporter: -The blackbox exporter allows blackbox probing of endpoints over HTTP, HTTPS, DNS, TCP, ICMP and gRPC. This exporter is ideally deployed cross region in order to check the service health across the network. -Deploying it as part of the cluster it's monitoring does still have its benefits as it will reach out the gateways and back in to provide some context about the health of your services. This can also serve as a simple way to check endpoint cert expiration. -Install this exporter following the documentation found at [BlackBox Deployment Doc](prometheus-blackbox-exporter.md). For more information regarding the BlackBox exporter see the upstream [BlackBox Exporter Doc](https://github.com/prometheus/blackbox_exporter) - -* ### OVN Monitoring: -OVN is installed a bit differently compared to the rest of the services as you can see in the [OVN Deployment Doc](infrastructure-ovn-setup.md). The installation ends up installing [Kube-OVN](https://github.com/kubeovn/kube-ovn) which exposes metrics about its operations. -However, at this point, there's no way for Prometheus to scrape those metrics. The way Genestack achieves this is by applying ServiceMonitor CRD's so Prometheus knows how to find and scrape these services for metric collection. -In the [Kube-OVN Deployment Doc](https://docs.rackspacecloud.com/prometheus-kube-ovn/) we see a simple command to apply the contents of [prometheus-ovn](https://github.com/rackerlabs/genestack/tree/main/base-kustomize/prometheus-ovn). -The contents are a set of ServiceMonitor manifests that define labels, namespaces and names to match to a service to monitor which is percisely what a [ServiceMonitor](https://prometheus-operator.dev/docs/api-reference/api/#monitoring.coreos.com/v1.ServiceMonitor) CRD is designed to do. -You can view more information about the metrics provided in the [Kube-OVN Metrics Doc](https://kubeovn.github.io/docs/stable/en/reference/metrics/). -Once we've ran the apply command we will have installed ServiceMonitors for Kube-OVN services: - * CNI - * Controller - * OVN - * Pinger - - You can view more information about OVN monitoring in the [OVN Monitoring Introduction Docs](ovn-monitoring-introduction.md). - -* ### Nginx Gateway Monitoring: -Genestack makes use of the Gateway API for its implementation of [Kubernetes Gateway API](https://gateway-api.sigs.k8s.io/). Genestack deploys this as part of its infrastructure, view the [Gateway Deployment Doc](infrastructure-gateway-api.md) for more information. -Nginx Gateway does expose important metrics for us to gather but it does not do so via a service. Instead we must make use another Prometheus CRD the [PodMonitor](https://prometheus-operator.dev/docs/getting-started/design/#podmonitor). -The install is similar to the above OVN monitoring as you can see in the [Nginx Gateway Exporter Deployment Doc](prometheus-nginx-gateway.md). The primary difference is the need to target and match on a pod that's exposing the metrics rather than a service. -You can view more information about the metrics exposed by the Nginx Gateway by viewing the [Nginx Gateway Fabric Docs](https://docs.nginx.com/nginx-gateway-fabric/how-to/monitoring/prometheus/). - -* ### OpenStack Metrics: -OpenStack Metrics are a bit different compared to the rest of the exporters as there's no single service, pod or deployment that exposes Prometheus metrics for collection. Instead, Genestack uses the [OpenStack Exporter](https://github.com/openstack-exporter/openstack-exporter) to gather the metrics for us. -The OpenStack exporter reaches out to all the configured OpenStack services, queries their API for stats and packages them as metrics Prometheus can then process. The OpenStack exporter is configurable and can collect metrics from just about every OpenStack service such as Keystone, Nova, Octavia etc.. -View the [OpenStack Exporter Deployment Doc](prometheus-openstack-metrics-exporter.md) for more information on how to configure and deploy the exporter in the Genestack workflow. -You can view more information about the OpenStack exporter in general and what metrics are collected in the [OpenStack Exporter Doc](https://github.com/openstack-exporter/openstack-exporter?tab=readme-ov-file#metrics). - -* ### Ceph Monitoring: -[Ceph](https://rook.io/docs/rook/latest-release/Getting-Started/intro/) comes with its own set of optimized collectors and exporters. In terms of deploying [Ceph Internally](storage-ceph-rook-internal.md) there is nothing for us to do. The service and ServiceMonitor CRD's are created and metrics will be available in Prometheus assuming metric collection is enabled in the helm chart. -If we are deploying [Ceph externally](storage-ceph-rook-external.md) then we will want to add another Prometheus CRD, the [ScrapeConfig](https://prometheus-operator.dev/docs/getting-started/design/#scrapeconfig). -The ScrapeConfig allows us to define external sources for Prometheus to scrape. - !!! example "Example ScrapeConfig for external Ceph monitoring" - - ``` yaml - apiVersion: monitoring.coreos.com/v1alpha1 - kind: ScrapeConfig - metadata: - name: external-ceph-monitor - namespace: prometheus - labels: - prometheus: sys\em-monitoring-prometheus - spec: - staticConfigs: - - labels: - job: prometheus - targets: - - 192.12.34.567:9283 - ``` -With this example we can simply apply it to the cluster and Prometheus will soon begin scraping metrics for our external Ceph cluster. -We can see additional information about the Ceph exporter at the [Ceph Github Docs](https://github.com/rook/rook/blob/master/design/ceph/ceph-exporter.md). -For additional information regarding the metrics collected and exposed from Ceph clusters view the [Ceph Telemetry Doc](https://github.com/rook/rook/blob/master/design/ceph/ceph-telemetry.md?plain=1). - -* ### Push Gateway: -The [Prometheus Push Gateway](https://github.com/prometheus/pushgateway) is used to gather metrics from short-lived jobs, like Kubernetes CronJobs. -It's not capable of turning Prometheus into a push-based monitoring system and should only be used when there is no other way to collect the desired metrics. -Currently, in Genestack the push gateway is only being used to gather stats from the OVN-Backup CronJob as noted in the [Pushgateway Deployment Doc](prometheus-pushgateway.md). - -* ### SNMP Exporter: -The [Prometheus SNMP Exporter](https://github.com/prometheus/snmp_exporter) is -used for gathering SNMP metrics. A default Genestack installation does not make -use of it, so you do not need to install it unless you plan to do additional -configuration beyond Genestack defaults and specifically plan to monitor some -SNMP-enabled devices. - -* ### Textfile Collector: -It's possible to gather node/host metrics that aren't exposed by any of the above exporters by utilizing the [Node Exporter Textfile Collector](https://github.com/prometheus/node_exporter?tab=readme-ov-file#textfile-collector). -Currently, in Genestack the textfile-collector is used to collect kernel-taint stats. To view more information about the textfile-collector and how to deploy your own custom exporter view the [Custom Metrics Deployment Doc](prometheus-custom-node-metrics.md). - -This is currently the complete list of exporters and monitoring callouts deployed within the Genestack workflow. That said, Genestack is constantly evolving and list may grow or change entirely as we look to further improve our systems! -With all these metrics available we need a way to visualize them to get a better picture of our systems and their health, we'll discuss that next! - -## Visualization - -In Genestack we deploy [Grafana](https://grafana.com/) as our default visualization tool. Grafana is open-sourced tooling which aligns well with the Genestack ethos while providing seamless visualization of the metrics generated by our systems. -Grafana also plays well with Prometheus and [Loki](infrastructure-loki.md), the default logging tooling deployed in Genestacks workflow, with various datasource plugins making integration a breeze. -Installing [Grafana](grafana.md) within Genestack is fairly straight forward, just follow the [Grafana Deployment Doc](grafana.md). - -The installation also takes care of installing the primary [datasources](https://grafana.com/docs/grafana/latest/datasources/) which are Grafana plugins used for querying specific datasets. -For example in Genestack we install the [Prometheus and Loki datasources](https://github.com/rackerlabs/genestack/blob/8b90d22b19795acd364afb05f08617c326f6c8f6/base-helm-configs/grafana/datasources.yaml#L4) as part of Genestack's default workflow. -You can manually add additional datasources by following the [add datasource](https://grafana.com/docs/grafana/latest/datasources/#add-a-data-source) documentation. -More information about the primary datasources can be found in the [Prometheus datasource](https://grafana.com/docs/grafana/latest/datasources/prometheus/) and [Loki datasource](https://grafana.com/docs/grafana/latest/datasources/loki/) documentation. - -As things stand now, the Grafana deployment does not deploy dashboards as part of the default deployment instructions. However, there are dashboards available found in the [etc directory](https://github.com/rackerlabs/genestack/tree/main/etc/grafana-dashboards) of the Genestack repo that can be installed manually by importing them into Grafana. -View the [importing dashboards](https://grafana.com/docs/grafana/latest/dashboards/build-dashboards/import-dashboards/) documentation for more information. -The dashboards available cover just about every exporter/metric noted here and then some. Some of the dashboards may not be complete or may not provide the desired view. Please feel free to adjust them as needed and submit a PR to [Genestack repo](https://github.com/rackerlabs/genestack) if they may help others! - -## Next Steps - -With what's deployed as part of our Genestack workflow today we get a fairly clear view of all our systems that allows us to properly monitor our Genestack cluster. -As we begin to expand to more regions or add other services that exist outside of our cluster, such as Swift, with its own monitoring systems a need may arise for tooling not provided within Genestack. -For example, Grafana may not provide all the features we'd like in a dashboard and we may want to find something that could combine multiple regions while being able to provide automation activity on alerts and way to notify support and on-call team members. -At that point it may be time to look at replacing certain tooling or running them in conjunction with things like [Dynatrace](https://www.dynatrace.com/) or [Datadog](https://www.datadoghq.com/) or any of the many tools available to fit our needs. diff --git a/docs/multi-region-support.md b/docs/multi-region-support.md deleted file mode 100644 index 4c0084894..000000000 --- a/docs/multi-region-support.md +++ /dev/null @@ -1,131 +0,0 @@ -# Supporting multiple regions with Genestack - -Genestack is fairly simple to get started with by just pulling down the code and following the basic set-up documentation with the base config files but there are instances where your deployment may get a bit more complicated. -Genestack provides a reasonably sane set of base configs with default values that configure infrastructure and openstack services utilizing `helm` and `kustomize` and this works great for a simple lab setup or even a single production region. -When it comes to supporting many regions with various different values across them a single set of configs just won't suffice. - -Below we'll discuss one way to better structure, version and maintain a multi-region genestack deployment. - -## Overview - -Firstly, we'll note that genestack is currently setup to run `helm` and `kustomize` commands from the `base-helm-configs` and `base-kustomize` directories. -These base config directories provide a sane set of defaults that can be easily applied to a lab type setup for testing purposes. Using the `aio-example-openstack-overrides.yaml` file as an additional argument to the `helm` commands you can easily adjust the values needed. -If deploying a single region for a more production like environment we can take advantage of the `prod-aio-example-openstack-overrides.yaml` file which allows us to override the various configs with production or otherwise custom values that meets the needs of our deployment. - -These examples allow us to adjust and override the default `helm` values for a single deployment, or potentially multiple deployments that have identical requirements but this doesn't help us with multiple deployments that have various differences that we'd like to maintain, track and update easily. - -With that in mind we'll discuss a suggested workflow to help resolve those concerns. - -## Multi-region workflow - -For this example workflow we'll work under the assumption that we have two regions with differing configs that we want to maintain and version control. The two regions in this example will be named as `sjc` and `dfw`. -Keep in mind that this could also apply to staging or dev environments where we'd use something like `sjc` and `sjc-staging`, but for this example we'll treat it as two different regions. - -So, up to this point we've followed the documentation and cloned the genestack repo which was placed in `/opt/genestack` and our primary genestack config directory is found in `/etc/genestack`. The config directory, `/etc/genestack` is primarily where -our inventory and bootstrap type configs are found. We will make use of `/etc/genstack` for our regional overrides as well. - -For this workflow we want to utilize a git repo to store our changes and custom configs. We also want to clearly define regional specific directories within the repo that will contain everything from the custom inventory to our helm config overrides. -The structure may look something like: - -!!! example - ``` - ├── my-genestack-configs - │ ├── region1 - │ │ ├── inventory - │ │ │ ├── inventory.yaml - │ │ ├── helm-configs - │ │ │ ├── nova - │ │ │ │ ├── region1-custom-nova-helm-overrides.yaml - │ ├── region2 - │ │ ├── inventory - │ │ │ ├── -inventory.yaml - │ │ ├── helm-configs - │ │ │ ├── nova - │ │ │ │ ├── region2-custom-nova-helm-overrides.yaml - └── .gitignore - ``` - -The above example is just that and is kept short just to give an idea of what we'll be working with. You may have many additional openstack services you need to override and may decided to adjust the structure in your own way as needed. - -The inventory noted above is what's used to deploy genestack infrastructure and bootstrapping and is also specific to the region so we'll want to maitain that in a similar fashion to our custom helm configs. -For our needs here we can copy the example found in `/opt/genestack/ansible/inventory/inventory.yaml.example`. - -#### Create a repo - -If you have yet to do so, create a github repository, we'll call it `my-genestack-configs` for this example. We are creating a repo in order to better maintain and version control our custom changes. - -See [Create a repo](https://docs.github.com/en/repositories/creating-and-managing-repositories/quickstart-for-repositories) for more information. - -!!! tip - You may opt to not create a repo and simply keep it local but the directory structure and workflow will be the same for this example - -With the repo created and cloned to somewhere like `/opt/my-genestack-configs` we can then create the directory structure as noted above and add our custom helm overrides. - -#### Creating custom overrides - -We're going to keep the examples very simple but just about everything found in the base-helm-configs can be overriden as you see fit. -For our example we just want to override the cpu_allocation as they are different between the two regions. - -Create the override files within the respective structure as noted above with the contents of: - -!!! example "region1-custom-nova-helm-overrides.yaml" - ``` - conf: - nova: - DEFAULT: - cpu_allocation_ratio: 8.0 - ``` - -!!! example "region2-custom-nova-helm-overrides.yaml" - ``` - conf: - nova: - DEFAULT: - cpu_allocation_ratio: 4.0 - ``` - -We now have the directory structure and override files needed so now we can run our helm upgrades! - -#### Symlink our repo - -Before we run the helm commands we'd like to make things a bit cleaner and also compatible with ansible/kubespray bootstrapping and infrastructure installation. -To do that, we'll simply symlink our regional named directory that we created above to `/etc/genestack`. - -For the rest of the workflow example we'll be working with the `sjc` environment. The same instructions would apply for the different regions. - -!!! example "symlink the repo" - ``` shell - ln -s /opt/my-genestack-configs/region1 /etc/genestack - ``` - -This will make our `/etc/genestack` directory look like: - -!!! example "/etc/genestack/" - ``` - ├── inventory - │ │ ├── inventory.yaml - ├── helm-configs - │ ├── nova - │ │ ├── region1-custom-nova-helm-overrides.yaml - ``` - -#### Running helm - -These instructions apply to all the openstack services, we are focusing on nova here. In our deployment guide we can find [compute kit installation](openstack-compute-kit.md). - -Everything there will be reused, especially if we haven't set things up prior, the difference for this multi-region workflow example is that we'll be adding an additional override file to the command. - -Looking at [Deploy Nova](openstack-compute-kit.md) in the compute kit installation documentation we see the `helm upgrade` command. You'll notice it has a single `-f` flag pointing to our `base-helm-configs` at `-f /etc/genestack/helm-configs/nova/nova-helm-overrides.yaml`. -We're going to simply add another `-f` flag below that one to include our overrides. Helm will see this and apply the values in order in the arguments. In otherwords, the second `-f` flag will override anything provided in the first. - -So, our helm command that we'll run against sjc will now look like: - -``` shell -/opt/genestack/bin/install-nova.sh -f /etc/genestack/helm-configs/nova/region1-nova-helm-overrides.yaml -``` - -Like mentioned above the only difference here is the additional flag to include our custom override and that's it, we can now version custom changes while maintaining upstream parity across many regions and/or staging envorinments! - -## Wrap-up - -This is a simple example workflow to handle multi-region deployments and may not work for every case please adjust anything in this example as you see fit and keep on stacking! diff --git a/docs/observability-info.md b/docs/observability-info.md deleted file mode 100644 index e21163f58..000000000 --- a/docs/observability-info.md +++ /dev/null @@ -1,105 +0,0 @@ -# Genestack Observability - -Genestack is made up of a vast array of components working away to provide a Kubernetes and OpenStack cloud infrastructure -to serve our needs. Here we'll discuss in a bit more detail about how we observe and visualize our Genestack operations. - -## Overview - -In this document we'll dive a bit deeper into Genestack observability by exploring the tooling deployed as part of the Genestack workflow that helps us monitor, alert, log and visualize metrics of our Genestack environment. - -Observability is often described as the ability to gather data about complex systems via monitoring, logging and performance metrics to better understand the state of the system as a whole. -In modern systems, especially cloud computing, where there are many components and various services distributed across clusters and even regions observability plays a crucial role toward maintaining performance reliability and even security of your systems. -With a robust observability platform complex systems become manageable and provides various stakeholders the tools needed to forecast and predict potential issues before they arise, resolve and discover root cause of problems that do arise and provide better means of analyzing the health and growth of their environments. - -Observability components used in Genestack that we'll discuss a bit further are as follows: - - * Fluentbit and Loki - * Log collection and aggregation - * Prometheus - * Systems monitoring - * Alert Manager - * Alert aggregator and notification router - * Grafana - * Visualization platform - -## Logging - -Logging is key to better understanding the health and performance of your systems. Logging gives insights into system events, errors and even security concerns. -Logging in Genestack as part of its default workflow is handled by [Fluentbit](https://fluentbit.io/) and [Loki](https://grafana.com/oss/loki/) which takes care of collection, processing and aggregation of Genestack's system and service logs. -You can view the [Fluentbit](https://github.com/rackerlabs/genestack/tree/main/base-helm-configs/fluentbit) and [Loki](infrastructure-loki.md) installation docs to get an idea of how we're deploying it in the Genestack infrastructure. -You can view their source code at [Fluentbit Github](https://github.com/fluent/fluent-bit) and [Loki Github](https://github.com/grafana/loki/tree/main). - -Fluentbit is deployed as the log collector, processor and forwarder. It is configured and deployed across the system to gather logs from Kubernetes pods and the various OpenStack services. -Once collected and processed it then forwards, or ships the logs off for consumption to Loki. Loki can then take care of long term storage as well as handling log accessability. -Loki can tag and label the logs for easy lookup using Loki [LogQL](https://grafana.com/docs/loki/latest/query/). - -The logs can be queried via a [logcli](https://grafana.com/docs/loki/latest/query/logcli/) command line tool for lookups or as a [Loki Datasource](https://grafana.com/docs/grafana/latest/datasources/loki/) in Grafana. - -An example that we use in our [project lookup](https://github.com/rackerlabs/genestack/blob/main/etc/grafana-dashboards/project_lookup.json) dashboard that allows us to query the logs for a specific service and project_id would look something like below. -!!! example "Example LokiQL lookup query" - - ```shell - {application="$service"} | logfmt | json | line_format "{{ .kubernetes_host}} {{.kubernetes_pod_name}} {{.log}}" |= `$project_id` - ``` -We can do something similar using the [logcli](https://grafana.com/docs/loki/latest/query/logcli/). - -!!! example "Example logcli lookup query" - - ```shell - logcli-parallel --since=15m '{application=~"nova|placement"} |~ ``' | jq -r '.log' - ``` -You can view more information about logging in Genestack at the [Logging Overview](genestack-logging.md) documentation page. - -## Monitoring and Alerting with Prometheus - -Monitoring and alerting are two crucial components for observability within the Genestack infrastructure. -By default, in Genestack we make use of Prometheus, an open-source monitoring system with a dimensional data model, flexible query language, efficient time series database and modern alerting approach. -As well as the AlertManager, a tooling that provides alert aggregation, grouping, deduplication and notification routing, which is conveniently packaged together with Prometheus in the [kube-prometheus-stack](https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack) for easy installation and configuration. -Prometheus and the related components fits Genestack open-source ethos and is easily integrated into Kubernetes and OpenStack systems and services. With easy means of installation, service discovery and configuration Prometheus is a top tier choice for the Genestack platform. - -The below diagram shows how all these monitoring and alerting components tie together: -![Prometheus Architecture](assets/images/prometheus-architecture.png) - -We have covered Prometheus, Prometheus alerting and the AlertManager in greater detail in the [Monitoring](monitoring-info.md) and [Alerting](alerting-info.md) documentation. - -## Visualization - -Now that we have the logging, monitoring, metrics and alerting portions of our observability platform mapped out we need a way to visualize all this data being provided. -For that we use [Grafana](https://grafana.com/) as our default visualization platform in Genestack. Grafana is an open-sourced, feature rich and highly pluggable visualization system that aligns well with Genestack. -Prometheus, Alertmanager and even Loki can easily plug right in and integrate with Grafana so that we can build out the visualization layer of our observability platform. - -As noted in the [Prometheus Alerting](alerting-info.md) documentation we can configure alerts via Prometheus configurations and alert on any metric collected. -It's also possible to set up alerting through Grafana, see Grafana's [alerting docs](https://grafana.com/docs/grafana/latest/alerting/) for more details. - -This comes in handy in the context of Loki and logs. Grafana with the [Loki datasource](https://grafana.com/docs/grafana/latest/datasources/loki/) allows us to configure alerts based on logging queries and the information returned. -One example in Genestack would be the [OVN Claimstorm alerts](ovn-alert-claim-storm.md). Below we can see an example of how this is configured. -![ovn claimstore alert](assets/images/loki-alerting-rules-example.png) - -As noted above we can also use Loki and Grafana to display logs for our services. The following example and image shows what that would look like. -An example that we use in our [project lookup](https://github.com/rackerlabs/genestack/blob/main/etc/grafana-dashboards/project_lookup.json) dashboard that allows us to query the logs for a specific service and project_id would look something like below. -!!! example "Example LokiQL lookup query" - - ```shell - {application="$service"} | logfmt | json | line_format "{{ .kubernetes_host}} {{.kubernetes_pod_name}} {{.log}}" |= `$project_id` - ``` -![project lookup example](assets/images/project-lookup-example.png) - -For additional information view the [Grafana](monitoring-info.md#visualization) portion of the [Monitoring Info](monitoring-info.md) documentation. - -## Datadog - -Fluentbit, Loki and Grafana makes for a powerful combination of log collection, aggregation and visualization and while these tools and the related components are the default choice in a Genestack deployment there are other solutions that may better suit your needs. -Genestack offers examples and basic configurations to deploy Grafana, Loki, Prometheus, etc... in a self-hosted and self-maintained manner which requires effort and costs to host and maintain the observability platfom and to store the logs. -This may not always be desirable and in such case something like [Datadog](https://www.datadoghq.com/) may be preferred to allieviate some of the burdens of hosting these solutions yourself. - -[Datadog](https://www.datadoghq.com/) offers many of the features we've discussed in this documentation and much more via agents that you install and configure within your systems. - -Datadog can work as a replacement or with our existing tools to form a hybrid approach for our observability platform. -There are plugins and agents that give you the flexibility you may desire. For example, [Fluentbit plugin](https://docs.datadoghq.com/integrations/fluentbit/) can act as the log collection service while instead of using the [Datadog logging agents](https://docs.datadoghq.com/containers/kubernetes/log/?tab=datadogoperator). -You can also use the [Prometheus Datadog plugins](https://docs.datadoghq.com/integrations/guide/prometheus-host-collection/) to provide additional metrics as you see fit. - -An example of installing Datadog in [Rackspace Flex](https://www.rackspace.com/resources/rackspace-openstack-flex) can be found in the [Running Datadog on OpenStack Flex](https://blog.rackspacecloud.com/blog/2024/11/12/running_datadog_on_openstack-flex/#deploying-datadog-on-our-openstack-flex-server) blog post. -Integrating Datadog in your Genestack installation is just as simple and can be accommplished by installing various agents to fit your goals. -View the [Datadog Kubernetes](https://docs.datadoghq.com/containers/kubernetes/installation/?tab=datadogoperator) installation instructions for more information. - -While Genestack provides a relatively comprehensive set of tooling and instructions for a production grade Kubernetes and OpenStack deployment, Datadog may be the right solution for your needs if you desire a little less hands on solution to your observability platform. diff --git a/docs/octavia-flavor-and-flavorprofile-guide.md b/docs/octavia-flavor-and-flavorprofile-guide.md deleted file mode 100644 index cef939189..000000000 --- a/docs/octavia-flavor-and-flavorprofile-guide.md +++ /dev/null @@ -1,122 +0,0 @@ -# Octavia Flavors - -This document is intended for users who want to use the command line interface (CLI) to create and manage Octavia flavors and flavor profiles for load balancing. Flavor profiles define specific configurations for the Octavia load balancer, allowing users to select from predefined flavors that match provider capabilities. This guide walks you through the process of creating and updating both flavors and flavor profiles. For instructions on creating other resources such as load balancers, listeners, monitors, and pools, please refer to the [Octavia CLI Load Balancer Setup Guide](https://docs.rackspacecloud.com/octavia-loadbalancer-setup-guide/) - -## Provider Capabilities - -To define a flavor, review the flavor capabilities exposed by the provider driver. Below providers already exist: -``` shell -$ openstack --os-cloud default loadbalancer provider list -+---------+------------------------------+ -| name | description | -+---------+------------------------------+ -| ovn | "The Octavia OVN driver" | -| amphora | "The Octavia Amphora driver" | -+---------+------------------------------+ -``` - -The following command lists all the available flavor capabilities in the Amphora provider. -``` shell -$ openstack --os-cloud default loadbalancer provider capability list amphora -+-------------------+-----------------------+--------------------------------------------------------------------------------------------------------------------------------------+ -| type | name | description | -+-------------------+-----------------------+--------------------------------------------------------------------------------------------------------------------------------------+ -| flavor | loadbalancer_topology | The load balancer topology. One of: SINGLE - One amphora per load balancer. ACTIVE_STANDBY - Two amphora per load balancer. | -| flavor | compute_flavor | The compute driver flavor ID. | -| flavor | amp_image_tag | The amphora image tag. | -| flavor | sriov_vip | When true, the VIP port will be created using an SR-IOV VF port. | -| availability_zone | compute_zone | The compute availability zone. | -| availability_zone | management_network | The management network ID for the amphora. | -| availability_zone | valid_vip_networks | List of network IDs that are allowed for VIP use. This overrides/replaces the list of allowed networks configured in `octavia.conf`. | -+-------------------+-----------------------+--------------------------------------------------------------------------------------------------------------------------------------+ -``` - -## Flavor Profiles - -To define a flavor profile, you specify both the provider and the flavor data, outlining the supported flavor settings for that provider. If you do not include the provider flag, the system will use the default provider, which is Amphora at Rackspace. Use the command below to create a flavor profile for the Amphora provider, setting up a load balancer with a single Amphora and the specified compute flavor. The compute_flavor in flavor_data defines the resources (CPU, RAM, disk) allocated to the Amphora VMs or containers, determining the size and performance of the load balancer instances. - -``` shell -$ openstack --os-cloud default loadbalancer flavorprofile create --name fp.single.lite --provider amphora --flavor-data '{"loadbalancer_topology": "SINGLE", "compute_flavor": "f485b7c3-4efd-4c0d-b8b0-997db6bdbbce"}' -+---------------+-----------------------------------------------------------------------------------------------+ -| Field | Value | -+---------------+-----------------------------------------------------------------------------------------------+ -| id | 5f4d2c7c-e294-4a9c-b97a-54a2b97a17a5 | -| name | fp.single.lite | -| provider_name | amphora | -| flavor_data | {"loadbalancer_topology": "SINGLE", "compute_flavor": "f485b7c3-4efd-4c0d-b8b0-997db6bdbbce"} | -+---------------+-----------------------------------------------------------------------------------------------+ -``` - -Use the command below to list the existing flavor profiles: -``` shell -$ openstack loadbalancer flavorprofile list -+--------------------------------------+----------------+---------------+ -| id | name | provider_name | -+--------------------------------------+----------------+---------------+ -| 5f4d2c7c-e294-4a9c-b97a-54a2b97a17a5 | fp.single.lite | amphora | -| 66244e86-c714-4e80-a250-997d414db9d9 | fp.ha.plus | amphora | -| a252f357-bd8e-4551-a40c-f98ac857d2f8 | fp.single.pro | amphora | -| bea6924c-59d6-42a2-9336-df726ab0bfdf | fp.single.plus | amphora | -| cfa628f1-2916-419c-876e-7b2d56643323 | fp.ha.lite | amphora | -| dc6186a0-82fc-4694-b521-50065ae26516 | fp.ha.pro | amphora | -+--------------------------------------+----------------+---------------+ -``` - -### Update a Flavor Profile - -To update a flavor profile, use the `openstack loadbalancer flavorprofile set` command. This allows you to modify properties of an existing flavor profile, such as its name, provider, and flavor data. -``` shell -$ openstack loadbalancer flavorprofile set --flavor-data '{"loadbalancer_topology": "ACTIVE_STANDBY"}' 5f4d2c7c-e294-4a9c-b97a-54a2b97a17a5 -``` - -You can extend the flavor profile with additional provider capabilities as needed. Below is an example: -``` shell -$ openstack loadbalancer flavorprofile set --flavor-data '{"loadbalancer_topology": "ACTIVE_STANDBY", "amp_image_tag": "amphora-image-v2", "sriov_vip": false}' 5f4d2c7c-e294-4a9c-b97a-54a2b97a17a5 -``` - -!!! note "Loadbalancer Topologies" - - The `loadbalancer_topology` field in the flavor data specifies the number of Amphora instances per - load balancer. The possible values are: - - - `SINGLE`: One Amphora per load balancer. - - `ACTIVE_STANDBY`: Two Amphora per load balancer. - -## Flavors - -To create a flavor using the previously defined flavor profile, run the following command: -``` shell -$ openstack loadbalancer flavor create --name single.lite --flavorprofile fp.single.lite --description "single amphora, 1 vcpu, 1024 ram, 10 disk" --enable -+-------------------+-------------------------------------------+ -| Field | Value | -+-------------------+-------------------------------------------+ -| id | 3480b6d0-b803-4373-b701-53420d895059 | -| name | single.lite | -| flavor_profile_id | 5f4d2c7c-e294-4a9c-b97a-54a2b97a17a5 | -| enabled | True | -| description | single amphora, 1 vcpu, 1024 ram, 10 disk | -+-------------------+-------------------------------------------+ -``` -At this point, the flavor is available for use by users creating new load balancers. - -Use the command below to list the existing flavors: -``` shell -$ openstack loadbalancer flavor list -+--------------------------------------+-------------+--------------------------------------+---------+ -| id | name | flavor_profile_id | enabled | -+--------------------------------------+-------------+--------------------------------------+---------+ -| 3480b6d0-b803-4373-b701-53420d895059 | single.lite | 5f4d2c7c-e294-4a9c-b97a-54a2b97a17a5 | True | -| 351d67c3-796f-4f41-bbb9-6d8d6bc389a8 | ha.plus | 66244e86-c714-4e80-a250-997d414db9d9 | True | -| 63a2533d-ec47-4dc8-b04c-e4c9fd55b6e9 | single.plus | bea6924c-59d6-42a2-9336-df726ab0bfdf | True | -| 81c4307b-e66c-4c0c-a177-c971951020d3 | ha.pro | dc6186a0-82fc-4694-b521-50065ae26516 | True | -| eb107a33-71ae-45a3-941a-05bbe84d33df | single.pro | a252f357-bd8e-4551-a40c-f98ac857d2f8 | True | -| f37c3e03-bb8f-4b3a-956c-e45a9c611319 | ha.lite | cfa628f1-2916-419c-876e-7b2d56643323 | True | -+--------------------------------------+-------------+--------------------------------------+---------+ -``` - -### Update a Flavor - -The `openstack loadbalancer flavor set` command updates an existing load balancer flavor, allowing you to modify attributes like name, description, or status. To disable a flavor, use the following command: -``` shell -$ openstack loadbalancer flavor set --disable 3480b6d0-b803-4373-b701-53420d895059 -``` diff --git a/docs/octavia-loadbalancer-setup-guide.md b/docs/octavia-loadbalancer-setup-guide.md deleted file mode 100644 index adca7e121..000000000 --- a/docs/octavia-loadbalancer-setup-guide.md +++ /dev/null @@ -1,276 +0,0 @@ -# Octavia CLI Load Balancer Setup Guide - -This document is intended for users who want to use the command line interface (CLI) to create/deploy a Cloud Load Balancer (CLB). At Rackspace Technology, the default provider is Amphora. Using the CLI is the only way to specify OVN as the provider instead of Amphora. These instructions will help provide the necessary information to create a load balancer, listener, monitor, and pool. This document assumes you are already familiar with creating/managing vms, networks, routers, and security groups and it assumes you already have this created. - -!!! note - - At Rackspace Technology, you are not allowed to attach directly to the Public Network. You will need to assign a floating IP to your CLB if you would like to make it publicly accessible. - - -## Choose the provider - -Rackspace Technology provides two options for your CLB, Amphora and OVN. Each has it's own benefits. - -| | Amphora | OVN | -| --- | --- | --- | -| Maturity | More mature | Not as mature | -| Features | L7 policies, SSL termination | does not support L7 policies or SSL termination | -| HA | yes | no | -| Resources | uses additional vms; can be slow to deploy | uses OVN; fast to deploy | -| Performance | good | better | -| Algorithms | Round Robin
Least Connections
Source IP
Source IP Port | Round Robin
Source IP Port | - -## Create the load balancer - -If you do not pass the provider flag, it will use the default. At Rackspace Technology, we default to amphora. You can check the available providers using the following command: - -``` shell -$ openstack --os-cloud default loadbalancer provider list -+---------+------------------------------+ -| name | description | -+---------+------------------------------+ -| ovn | "The Octavia OVN driver" | -| amphora | "The Octavia Amphora driver" | -+---------+------------------------------+ -``` - -If using the amphora provider, you can also select the type/flavor of load balancer. The default at Rackspace Technology for amphora is `ha.plus`. OVN does NOT use these flavors. To see your options use the following command: - -``` shell -$ openstack --os-cloud default loadbalancer flavor list -+--------------------------------------+-------------+--------------------------------------+---------+ -| id | name | flavor_profile_id | enabled | -+--------------------------------------+-------------+--------------------------------------+---------+ -| 3480b6d0-b803-4373-b701-53420d895059 | single.lite | 5f4d2c7c-e294-4a9c-b97a-54a2b97a17a5 | True | -| 351d67c3-796f-4f41-bbb9-6d8d6bc389a8 | ha.plus | 66244e86-c714-4e80-a250-997d414db9d9 | True | -| 63a2533d-ec47-4dc8-b04c-e4c9fd55b6e9 | single.plus | bea6924c-59d6-42a2-9336-df726ab0bfdf | True | -| 81c4307b-e66c-4c0c-a177-c971951020d3 | ha.pro | dc6186a0-82fc-4694-b521-50065ae26516 | True | -| eb107a33-71ae-45a3-941a-05bbe84d33df | single.pro | a252f357-bd8e-4551-a40c-f98ac857d2f8 | True | -| f37c3e03-bb8f-4b3a-956c-e45a9c611319 | ha.lite | cfa628f1-2916-419c-876e-7b2d56643323 | True | -+--------------------------------------+-------------+--------------------------------------+---------+ -``` - -Use the following command to create the load balancer. The name and description flags are optional, but if you do not use the name flag, you will need to reference it by id later. - -``` shell -$ openstack --os-cloud default loadbalancer create --name OVN-Test --vip-subnet-id CLB-SUBNET-TEST --provider ovn -+---------------------+--------------------------------------+ -| Field | Value | -+---------------------+--------------------------------------+ -| admin_state_up | True | -| availability_zone | az1 | -| created_at | 2024-08-30T17:48:46 | -| description | | -| flavor_id | None | -| id | 10339382-2024-4631-a8d2-681548120505 | -| listeners | | -| name | OVN-Test | -| operating_status | OFFLINE | -| pools | | -| project_id | 9e822f3bce56475787f3000aa4ef89e6 | -| provider | ovn | -| provisioning_status | PENDING_CREATE | -| updated_at | None | -| vip_address | 192.168.32.214 | -| vip_network_id | 1a602d99-71a2-48f1-b8af-319235ebc473 | -| vip_port_id | 38c74c73-bc3f-430e-b663-d419ce7be4e6 | -| vip_qos_policy_id | None | -| vip_subnet_id | 5e1f5e82-952e-4e8a-bf1b-32dd832569a5 | -| vip_vnic_type | normal | -| tags | | -| additional_vips | [] | -+---------------------+--------------------------------------+ - -$ openstack --os-cloud default loadbalancer list -+--------------------------------------+----------+----------------------------------+----------------+---------------------+------------------+----------+ -| id | name | project_id | vip_address | provisioning_status | operating_status | provider | -+--------------------------------------+----------+----------------------------------+----------------+---------------------+------------------+----------+ -| 10339382-2024-4631-a8d2-681548120505 | OVN-Test | 9e822f3bce56475787f3000aa4ef89e6 | 192.168.32.214 | ACTIVE | ONLINE | ovn | -+--------------------------------------+----------+----------------------------------+----------------+---------------------+------------------+----------+ -``` - -If you used amphora as the provider, it may take a few minutes before the provisioning_status is active. - - -## Create the listener - -``` shell -$ openstack --os-cloud default loadbalancer listener create --protocol TCP --protocol-port 80 --name HTTP-listener OVN-Test -+-----------------------------+--------------------------------------+ -| Field | Value | -+-----------------------------+--------------------------------------+ -| admin_state_up | True | -| connection_limit | -1 | -| created_at | 2024-08-30T17:55:35 | -| default_pool_id | None | -| default_tls_container_ref | None | -| description | | -| id | 0fad0e34-e87f-4c1a-ad4b-1faa168fe97f | -| insert_headers | None | -| l7policies | | -| loadbalancers | 10339382-2024-4631-a8d2-681548120505 | -| name | HTTP-listener | -| operating_status | OFFLINE | -| project_id | 9e822f3bce56475787f3000aa4ef89e6 | -| protocol | TCP | -| protocol_port | 80 | -| provisioning_status | PENDING_CREATE | -| sni_container_refs | [] | -| timeout_client_data | 50000 | -| timeout_member_connect | 5000 | -| timeout_member_data | 50000 | -| timeout_tcp_inspect | 0 | -| updated_at | None | -| client_ca_tls_container_ref | None | -| client_authentication | NONE | -| client_crl_container_ref | None | -| allowed_cidrs | None | -| tls_ciphers | None | -| tls_versions | None | -| alpn_protocols | None | -| tags | | -| hsts_max_age | None | -| hsts_include_subdomains | False | -| hsts_preload | False | -+-----------------------------+--------------------------------------+ - -$ openstack --os-cloud default loadbalancer listener list -+--------------------------------------+-----------------+---------------+----------------------------------+----------+---------------+----------------+ -| id | default_pool_id | name | project_id | protocol | protocol_port | admin_state_up | -+--------------------------------------+-----------------+---------------+----------------------------------+----------+---------------+----------------+ -| 0fad0e34-e87f-4c1a-ad4b-1faa168fe97f | None | HTTP-listener | 9e822f3bce56475787f3000aa4ef89e6 | TCP | 80 | True | -+--------------------------------------+-----------------+---------------+----------------------------------+----------+---------------+----------------+ -``` - -## Create the monitor - -The monitor will check to see if the servers in your pool are responding properly (defined by your monitor). This is optional, but recommended. Originally, we did not configure a monitor and so, you may notice that the rest of the examples do not show the monitor applied. - -``` shell -$ openstack --os-cloud default loadbalancer healthmonitor create --delay 5 --max-retries 3 --timeout 5 --type TCP HTTP_POOL -+---------------------+--------------------------------------+ -| Field | Value | -+---------------------+--------------------------------------+ -| project_id | 9e822f3bce56475787f3000aa4ef89e6 | -| name | | -| admin_state_up | True | -| pools | 02b3c02e-7efa-4988-83b5-4a5b6d5d238a | -| created_at | 2024-08-30T19:57:54 | -| provisioning_status | PENDING_CREATE | -| updated_at | None | -| delay | 5 | -| expected_codes | None | -| max_retries | 3 | -| http_method | None | -| timeout | 5 | -| max_retries_down | 3 | -| url_path | None | -| type | TCP | -| id | 3edfc7a2-77ec-4dfd-93d1-a0dc9b011da8 | -| operating_status | OFFLINE | -| http_version | None | -| domain_name | None | -| tags | | -+---------------------+--------------------------------------+ - -$ openstack --os-cloud default loadbalancer healthmonitor list -+--------------------------------------+------+----------------------------------+------+----------------+ -| id | name | project_id | type | admin_state_up | -+--------------------------------------+------+----------------------------------+------+----------------+ -| 3edfc7a2-77ec-4dfd-93d1-a0dc9b011da8 | | 9e822f3bce56475787f3000aa4ef89e6 | TCP | True | -+--------------------------------------+------+----------------------------------+------+----------------+ -``` - -## Create the pool - -Here is where you will decide what load balancing algorithm to use. OVN can only use SOURCE_IP_PORT. Most common load balancer algorithms to use with amphora are ROUND_ROBIN or LEAST_CONNECTIONS. Use the help flag to see more options: `openstack --os-cloud default loadbalancer pool create --help` - -``` shell -$ openstack --os-cloud default loadbalancer pool create --protocol TCP --lb-algorithm SOURCE_IP_PORT --listener HTTP-listener --name HTTP_POOL -+----------------------+--------------------------------------+ -| Field | Value | -+----------------------+--------------------------------------+ -| admin_state_up | True | -| created_at | 2024-08-30T18:03:00 | -| description | | -| healthmonitor_id | | -| id | 02b3c02e-7efa-4988-83b5-4a5b6d5d238a | -| lb_algorithm | SOURCE_IP_PORT | -| listeners | 0fad0e34-e87f-4c1a-ad4b-1faa168fe97f | -| loadbalancers | 10339382-2024-4631-a8d2-681548120505 | -| members | | -| name | HTTP_POOL | -| operating_status | OFFLINE | -| project_id | 9e822f3bce56475787f3000aa4ef89e6 | -| protocol | TCP | -| provisioning_status | PENDING_CREATE | -| session_persistence | None | -| updated_at | None | -| tls_container_ref | None | -| ca_tls_container_ref | None | -| crl_container_ref | None | -| tls_enabled | False | -| tls_ciphers | None | -| tls_versions | None | -| tags | | -| alpn_protocols | None | -+----------------------+--------------------------------------+ - -$ openstack --os-cloud default loadbalancer pool list -+--------------------------------------+-----------+----------------------------------+---------------------+----------+----------------+----------------+ -| id | name | project_id | provisioning_status | protocol | lb_algorithm | admin_state_up | -+--------------------------------------+-----------+----------------------------------+---------------------+----------+----------------+----------------+ -| 02b3c02e-7efa-4988-83b5-4a5b6d5d238a | HTTP_POOL | 9e822f3bce56475787f3000aa4ef89e6 | ACTIVE | TCP | SOURCE_IP_PORT | True | -+--------------------------------------+-----------+----------------------------------+---------------------+----------+----------------+----------------+ -``` - -## Add the servers to the pool - -First, get the IPs of the servers you would like to add to the pool: - -``` shell -$ openstack --os-cloud default server list | grep OVN -| 1d0353e0-d82c-4954-b849-2f4e858e372e | OVN-CLB-2 | ACTIVE | CLB-TEST=192.168.32.87 | Ubuntu-20.04 | gp.0.1.2 | -| d97a3662-7def-4eb5-b047-db8da8f74f5c | OVN-CLB-3 | ACTIVE | CLB-TEST=192.168.32.124 | Ubuntu-20.04 | gp.0.1.2 | -| 031e0b95-4b4f-46f7-8e42-3ce9039b431c | OVN-CLB-1 | ACTIVE | CLB-TEST=192.168.32.175 | Ubuntu-20.04 | gp.0.1.2 | -``` - -Add the servers using the IP address: - -``` shell -$ openstack --os-cloud default loadbalancer member create --address 192.168.32.175 --protocol-port 80 --name SERVER1 HTTP_POOL -$ openstack --os-cloud default loadbalancer member create --address 192.168.32.87 --protocol-port 80 --name SERVER2 HTTP_POOL -$ openstack --os-cloud default loadbalancer member create --address 192.168.32.124 --protocol-port 80 --name SERVER3 HTTP_POOL - -$ openstack --os-cloud default loadbalancer member list HTTP_POOL -+--------------------------------------+---------+----------------------------------+---------------------+----------------+---------------+------------------+--------+ -| id | name | project_id | provisioning_status | address | protocol_port | operating_status | weight | -+--------------------------------------+---------+----------------------------------+---------------------+----------------+---------------+------------------+--------+ -| 44436497-7ac9-4a53-bb3c-7e883331cd93 | SERVER1 | 9e822f3bce56475787f3000aa4ef89e6 | ACTIVE | 192.168.32.175 | 80 | NO_MONITOR | 1 | -| be484beb-583b-488f-85b9-dc57d0522a9f | SERVER2 | 9e822f3bce56475787f3000aa4ef89e6 | ACTIVE | 192.168.32.87 | 80 | NO_MONITOR | 1 | -| d4ac7f15-8bd9-4fd9-be83-3a071f9774f9 | SERVER3 | 9e822f3bce56475787f3000aa4ef89e6 | ACTIVE | 192.168.32.124 | 80 | NO_MONITOR | 1 | -+--------------------------------------+---------+----------------------------------+---------------------+----------------+---------------+------------------+--------+ -``` - - -## OPTIONAL: Associate a floating IP - -If you want to make the load balancer publically accessible, you will need to associate a floating IP to it. First get a list of your available floating IPs: - -``` shell -$ openstack --os-cloud default floating ip list | grep None -| 753914ad-31b8-44eb-9ad7-cb9d75b81b58 | 65.17.X.X | None | None | 723f8fa2-dbf7-4cec-8d5f-017e62c12f79 | 9e822f3bce56475787f3000aa4ef89e6 | -``` - -You will also need to know the port id of your load balancer: - -``` shell -$ openstack --os-cloud default loadbalancer show OVN-Test | grep vip_port_id -| vip_port_id | 38c74c73-bc3f-430e-b663-d419ce7be4e6 | -``` - -With both of these pieces of information, you can associate your floating IP: - -``` shell -openstack --os-cloud default floating ip set --port 38c74c73-bc3f-430e-b663-d419ce7be4e6 65.17.X.X -``` diff --git a/docs/openstack-barbican.md b/docs/openstack-barbican.md deleted file mode 100644 index fa81b5358..000000000 --- a/docs/openstack-barbican.md +++ /dev/null @@ -1,59 +0,0 @@ -# Deploy Barbican - -OpenStack Barbican is the dedicated security service within the OpenStack ecosystem, focused on the secure storage, management, and provisioning of sensitive data such as encryption keys, certificates, and passwords. Barbican plays a crucial role in enhancing the security posture of cloud environments by providing a centralized and controlled repository for cryptographic secrets, ensuring that sensitive information is protected and accessible only to authorized services and users. It integrates seamlessly with other OpenStack services to offer encryption and secure key management capabilities, which are essential for maintaining data confidentiality and integrity. In this document, we will explore the deployment of OpenStack Barbican using Genestack. With Genestack, the deployment of Barbican is optimized, ensuring that cloud infrastructures are equipped with strong and scalable security measures for managing critical secrets. - -## Create secrets - -!!! note "Information about the secretes used" - - Manual secret generation is only required if you haven't run the `create-secrets.sh` script located in `/opt/genestack/bin`. - - ??? example "Example secret generation" - - ``` shell - kubectl --namespace openstack \ - create secret generic barbican-rabbitmq-password \ - --type Opaque \ - --from-literal=username="barbican" \ - --from-literal=password="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-64};echo;)" - kubectl --namespace openstack \ - create secret generic barbican-db-password \ - --type Opaque \ - --from-literal=password="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-32};echo;)" - kubectl --namespace openstack \ - create secret generic barbican-admin \ - --type Opaque \ - --from-literal=password="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-32};echo;)" - ``` - -## Setup Barbican Overrides - -When deploying barbican, it is important to provide the necessary configuration values to ensure that the service is properly -configured and integrated with other OpenStack services. The `/etc/genestack/helm-configs/barbican/barbican-helm-overrides.yaml` -file contains the necessary configuration values for Barbican, including database connection details, RabbitMQ credentials, and other -service-specific settings. By providing these values, you can customize the deployment of Barbican to meet your specific requirements -and ensure that the service operates correctly within your OpenStack environment. - -!!! tip "Set the `host_href` value" - - The `host_href` value should be set to the public endpoint of the Barbican service. This value is used by other OpenStack services and public consumers to communicate with Barbican and should be accessible from all OpenStack services. - - ``` yaml - conf: - barbican: - DEFAULT: - host_href: "https://barbican.your.domain.tld" - ``` - -## Run the package deployment - -!!! example "Run the Barbican deployment Script `bin/install-barbican.sh`" - - ``` shell - --8<-- "bin/install-barbican.sh" - ``` - -!!! tip - - You may need to provide custom values to configure your openstack services, for a simple single region or lab deployment you can supply an additional overrides flag using the example found at `base-helm-configs/aio-example-openstack-overrides.yaml`. - In other cases such as a multi-region deployment you may want to view the [Multi-Region Support](multi-region-support.md) guide to for a workflow solution. diff --git a/docs/openstack-ceilometer.md b/docs/openstack-ceilometer.md deleted file mode 100644 index e64c8ae2c..000000000 --- a/docs/openstack-ceilometer.md +++ /dev/null @@ -1,70 +0,0 @@ -# Deploy Ceilometer - -OpenStack Ceilometer is the telemetry service within the OpenStack ecosystem, responsible for collecting and delivering usage data across various OpenStack services. Ceilometer plays a critical role in monitoring and metering the performance and resource consumption of cloud infrastructure, providing essential data for billing, benchmarking, and operational insights. By aggregating metrics such as CPU usage, network bandwidth, and storage consumption, Ceilometer enables cloud operators to track resource usage, optimize performance, and ensure compliance with service-level agreements. In this document, we will discuss the deployment of OpenStack Ceilometer using Genestack. With Genestack, the deployment of Ceilometer is made more efficient, ensuring that comprehensive and reliable telemetry data is available to support the effective management and optimization of cloud resources. - -## Create Secrets - -!!! note "Information about the secretes used" - - Manual secret generation is only required if you haven't run the `create-secrets.sh` script located in `/opt/genestack/bin`. - - ??? example "Example secret generation" - - ``` shell - kubectl --namespace openstack create secret generic ceilometer-keystone-admin-password \ - --type Opaque \ - --from-literal=password="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-32};echo;)" - kubectl --namespace openstack create secret generic ceilometer-keystone-test-password \ - --type Opaque \ - --from-literal=password="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-32};echo;)" - kubectl --namespace openstack create secret generic ceilometer-rabbitmq-password \ - --type Opaque \ - --from-literal=password="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-32};echo;)" - ``` - -## Run the package deployment - -!!! example "Run the Ceilometer deployment Script `bin/install-ceilometer.sh`" - - ``` shell - --8<-- "bin/install-ceilometer.sh" - ``` - -!!! tip - - You may need to provide custom values to configure your openstack services, for a simple single region or lab deployment you can supply an additional overrides flag using the example found at `base-helm-configs/aio-example-openstack-overrides.yaml`. - In other cases such as a multi-region deployment you may want to view the [Multi-Region Support](multi-region-support.md) guide to for a workflow solution. - -## Verify Ceilometer Workers - -As there is no Ceilometer API, we will do a quick validation against the -Gnocchi API via a series of `openstack metric` commands to confirm that -Ceilometer workers are ingesting metric and event data then persisting them -storage. - -### Verify metric resource types exist - -The Ceilomter db-sync job will create the various resource types in Gnocchi. -Without them, metrics can't be stored, so let's verify they exist. The -output should include named resource types and some attributes for resources -like `instance`, `instance_disk`, `network`, `volume`, etc. - -``` shell -kubectl exec -it openstack-admin-client -n openstack -- openstack metric resource-type list -``` - -### Verify metric resources - -Confirm that resources are populating in Gnocchi - -``` shell -kubectl exec -it openstack-admin-client -n openstack -- openstack metric resource list -``` - -### Verify metrics - -Confirm that metrics can be retrieved from Gnocchi - -``` shell -kubectl exec -it openstack-admin-client -n openstack -- openstack metric list -``` diff --git a/docs/openstack-cinder-fips-encryption.md b/docs/openstack-cinder-fips-encryption.md deleted file mode 100644 index 71e78ecf4..000000000 --- a/docs/openstack-cinder-fips-encryption.md +++ /dev/null @@ -1,148 +0,0 @@ -# FIPS Enabled Cinder Storage (LUKS) - -!!! note - - Genestack ships with Barbican key manager enabled by default for Cinder and Nova services. No further configuration is needed. - -??? warning "LUKS encrypted volumes are currently only supported in iSCSI workloads." - Ceph RBD is needs additional testing. NFS backed Cinder volumes are known not to work:" - - * https://review.opendev.org/c/openstack/cinder/+/597148 - * https://review.opendev.org/c/openstack/cinder/+/749155 - * https://bugs.launchpad.net/nova/+bug/1987311 - * https://review.opendev.org/c/openstack/nova/+/854030 - -To create a FIPS enabled Cinder front end to be consumed by clients the folllowing command is run: - -!!! note - - These set of commands is ran against our standard LVM iSCSI deployment covered in [Genestack Cinder LVM iSCSI](https://docs.rackspacecloud.com/openstack-cinder-lvmisci/) With modified commands to be run after cinder service is deployed on your storage nodes. - -```shell -# kubectl --namespace openstack exec -ti openstack-admin-client -- openstack volume type create --encryption-provider luks \ ---encryption-cipher aes-xts-plain64 --encryption-key-size 256 \ ---encryption-control-location front-end --property volume_backend_name=LVM_iSCSI lvmdriver-1 -``` - -```shell -+-------------+-----------------------------------------------------------------------------------------------------------------------------------------------+ -| Field | Value | -+-------------+-----------------------------------------------------------------------------------------------------------------------------------------------+ -| description | None | -| encryption | cipher='aes-xts-plain64', control_location='front-end', encryption_id='766bcb86-db37-4e7b-841c-df50e5d5c069', key_size='256', provider='luks' | -| id | 66573d74-2f30-4a89-b51a-382ec6a371b6 | -| is_public | True | -| name | lvmdriver-1 | -| properties | volume_backend_name='LVM_iSCSI' | -+-------------+-----------------------------------------------------------------------------------------------------------------------------------------------+ -``` - -Verify functionality of encrypted volume - -```shell -kubectl --namespace openstack exec -ti openstack-admin-client -- openstack volume create --size 1 test -``` - -```shell -+---------------------+--------------------------------------+ -| Field | Value | -+---------------------+--------------------------------------+ -| attachments | [] | -| availability_zone | az1 | -| bootable | false | -| consistencygroup_id | None | -| created_at | 2024-10-17T20:01:19.233106 | -| description | None | -| encrypted | True | -| id | 7b2a9061-bcb8-46d2-8b20-ecc70b35da7d | -| migration_status | None | -| multiattach | False | -| name | test | -| properties | | -| replication_status | None | -| size | 1 | -| snapshot_id | None | -| source_volid | None | -| status | creating | -| type | lvmdriver-1 | -| updated_at | None | -| user_id | 70ac20d4fa234a67bed220f80cef1cb6 | -+---------------------+--------------------------------------+ -``` - -Verify encryption field after volume is created: - -```shell -# kubectl --namespace openstack exec -ti openstack-admin-client -- openstack volume show 7b2a9061-bcb8-46d2-8b20-ecc70b35da7d -+--------------------------------+---------------------------------------------------------------+ -| Field | Value | -+--------------------------------+---------------------------------------------------------------+ -| attachments | [] | -| availability_zone | az1 | -| bootable | false | -| consistencygroup_id | None | -| created_at | 2024-10-17T20:01:19.000000 | -| description | None | -| encrypted | True | -| id | 7b2a9061-bcb8-46d2-8b20-ecc70b35da7d | -| migration_status | None | -| multiattach | False | -| name | test | -| os-vol-host-attr:host | genestack-storage1.lab.underworld.local@lvmdriver-1#LVM_iSCSI | -| os-vol-mig-status-attr:migstat | None | -| os-vol-mig-status-attr:name_id | None | -| os-vol-tenant-attr:tenant_id | 2f3dd2e07f2e4a96af2f8392984e5149 | -| properties | | -| replication_status | None | -| size | 1 | -| snapshot_id | None | -| source_volid | None | -| status | available | -| type | lvmdriver-1 | -| updated_at | 2024-10-17T20:01:20.000000 | -| user_id | 70ac20d4fa234a67bed220f80cef1cb6 | -+--------------------------------+---------------------------------------------------------------+ -``` - -Extra verification, steps done on LVM iSCSI node - -```shell -root@genestack-storage1:~# lsblk -NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS -loop0 7:0 0 63.9M 1 loop /snap/core20/2105 -loop1 7:1 0 63.9M 1 loop /snap/core20/2318 -loop3 7:3 0 40.4M 1 loop /snap/snapd/20671 -loop4 7:4 0 87M 1 loop /snap/lxd/28373 -loop5 7:5 0 38.8M 1 loop /snap/snapd/21759 -loop6 7:6 0 87M 1 loop /snap/lxd/29351 -nbd0 43:0 0 0B 0 disk -nbd1 43:32 0 0B 0 disk -nbd2 43:64 0 0B 0 disk -nbd3 43:96 0 0B 0 disk -nbd4 43:128 0 0B 0 disk -nbd5 43:160 0 0B 0 disk -nbd6 43:192 0 0B 0 disk -nbd7 43:224 0 0B 0 disk -xvda 202:0 0 60G 0 disk -├─xvda1 202:1 0 59.9G 0 part / -├─xvda14 202:14 0 4M 0 part -└─xvda15 202:15 0 106M 0 part /boot/efi -xvdb 202:16 0 12M 0 disk -└─xvdb1 202:17 0 10M 0 part -xvdc 202:32 0 100G 0 disk -└─cinder--volumes--1-7b2a9061--bcb8--46d2--8b20--ecc70b35da7d 253:0 0 1G 0 lvm -nbd8 43:256 0 0B 0 disk -nbd9 43:288 0 0B 0 disk -nbd10 43:320 0 0B 0 disk -nbd11 43:352 0 0B 0 disk -nbd12 43:384 0 0B 0 disk -nbd13 43:416 0 0B 0 disk -nbd14 43:448 0 0B 0 disk -nbd15 43:480 0 0B 0 disk -root@genestack-storage1:~# dd if=/dev/mapper/cinder--volumes--1-7b2a9061--bcb8--46d2--8b20--ecc70b35da7d of=/root/verify-luks bs=1M -1024+0 records in -1024+0 records out -1073741824 bytes (1.1 GB, 1.0 GiB) copied, 4.75154 s, 226 MB/s -root@genestack-storage1:~# head /root/verify-luks -LUKS??aesxts-plain64sha256 ?76???N??_voTa?"M??}?? -``` diff --git a/docs/openstack-cinder-lvmisci.md b/docs/openstack-cinder-lvmisci.md deleted file mode 100644 index 300f1b444..000000000 --- a/docs/openstack-cinder-lvmisci.md +++ /dev/null @@ -1,294 +0,0 @@ -# Cinder LVM iSCSI Deployment - -Once the helm deployment is complete cinder and all of it's API services will be online. However, using this setup there will be -no volume node at this point. The reason volume deployments have been disabled is because we didn't expose ceph to the openstack -environment and OSH makes a lot of ceph related assumptions. For testing purposes we're wanting to run with the logical volume -driver (reference) and manage the deployment of that driver in a hybrid way. As such there's a deployment outside of our normal -K8S workflow will be needed on our volume host. - -!!! note - - The LVM volume makes the assumption that the storage node has the required volume group setup `lvmdriver-1` on the node This is not something that K8S is handling at this time. - -While cinder can run with a great many different storage backends, for the simple case we want to run with the Cinder reference -driver, which makes use of Logical Volumes. Because this driver is incompatible with a containerized work environment, we need -to run the services on our baremetal targets. Genestack has a playbook which will facilitate the installation of our services -and ensure that we've deployed everything in a working order. The playbook can be found at `playbooks/deploy-cinder-volumes-reference.yaml`. -Included in the playbooks directory is an example inventory for our cinder hosts; however, any inventory should work fine. - -## Host Setup - -The cinder target hosts need to have some basic setup run on them to make them compatible with our Logical Volume Driver. - -1. Ensure DNS is working normally. - -Assuming your storage node was also deployed as a K8S node when we did our initial Kubernetes deployment, the DNS should already be -operational for you; however, in the event you need to do some manual tweaking or if the node was note deployed as a K8S worker, then -make sure you setup the DNS resolvers correctly so that your volume service node can communicate with our cluster. - -!!! note - - This is expected to be our CoreDNS IP, in my case this is `169.254.25.10`. - -This is an example of my **systemd-resolved** conf found in `/etc/systemd/resolved.conf` -``` conf -[Resolve] -DNS=169.254.25.10 -#FallbackDNS= -Domains=openstack.svc.cluster.local svc.cluster.local cluster.local -#LLMNR=no -#MulticastDNS=no -DNSSEC=no -Cache=no-negative -#DNSStubListener=yes -``` - -Restart your DNS service after changes are made. - -``` shell -systemctl restart systemd-resolved.service -``` - -2. Volume Group `cinder-volumes-1` needs to be created, which can be done in two simple commands. - -Create the physical volume - -``` shell -pvcreate /dev/vdf -``` - -Create the volume group - -``` shell -vgcreate cinder-volumes-1 /dev/vdf -``` - -It should be noted that this setup can be tweaked and tuned to your heart's desire; additionally, you can further extend a -volume group with multiple disks. The example above is just that, an example. Check out more from the upstream docs on how -to best operate your volume groups for your specific needs. - -## Hybrid Cinder Volume deployment - -With the volume groups and DNS setup on your target hosts, it is now time to deploy the volume services. The playbook `playbooks/deploy-cinder-volumes-reference.yaml` will be used to create a release target for our python code-base and deploy systemd services -units to run the cinder-volume process. - -!!! note - - Consider the **storage** network on your Cinder hosts that will be accessible to Nova compute hosts. By default, the playbook uses `ansible_default_ipv4.address` to configure the target address, which may or may not work for your environment. Append var, i.e., `-e cinder_storage_network_interface=ansible_br_mgmt` to use the specified iface address in `cinder.conf` for `my_ip` and `target_ip_address` in `cinder/backends.conf`. **Interface names with a `-` must be entered with a `_` and be prefixed with `ansible`** - -### Example without storage network interface override - -!!! note - - When deploying with multipath, the `enable_multipath` variable must be set to `true`. this can be done on the CLI or in the inventory file. - -``` shell -ansible-playbook -i inventory-example.yaml deploy-cinder-volumes-reference.yaml -``` - -Once the playbook has finished executing, check the cinder api to verify functionality. - -``` shell -root@openstack-node-0:~# kubectl --namespace openstack exec -ti openstack-admin-client -- openstack volume service list -+------------------+--------------------------------------------+------+---------+-------+----------------------------+ -| Binary | Host | Zone | Status | State | Updated At | -+------------------+--------------------------------------------+------+---------+-------+----------------------------+ -| cinder-scheduler | cinder-volume-worker | nova | enabled | up | 2023-12-26T17:43:07.000000 | -| cinder-volume | openstack-node-4.cluster.local@lvmdriver-1 | nova | enabled | up | 2023-12-26T17:43:04.000000 | -+------------------+--------------------------------------------+------+---------+-------+----------------------------+ -``` - -!!! note - - The volume service is up and running with our `lvmdriver-1` target. - -At this point it would be a good time to define your types within cinder. For our example purposes we need to define the `lvmdriver-1` -type so that we can schedule volumes to our environment. - -``` shell -root@openstack-node-0:~# kubectl --namespace openstack exec -ti openstack-admin-client -- openstack volume type create lvmdriver-1 -+-------------+--------------------------------------+ -| Field | Value | -+-------------+--------------------------------------+ -| description | None | -| id | 6af6ade2-53ca-4260-8b79-1ba2f208c91d | -| is_public | True | -| name | lvmdriver-1 | -+-------------+--------------------------------------+ -``` - -!!! warning - - **Before** creating a volume, ensure that your volume type has been set up correctly and that you have applied QoS policies, provisioning specifications (min and max volume size), and any extra specs. See [Cinder Volume QoS Policies](openstack-cinder-volume-qos-policies.md), [Cinder Volume Provisioning Specs](openstack-cinder-volume-provisioning-specs.md), and [Cinder Volume Type Specs](openstack-cinder-volume-type-specs.md). - - -## Validate functionality - -If wanted, create a test volume to tinker with - -``` shell -root@openstack-node-0:~# kubectl --namespace openstack exec -ti openstack-admin-client -- openstack volume create --size 1 test -+---------------------+--------------------------------------+ -| Field | Value | -+---------------------+--------------------------------------+ -| attachments | [] | -| availability_zone | az1 | -| bootable | false | -| consistencygroup_id | None | -| created_at | 2023-12-26T17:46:15.639697 | -| description | None | -| encrypted | False | -| id | c744af27-fb40-4ffa-8a84-b9f44cb19b2b | -| migration_status | None | -| multiattach | False | -| name | test | -| properties | | -| replication_status | None | -| size | 1 | -| snapshot_id | None | -| source_volid | None | -| status | creating | -| type | lvmdriver-1 | -| updated_at | None | -| user_id | 2ddf90575e1846368253474789964074 | -+---------------------+--------------------------------------+ - -root@openstack-node-0:~# kubectl --namespace openstack exec -ti openstack-admin-client -- openstack volume list -+--------------------------------------+------+-----------+------+-------------+ -| ID | Name | Status | Size | Attached to | -+--------------------------------------+------+-----------+------+-------------+ -| c744af27-fb40-4ffa-8a84-b9f44cb19b2b | test | available | 1 | | -+--------------------------------------+------+-----------+------+-------------+ -``` - -You can validate the environment is operational by logging into the storage nodes to validate the LVM targets are being created. - -``` shell -root@openstack-node-4:~# lvs - LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert - c744af27-fb40-4ffa-8a84-b9f44cb19b2b cinder-volumes-1 -wi-a----- 1.00g -``` - -## LVM iSCSI and Multipath - -!!! tip - The use of iSCSI without multipath is discouraged and will lead to VMs having issues reaching attached storage during networking events. - -!!! note - This configuration will use two storage CIDRs, please make sure there are two network paths back to storage. - -## Enable multipath in Nova Compute - -Toggle volume_use_multipath to true in /etc/genestack/helm-configs/nova/nova-helm-overrides.yaml - -``` shell -sed -i 's/volume_use_multipath: false/volume_use_multipath: true/' /etc/genestack/helm-configs/nova/nova-helm-overrides.yaml -sed -i 's/enable_iscsi: false/enable_iscsi: true/' /etc/genestack/helm-configs/nova/nova-helm-overrides.yaml -``` - -## Enable iSCSi and Multipath services on Compute Nodes - -Add variable to your inventory file and re-run host-setup.yaml - -``` yaml -storage: - vars: - enable_iscsi: true -``` - -## Enable iSCSI and Custom Mutlipath configuration - -!!! note - The included custom multipath config file uses queue-length and sends IO out all active paths when using iSCSI LVM, configure to your environment as you see fit. - -Add variable to your inventory file, edit /opt/genestack/ansible/playbooks/templates/genestack-multipath.conf and re-run host-setup.yaml - -``` yaml -storage: - vars: - enable_iscsi: true - custom_multipath: true -``` - -## Enable iSCSI with LVM - -There should be two networks defined on the openstack cluster: br_storage and br_storage_secondary - -## Verify operations - -Once a cinder volume is attach you should see on the LVM iSCSI node the following: - -``` shell -root@genestack-storage1:~# tgtadm --mode target --op show -Target 4: iqn.2010-10.org.openstack:dd88d4b9-1297-44c1-b9bc-efd6514be035 - System information: - Driver: iscsi - State: ready - I_T nexus information: - I_T nexus: 4 - Initiator: iqn.2004-10.com.ubuntu:01:8392e3447710 alias: genestack-compute2.cluster.local - Connection: 0 - IP Address: 10.1.2.213 - I_T nexus: 5 - Initiator: iqn.2004-10.com.ubuntu:01:8392e3447710 alias: genestack-compute2.cluster.local - Connection: 0 - IP Address: 10.1.1.213 - LUN information: - LUN: 0 - Type: controller - SCSI ID: IET 00040000 - SCSI SN: beaf40 - Size: 0 MB, Block size: 1 - Online: Yes - Removable media: No - Prevent removal: No - Readonly: No - SWP: No - Thin-provisioning: No - Backing store type: null - Backing store path: None - Backing store flags: - LUN: 1 - Type: disk - SCSI ID: IET 00040001 - SCSI SN: beaf41 - Size: 10737 MB, Block size: 512 - Online: Yes - Removable media: No - Prevent removal: No - Readonly: No - SWP: No - Thin-provisioning: No - Backing store type: rdwr - Backing store path: /dev/cinder-volumes-1/dd88d4b9-1297-44c1-b9bc-efd6514be035 - Backing store flags: - Account information: - sRs8FV73FeaF2LFnPb4j - ACL information: - ALL -``` - -On Compute nodes using generic multipath configuration file. - -``` shell - -root@genestack-compute2:~# multipath -ll -mpathb (360000000000000000e00000000040001) dm-0 IET,VIRTUAL-DISK -size=20G features='0' hwhandler='0' wp=rw -|-+- policy='service-time 0' prio=1 status=active -| `- 2:0:0:1 sda 8:0 active ready running -`-+- policy='service-time 0' prio=1 status=enabled - `- 4:0:0:1 sdb 8:16 active ready running -``` - -Using custom multipath configuration file - -``` shell - -root@genestack-compute1:~# multipath -ll -360000000000000000e00000000010001 dm-0 IET,VIRTUAL-DISK -size=10G features='0' hwhandler='0' wp=rw -`-+- policy='queue-length 0' prio=1 status=active - |- 2:0:0:1 sda 8:0 active ready running - `- 3:0:0:1 sdb 8:16 active ready running -``` diff --git a/docs/openstack-cinder-netapp-container.md b/docs/openstack-cinder-netapp-container.md deleted file mode 100644 index fd55b8f8e..000000000 --- a/docs/openstack-cinder-netapp-container.md +++ /dev/null @@ -1,72 +0,0 @@ -# NetApp Volume Worker Configuration Documentation - -This document provides information on configuring NetApp backends for the isolated Cinder volume worker. Each backend is defined by a set of -11 comma-separated options, and multiple backends can be specified by separating them with semicolons. - - -!!! warning "The NetApp container is incompatible with iSCSI workloads" - - The NetApp container is incompatible with iSCSI workloads. If the environment requires iSCSI support, review the [Cinder NetApp Worker ](openstack-cinder-netapp-worker.md) documentation instead. - -## Backend Options - -Below is a table detailing each option, its position in the backend configuration, a description, and the expected data type. - -| Option Index | Option Name | Description | Type | -|--------------|-------------------------------|------------------------------------------------------------------------------|---------| -| 0 | `backend_name` | The name of the backend configuration section. Used as `volume_backend_name`.| String | -| 1 | `netapp_login` | Username for authenticating with the NetApp storage system. | String | -| 2 | `netapp_password` | Password for authenticating with the NetApp storage system. | String | -| 3 | `netapp_server_hostname` | Hostname or IP address of the NetApp storage system. | String | -| 4 | `netapp_server_port` | Port number to communicate with the NetApp storage system. | Integer | -| 5 | `netapp_vserver` | The name of the Vserver on the NetApp storage system. | String | -| 6 | `netapp_dedup` | Enable (`True`) or disable (`False`) deduplication. | Boolean | -| 7 | `netapp_compression` | Enable (`True`) or disable (`False`) compression. | Boolean | -| 8 | `netapp_thick_provisioned` | Use thick (`True`) or thin (`False`) provisioning. | Boolean | -| 9 | `netapp_lun_space_reservation`| Enable (`enabled`) or disable (`disabled`) LUN space reservation. | String | - -### Detailed Option Descriptions - -- **`backend_name`**: A unique identifier for the backend configuration. This name is used internally by Cinder to distinguish between different backends. -- **`netapp_login`**: The username credential required to authenticate with the NetApp storage system. -- **`netapp_password`**: The password credential required for authentication. Ensure this is kept secure. -- **`netapp_server_hostname`**: The address of the NetApp storage system. This can be either an IP address or a fully qualified domain name (FQDN). -- **`netapp_server_port`**: The port number used for communication with the NetApp storage system. Common ports are `80` for HTTP and `443` for HTTPS. -- **`netapp_vserver`**: Specifies the virtual storage server (Vserver) on the NetApp storage system that will serve the volumes. -- **`netapp_dedup`**: A boolean value to enable or disable deduplication on the storage volumes. Acceptable values are `True` or `False`. -- **`netapp_compression`**: A boolean value to enable or disable compression on the storage volumes. Acceptable values are `True` or `False`. -- **`netapp_thick_provisioned`**: Determines whether volumes are thick (`True`) or thin (`False`) provisioned. -- **`netapp_lun_space_reservation`**: A String indicating whether to enable space reservation for LUNs. If `enabled`, space is reserved for the entire LUN size at creation time. - -## Example opaque Configuration - -Before deploying the NetApp volume worker, create the necessary Kubernetes secret with the `BACKENDS` environment variable: - -```shell -kubectl --namespace openstack create secret generic cinder-netapp \ - --type Opaque \ - --from-literal=BACKENDS="backend1,user1,password1,host1,80,vserver1,qos1,True,True,False,enabled" -``` - -### `BACKENDS` Environment Variable Structure - -The `BACKENDS` environment variable is used to pass backend configurations to the NetApp volume worker. Each backend configuration consists of 11 options -in a specific order. - -!!! Example "Replace the placeholder values with your actual backend configuration details" - - ```shell - BACKENDS="backend1,user1,password1,host1,80,vserver1,qos1,True,True,False,disabled;backend2,user2,password2,host2,443,vserver2,qos2,False,True,True,enabled" - ``` - -## Run the deployment - -!!! warning - - **Before** deploying a new backend, ensure that your volume type has been set up correctly and that you have applied QoS policies, provisioning specifications (min and max volume size), and any extra specs. See [Cinder Volume QoS Policies](openstack-cinder-volume-qos-policies.md), [Cinder Volume Provisioning Specs](openstack-cinder-volume-provisioning-specs.md), and [Cinder Volume Type Specs](openstack-cinder-volume-type-specs.md). - -With your configuration defined, run the deployment with a standard `kubectl apply` command. - -``` shell -kubectl --namespace openstack apply -k /etc/genestack/kustomize/cinder/netapp -``` diff --git a/docs/openstack-cinder-netapp-worker.md b/docs/openstack-cinder-netapp-worker.md deleted file mode 100644 index d0e171a35..000000000 --- a/docs/openstack-cinder-netapp-worker.md +++ /dev/null @@ -1,115 +0,0 @@ -# NetApp Volume Worker Configuration Documentation - -The NetApp Volume Worker is a cinder-volume service that is configured to use the NetApp ONTAP driver. This service is responsible for managing the creation, deletion, and management of volumes in the OpenStack environment. The NetApp Volume Worker is a stateful service that is deployed on a baremetal node that has access to the NetApp storage system. - -## Configuration - -The `deploy-cinder-volumes-netapp-reference.yaml` playbook is used to deploy the NetApp Volume Worker. The playbook will deploy the cinder-volume service on the specified nodes and configure the service to use the NetApp ONTAP driver. This playbook will read from the Kubernetes environment to determine the necessary configuration parameters for the NetApp ONTAP driver. As an operator, you will need to ensure that the necessary configuration parameters are set in the Kubernetes environment before running the playbook. - -!!! warning - - **Before** deploying a new backend, ensure that your volume type has been set up correctly and that you have applied QoS policies, provisioning specifications (min and max volume size), and any extra specs. See [Cinder Volume QoS Policies](openstack-cinder-volume-qos-policies.md), [Cinder Volume Provisioning Specs](openstack-cinder-volume-provisioning-specs.md), and [Cinder Volume Type Specs](openstack-cinder-volume-type-specs.md). - -### Backends Configuration - -The NetApp ONTAP driver requires a backend configuration to be set in the Kubernetes environment. The backend configuration specifies the storage system that the NetApp Volume Worker will use to create and manage volumes. The backend configuration is a Kubernetes secret that contains the necessary configuration parameters for the NetApp ONTAP driver. To define the backends, update the helm overrides file with the necessary configuration parameters. - -!!! example "Cinder NetApp Backend Configuration in Helm" - - ``` yaml - conf: - backends: - block-ha-performance-at-rest-encrypted: - netapp_login: - netapp_password: - netapp_server_hostname: - netapp_server_port: - netapp_storage_family: ontap_cluster - netapp_storage_protocol: iscsi - netapp_transport_type: http - netapp_vserver: - netapp_dedup: True - netapp_compression: True - netapp_thick_provisioned: True - netapp_lun_space_reservation: enabled - volume_driver: cinder.volume.drivers.netapp.common.NetAppDriver - volume_backend_name: block-ha-performance-at-rest-encrypted - block-ha-standard-at-rest-encrypted: - netapp_login: - netapp_password: - netapp_server_hostname: - netapp_server_port: - netapp_storage_family: ontap_cluster - netapp_storage_protocol: iscsi - netapp_transport_type: http - netapp_vserver: - netapp_dedup: True - netapp_compression: True - netapp_thick_provisioned: True - netapp_lun_space_reservation: enabled - volume_driver: cinder.volume.drivers.netapp.common.NetAppDriver - volume_backend_name: block-ha-standard-at-rest-encrypted - ``` - -### Detailed Variable Descriptions - -- **`LOGIN`**: The username credential required to authenticate with the NetApp storage system. -- **`PASSWORD`**: The password credential required for authentication. Ensure this is kept secure. -- **`SERVER_NAME_OR_ADDRESS`**: The address of the NetApp storage system. This can be either an IP address or a fully qualified domain name (FQDN). -- **`SERVER_PORT`**: The port number used for communication with the NetApp storage system. Common ports are `80` for HTTP and `443` for HTTPS. -- **`VSERVER`**: Specifies the virtual storage server (Vserver) on the NetApp storage system that will serve the volumes. - -## Host Setup - -The cinder target hosts need to have some basic setup run on them to make them compatible with our Logical Volume Driver. - -### Ensure DNS is working normally. - -Assuming your storage node was also deployed as a K8S node when we did our initial Kubernetes deployment, the DNS should already be -operational for you; however, in the event you need to do some manual tweaking or if the node was note deployed as a K8S worker, then -make sure you setup the DNS resolvers correctly so that your volume service node can communicate with our cluster. - -!!! note - - This is expected to be our CoreDNS IP, in my case this is `169.254.25.10`. - -This is an example of my **systemd-resolved** conf found in `/etc/systemd/resolved.conf` -``` conf -[Resolve] -DNS=169.254.25.10 -#FallbackDNS= -Domains=openstack.svc.cluster.local svc.cluster.local cluster.local -#LLMNR=no -#MulticastDNS=no -DNSSEC=no -Cache=no-negative -#DNSStubListener=yes -``` - -Restart your DNS service after changes are made. - -``` shell -systemctl restart systemd-resolved.service -``` - -## Run the deployment - -The `deploy-cinder-volumes-netapp-reference.yaml` will target the `cinder_storage_nodes` group in the inventory file. The inventory file should be updated to reflect the actual hostnames of the nodes that will be running the cinder-volume-netapp service. - -``` shell -ansible-playbook -i inventory-example.yaml deploy-cinder-volumes-netapp-reference.yaml -``` - -Once the playbook has finished executing, check the cinder api to verify functionality. - -``` shell -root@openstack-node-0:~# kubectl --namespace openstack exec -ti openstack-admin-client -- openstack volume service list -+------------------+--------------------------------------------------------------------+------+---------+-------+----------------------------+ -| Binary | Host | Zone | Status | State | Updated At | -+------------------+--------------------------------------------------------------------+------+---------+-------+----------------------------+ -| cinder-scheduler | cinder-volume-worker | nova | enabled | up | 2023-12-26T17:43:07.000000 | -| cinder-volume | cinder-volume-netapp-worker@block-ha-performance-at-rest-encrypted | nova | enabled | up | 2023-12-26T17:43:04.000000 | -+------------------+--------------------------------------------------------------------+------+---------+-------+----------------------------+ -``` - -After the playbook has executed, the cinder-volume-netapp service should be running on the specified nodes and should be configured to use the NetApp ONTAP driver. The service should be able to create, delete, and manage volumes on the NetApp storage system. Validate the service is running by checking the cinder volume service list via the API or on the command line with `systemctl status cinder-volume-netapp`. diff --git a/docs/openstack-cinder-volume-provisioning-specs.md b/docs/openstack-cinder-volume-provisioning-specs.md deleted file mode 100644 index d19b148cf..000000000 --- a/docs/openstack-cinder-volume-provisioning-specs.md +++ /dev/null @@ -1,12 +0,0 @@ -# Set Volume Type Provisioning Specifications - -*Before* creating a volume within any volume type, the provisioning specifications must be set. - -## Minimum and Maximum volume size - -These specifications are set in the volume type. The following commands constrain the `lvmdriver-1` volume type to a size between 10 GB and 2 TB. - -``` shell -root@openstack-node-0:~# kubectl --namespace openstack exec -ti openstack-admin-client -- openstack volume type set --property provisioning:min_vol_size=10 6af6ade2-53ca-4260-8b79-1ba2f208c91d -root@openstack-node-0:~# kubectl --namespace openstack exec -ti openstack-admin-client -- openstack volume type set --property provisioning:max_vol_size=2048 6af6ade2-53ca-4260-8b79-1ba2f208c91d -``` diff --git a/docs/openstack-cinder-volume-qos-policies.md b/docs/openstack-cinder-volume-qos-policies.md deleted file mode 100644 index e11767784..000000000 --- a/docs/openstack-cinder-volume-qos-policies.md +++ /dev/null @@ -1,109 +0,0 @@ -# Volume QoS Policies - -## LVM - - -### Example QoS policy for LVM driver volume type - -In order to apply a QoS policy to the `lvmdriver-1` volume type, you must first create the QoS policy. - -``` shell -root@openstack-node-0:~# kubectl --namespace openstack exec -ti openstack-admin-client -- openstack volume qos create --consumer "both" --property "read_iops_sec_per_gb=1" --property "write_iops_sec_per_gb=1" lvmdriver-1-iops -+------------+-----------------------------------------------------+ -| Field | Value | -+------------+-----------------------------------------------------+ -| consumer | both | -| id | b35fdf9c-d5bd-40f9-ae3a-8605c246ef2e | -| name | lvmdriver-1-iops | -| properties | read_iops_sec_per_gb='1', write_iops_sec_per_gb='1' | -+------------+-----------------------------------------------------+ -``` - -Once you have created the QoS policy, apply it to the `lvmdriver-1` volume type. -The command will utilize the `QOS_ID` and `VOLUME_TYPE_ID`. - -``` shell -root@openstack-node-0:~# kubectl --namespace openstack exec -ti openstack-admin-client -- openstack volume qos associate b35fdf9c-d5bd-40f9-ae3a-8605c246ef2e 6af6ade2-53ca-4260-8b79-1ba2f208c91d -``` - -## NetAPP ONTAP - -The most recent releases of the ONTAP driver (OpenStack Train and higher) allow QoS policies to be set per volume at the Cinder volume type rather than trying to utilize a QoS policy created on a target NetApp device. For a more detailed explanation, consult [NetApp Cinder QoS Concepts](https://netapp-openstack-dev.github.io/openstack-docs/train/cinder/key_concepts/section_cinder-key-concepts.html#qos-spec) - -### Example QoS policy for NetApp ONTAP volume type - -In order to apply a QoS policy to the `netapp-1` volume type, you must first create the QoS policy. - -``` shell -root@openstack-node-0:~# kubectl --namespace openstack exec -ti openstack-admin-client -- openstack volume qos create --consumer "back-end" --property "peakIOPSperGiB=8" --property "expectedIOPSperGiB=7" netapp-qos -+------------+--------------------------------------------+ -| Field | Value | -+------------+--------------------------------------------+ -| consumer | back-end | -| id | 9435160f-0e4a-4486-88b0-d6beb022732a | -| name | netapp-qos | -| properties | expectedIOPSperGiB='7', peakIOPSperGiB='8' | -+------------+--------------------------------------------+ -``` - -`expectedIOPSperGiB=7` was chosen because the target IOPSperGiB or expectedIOPSperGiB will be observed to be `5 IOPSperGiB` or `5,000 IOPS` when running FIO tests. Likewise, the `peakIOPSperGiB=8` was chosen because it is a value of `1` over the `expectedIOPSperGiB=7` and will effectively cap a burst in IOPs to an actual observerd value of `6 IOPSperGiB` or `6,000 IOPS`. - -``` shell -root@openstack-node-0:~# kubectl --namespace openstack exec -ti openstack-admin-client -- openstack volume type show 1bdb5364-ed04-4bbe-8e41-9c5fae148c3d -+--------------------+----------------------------------------+ -| Field | Value | -+--------------------+----------------------------------------+ -| access_project_ids | | -| description | None | -| id | 1bdb5364-ed04-4bbe-8e41-9c5fae148c3d | -| is_public | False | -| name | netapp-1 | -| properties | volume_backend_name='netapp-1-backend' | -| qos_specs_id | None | -+--------------------+----------------------------------------+ -``` - -Once you have created the QoS policy, apply it to the `netapp-1` volume type. -The command will utilize the `QOS_ID` and `VOLUME_TYPE_ID`. - -``` shell -root@openstack-node-0:~# kubectl --namespace openstack exec -ti openstack-admin-client -- openstack volume qos associate 9435160f-0e4a-4486-88b0-d6beb022732a 1bdb5364-ed04-4bbe-8e41-9c5fae148c3d -root@openstack-node-0:~# kubectl --namespace openstack exec -ti openstack-admin-client -- openstack volume type show 1bdb5364-ed04-4bbe-8e41-9c5fae148c3d -+--------------------+----------------------------------------+ -| Field | Value | -+--------------------+----------------------------------------+ -| access_project_ids | | -| description | None | -| id | 1bdb5364-ed04-4bbe-8e41-9c5fae148c3d | -| is_public | False | -| name | netapp-1 | -| properties | volume_backend_name='netapp-1-backend' | -| qos_specs_id | 9435160f-0e4a-4486-88b0-d6beb022732a | -+--------------------+----------------------------------------+ -``` - -## Disassociate a QoS policy from a volume type - -In order to delete a QoS policy, you must first disassociate it from any volume types that it has been associated with. - -``` shell -root@openstack-node-0:~# kubectl --namespace openstack exec -ti openstack-admin-client -- openstack volume qos disassociate --volume-type 1bdb5364-ed04-4bbe-8e41-9c5fae148c3d 9435160f-0e4a-4486-88b0-d6beb022732a -root@openstack-node-0:~# kubectl --namespace openstack exec -ti openstack-admin-client -- openstack volume type show 1bdb5364-ed04-4bbe-8e41-9c5fae148c3d -+--------------------+----------------------------------------+ -| Field | Value | -+--------------------+----------------------------------------+ -| access_project_ids | | -| description | None | -| id | 1bdb5364-ed04-4bbe-8e41-9c5fae148c3d | -| is_public | False | -| name | netapp-1 | -| properties | volume_backend_name='netapp-1-backend' | -| qos_specs_id | None | -+--------------------+----------------------------------------+ -``` - -## Delete a QoS policy - -``` shell -root@openstack-node-0:~# kubectl --namespace openstack exec -ti openstack-admin-client -- openstack volume qos delete 9435160f-0e4a-4486-88b0-d6beb022732a -``` diff --git a/docs/openstack-cinder-volume-type-specs.md b/docs/openstack-cinder-volume-type-specs.md deleted file mode 100644 index 836d37975..000000000 --- a/docs/openstack-cinder-volume-type-specs.md +++ /dev/null @@ -1,16 +0,0 @@ -# Set Volume Type Specifications - -## Example: NetApp ONTAP driver volume specifications (deduplication and compression) - -To set and unset additional properties on a NetApp volume type, use the syntax examples. - -``` shell - -root@openstack-node-0:~# kubectl --namespace openstack exec -ti openstack-admin-client -- openstack volume type set --property netapp_dedup='true' - -root@openstack-node-0:~# kubectl --namespace openstack exec -ti openstack-admin-client -- openstack volume type set --property netapp_compression='true' - -root@openstack-node-0:~# kubectl --namespace openstack exec -ti openstack-admin-client -- openstack volume type unset --property netapp_dedup - -root@openstack-node-0:~# kubectl --namespace openstack exec -ti openstack-admin-client -- openstack volume type unset --property netapp_compression -``` diff --git a/docs/openstack-cinder.md b/docs/openstack-cinder.md deleted file mode 100644 index df13df88b..000000000 --- a/docs/openstack-cinder.md +++ /dev/null @@ -1,46 +0,0 @@ -# Deploy Cinder - -OpenStack Cinder is a core component of the OpenStack cloud computing platform, responsible for providing scalable, persistent block storage to cloud instances. It allows users to manage volumes, snapshots, and backups, enabling efficient storage operations within both private and public cloud environments. This document details the deployment of OpenStack Cinder within Genestack. - -> Genestack facilitates the deployment process by leveraging Kubernetes' orchestration capabilities, ensuring seamless integration and management of Cinder services spanning across storage types, platforms and environments. - -## Create secrets - -!!! note "Information about the secretes used" - - Manual secret generation is only required if you haven't run the `create-secrets.sh` script located in `/opt/genestack/bin`. - - ??? example "Example secret generation" - - ``` shell - kubectl --namespace openstack \ - create secret generic cinder-rabbitmq-password \ - --type Opaque \ - --from-literal=username="cinder" \ - --from-literal=password="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-64};echo;)" - kubectl --namespace openstack \ - create secret generic cinder-db-password \ - --type Opaque \ - --from-literal=password="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-32};echo;)" - kubectl --namespace openstack \ - create secret generic cinder-admin \ - --type Opaque \ - --from-literal=password="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-32};echo;)" - ``` - -## Run the package deployment - -!!! example "Run the Cinder deployment Script `bin/install-cinder.sh`" - - ``` shell - --8<-- "bin/install-cinder.sh" - ``` - -!!! tip - - You may need to provide custom values to configure your openstack services, for a simple single region or lab deployment you can supply an additional overrides flag using the example found at `base-helm-configs/aio-example-openstack-overrides.yaml`. - In other cases such as a multi-region deployment you may want to view the [Multi-Region Support](multi-region-support.md) guide to for a workflow solution. - -## Demo - -[![asciicast](https://asciinema.org/a/629808.svg)](https://asciinema.org/a/629808) diff --git a/docs/openstack-cloud-design-az.md b/docs/openstack-cloud-design-az.md deleted file mode 100644 index 2a1c0aa92..000000000 --- a/docs/openstack-cloud-design-az.md +++ /dev/null @@ -1,130 +0,0 @@ -# Availability Zones - -Availability Zones are one of the most arbitrary designed domains in a cloud. In a large-scale cloud, they could be multiple data centers in the same geographical area, while in a smaller cloud they could be separate data halls in the same data center or separate racks in the same data hall. - -Ultimately, because it has no set physical analogue, an Availability Zone becomes 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 your users to to separate resources for resilience against failures. - -Availability Zones are a logical abstraction for partitioning a cloud without knowing the physical infrastructure. They can be used to partition a cloud on arbitrary factors, such as location (country, data center, rack), network layout, or power source. - -![Availability Zones in Cloud Hierarchy](assets/images/cloud-hierarchy-az.png) - -## The Use Case for Availability Zones - -Typically, a [region](openstack-cloud-design-regions.md) encompasses at least two, ideally more, availability zones (AZs). All AZs are fully independent, featuring redundant power, cooling, and networking resources, and are interconnected within a region via dedicated high-bandwidth, low-latency links. Connectivity between AZs in-Region are typically extremely fast[^1]. - -!!! Genestack - See the [data center](https://www.rackspace.com/about/data-centers){:target="_blank"} pages on the Rackspace website for information on how Rackspace deploys and manages data centers to deliver these capabilities. - -There is no standard for quantifying distance between AZs. What constitutes "in-Region" is defined by a the cloud provider, so when designing a cloud there is a lot of latitude.Distance between AZs depends on the region and the specific cloud provider[^2]. - -In all cases, distance between AZs are designed to have them strategically located a sufficient distance from one another to minimize the likelihood that a single event will impact multiple Availability Zones. At the same time, they are close enough to maintain low-latency connectivity for replication and failover scenarios. - -In larger cases, this is to mitigate larger failure domains, such as a natural disaster or power outage, while in smaller cases (e.g. defining AZs as two separate data halls at the same data center) this would be to mitigate interruptions to one part of a data center campus from impacting other portions of the campus. - -Availability Zones are often also used to distribute Region resources closer to the "edge" as organizations frequently choose the AZ closest to their physical location[^3]. - -The high-speed bandwidth means that applications and services can take advantage of multiple AZs to have built-in redundancy even in-Region. It is possible to run redundant workloads across geographically dispersed AZs to take advantage of the high availability and resiliency they offer. - -### Availability Zone Scoping - -One thing that needs to be decided early-on in cloud design, is the _scope_ of Availability Zones and what their intended usage pattern is. - -If Availability Zones are intended to be a more "global" construct, then having identically named AZs in Nova, Cinder, and Neutron makes sense. The user will (correctly) assume that the AZ applies equally across all the services. - -If Availability Zones are meant to be uniquely used inside each service, then naming them identically will lead to user configuration. In this case, it would be advised to name your AZs with the service name or type as a part of the naming scheme. - -## Availability Zones in Nova - -Availability Zones in Nova can essentially be qualified as migration boundaries. You cannot migrate or move instances from one AZ to another[^4]. - -It is not allowed to move instances between Availability Zones. If adding a host to an aggregate or removing a host from an aggregate would cause an instance to move between Availability Zones, including moving from or moving to the default AZ, then the operation will be rejected. The administrator should drain the instances from the host first then the host can be moved. - -!!! Note - It is important to understand that Nova AZs in OpenStack are not a database-level construct. They are defined by adding metadata to a [Host Aggregate](openstack-cloud-design-ha.md). - -### Availability Zones vs. Host Aggregates - -The addition of this specific metadata to an aggregate makes the aggregate visible from an end-user perspective and consequently allows users to schedule instances to a specific set of hosts, the ones belonging to the aggregate. There are a few additional differences to note when comparing availability zones and host aggregates: - -- A host can be part of multiple aggregates but it can only be in one Availability Zone. - -- By default a host is part of a default Availability Zone even if it doesn’t belong to a host aggregate. The name of this default availability zone can be configured using the `default_availability_zone` config option. - -!!! Note - See [Host Aggregates](openstack-cloud-design-ha.md) for more information. - -### Availability Zones and Placement - -In order for [Placement](https://docs.openstack.org/placement/latest/){:target="_blank"} to use to honor Availability Zone requests, there must be placement aggregates that match the membership and UUID of Nova Host Aggregates that you assign as availability zones. An aggregate metadata key is used to controls this function. As of OpenStack 28.0.0 (Bobcat), this is the only way to schedule instances to availability-zones. - -Administrators can configure a default availability zone where instances will be placed when the user fails to specify one. For more information on how to do this, refer to [Availability Zones](https://docs.openstack.org/nova/latest/reference/glossary.html#term-Availability-Zone){:target="_blank"}. - -## Availability Zones in Cinder - -OpenStack block storage – [Cinder](https://docs.openstack.org/cinder/latest/){:target="_blank"} – also supports the concept of Availability Zones (AZs.) Creating availability zones in Cinder is accomplished by setting a configuration parameter in `cinder.conf`, on the nodes where the `cinder-volume` service runs. - -!!! Note - You can only set the availability zone to one value. This is consistent with availability zones in the other OpenStack projects that do not allow for the notion of overlapping failure domains. - -In Cinder, AZs should not be confused with storage types, either stated as explicit technologies (NVMe, SSD, HDD) or as different SLAs (commodity, performance.) However, storage backends, storage drivers, and storage architecture may affect how you set up Availability Zones. - -You will want to have the same Availability Zone criteria for storage as you do for compute resources and set up Availability Zones in Cinder to match what has been defined in Nova. - -!!! Warning - If you are not going to provide each storage type (NVMe/SSD/HDD) or (commodity/performance) in each AZ, you may have users end-up running into scheduler errors as they try to construct parallel environments for HA in different AZs. - -This matching includes naming of Availability Zones. If your AZs don't match, it can cause problems when Nova makes API calls to Cinder. For example, when performing a Boot from Volume API call through Nova, if Nova decided to provision your VM in an AZ called _name_, it will tell Cinder to provision a boot volume in an AZ also called _name_. If Cinder doesn’t have an AZ called _name_, this API call will fail. - -!!! Tip - You can prevent this from happening by setting the following parameter in `cinder.conf` the nodes running the `cinder-api` service: - ``` - [DEFAULT] - allow_availability_zone_fallback=True - ``` - This parameter prevents the API call from failing, because if the AZ _name_ does not exist, Cinder will fallback to another availability zone (whichever you defined as the `default_availability_zone` parameter or in the `storage_availability_zone` parameter.) - -The Cinder multi-backend feature allows you to configure multiple storage backends in the same `cinder.conf` (for the same `cinder-volume` service), but Cinder Availability Zones can only be defined _once_ per `cinder-volume` service, and not per-backend per-cinder-volume service. - -!!! Note - Even if you define multiple backends in one `cinder.conf` they will all inherit the same availability zone. - -If you’re using a third party storage appliances[^5], or are making use of software-defined storage solutions like [Ceph](https://docs.ceph.com/en/latest/rbd/rbd-openstack/){:target="_blank"}, then these systems typically have their own built-in redundancy that exist outside of OpenStack. - -### Using Cinder and Nova Availability Zones Together - -As mentioned [above](openstack-cloud-design-az.md#availability-zone-scoping), if not Availability Zones for multiple services are not implemented carefully, the combination of Nova and Cinder AZ features can allow users to not have the desired effect. Confusion about different AZ types will happen, and you can have the following scenarios occur, depending on how your AZs are configured in Nova and Cinder: - -1. **There is only a single compute AZ and a single Cinder AZ and they have the same name:** This is the default configuration if you use “stock” OpenStack: Nova’s default AZ is `nova` and Cinder has the same default value. - -2. **There are multiple Nova and Cinder AZs, there is the same number of both, and they share the same names:** In this case, users that use AZ information to configure both Nova instances as well as Cinder volumes using the same AZ name will “just work”. - -3. **There are multiple Nova and Cinder AZs, there is either a different number of each or they have different names:** In this case, users must be careful to explicitly specify a correct AZ when creating Nova instances and/or Cinder volumes, and the OpenStack deployment must have Nova configured to allow attaching volumes in other AZs, or else users may not be able to achieve their desired configuration. - -## Availability Zones in Neutron - -Like with Nova, [Availability Zones](https://docs.openstack.org/neutron/latest/admin/config-az.html){:target="_blank"} are a way to provide separate failure domains. Availability Zones in Neutron are built around groups of network nodes that run the core network services. Availability Zones are created by setting attributes to the agents on the network nodes. - -Availability Zones allow Neutron to provide [high availability](https://docs.openstack.org/neutron/latest/admin/config-az.html#achieving-high-availability-with-availability-zone){:target="_blank"} for routers, L3 gateways, IPAM (DHCP) and other networking services. This provides an extra layer of protection by segmenting networking service deployments into isolated failure domains. This allows you to group networking nodes that are in different locations, or that are attached to different power sources into separate Availability Zones and configure scheduling for resources with high availability so that they are scheduled on different Availability Zones. - -By deploying HA nodes across different availability zones, it is guaranteed that network services remain available in face of zone-wide failures that affect the deployment. - -### Neutron Availability Zones and OVN - -!!! Genestack - [Open Virtual Networking (OVN)](https://www.ovn.org/en/){:target="_blank"} is the networking fabric being used in [Genestack](infrastructure-ovn-setup.md). - -Additional [special configuration](https://docs.openstack.org/neutron/latest/admin/ovn/availability_zones.html){:target="_blank"} is necessary to enable Availability Zones when using OVN. - -## Sharing Keystone Across Availability Zones - -Availability Zones are a subset of a Region. Previously, we defined the scope of Keystone to be [regional](openstack-cloud-design-regions.md/#keystone). This means that all of the services in an AZ can be serviced by the Region-level Keystone deployment. - -## Sharing Glance Across Availability Zones - -As with Keystone, Glance can also be shared across Availability Zones. The [Region-level Glance deployment](openstack-cloud-design-regions.md/#glance) can be used across all the AZs defined in the region. - -[^1]: Typical speeds range from 10Gbps to 400Gbps in network throughput between AZs, with latencies as low as 1 to 2 milliseconds. -[^2]: For instance, for Azure Cloud Services [in Northern Virginia](https://dgtlinfra.com/amazon-aws-microsoft-data-centers-virginia/){:target="_blank"}, Microsoft has set a self-imposed requirement for its data centers to be located within approximately 12.5 miles (20 kilometers) of existing data centers in its regional network. -[^3]: This is typical for hybrid cloud deployments where there is a need to have customer data centers separate from cloud provider data centers, but still a need for high-speed connectivity, such as for fail-over, disaster recovery, or data access. -[^4]: The OpenStack [Placement](https://docs.openstack.org/placement/latest/){:target="_blank"} service and the scheduler work to prevent this from happening, but some actions can still attempt to do this, yielding unpredictable results. -[^5]: For example: [NetApp](https://www.netapp.com/hybrid-cloud/openstack-private-cloud/){:target="_blank"} or [Pure Storage](https://www.purestorage.com/content/dam/pdf/en/solution-briefs/sb-enhancing-openstack-deployments-with-pure.pdf){:target="_blank"}. diff --git a/docs/openstack-cloud-design-dr.md b/docs/openstack-cloud-design-dr.md deleted file mode 100644 index db4dc5343..000000000 --- a/docs/openstack-cloud-design-dr.md +++ /dev/null @@ -1,133 +0,0 @@ -# Disaster Recovery for OpenStack Clouds - -## Introduction - -When designing and deploying clouds using OpenStack, Disaster Recovery (DR) needs to be forefront in your mind. DR needs to be a part of the design and architecture from the start. Disasters can strike in various forms, ranging from the failure of a single node to a complete site outage. While built-in redundancy measures are essential for maintaining the resilience of production-scale OpenStack environments, the effectiveness of the recovery process largely depends on careful planning and a well-defined approach. - -## Understanding Disaster Scenarios and Potential Risks - -OpenStack environments are susceptible to a wide array of failure scenarios, each presenting unique challenges and potential risks to the cloud's stability and performance. Depending on the level where the failure occurs, it may be able to be easily mitigated due to redundancy and/or recovery processes, or it may lead to a more serious outage that requires unplanned maintenance. - -By gaining a thorough understanding of these scenarios, you can better prepare for and mitigate the impact of such failures on your OpenStack clouds. Some of the layers where most common disaster scenarios include: - -### Service Failures - -Service failures are when a particular OpenStack service (or supporting service[^1]) becomes unavailable. These are often attributed to software issues, operating system bugs, or failed OpenStack upgrades. These failures can affect critical cloud services such as Cinder, Nova, Neutron, or Keystone. The impact on instances varies depending on the affected service, with potential consequences ranging from deployment failures to service interruptions. - -### Controller Node Failures - -Hardware failures can lead to the complete outage of a Controller Node, whether virtual or physical. While Controller Node failures may not directly impact running instances and their data plane traffic, they can disrupt administrative tasks performed through the OpenStack agent. Additionally, the loss of the database hosted on the failed controller can result in the permanent loss of instance or service information. - -!!! Note - This is a different scenario than a Control Plane Failure. The impact of the failure of a Controller Node will usually be mitigated through Controller Node redundancy in the control plane. As long as there is no data corruption, service should be uninterrupted during recovery. - -### Compute Node Failures - -Compute Node failures are the most prevalent issue in OpenStack clouds – mostly because Compute Nodes make up the majority of the cloud, by node type population. Compute Node failures are often caused by hardware failures, whether disk, RAM, or other hardware failure. The primary risk associated with compute node failures is the potential loss of instances and their disk data if they are using local storage. - -!!! Info - This risk is not unique to OpenStack. Any cloud (or any compute environment at all) where storage is co-located with compute[^2] has this risk. - -### Network Failures - -Network failures can stem from various sources, including faulty SFP connectors, cables, NIC issues, or switch failures. These failures can impact both the data and control planes. Data plane NIC failures directly affect the instances using those NICs, while control-plane network failures can disrupt pending tasks such as reboots, migrations, and evacuations. - -The easiest way to account for this is to build redundancy at every level of your network: - -- **Redundant NICs** for each host → switch connectivity -- **Redundant Connections (e.g. LACP)** for each host → switch connectivity -- **Redundant Top-of-Rack (ToR) or Leaf Switches** for host → switch connectivity -- **Redundant Aggregation or Spine Switches** for switch → switch connectivity - -Having this level of redundancy won't eliminate failures, but it can massively limit or even eliminate service outage at a given level of your network, at least until maintenance can replace the affected hardware. - -### Instance Failures - -OpenStack instances, whether standalone or part of an application node, are prone to failures caused by human errors, host disk failures, power outages, and other issues. Instance failures can result in data loss, instance downtime, and instance deletion, often requiring redeployment of the affected instance or even the entire application stack that instance is part of. - -By recognizing and preparing for these potential disaster scenarios, organizations can develop comprehensive disaster recovery strategies that minimize the impact of such events on their OpenStack environments, ensuring greater system resilience and minimizing downtime. - -## Ensuring Controller Redundancy in OpenStack - -One of the fundamental design considerations in OpenStack is the implementation of a cluster with multiple controllers. A minimum of three controllers is typically deployed to maintain quorum and ensure system consistency in the event of a single server failure. By distributing services across multiple controllers, organizations can enhance the resilience and fault tolerance of their OpenStack environment. - -### Controller Deployment Strategies - -There are several standard practices for managing controller redundancy in OpenStack: - -- **Bare Metal with Containerized Services:** In this approach, each service is hosted in a container on separate bare metal servers. For example, the nova-scheduler service might run on one server, while the keystone service runs on another. This strategy provides isolation between services, potentially enhancing security and simplifying troubleshooting. This is the approach that [OpenStack-Ansible](https://docs.openstack.org/openstack-ansible/latest/){:target="_blank"} and [Kolla-Ansible](https://docs.openstack.org/kolla-ansible/latest/){:target="_blank"} take. - -- **Replicated Control Plane Services:** All control plane services are hosted together on each of the three or more servers. This replication of services across multiple servers simplifies deployment and management, as each server can be treated as a self-contained unit. In the event of a server failure, the remaining servers in the cluster continue to provide the necessary services, ensuring minimal disruption. This _hyperconverged_ approach is good for smaller OpenStack deployments, but starts to become problematic as the cluster scales. This is another approach that [OpenStack-Ansible](https://docs.openstack.org/openstack-ansible/latest/){:target="_blank"} takes, and one that Rackspace is currently using for on-prem OpenStack deployments. - -- **Kubernetes-Managed Containerized Workloads:** Kubernetes can be used to manage the OpenStack control plane services as containerized workloads. This approach enables easier scaling of individual services based on demand while offering self-healing mechanisms to automatically recover from failures. _This is the approach taken by [Genestack](deployment-guide-welcome.md)._ - -### Load Balancing and High Availability - -To ensure high availability and distribute traffic among controller nodes, load balancers such as HAProxy or NGINX are commonly used for most OpenStack web services. In addition, tools like Pacemaker can be employed to provide powerful features such as service high availability, migrating services in case of failures, and ensuring redundancy for the control plane services. - -Most deployment tooling currently achieves this via two patterns: - -- **Having multiple Controller Nodes:** This is what OpenStack-Ansible and Kolla-Ansible do today. They have multiple nodes and fail-over services individually when there is a problem and with service workload balancing for some services. Usually, this is implemented using a software load balancer like [HAProxy](https://www.haproxy.org/){:target="_blank"} or with hardware load balancers. - -- **Using a microservices-based approach:** _This is the approach that Genestack takes by deploying the OpenStack services inside of Kubernetes._ Kubernetes provides, autoscaling, load balancing, and failover capabilities for all of the OpenStack services. - -### Database and Message Queue Redundancy - -Special consideration must be given to mission-critical services like databases and message queues to ensure high availability. - -[MariaDB](https://mariadb.org/){:target="_blank"} or [MySQL](https://dev.mysql.com/community/){:target="_blank"} are the standard databases for OpenStack. To have redundancy, [Galera](https://galeracluster.com/){:target="_blank"} clustering can be used to provide multi-read/write capabilities. Regular database backups should be maintained and transferred to multiple locations outside the cluster for emergency cases. - -Message queues should be configured in a distributed mode for redundancy. The most common message queue used for OpenStack is [RabbitMQ](https://www.rabbitmq.com/){:target="_blank"}, which has [various](https://www.rabbitmq.com/docs/reliability){:target="_blank"} capabilities that can be implemented to provide reliability and redundancy. - -In some cases, with larger deployments, services might have to be separated and deployed in their own dedicated infrastructures. The OpenStack [Large Scale SIG](https://docs.openstack.org/large-scale/index.html){:target="_blank"} provides documentation on various scaling techniques for the various OpenStack services, as well as guidance around when it is appropriate to isolate a service or to scale it independently of other services. - -### Controller Redeployment and Backup Strategies - -To facilitate rapid redeployment of controllers in the event of a disaster, organizations should maintain backups of the base images used to deploy the controllers. These images should include the necessary packages and libraries for the basic functionality of the controllers. - -The backup strategy for Controller Nodes should consist of periodic snapshots of the controllers. These should be taken and transferred to safe locations to enable quick recovery without losing critical information or spending excessive time restoring backups. - -!!! Warning - You must backup _all_ controller nodes at the same time. Having "state skew" between the controllers has the potential to render the entire OpenStack deployment inoperable. Additionally, if you need to restore the control plane from a backup, it has the potential to differ from what is _currently running_ in terms of instances, networks, storage allocation, etc. - -Implementing robust controller redundancy strategies can enable you to significantly enhance the resilience and fault tolerance of your OpenStack deployment, minimizing the impact of controller failures, and ensuring the smooth operation of their cloud infrastructure. - -## Achieving Compute Node Redundancy in OpenStack - -Compute nodes are the workhorses of an OpenStack environment, hosting the instances that run various applications and services. To ensure the resilience and availability of these instances, it is crucial to design compute node redundancy strategies that can effectively handle failures and minimize downtime. - -Implementing a well-designed Compute Node redundancy strategy will enable you to significantly enhance the resilience and availability of OpenStack instances, minimize user downtime, and ensure the smooth operation of the cloud-based applications and services your users deploy. - -### Capacity Planning and Spare Nodes - -When designing compute node redundancy, it is essential to consider the capacity of the overcloud compute nodes and the criticality of the instances running on them. - -!!! Tip - A best practice is to always maintain at least one spare compute node to accommodate the evacuation of instances from a node that has failed or that requires maintenance. This is often referred to as the _**N+1**_ strategy. - -If multiple compute node groups have different capabilities, such as CPU architectures, SR-IOV, or DPDK, the redundancy design must be more granular to address the specific requirements of each component. - -### Host Aggregates and Availability Zones - -To effectively manage compute node redundancy, subdivide your nodes into multiple [Host Aggregates (HAs)](openstack-cloud-design-ha.md) and assign one or more spare compute nodes with the same capabilities and resources to each aggregate. These spare nodes must be kept free of load to ensure they can accommodate instances from a failed compute node. WHen you are creating [Availability Zones (AZs)](openstack-cloud-design-az.md) from host aggregates, you allow users to select where their instances are deployed based on their requirements. If a Compute Node fails within an AZ, the instances can be seamlessly evacuated to the spare node(s) within the same AZ. This minimizes disruptions and maintains service continuity. - -!!! Tip - You will want to implement _**N+1**_ for all Host Aggregates and Availability Zones so that each group of compute resources has some redundancy and spare capacity. - -### Fencing Mechanism and Instance High-Availability Policies - -For mission-critical deployed services that cannot tolerate any downtime due to compute node failures, implementing fencing mechanisms and instance high-availability (HA) policies can further mitigate the impact of such failures. - -!!! Info - OpenStack provides the [Masakari](https://docs.openstack.org/masakari/latest/){:target="_blank"} project to provide Instance High Availability. - -Defining specific High Availability (HA) policies for instances enables you to determine the actions to be taken if the underlying host goes down, or the instance crashes. For example, for instances that cannot tolerate downtime, the applicable HA policy in Masakari is "ha-offline," which triggers the evacuation of the instance to another compute node (the spare node.) To enable this functionality, the fencing agent must be enabled in Nova. - -Masakari is a great feature, but imposes architectural requirements and limitations that can be at odds with providing a large-scale OpenStack cloud. You may want to consider limiting your cloud to have a smaller-scale "High Availability" Host Aggregate or Availability Zone to limit the architecture impact (as well as the associated costs) of providing this feature. - -### Monitoring and Automated Recovery - -Continuously monitor the health and status of compute nodes to quickly detect and respond to failures. Having automated recovery mechanisms that can trigger the evacuation of instances from a failed node to a spare node based on predefined policies and thresholds, is one way to cut down on service emergencies. This automation ensures rapid recovery and minimizes the need for manual intervention, reducing the overall impact of compute node failures on the OpenStack environment. Like with all automation, it can be a delicate balance of risk and reward, so _test everything_ and make sure the added complexity doesn't increase the administrative burden instead of cutting it down. - -[^1]: e.g. MySQL/MariaDB, RabbitMQ, etc. -[^2]: There are various hyperconverged architectures that attempt to mitigate this, however co-locating storage with compute via hyperconvergence means that failure of a Compute Node _also_ is failure of a Storage Node, so now you are dealing with _multiple_ failure types. diff --git a/docs/openstack-cloud-design-genestack-infra.md b/docs/openstack-cloud-design-genestack-infra.md deleted file mode 100644 index 988fdc308..000000000 --- a/docs/openstack-cloud-design-genestack-infra.md +++ /dev/null @@ -1,76 +0,0 @@ -## Genestack Infrastructure Design Notes - -### Ironic for bare-metal provisioning - -Our internal deployment team uses OpenStack bare metal provisioning, a.k.a **Ironic**, which provides bare metal machines instead of virtual machines, forked from the Nova baremetal driver. It is best thought of as a bare metal hypervisor API and a set of plugins which interact with the bare metal hypervisors. By default, it will use PXE and IPMI in order to provision and turn on/off machines, but Ironic also supports vendor-specific plugins which may implement additional functionality. - -After switch and firewall configuration, deployment nodes are created with in the environment which host the required Ironic services: - -- PXE -- DHCP -- NBP -- TFTP -- IPMI - -### Ironic Diagram - -![conceptual_architecture](./assets/images/ironic-architecture.png) - -#### Benefits of Ironic - -​ With a standard API and lightweight footprint, Ironic can serve as a driver for a variety of bare metal infrastructure. Ironic allows users to manage bare metal infrastructure like they would virtual machines and provides ideal infrastructure to run container orchestration frameworks like Kubernetes to optimize performance. - -#### Integration Methods and Use-Case - -​ Ironic is being used today to deploy the infrastructure for Rackspace's Openstack public cloud in an internal product known as Undercloud. Undercloud is agnostic to tooling making it flexible to use in local or remote datacenters. - -​ For example, a customer in their own datacenter can stand up the reference architecture hardware for Rackspace OpenStack and, granting ingress access to DRAC or iLO, allow our engineers to create the Ironic environment and flavors required for the compute hardware. The servers are identified their first PXE boot and the proper server flavor and image are applied. When a server goes offline to due hardware or drive failures, it can be re-provisioned after repair back to its original operating system and added back to the Openstack environment through Flex automation. - -### Leaf-Spline Network Architecture - -#### Overview - -​ Spine-leaf, or leaf-spine, is a two-layer network topology composed of spine and leaf switches. A spine-leaf architecture helps data center networks reduce network latency and hop count and improve network efficiency. This two-layer full-mesh network topology was designed as an alternative to three-tier architectures and is suitable for modern data centers that experience more east-west network traffic than north-south or switch-to-switch traffic. East-west traffic flows transfer data packets from server to server within a data center. - -- **Spine switches.** Leaf switches connect to spine switches and mesh into the spine, forming the access layer that delivers network connection points for servers. -- **Leaf switches.** Servers and storage connect to leaf switches and consist of access switches that aggregate traffic from servers. They connect directly to the spine. - -![leaf-spline](assets/images/leaf-spline.png) - -#### Advantages of Leaf-Spline Architecture - -- **Redundancy.** Each leaf switch connects to every spine switch, which increases the amount of redundancy while also reducing potential bottlenecks. -- **Lower latency.** Spine-leaf minimizes latency and bottlenecks because each payload only has to travel to a spine switch and to another leaf switch (two hops) to reach its endpoint. -- **Performance.** Protocols such as Shortest Path Bridging (SPB) and Transparent Interconnection of Lots of Links (TRILL) aid in avoiding traffic congestion. -- **Scalability.** Additional spine switches can be added to help avoid oversubscriptionand increase scalability. -- **Reduces spending.** A spine-leaf architecture increases the number of connections each switch can handle, so data centers require fewer devices to deploy. - -#### Network Design Details - -​ Rackspace utilizes Spline-leaf network architecture where server to server traffic (east-west) has higher importance than external connectivity of the deployed application. This is ideal for single or multi tenant deployments that process large workloads of internal data kept in **block** or **object** storage. - -### Commodity Storage Solutions - -​ Commodity storage hardware, sometimes known as off-the-shelf storage, is relatively inexpensive storage systems utilizing standard hard rives that are widely available and basically interchangeable with other drives of its type. These drives are housed in simple JBOD (just a bunch of disks) chassis or in smarter storage solutions such as Dell EMC or NetApp enclosures. - -#### Cost effectiveness - -​ A major advantage of using commodity storage is for data resilience and reduced storage costs. Because of their ability to spread data across spans of inexpensive disks, data loss risk is greatly reduced when a drive inevitably fails. Data is automatically rebalanced to healthy drives before a degraded drive is removed from the cluster to be replaced as time permits by support staff. - -#### Genestack Storage Integrations - -​ Genestack easily integrates commodity storage into its cloud solutions by leveraging it for Ceph (block/object storage) and Swift (object storage) storage targets. - -​ **Ceph** is an open source software-defined storage solution designed to address the block, file and object storage needs of modern enterprises. Its highly scalable architecture sees it being adopted as the new norm for high-growth block storage, object stores, and data lakes. - -- **Scalability**: Ceph can scale to support hundreds of petabytes of data and tens of billions of objects. -- **Self-managed**: Ceph is designed to be self-healing and self-managing, so it can handle failures without interruption. -- **Fault-tolerant**: Ceph replicates data to make it fault-tolerant. -- **Uses commodity hardware**: Ceph runs on commodity hardware, such as servers, switches, hard drives, and device drives. - -**Swift,** or Openstack Object Storage, is a software-based, open-source storage system that allows users to store and retrieve large amounts of data: - -- **Data storage:** Swift is used to store unstructured data, such as images, text files, photos, documents, email, and video files. -- **Cost-effectiveness:** Swift can use inexpensive **commodity hard drives** and servers instead of more expensive equipment. -- **Scalability:** Swift uses a distributed architecture with no central point of control, which allows for greater scalability, redundancy, and permanence. -- **API-accessible:** Swift provides an API-accessible storage platform that can be integrated directly into applications. diff --git a/docs/openstack-cloud-design-ha.md b/docs/openstack-cloud-design-ha.md deleted file mode 100644 index 1d4bf41cd..000000000 --- a/docs/openstack-cloud-design-ha.md +++ /dev/null @@ -1,49 +0,0 @@ -# Host Aggregates - -[Host Aggregates](https://docs.openstack.org/nova/latest/admin/aggregates.html){:target="_blank"} 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. - -Host Aggregates[^1] are a mechanism for partitioning hosts in an OpenStack cloud, or a [Region](openstack-cloud-design-regions.md) of an OpenStack cloud, based on arbitrary characteristics. Examples where an administrator may want to do this include where a group of hosts have additional hardware or performance characteristics. - -![Host Aggregates](assets/images/Host-Aggregates.png) - -Each node can have multiple aggregates, each aggregate can have multiple key-value pairs, and the same key-value pair can be assigned to multiple aggregates. This information can be used in the scheduler to enable advanced scheduling or to define logical groups for migration. In general, Host Aggregates can be thought of as a way to segregate compute resources _behind the scenes_ to control and influence where VM instances will be placed. - -## Host Aggregates in Nova - -Host aggregates are not explicitly exposed to users. Instead administrators map flavors to host aggregates. Administrators do this by setting metadata on a host aggregate, and setting matching flavor extra specifications. The scheduler then endeavors to match user requests for instances of the given flavor to a host aggregate with the same key-value pair in its metadata. Hosts can belong to multiple Host Aggregates, depending on the attributes being used to define the aggregate. - -A common use case for host aggregates is when you want to support scheduling instances to a subset of compute hosts because they have a specific capability. For example, you may want to allow users to request compute hosts that have NVMe drives if they need access to faster disk I/O, or access to compute hosts that have GPU cards to take advantage of GPU-accelerated code. Examples include: - -- Hosts with GPU compute resources -- Hosts with different local storage capabilities (e.g. SSD vs NVMe) -- Different CPU manufacturers (e.g. AMD vs Intel) -- Different CPU microarchitectures (e.g. Skylake vs Raptor Cove) - -![Multiple Host Aggregates](assets/images/Multiple-Host-Aggregates.png) - -### Host Aggregates vs. Availability Zones - -While Host Aggregates themselves are hidden from OpenStack cloud users, Cloud administrators are able to optionally expose a host aggregate as an [Availability Zone](openstack-cloud-design-az.md). Availability zones differ from host aggregates in that they are explicitly exposed to the user, and hosts membership is exclusive -- hosts can only be in a single availability zone. - -!!! Warning - It is not allowed to move instances between Availability Zones. If adding a host to an aggregate or removing a host from an aggregate would cause an instance to move between Availability Zones (including moving from or moving to the default AZ) then the operation will be fail. - -### Host Aggregates in Genestack - -!!! Genestack - Genestack is designed to use [Host Aggregates](openstack-host-aggregates.md) to take advantage of various compute host types. - -## Aggregates and Placement - -The [Placement](https://docs.openstack.org/placement/latest/){:target="_blank"} service also has a concept of [Aggregates](https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/alloc-candidates-member-of.html). However, these are not the same thing as Host Aggregates in Nova. Placement Aggregates are defined purely as groupings of related resource providers. As compute nodes in Nova are represented in Placement as resource providers, they can be added to a Placement Aggregate as well. - -## Host Aggregates and Glance - -The primary way that Glance can influence placement and work with Host Aggregates is via [Metadata](https://docs.openstack.org/glance/latest/user/metadefs-concepts.html){:target="_blank"}. - -You can map flavors and images to Host Aggregates by setting metadata on the Host Aggregate, and then set Glance image metadata properties to correlate to the host aggregate metadata. Placement can then use this metadata to schedule instances when the required filters are enabled. - -!!! Note - Metadata that you specify in a Host Aggregate limits the use of that host to any instance that has the same metadata specified in its flavor or image. - -[^1]: Host aggregates started out as a way to use Xen hypervisor resource pools, but have since been generalized to provide a mechanism to allow administrators to assign key-value pairs to groups of machines. diff --git a/docs/openstack-cloud-design-intro.md b/docs/openstack-cloud-design-intro.md deleted file mode 100644 index 3602b7170..000000000 --- a/docs/openstack-cloud-design-intro.md +++ /dev/null @@ -1,14 +0,0 @@ -# Introduction - -![OpenStack](assets/images/OpenStack-Logo-Vertical.svg){align=right : style="max-width:250px"} - -## Welcome to Genestack - -[Genestack](index.md) is a new way of deploying [OpenStack](https://openstack.org){:target="\_blank"} and [Kubernetes](kttps://k8s.io){:target="\_blank"} together to create a new type of unified cloud infrastructure. Before diving into the Genestack details and inner-workings, it will be important to decide how you want to structure your cloud. - -![Kubernetes](assets/images/kubernetes-stacked-color.svg){align=right : style="max-width:250px"} - -This section of the documentation covers some basic OpenStack cloud design principles, and offers insight into how these can be realized when building a solution using OpenStack and Genestack. - -!!! Genestack - Watch for **Genestack** boxes like this one to show where various design decisions, technologies, or ideas that Genestack is using! diff --git a/docs/openstack-cloud-design-regions.md b/docs/openstack-cloud-design-regions.md deleted file mode 100644 index 8f0cc909c..000000000 --- a/docs/openstack-cloud-design-regions.md +++ /dev/null @@ -1,95 +0,0 @@ -# Regions - -Regions are separate physical locations served by a single cloud. In terms of our taxonomy, a Cloud can contain several Regions. - -![Regions in Cloud Hierarchy](assets/images/cloud-hierarchy-region.png) - -In OpenStack, a Region is defined as an independently deployed cloud infrastructure, excepting authentication (Keystone) and possibly a dashboard (Horizon or Skyline.) **_A Region should be able to operate autonomously from other Regions._** This means that a Region has it's own API endpoints for most services. For the OpenStack CLI, this usually means a separate entry in -[`clouds.yaml`](https://docs.openstack.org/python-openstackclient/latest/configuration/index.html#clouds-yaml){:target="_blank"} -or a separate `openrc` file. - -!!! tip - - For discoverability, you may elect to have "generic" DNS names for some services that use geo-IP or other context clues to direct user to the appropriate endpoint. - - For example, if you have an internal cloud that has geographic regions on continents or countries, "cloud.company.corp" may just direct user to their in-region Horizon or Keystone instance, like "us.cloud.company.corp" for North America or "apac.cloud.company.corp" for Asia. - -## Designing Services for Multiple Regions - -### Keystone - -A unified [Keystone](https://docs.openstack.org/keystone/latest/){:target="_blank"} service is essentially what separates a Region deployment from a Cloud deployment. - -In most cases, when you deploy a multi-region cloud, you first either deploy a global Keystone service first, either stand-alone or as a part of your primary region, and then deploy additional regions federating from it. - -This is usually trivial, as you ought to be backing Keystone with some large-scale authentication (authn) and authorization (authz) infrastructure such as a [LDAP](https://docs.openstack.org/keystone/latest/admin/configuration.html#integrate-identity-with-ldap){:target="_blank"}[^1]. You can also use Keystone's built-in federation, as is done at [Rackspace](openstack-keystone-federation.md). - -### Horizon/Skyline - -The [Horizon](https://docs.openstack.org/horizon/latest/){:target="_blank"} and [Skyline](https://docs.openstack.org/skyline/latest/){:target="_blank"} web control panels are one of the primary ways that users interact with OpenStack. Collectively, we usually refer to their functionality as the "Dashboard." - -Regions can have their own dashboard logins[^2], or a cloud provider may want to create a landing page where there is the ability for the user to select the region into which they want to login. - -OpenStack currently does not have any multi-region capability with the dashboards, so if a "single pane of glass" approach is desired, third-party tooling will need to be required. - -!!! Example - [ManageIQ](https://docs.openstack.org/horizon/latest/){:target="_blank"} is an open-source [Cloud Management Platform (CMP)](https://en.wikipedia.org/wiki/Cloud_management#Cloud_Management_Platforms_(CMP)){:target="_blank"} that is capable of managing multiple OpenStack clouds or regions. ManageIQ has excellent support via it's [OpenStack provider](https://www.manageiq.org/docs/reference/latest/managing_providers/cloud_providers/openstack_providers.html){:target="_blank"} and multiple OpenStack API endpoints can be added to provide common management through the ManageIQ web interface and [API](https://www.manageiq.org/docs/api){:target="_blank"}. - -### Nova - -[Nova](https://docs.openstack.org/nova/latest/){:target="_blank"} is probably the easiest service to rationalize on a per-Region basis. Cloud users generally have few issues understanding Regions as a cloud organization structure around compute resources. - -Regions are generally assumed to be autonomous and self-contained with respect to compute. In fact, Regions usually become one of the defining factors for how compute resources in a cloud are -organized. This is no different in OpenStack. - -When migrating compute resources from one region to another, it is generally assumed that users will export their instances from one region, and import them into another. More likely, compute instances will be deployed in multiple regions simultaneously, using networking, load balancers, DNS, and other tools to steer traffic and divide workloads across various regions. - -### Neutron - -Connecting [Neutron](https://docs.openstack.org/neutron/latest/){:target="_blank"} across regions can be very useful for users. In fact, having this capability can be essential for users to see your cloud as being viable for high-availability. - -Inter-region connectivity is a key capability that can underlie various HA-enablement services such as data replication, automated disaster recovery, block device mirroring, service locality (e.g. GeoIP.) That being said, building inter-region connectivity into Neutron proper would raise some questions that would be difficult to answer in terms of design: - -1. Which region would "own" the resource being created? -2. If both regions "own" it, how is that synchronized? Also, wouldn't that limit the autonomy of regions? - -These kind of "existential questions" should always raise a red flag – the main goal of Region is to be able to operate autonomously, so the best solution will be to create something that isn't "owned" by either end -- a VPN. - -!!! tip - - While it may seem like Neutron's [VPN as a Service (VPNaaS)](https://docs.openstack.org/neutron-vpnaas/latest/user/index.html){:target="_blank"} is a good fit for something like this, VPNaaS is primarily designed for client-server VPNs. This application is better suited for point-to-point VPNs. - -!!! example - - You may even want your cloud users to look at something like [Tailscale](https://tailscale.com/){:target="_blank"} or even just plain [Wireguard](https://www.wireguard.com/){:target="_blank"} to create their own site-to-site VPN overlay networks. - -### Cinder - -In most cases, [Cinder](https://docs.openstack.org/cinder/latest/){:target="_blank"}, like Nova, should be contained within it's region. However, there are special cases like block-device replication that may make you want to consider how to accomplish this within the framework of Cinder. - -As with Neutron, the key is designing services that can be put together with other building blocks to create the useful combinations that cloud users are looking to take advantage of. For Cinder, this usually means some kind of cross-region replication. - -!!! Note - Currently, Cinder [replication](https://docs.openstack.org/cinder/latest/contributor/replication.html){:target="_blank"} is limited to in-region backend failure scenarios where volumes can be saved to multiple backends. - -Replicating Cinder volumes from one Region to another is more complicated in the sense that not only does the actual volume storage need to be replicated, but both regions would need to have the metadata in sync for those volumes. Ultimately, there would need to be a way to synchronize the _state_ of those volumes so that both Regions understand the local and the remote to be the _same volume_. This is much more complex. - -### Glance - -If we strictly adhere to the definition that regions are separate physical locations served by a single cloud, then [Glance](https://docs.openstack.org/glance/latest/){:target="_blank"} should just be deployed on a per-region bases like most services. However, Glance is one of the OpenStack services that can you may want to consider to deploy cloud-wide. - -Glance provides a simple way to do with with [glance-replicator](https://docs.openstack.org/glance/latest/cli/glancereplicator.html){:target="_blank"}. While this is good for bootstrapping a new glance instance, you will need to continuously keep your regions in sync for this to be useful. - -A good way to do this is to have a shared Glance service with distributed backends – this is best if when OpenStack instances are located across several sites. - -!!! Example - One way to accomplish this would be to use a Glance backend on top of replicated storage. Then, you can replicate the Glace storage backend across multiple regions and expose the service from a single IP in the service catalog. That service IP could resolve to localized endpoints via geo-IP. - - Remember – your glance back-end does not necessarily need to be shared with Cinder or Swift or any other services, so using an existing storage backend with replication capabilities that you already deploy could be a economically-efficient way to achieve this goal. - -[^1]: - LDAP integration can also be used to [integrate Keystone with Active Directory](https://wiki.openstack.org/wiki/HowtoIntegrateKeystonewithAD){:target="_blank"}. - -[^2]: - Having your dashboard URL and API endpoint URL for regions follow a specific schema, like - `.region.cloud.corp` can make things easily discoverable for your users. diff --git a/docs/openstack-cloud-design-topology.md b/docs/openstack-cloud-design-topology.md deleted file mode 100644 index 1683e8ea7..000000000 --- a/docs/openstack-cloud-design-topology.md +++ /dev/null @@ -1,49 +0,0 @@ -# Cloud Topology - -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 resilience against failures, and that means understanding what failure domains the cloud infrastructure has. - -As the cloud designer and builder, providing the capabilities for high-availability means effectively defining your cloud structure for users to work around these failure domains. Depending on the resources you have or wish to make available to your users, you should decide how to set up the topology and architecture of your cloud to enable users to plan their deployments to maximize the availability of their applications. This cloud topology consists of the hierarchy of organizational units of your cloud and decide how your services function across them. Examples of these organizational units include: - -- Clouds -- Regions -- Availability Zones - -These are typically arranged as in a hierarchy, with each increasing lower layer becoming less independent of the other layers: - -![Cloud Hierarchy](assets/images/cloud-hierarchy.png) - -## Clouds - -At the highest level, a cloud is a unique set of services that operates completely independently. 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: - -- Complete operational independence, meaning no cross-dependencies with one another -- Each cloud does not have to offer the same set of services as the others -- Each cloud can be at a different software version or release from the others -- Cloud operations for one cloud is completely independent from the others - -For your users, it means that ultimately if there is any kind of failure for _Cloud A_ then this would have no effect at all in _Cloud B_. - -While simplistic, this is an entirely valid design pattern. If there is a need to deploy several locations that are (mostly[^1]) independent, then this pattern works very well. Each cloud can operate completely independently of one another, and maintenance or downtime of one cloud or a service in one cloud has no effect on the other clouds. - -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 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 data centers 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 multiple regions to provide high-availability. - -## Availability Zones - -Availability Zones are another logical grouping for sets of closely related resources and services. 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 availability 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]: The various clouds themselves should be completely independent, but they might rely on a shared backend service like LDAP for authentication. -[^2]: This could be containers, container orchestration, such as [Kubernetes](https://kubernetes.io){:target="\_blank"} or functions-as-a-service (FaaS) capabilities. diff --git a/docs/openstack-clouds.md b/docs/openstack-clouds.md deleted file mode 100644 index 6805bf3ba..000000000 --- a/docs/openstack-clouds.md +++ /dev/null @@ -1,160 +0,0 @@ -# Create an OpenStack Cloud Config - -There are a lot of ways you can go to connect to your cluster. This example will use your cluster internals to generate a cloud config compatible with your environment using the Admin user. - -## Create the needed directories - -``` shell -mkdir -p ~/.config/openstack -``` - -## Token Caching - -In the following examples authentication caching is able by default in config, however, to make this work on most modern operating systems you will need to install the `keyring` package. Installing the `keyring` is simple and can be done across a number of operating systems with the default package manager. - -#### MacOS - -``` shell -brew install keyring -``` - -#### Ubuntu or Debian - -``` shell -apt install python3-keyring -``` - -#### Enterprise Linux - -``` shell -dnf install python3-keyring -``` - -#### Source - -!!! tip - - Users may want to use a Virtual Environment so that they do not have any risk of hurting their default Python environment. For more information on seting up a venv please visit the python [documentation](https://packaging.python.org/en/latest/tutorials/installing-packages/#creating-and-using-virtual-environments) on working with virtual environments. - -``` shell -python -m pip install keyring -``` - -##### Microsoft Windows Example - -Ensure that the C:\Python27\Scripts directory is defined in the PATH environment variable, and use the easy_install command from the setuptools package: - -``` shell -C:> py -m pip install keyring -``` - -## Generate the cloud config file from within the environment - -``` shell -cat > ~/.config/openstack/clouds.yaml <`. Mounting a VM disk directly on a hypervisor or another server can be useful when you need to: - -- Recover files from a corrupted or inaccessible instance. -- Inspect or troubleshoot data that may be causing issues within the VM. -- Perform forensics or backups on a specific partition. - -The following instructions outline how to attach a VM disk image as a block device, mount it to the filesystem, and then cleanly detach it afterward. - -## Prerequisites - -1. **Root or Sudo Access**: You must have sufficient privileges to run `modprobe`, `qemu-nbd`, and mount commands. -2. **qemu-nbd Installed**: The `qemu-utils` or `qemu-kvm` package (depending on your distribution) must be installed to provide the `qemu-nbd` command. -3. **Identify the Correct Instance Disk**: Ensure you have the correct path to the VM’s disk file under `/var/lib/nova/instances`. - -!!! note - - Always confirm the instance UUID (`00000000-0000-0000-0000-000000000000` in the examples) corresponds to the target VM. - -## Mounting the VM Disk (Attach Procedure) - -Before mounting the VM disk, you need to connect the disk file to a Network Block Device (NBD) and then mount the desired partition. It is recommended that be done only on instances that are powered off. - -### Load the NBD Kernel Module - -``` shell -modprobe nbd max_part=8 -``` - -- `nbd` is the Network Block Device driver. -- `max_part=8` ensures up to eight partitions can be recognized on each NBD device. - -### Connect qemu-nbd to the Disk File - -``` shell -qemu-nbd --connect=/dev/nbd0 /var/lib/nova/instances/00000000-0000-0000-0000-000000000000/disk -``` - -- This command associates the instance disk file with the `/dev/nbd0` block device. - -#### Identify Partitions** (Optional but recommended) - -``` shell -fdisk /dev/nbd0 -l -``` - -- Lists all partitions on `/dev/nbd0`, helping you determine which partition to mount. -- Commonly, the first partition is `/dev/nbd0p1`, the second `/dev/nbd0p2`, etc. - -### Create a Mount Point - -``` shell -mkdir /mnt/00000000-0000-0000-0000-000000000000 -``` - -- Make a new directory where you will mount the disk’s partition. - -### Mount the Desired Partition - -``` shell -mount /dev/nbd0p1 /mnt/00000000-0000-0000-0000-000000000000 -``` - -- Adapts to whichever partition (`p1`, `p2`, etc.) you need to access. -- At this point, you can navigate to `/mnt/00000000-0000-0000-0000-000000000000` and inspect or recover data. - -## Unmounting the VM Disk (Detach Procedure) - -When your recovery or data inspection is complete, you should properly unmount the disk and detach the NBD device. - -### Unmount the Partition - -``` shell -umount /mnt/00000000-0000-0000-0000-000000000000 -``` - -- Ensure no processes are accessing the mount point before unmounting. - -### Remove the Mount Point Directory - -``` shell -rmdir /mnt/00000000-0000-0000-0000-000000000000 -``` - -- This step is optional but helps keep the filesystem clean. - -### Disconnect the qemu-nbd Association - -``` shell -qemu-nbd --disconnect /dev/nbd0 -``` - -- Frees the `/dev/nbd0` device from the disk file. - -### Remove the NBD Module - -``` shell -rmmod nbd -``` - -- Unloads the `nbd` kernel module if no longer needed. -- This helps prevent accidental reuse of `/dev/nbd0` by another process. - -## Additional Considerations - -1. **Data Consistency**: Mounting an active disk used by a running VM can lead to data corruption if the VM is simultaneously writing to that disk. Ideally, power off the VM or ensure the disk is not in active use before performing these steps. -2. **Multiple Partitions**: If you have more than one partition (e.g., root on `/dev/nbd0p1`, swap on `/dev/nbd0p2`), mount only the partition(s) you specifically need. -3. **Filesystem Type**: If you encounter errors mounting the filesystem (e.g., an unsupported or unfamiliar file system type), consider specifying the filesystem with `-t`, such as `mount -t ext4 /dev/nbd0p1 /mnt/...`. -4. **Cleanup**: Always remember to unmount and disconnect when finished. Leaving a disk mounted can risk accidental data changes or locks. - -## Conclusion - -Mounting a VM’s data disk using `qemu-nbd` in an OpenStack environment can greatly simplify recovery, troubleshooting, or forensic efforts. By safely attaching and detaching the disk file, operators can inspect and manipulate VM data without having to boot the instance. With the above procedure, you can maintain a secure, controlled environment for delicate recovery operations. diff --git a/docs/openstack-deploy-cli.md b/docs/openstack-deploy-cli.md deleted file mode 100644 index 39d97b259..000000000 --- a/docs/openstack-deploy-cli.md +++ /dev/null @@ -1,67 +0,0 @@ -# Openstack Deploying the Command Line Tools - -Before we can get started we need to install a few things. - -## Installing Python - -While most operating systems have some form of Python already installed, you will need to ensure you have python available on your system to use the standard command line utilities. If you need to install python, consult your operating system documentation or the upstream python [documentation](https://www.python.org/downloads) to get started. - -### Installing `pip` - -Pip is the python package manager and can make installing libraries very simple; however, some build tools may be required. For more information on installing `pip`, consult the [upstream documentation](https://pip.pypa.io/en/stable/installation). - -#### MacOS - -``` shell -python -m ensurepip --upgrade -``` - -#### Microsoft Windows - -Ensure that the C:\Python27\Scripts directory is defined in the PATH environment variable, and use the easy_install command from the setuptools package: - -``` shell -C:> py -m ensurepip --upgrade -``` - -#### Linux - -``` shell -python -m ensurepip --upgrade -``` - -### Installing the Openstack Client Using `pip` - -Assuming you have `pip` installed, it can be used to install the openstack client utilities. - -!!! tip - - Users may want to use a Virtual Environment so that they do not have any risk of hurting their default Python environment. For more information on seting up a venv please visit the python [documentation](https://packaging.python.org/en/latest/tutorials/installing-packages/#creating-and-using-virtual-environments) on working with virtual environments. - -``` shell -pip install python-openstackclient -``` - -For further information on Openstack Command Line and Authentication please visit the [upstream docs](https://docs.openstack.org/python-openstackclient/latest/cli/man/openstack.html). - -### Installing the OpenStack Client with packages - -Package based client install is a great way to simplify the installation process, however, it does come with a greater possibility to lag behind a given release and may not be as featurefull. - -#### MacOS - -``` shell -brew install openstackclient -``` - -#### Ubuntu or Debian - -``` shell -apt install python3-openstackclient -``` - -#### Enterprise Linux - -``` shell -dnf install python3-openstackclient -``` diff --git a/docs/openstack-flavors.md b/docs/openstack-flavors.md deleted file mode 100644 index f39d2a6a5..000000000 --- a/docs/openstack-flavors.md +++ /dev/null @@ -1,240 +0,0 @@ -# Create Flavors - -Flavors in OpenStack are pre-defined configurations of compute, memory, and storage resources for virtual machines. They allow administrators to offer a range of instance sizes to users. Below are the default flavors typically expected in an OpenStack cloud. These flavors can be customized based on your specific requirements. For more detailed information on managing flavors, refer to the [upstream admin documentation](https://docs.openstack.org/nova/latest/admin/flavors.html). - -## Flavor Anatomy - -Our flavors follow a simple to understand flow which lets a user better understand what they're getting at a glance. - -``` mermaid -flowchart LR - id1{{NAME}} o-.-o id2{{GENERATION}} o-.-o id3{{CPU}} o-.-o id4{{MEMORY}} -``` - -### Flavor Naming - -The current naming conventions are all strings and fall under one of four classes. - -| Key | Description | -| --- | ----------- | -| gp | General Purpose | -| co | Compute Optimized | -| ao | Accelerator Optimized | -| mo | Memory Optimized | - -### Flavor Generation - -The generation slot is an integer that starts at 0. Within the Rackspace OpenStack this value is tied to the hardware generation being supported by the flavor itself. - -### Flavor CPU - -The CPU slot is an integrate representing the number of vCPU a flavor will provide to an instance. - -### Flavor Memory - -The Memory slot is an integrate representing the gigabytes of RAM a flavor will provide to an instance. - -## Flavor Resource Breakdown - -The flavors used within our Genestack environment have been built to provide the best possible default user experience. Our flavors create an environment with the following specifications. - -| Name | GB | vCPU | Local Disk (GB) | Ephemeral Disk (GB) | Swap Space (MB) | Max Network Bandwidth (Gbps) | -| ---- | -- | ---- | --------------- | ------------------- | --------------- | ---------------------------- | -| gp.0.1.2 | 2 | 1 | 10 | 0 | 0 | 2 | -| gp.0.1.4 | 4 | 1 | 10 | 0 | 0 | 4 | -| gp.0.2.2 | 2 | 2 | 40 | 0 | 1024 | 2 | -| gp.0.2.4 | 4 | 2 | 40 | 0 | 1024 | 4 | -| gp.0.2.6 | 6 | 2 | 40 | 0 | 1024 | 4 | -| gp.0.2.8 | 8 | 2 | 40 | 0 | 1024 | 6 | -| gp.0.4.4 | 4 | 4 | 80 | 64 | 4096 | 4 | -| gp.0.4.8 | 8 | 4 | 80 | 64 | 4096 | 6 | -| gp.0.4.12 | 12 | 4 | 80 | 64 | 4096 | 6 | -| gp.0.4.16 | 16 | 4 | 80 | 64 | 4096 | 8 | -| gp.0.8.16 | 16 | 8 | 160 | 128 | 8192 | 8 | -| gp.0.8.24 | 24 | 8 | 160 | 128 | 8192 | 10 | -| gp.0.8.32 | 32 | 8 | 160 | 128 | 8192 | 10 | -| gp.0.16.64 | 64 | 16 | 240 | 128 | 8192 | 10 | -| gp.0.24.96 | 96 | 24 | 240 | 128 | 8192 | 10 | -| gp.0.32.128 | 128 | 32 | 240 | 128 | 8192 | 10 | -| gp.0.48.192 | 192 | 48 | 240 | 128 | 8192 | 10 | -| mo.1.2.12 | 12 | 2 | 80 | 0 | 0 | 6 | -| mo.1.2.16 | 16 | 2 | 80 | 0 | 0 | 8 | -| mo.1.4.20 | 20 | 4 | 80 | 0 | 0 | 10 | -| mo.1.4.24 | 24 | 4 | 80 | 0 | 0 | 10 | -| mo.1.4.32 | 32 | 4 | 80 | 0 | 0 | 10 | -| mo.1.8.64 | 64 | 8 | 80 | 0 | 0 | 10 | - -## Flavor Properties - -Flavor properties provide some additional configuration to highlight placement and create hardware functionality. - -| Property | Value | Description | -| ---------|-------|-------------| -| hw:mem_page_size | any | Defines how hughpages are used within the instance type, our default is auto, acceptible options could also be `small` or `large` | -| hw:cpu_max_threads | 1 | Sets the max number of threads per-core used within the instances. | -| hw:cpu_max_sockets | 2 | Sets the max number of sockets used within the instances. While any integer is acceptible, the highest recommended maximum is 4. | -| :category | String | Display property used within skyline to group flavor classes. Our options are `general_purpose`, `memory_optimized`, and `compute_optimized`. | -| :architecture | x86_architecture | Display property used within skyline to group flavor classes. Our option is currently limited to `x86_architecture` | -| quota:vif_inbound_peak | int | Defines the maximum allowed inbound (ingress) bandwidth on the network interface, representing the peak throughput for incoming data to the instance. The speed limit values are specified in kilobytes/second | -| quota:vif_inbound_burst | int | Specifies the maximum burst rate for inbound traffic. The burst is the allowance for temporary spikes in traffic, higher than the average rate but still within the maximum peak limit. The burst value is in kilobytes | -| quota:vif_inbound_average | int | Sets the average allowable bandwidth for inbound traffic over a sustained period. This is typically the sustained rate at which the instance can receive data, usually lower than the peak and burst rates. The speed limit values are specified in kilobytes/second | -| quota:vif_outbound_peak | int | Defines the maximum bandwidth allowed for outbound (egress) traffic on the network interface. Similar to inbound, it sets the peak limit for data leaving the instance. The speed limit values are specified in kilobytes/second | -| quota:vif_outbound_burst | int | Specifies the maximum burst rate for outbound traffic, allowing short-term spikes in the outgoing traffic, similar to the inbound burst rate. The burst value is in kilobytes | -| quota:vif_outbound_average | int | Sets the average bandwidth for outbound traffic over time, ensuring that the sustained outgoing traffic rate does not exceed this value over a longer period. The speed limit values are specified in kilobytes/second | - - ----- - -??? example "Example Creation of Flavors Built for Production" - - ``` shell - openstack --os-cloud default flavor create --description "Useful Information for users" --ram 2048 --vcpu 1 --disk 10 --ephemeral 0 --swap 0 --property "hw:mem_page_size=any" --property "hw:cpu_max_threads=1" --property "hw:cpu_max_sockets=2" --property ":category=general_purpose" --property ":architecture=x86_architecture" --property "quota:vif_inbound_peak"="250000" --property "quota:vif_inbound_burst"="250000" --property "quota:vif_inbound_average"="125000" --property "quota:vif_outbound_peak"="250000" --property "quota:vif_outbound_burst"="250000" --property "quota:vif_outbound_average"="125000" gp.0.1.2 - openstack --os-cloud default flavor create --description "Useful Information for users" --ram 4096 --vcpu 1 --disk 10 --ephemeral 0 --swap 0 --property "hw:mem_page_size=any" --property "hw:cpu_max_threads=1" --property "hw:cpu_max_sockets=2" --property ":category=general_purpose" --property ":architecture=x86_architecture" --property "quota:vif_inbound_peak"="500000" --property "quota:vif_inbound_burst"="500000" --property "quota:vif_inbound_average"="250000" --property "quota:vif_outbound_peak"="500000" --property "quota:vif_outbound_burst"="500000" --property "quota:vif_outbound_average"="250000" gp.0.1.4 - openstack --os-cloud default flavor create --description "Useful Information for users" --ram 2048 --vcpu 2 --disk 40 --ephemeral 0 --swap 1024 --property "hw:mem_page_size=any" --property "hw:cpu_max_threads=1" --property "hw:cpu_max_sockets=2" --property ":category=general_purpose" --property ":architecture=x86_architecture" --property "quota:vif_inbound_peak"="250000" --property "quota:vif_inbound_burst"="250000" --property "quota:vif_inbound_average"="125000" --property "quota:vif_outbound_peak"="250000" --property "quota:vif_outbound_burst"="250000" --property "quota:vif_outbound_average"="125000" gp.0.2.2 - openstack --os-cloud default flavor create --description "Useful Information for users" --ram 4096 --vcpu 2 --disk 40 --ephemeral 0 --swap 1024 --property "hw:mem_page_size=any" --property "hw:cpu_max_threads=1" --property "hw:cpu_max_sockets=2" --property ":category=general_purpose" --property ":architecture=x86_architecture" --property "quota:vif_inbound_peak"="500000" --property "quota:vif_inbound_burst"="500000" --property "quota:vif_inbound_average"="250000" --property "quota:vif_outbound_peak"="500000" --property "quota:vif_outbound_burst"="500000" --property "quota:vif_outbound_average"="250000" gp.0.2.4 - openstack --os-cloud default flavor create --description "Useful Information for users" --ram 6144 --vcpu 2 --disk 40 --ephemeral 0 --swap 1024 --property "hw:mem_page_size=any" --property "hw:cpu_max_threads=1" --property "hw:cpu_max_sockets=2" --property ":category=general_purpose" --property ":architecture=x86_architecture" --property "quota:vif_inbound_peak"="500000" --property "quota:vif_inbound_burst"="500000" --property "quota:vif_inbound_average"="312500" --property "quota:vif_outbound_peak"="500000" --property "quota:vif_outbound_burst"="500000" --property "quota:vif_outbound_average"="312500" gp.0.2.6 - openstack --os-cloud default flavor create --description "Useful Information for users" --ram 8192 --vcpu 2 --disk 40 --ephemeral 0 --swap 1024 --property "hw:mem_page_size=any" --property "hw:cpu_max_threads=1" --property "hw:cpu_max_sockets=2" --property ":category=general_purpose" --property ":architecture=x86_architecture" --property "quota:vif_inbound_peak"="750000" --property "quota:vif_inbound_burst"="750000" --property "quota:vif_inbound_average"="375000" --property "quota:vif_outbound_peak"="750000" --property "quota:vif_outbound_burst"="750000" --property "quota:vif_outbound_average"="375000" gp.0.2.8 - openstack --os-cloud default flavor create --description "Useful Information for users" --ram 4096 --vcpu 4 --disk 80 --ephemeral 64 --swap 4096 --property "hw:mem_page_size=any" --property "hw:cpu_max_threads=1" --property "hw:cpu_max_sockets=2" --property ":category=general_purpose" --property ":architecture=x86_architecture" --property "quota:vif_inbound_peak"="500000" --property "quota:vif_inbound_burst"="500000" --property "quota:vif_inbound_average"="250000" --property "quota:vif_outbound_peak"="500000" --property "quota:vif_outbound_burst"="500000" --property "quota:vif_outbound_average"="250000" gp.0.4.4 - openstack --os-cloud default flavor create --description "Useful Information for users" --ram 8192 --vcpu 4 --disk 80 --ephemeral 64 --swap 4096 --property "hw:mem_page_size=any" --property "hw:cpu_max_threads=1" --property "hw:cpu_max_sockets=2" --property ":category=general_purpose" --property ":architecture=x86_architecture" --property "quota:vif_inbound_peak"="750000" --property "quota:vif_inbound_burst"="750000" --property "quota:vif_inbound_average"="375000" --property "quota:vif_outbound_peak"="750000" --property "quota:vif_outbound_burst"="750000" --property "quota:vif_outbound_average"="375000" gp.0.4.8 - openstack --os-cloud default flavor create --description "Useful Information for users" --ram 12288 --vcpu 4 --disk 80 --ephemeral 64 --swap 4096 --property "hw:mem_page_size=any" --property "hw:cpu_max_threads=1" --property "hw:cpu_max_sockets=2" --property ":category=general_purpose" --property ":architecture=x86_architecture" --property "quota:vif_inbound_peak"="750000" --property "quota:vif_inbound_burst"="750000" --property "quota:vif_inbound_average"="437500" --property "quota:vif_outbound_peak"="750000" --property "quota:vif_outbound_burst"="750000" --property "quota:vif_outbound_average"="437500" gp.0.4.12 - openstack --os-cloud default flavor create --description "Useful Information for users" --ram 16384 --vcpu 4 --disk 80 --ephemeral 64 --swap 4096 --property "hw:mem_page_size=any" --property "hw:cpu_max_threads=1" --property "hw:cpu_max_sockets=2" --property ":category=general_purpose" --property ":architecture=x86_architecture" --property "quota:vif_inbound_peak"="1000000" --property "quota:vif_inbound_burst"="1000000" --property "quota:vif_inbound_average"="500000" --property "quota:vif_outbound_peak"="1000000" --property "quota:vif_outbound_burst"="1000000" --property "quota:vif_outbound_average"="500000" gp.0.4.16 - openstack --os-cloud default flavor create --description "Useful Information for users" --ram 16384 --vcpu 8 --disk 160 --ephemeral 128 --swap 8192 --property "hw:mem_page_size=any" --property "hw:cpu_max_threads=1" --property "hw:cpu_max_sockets=2" --property ":category=general_purpose" --property ":architecture=x86_architecture" --property "quota:vif_inbound_peak"="1000000" --property "quota:vif_inbound_burst"="1000000" --property "quota:vif_inbound_average"="500000" --property "quota:vif_outbound_peak"="1000000" --property "quota:vif_outbound_burst"="1000000" --property "quota:vif_outbound_average"="500000" gp.0.8.16 - openstack --os-cloud default flavor create --description "Useful Information for users" --ram 24576 --vcpu 8 --disk 160 --ephemeral 128 --swap 8192 --property "hw:mem_page_size=any" --property "hw:cpu_max_threads=1" --property "hw:cpu_max_sockets=2" --property ":category=general_purpose" --property ":architecture=x86_architecture" --property "quota:vif_inbound_peak"="1250000" --property "quota:vif_inbound_burst"="1250000" --property "quota:vif_inbound_average"="687500" --property "quota:vif_outbound_peak"="1250000" --property "quota:vif_outbound_burst"="1250000" --property "quota:vif_outbound_average"="687500" gp.0.8.24 - openstack --os-cloud default flavor create --description "Useful Information for users" --ram 32768 --vcpu 8 --disk 160 --ephemeral 128 --swap 8192 --property "hw:mem_page_size=any" --property "hw:cpu_max_threads=1" --property "hw:cpu_max_sockets=2" --property ":category=general_purpose" --property ":architecture=x86_architecture" --property "quota:vif_inbound_peak"="1250000" --property "quota:vif_inbound_burst"="1250000" --property "quota:vif_inbound_average"="750000" --property "quota:vif_outbound_peak"="1250000" --property "quota:vif_outbound_burst"="1250000" --property "quota:vif_outbound_average"="750000" gp.0.8.32 - openstack --os-cloud default flavor create --description "Useful Information for users" --ram 65536 --vcpu 16 --disk 240 --ephemeral 128 --swap 8192 --property "hw:mem_page_size=any" --property "hw:cpu_max_threads=1" --property "hw:cpu_max_sockets=2" --property ":category=general_purpose" --property ":architecture=x86_architecture" --property "quota:vif_inbound_peak"="1250000" --property "quota:vif_inbound_burst"="1250000" --property "quota:vif_inbound_average"="875000" --property "quota:vif_outbound_peak"="1250000" --property "quota:vif_outbound_burst"="1250000" --property "quota:vif_outbound_average"="875000" gp.0.16.64 - openstack --os-cloud default flavor create --description "Useful Information for users" --ram 98304 --vcpu 24 --disk 240 --ephemeral 128 --swap 8192 --property "hw:mem_page_size=any" --property "hw:cpu_max_threads=1" --property "hw:cpu_max_sockets=2" --property ":category=general_purpose" --property ":architecture=x86_architecture" --property "quota:vif_inbound_peak"="1250000" --property "quota:vif_inbound_burst"="1250000" --property "quota:vif_inbound_average"="937500" --property "quota:vif_outbound_peak"="1250000" --property "quota:vif_outbound_burst"="1250000" --property "quota:vif_outbound_average"="937500" gp.0.24.96 - openstack --os-cloud default flavor create --description "Useful Information for users" --ram 131072 --vcpu 32 --disk 240 --ephemeral 128 --swap 8192 --property "hw:mem_page_size=any" --property "hw:cpu_max_threads=1" --property "hw:cpu_max_sockets=2" --property ":category=general_purpose" --property ":architecture=x86_architecture" --property "quota:vif_inbound_peak"="1250000" --property "quota:vif_inbound_burst"="1250000" --property "quota:vif_inbound_average"="1000000" --property "quota:vif_outbound_peak"="1250000" --property "quota:vif_outbound_burst"="1250000" --property "quota:vif_outbound_average"="1000000" gp.0.32.128 - openstack --os-cloud default flavor create --description "Useful Information for users" --ram 196608 --vcpu 48 --disk 240 --ephemeral 128 --swap 8192 --property "hw:mem_page_size=any" --property "hw:cpu_max_threads=1" --property "hw:cpu_max_sockets=2" --property ":category=general_purpose" --property ":architecture=x86_architecture" --property "quota:vif_inbound_peak"="1250000" --property "quota:vif_inbound_burst"="1250000" --property "quota:vif_inbound_average"="1062500" --property "quota:vif_outbound_peak"="1250000" --property "quota:vif_outbound_burst"="1250000" --property "quota:vif_outbound_average"="1062500" gp.0.48.192 - openstack --os-cloud default flavor create --description "Useful Information for users" --ram 12288 --vcpu 2 --disk 80 --ephemeral 0 --swap 0 --property "hw:mem_page_size=any" --property "hw:cpu_max_threads=1" --property "hw:cpu_max_sockets=2" --property ":category=memory_optimized" --property ":architecture=x86_architecture" --property "quota:vif_inbound_peak"="750000" --property "quota:vif_inbound_burst"="750000" --property "quota:vif_inbound_average"="437500" --property "quota:vif_outbound_peak"="750000" --property "quota:vif_outbound_burst"="750000" --property "quota:vif_outbound_average"="437500" mo.0.2.12 - openstack --os-cloud default flavor create --description "Useful Information for users" --ram 16384 --vcpu 2 --disk 80 --ephemeral 0 --swap 0 --property "hw:mem_page_size=any" --property "hw:cpu_max_threads=1" --property "hw:cpu_max_sockets=2" --property ":category=memory_optimized" --property ":architecture=x86_architecture" --property "quota:vif_inbound_peak"="1000000" --property "quota:vif_inbound_burst"="1000000" --property "quota:vif_inbound_average"="500000" --property "quota:vif_outbound_peak"="1000000" --property "quota:vif_outbound_burst"="1000000" --property "quota:vif_outbound_average"="500000" mo.0.2.16 - openstack --os-cloud default flavor create --description "Useful Information for users" --ram 20480 --vcpu 4 --disk 80 --ephemeral 0 --swap 0 --property "hw:mem_page_size=any" --property "hw:cpu_max_threads=1" --property "hw:cpu_max_sockets=2" --property ":category=memory_optimized" --property ":architecture=x86_architecture" --property "quota:vif_inbound_peak"="1250000" --property "quota:vif_inbound_burst"="1250000" --property "quota:vif_inbound_average"="625000" --property "quota:vif_outbound_peak"="1250000" --property "quota:vif_outbound_burst"="1250000" --property "quota:vif_outbound_average"="625000" mo.0.4.20 - openstack --os-cloud default flavor create --description "Useful Information for users" --ram 24576 --vcpu 4 --disk 80 --ephemeral 0 --swap 0 --property "hw:mem_page_size=any" --property "hw:cpu_max_threads=1" --property "hw:cpu_max_sockets=2" --property ":category=memory_optimized" --property ":architecture=x86_architecture" --property "quota:vif_inbound_peak"="1250000" --property "quota:vif_inbound_burst"="1250000" --property "quota:vif_inbound_average"="687500" --property "quota:vif_outbound_peak"="1250000" --property "quota:vif_outbound_burst"="1250000" --property "quota:vif_outbound_average"="687500" mo.0.4.24 - openstack --os-cloud default flavor create --description "Useful Information for users" --ram 32768 --vcpu 4 --disk 80 --ephemeral 0 --swap 0 --property "hw:mem_page_size=any" --property "hw:cpu_max_threads=1" --property "hw:cpu_max_sockets=2" --property ":category=memory_optimized" --property ":architecture=x86_architecture" --property "quota:vif_inbound_peak"="1250000" --property "quota:vif_inbound_burst"="1250000" --property "quota:vif_inbound_average"="750000" --property "quota:vif_outbound_peak"="1250000" --property "quota:vif_outbound_burst"="1250000" --property "quota:vif_outbound_average"="750000" mo.0.4.32 - openstack --os-cloud default flavor create --description "Useful Information for users" --ram 65536 --vcpu 8 --disk 80 --ephemeral 0 --swap 0 --property "hw:mem_page_size=any" --property "hw:cpu_max_threads=1" --property "hw:cpu_max_sockets=2" --property ":category=memory_optimized" --property ":architecture=x86_architecture" --property "quota:vif_inbound_peak"="1250000" --property "quota:vif_inbound_burst"="1250000" --property "quota:vif_inbound_average"="875000" --property "quota:vif_outbound_peak"="1250000" --property "quota:vif_outbound_burst"="1250000" --property "quota:vif_outbound_average"="875000" mo.0.8.64 - ``` - -## Use Case Specific Flavors - -While having a standard set of flavors is useful, creating use case-specific flavors can greatly enhance the flexibility and efficiency of your cloud environment. Custom flavors allow you to optimize resource allocation for specific workloads, such as high-performance computing, vendor-specific instructions, and hardware pass-through. - -### Example: Vendor-Specific Scheduling - -This example configures a flavor that requires deployment on a specific CPU vendor. - -``` shell -openstack --os-cloud default flavor create intel.medium - --public \ - --ram 8192 \ - --disk 60 \ - --vcpus 4 \ - --ephemeral 10 \ - --swap 1024 -``` - -Now, set the capabilities property to ensure that the `cpu_info:vendor` is **Intel**. - -``` shell -openstack --os-cloud default flavor set intel.medium \ - --property capabilities:cpu_info:vendor='Intel' -``` - -### Example: Network Bandwidth Limits - -This example configures a flavor to use network traffic bandwidth limits for outbound and inbound traffic - -``` shell -openstack --os-cloud default flavor create gp.0.8.24 \ - --public \ - --ram 24576 \ - --disk 160 \ - --vcpus 8 \ - --ephemeral 128 \ - --swap 8192 -``` - -Now, set the following properties: `vif_inbound_average`, `vif_inbound_burst`, `vif_inbound_peak`, `vif_outbound_average`, `vif_outbound_burst`, and `vif_outbound_peak`. These values define the respective limits for network traffic. The speed limits are specified in kilobytes per second (kB/s), while the burst values are also specified in kilobytes. - -```shell -openstack --os-cloud default flavor set gp.0.8.24 \ - --property "quota:vif_inbound_peak"="1250000" \ - --property "quota:vif_inbound_burst"="1250000" \ - --property "quota:vif_inbound_average"="687500" \ - --property "quota:vif_outbound_peak"="1250000" \ - --property "quota:vif_outbound_burst"="1250000" \ - --property "quota:vif_outbound_average"="687500" -``` - -### Example: NUMA Preferred Affinity Policy - -This example configures a flavor to use the preferred PCI NUMA affinity policy for any Neutron SR-IOV interfaces. - -``` shell -openstack --os-cloud default flavor create np.medium \ - --public \ - --ram 8192 \ - --disk 60 \ - --vcpus 4 \ - --ephemeral 10 \ - --swap 1024 -``` - -Now, set the hardware property to ensure that `pci_numa_affinity_policy` is **preferred**. - -``` shell -openstack --os-cloud default flavor set np.medium \ - --property hw:pci_numa_affinity_policy=preferred -``` - -### Example: GPU Passthrough - -This example configures a flavor for GPU passthrough with a specific GPU alias, such as the NVIDIA P2000. - -``` shell -openstack --os-cloud default flavor create gpu-p2000.medium \ - --public \ - --ram 8192 \ - --disk 60 \ - --vcpus 4 \ - --ephemeral 10 \ - --swap 1024 -``` - -Now, set the hardware property to ensure that `pci_passthrough:alias` is **p2000**. - -``` shell -openstack --os-cloud default flavor set gpu-p2000.medium \ - --property pci_passthrough:alias=p2000:1 \ - --property hw:hide_hypervisor_id='true' -``` - -!!! note - - The `pci_passthrough` property assumes that the **p2000** alias has been set up on your compute node. Review the [service-specific overrides](openstack-service-overrides.md) setup for more on custom compute configurations and refer to the [Genestack documentation](openstack-pci-passthrough.md) on leveraging passthrough devices. - -!!! note - - The `hw:hide_hypervisor_id` will hide the Hypervisor ID from an instances. This useful in a lot of environments, see the [upstream documentation](https://bugs.launchpad.net/nova/+bug/1841932) for more information. - -## Benefits of Custom Flavors - -In OpenStack, flavors define the compute, memory, and storage capacity of nova computing instances. To put it simply, a flavor is an available hardware configuration for a server. It defines the size of a virtual server that can be launched and a custom flavor puts you in control of how your hardware is carved up. - -### Resource Optimization - -Custom flavors help ensure that resources are allocated efficiently. For example, an HPC workload can be assigned a flavor optimized for high CPU usage, while a database application can be assigned a flavor with ample memory. - -### Cost Management - -By tailoring flavors to specific use cases, you can manage costs more effectively. Users only consume the resources they need, which can reduce overall cloud expenditure. - -### Enhanced Performance - -Custom flavors can lead to better performance for specialized workloads. By providing the right mix of resources, applications can run more smoothly and efficiently. - -### User Satisfaction - -Offering a variety of flavors allows users to select configurations that best meet their needs, leading to higher satisfaction and better utilization of the cloud environment. - -## Conclusion - -Flavors are a fundamental aspect of OpenStack that enable flexible and efficient resource allocation. By creating both standard and use case-specific flavors, administrators can optimize their cloud environment to meet diverse workload requirements. This not only improves performance and cost-efficiency but also enhances the overall user experience. diff --git a/docs/openstack-floating-ips.md b/docs/openstack-floating-ips.md deleted file mode 100644 index f37961509..000000000 --- a/docs/openstack-floating-ips.md +++ /dev/null @@ -1,319 +0,0 @@ -# Openstack Floating Ips - -To read more about Openstack Floating Ips using the [upstream docs](https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/floating-ip.html). - -#### List and view floating ips - -``` shell -openstack --os-cloud={cloud name} floating ip list - [--network ] - [--port ] - [--fixed-ip-address ] - [--long] - [--status ] - [--project [--project-domain ]] - [--router ] -``` - -#### Create a floating ip - -``` shell -openstack --os-cloud={cloud name} floating ip create - [--subnet ] - [--port ] - [--floating-ip-address ] - [--fixed-ip-address ] - [--description ] - [--project [--project-domain ]] - -``` - -#### Delete a floating ip(s) - -!!! note - - Ip address or ID can be used to specify which ip to delete. - - -``` shell -openstack --os-cloud={cloud name} floating ip delete [ ...] -``` - -#### Floating ip set - -Set floating IP properties - -``` shell -openstack --os-cloud={cloud name} floating ip set - --port - [--fixed-ip-address ] - -``` - -#### Display floating ip details - -``` shell -openstack --os-cloud={cloud name} floating ip show $VIP -``` - -#### Unset floating IP Properties - -``` shell -openstack --os-cloud={cloud name} floating ip unset --port $VIP -``` - -#### Associate floating IP addresses - -You can assign a floating IP address to a project and to an instance. - -Associate an IP address with an instance in the project, as follows: - -``` shell -openstack --os-cloud={cloud name} server add floating ip $INSTANCE_UUID $VIP -``` - -#### Disassociate floating IP addresses - -To disassociate a floating IP address from an instance: - -``` shell -openstack --os-cloud={cloud name} server remove floating ip $INSTANCE_UUID $VIP -``` - -To remove the floating IP address from a project: - -``` shell -openstack --os-cloud={cloud name} floating ip delete $VIP -``` - -#### Floating Ip Example - -Below is a quick example of how we can assign floating ips. - -You will need to get your cloud name from your `clouds.yaml`. More information on this can be found [here](build-test-envs.md). Underneath "clouds:" you will find your cloud name. - -First create a floating ip either from PUBLICNET or the public ip pool. - -``` shell -openstack --os-cloud={cloud name} floating ip create PUBLICNET -``` - -Second get the cloud server UUID. - -``` shell -openstack --os-cloud={cloud name} server list -``` - -Third add the floating ip to the server - -``` shell -openstack --os-cloud={cloud name} server add floating ip $UUID $VIP -``` - -#### Shared floating IP and virtual IP - -You can often use a load balancer instead of a shared floating IP or virtual IP. -For advanced networking needs, using an instance that does something like you -might do with a network appliance operating system, you might need a real shared -floating IP that two instances can share with something like _keepalived_, but -you should probably use a load balancer unless you actually need the additional -capabilities from a shared floating IP or virtual IP. - -In _Genestack_ Flex, with OVN, you can implement a shared floating IP mostly as -standard for OpenStack, but Neutron's `allowed-address-pairs` depends on your -Neutron plugin, _ML2/OVN_ in this case, so while most OpenStack documentation -will show altering `allowed-address-pairs` with a CIDR as seen -[here](https://docs.openstack.org/neutron/latest/admin/archives/introduction.html#allowed-address-pairs), -OVN doesn't support CIDRs on its equivalent to port security on logical switch -ports in its NB database, so you just have to use a single IP address instead of -a CIDR. - -With that caveat, you can set up a shared floating IP like this: - -1. Create a Neutron network - - ``` shell - openstack --os-cloud={cloud name} network create tester-network - ``` - -2. Create a subnet for the network - - ``` shell - openstack --os-cloud={cloud name} subnet create --network tester-network \ - --subnet-range $CIDR \ - tester-subnet - ``` - -3. Create servers on the network - - Create `tester1` server. - - ``` shell - openstack --os-cloud={cloud name} server create tester1 --flavor m1.tiny \ - --key-name keypair \ - --network tester-network \ - --image $IMAGE_UUID - ``` - - Create `tester2` server. - - ``` shell - openstack --os-cloud={cloud name} server create tester2 --flavor m1.tiny \ - --key-name keypair \ - --network tester-network \ - --image $IMAGE_UUID - ``` - -4. Create a port with a fixed IP for the VIP. - - ``` shell - openstack --os-cloud={cloud name} port create --fixed-ip subnet=tester-subnet \ - --network tester-network \ - --no-security-group tester-vip-port - ``` - - You will probably want to note the IP on the port here as your VIP. - -5. Create a router - - You will typically need a router with an external gateway to use any - public IP, depending on your configuration. - - ``` shell - openstack --os-cloud={cloud name} router create tester-router - ``` - -6. Add at external Internet gateway to the router - - At Rackspace, we usually call the public Internet network for instances - PUBLICNET. You can use the name or ID that provides external networks - for your own installation. - - ``` shell - openstack --os-cloud={cloud name} router set --external-gateway PUBLICNET tester-router - ``` - -7. Add the subnet to the router - - ``` shell - openstack --os-cloud={cloud name} router add subnet tester-router tester-subnet - ``` - -8. Create a floating IP for the port - - You can't do this step until you've created the router as above, because - Neutron requires reachability between the subnet for the port and the - floating IP for the network. If you followed in order, this should work - here. - - ``` shell - openstack --os-cloud={cloud name} floating ip create --port tester-vip-port PUBLICNET - ``` - - Note and retain the ID and/or IP returned, since you will need it for the - next step. - -9. Put the floating IP in the `allowed-address-pair` list of the ports for your - two instances. - - Here, **specify only the VIP IP address**/**omit the netmask**. This deviates - from other examples you may see, which may include a netmask, because it can - vary with details of the plugin used with Neutron. For Neutron with ML2/OVN, - you only specify the IP address here, without a netmask. - - You use the private VIP because the DNAT occurs before it reaches the - instances. - - ``` shell - openstack --os-cloud={cloud name} port list server tester1 # retrieve port UUID - openstack --os-cloud={cloud name} port set --allowed-address ip-address= - ``` - - ``` shell - openstack --os-cloud={cloud name} port list server tester2 # retrieve port UUID - openstack --os-cloud={cloud name} port set --allowed-address ip-address= - ``` - -The steps above complete creating the shared floating IP and VIP. The following -steps allow you to test it. - -1. Create a bastion server. - - With the two test instances connected to a subnet on a router with an - external gateway, they can reach the Internet, but you will probably need - a server with a floating IP to reach these two servers to install and - configure _keepalived_ and test your shared floating IP / VIP. This example - shows only a test. - - ``` shell - openstack --os-cloud={cloud name} server create tester-bastion --flavor m1.tiny \ - --key-name keypair \ - --network tester-network \ - --image $IMAGE_UUID - ``` - -2. Add floating IP to bastion server. - - You can specify the UUID or IP of the floating IP. - - ``` shell - openstack --os-cloud={cloud name} server add floating ip tester-bastion $UUID - ``` - -3. Alter security group rules to allow SSH and ICMP: - - You will likely find you can't SSH to the floating IP you added to the - instance unless you've altered your default security group or taken other - steps because the default security group will prevent all ingress traffic. - - ``` shell - openstack --os-cloud={cloud name} security group rule create --proto tcp \ - --dst-port 22 \ - --remote-ip 0.0.0.0/0 default - ``` - - Now enable ICMP. - - ``` shell - openstack --os-cloud={cloud name} security group rule create --proto icmp \ - --dst-port -1 default - ``` - -4. SSH to the first test instance from the bastion. - -5. Configure the VIP on the interface as a test on the first test instance: - - ``` shell - sudo ip address add $VIP/24 dev enp3s0 - ``` - - Note that you add the internal VIP here, not the floating public IP. Use - the appropriate netmask (usually /24 unless you picked something else.) - -6. Ping the floating IP. - - Ping should now work. For a general floating IP on the Internet, you can - usually ping from any location, so you don't necessarily have to use your - bastion. - - ``` shell - ping $VIP - ``` - - Since the ports for the two servers look almost identical, if it works on - one, it should work on the other, so you can delete the IP from the first - instance and try it on the second: - - ``` shell - sudo ip address del $VIP/24 dev enp3s0 - ``` - - You may need to ping the internal IP address from your bastion server or - take other steps to take care of the ARP caches. You can use arping on - the instance with the VIP for that: - - ``` shell - sudo arping -i enp3s0 -U -S $VIP $VIP # VIP twice - ``` - - and ^C/break out of it once ping starts working with the address. diff --git a/docs/openstack-getting-started-cli.md b/docs/openstack-getting-started-cli.md deleted file mode 100644 index 648265a26..000000000 --- a/docs/openstack-getting-started-cli.md +++ /dev/null @@ -1,76 +0,0 @@ -# OpenStack Getting Started with CLI - -After you have installed the OpenStack command-line tools, you can proceed with initializing your account. This guide will show you how to run a command with an unscoped and scoped token to set up your account. - -!!! note - - This document makes the assumption that your account has the `OPENSTACK_FLEX` role assigned to it. If you do not have the `OPENSTACK_FLEX` role, you may not be permitted access to the environment. - -## Prerequisites - -1. Ensure you have the OpenStack command-line tools installed. If not, follow the instructions in the [Openstack Deploying the Command Line Tools](openstack-deploy-cli.md) documentation. -2. Obtain your OpenStack credentials: **username**, **password**, and **domain**. -3. Obtain the authentication URL. - -## Authenticating with OpenStack - -Before you can run OpenStack commands, you need to authenticate using your OpenStack credentials. This involves obtaining an unscoped token and then using it to get a scoped token. - -### Step 1: Obtain your projects - -To obtain a list of our available projects, we'll need to run a command with an unscoped token. Unscoped tokens are used to identify a user but does not define an association with a project. - -!!! note - - This step authenticates you with the OpenStack Identity service (Keystone) and is required for first time access to the environment. - -Run the following command, replacing the placeholders with your actual OpenStack credentials: - -``` shell -openstack project list --os-auth-url ${AUTH_URL} \ - --os-username ${USERNAME} \ - --os-password ${PASSWORD} \ - --os-user-domain-name ${DOMAIN_NAME} -``` - -> Replace the placeholders with your actual credentials and project name. - -This command returns a list of your available projects, the returned information will be used to in later commands - -### Step 2: Obtain a Scoped Token - -A scoped token is associated with a specific project and is used to perform actions within that project. - -Run the following command to obtain a scoped token: - -``` shell -openstack token issue --os-auth-url ${AUTH_URL} \ - --os-username ${USERNAME} \ - --os-password ${PASSWORD} \ - --os-user-domain-name ${DOMAIN_NAME} \ - --os-project-domain-name ${DOMAIN_NAME} \ - --os-project-name ${PROJECT_NAME} -``` - -This command returns a scoped token that you will use for subsequent OpenStack commands. - -## Running an OpenStack Command - -With your scoped token, you can now run OpenStack commands. For example, to list the available flavors, use: - -``` shell -openstack flavor list --os-auth-url ${AUTH_URL} \ - --os-username ${USERNAME} \ - --os-password ${PASSWORD} \ - --os-user-domain-name ${DOMAIN_NAME} \ - --os-project-domain-name ${DOMAIN_NAME} \ - --os-project-name ${PROJECT_NAME} -``` - -This command lists all flavors available to your project. - -## Further Reading - -For more detailed information on OpenStack command-line interface and authentication, refer to the [our documentation](openstack-clouds.md) for creating your `clouds.yaml`. - -By following these steps, you should be able to initialize your account and start using the OpenStack CLI. diff --git a/docs/openstack-glance-images.md b/docs/openstack-glance-images.md deleted file mode 100644 index 90c64cf9d..000000000 --- a/docs/openstack-glance-images.md +++ /dev/null @@ -1,420 +0,0 @@ -# Glance Images Overview - -The following page highlights how to retrieve various images and upload them into Glance. - -## Image Properties Breakdown - -Throughout the various examples you'll notice the images have a number of properties defined. -All of these properties enhance the user experience and usability of the images being provided -in these examples. - -The properties of note are the following. - -| Property | Value | Notes | -|----------------------------------------------------------------------------------------------------------|--------|----------------------| -| [hw_scsi_model](https://docs.openstack.org/glance/latest/admin/useful-image-properties.html) | STRING | Needed for multipath | -| [hw_disk_bus](https://docs.openstack.org/glance/latest/admin/useful-image-properties.html) | STRING | Needed for multipath | -| [hw_vif_multiqueue_enabled](https://docs.openstack.org/glance/latest/admin/useful-image-properties.html) | BOOL | -| [hw_qemu_guest_agent](https://docs.openstack.org/glance/latest/admin/useful-image-properties.html) | BOOL | -| [hw_machine_type](https://docs.openstack.org/glance/latest/admin/useful-image-properties.html) | STRING | -| [hw_firmware_type](https://docs.openstack.org/glance/latest/admin/useful-image-properties.html) | STRING | -| [os_require_quiesce](https://docs.openstack.org/glance/latest/admin/useful-image-properties.html) | BOOL | -| [os_type](https://docs.openstack.org/openstacksdk/latest/user/resources/image/v2/image.html) | STRING | -| [os_admin_user](https://docs.openstack.org/openstacksdk/latest/user/resources/image/v2/image.html) | STRING | [See Default Usernames for Images](#default-usernames-for-images) | -| [os_distro](https://docs.openstack.org/openstacksdk/latest/user/resources/image/v2/image.html) | STRING | -| [os_version](https://docs.openstack.org/openstacksdk/latest/user/resources/image/v2/image.html) | STRING | - -### Default Usernames for Images - -All of the images that Rackspace provides have properties that define the default username for the image. This property can be seen discovered using the `openstack image show` command and referencing the `os_admin_user` property. - -``` shell -openstack --os-cloud default image show Ubuntu-22.04 -f json -``` - -!!! example "Output in JSON format" - - ``` json - { - "checksum": "84e36c4cc4182757b34d2dc578708f7c", - "container_format": "bare", - "created_at": "2024-06-21T17:02:35Z", - "disk_format": "qcow2", - "file": "/v2/images/5cdcb4a2-0fa9-4af0-ad90-85e70bf38c0c/file", - "id": "5cdcb4a2-0fa9-4af0-ad90-85e70bf38c0c", - "min_disk": 0, - "min_ram": 0, - "name": "Ubuntu-20.04", - "owner": "8fb86e74be8d49f3befde1f647d9f2ef", - "properties": { - "os_hidden": false, - "os_hash_algo": "sha512", - "os_hash_value": "2e3417e9d63a40b8521a1dceb52cdffcbe6f5f738e0027193b7863f4b3de09ccf7bc78f000de4dbe4f91a867d0c4a75dc19c78960cc0d715fe575336fb297f01", - "hw_firmware_type": "uefi", - "owner_specified.openstack.md5": "", - "owner_specified.openstack.sha256": "", - "owner_specified.openstack.object": "images/Ubuntu-20.04", - "hypervisor_type": "kvm", - "img_config_drive": "optional", - "os_distro": "ubuntu", - "os_version": "20.04", - "hw_machine_type": "q35", - "hw_vif_multiqueue_enabled": true, - "os_type": "linux", - "os_admin_user": "ubuntu", - "hw_qemu_guest_agent": "yes", - "os_require_quiesce": true - }, - "protected": false, - "schema": "/v2/schemas/image", - "size": 625475584, - "status": "active", - "tags": [], - "updated_at": "2024-09-24T22:31:37Z", - "virtual_size": 2361393152, - "visibility": "public" - } - ``` - -Using this value operators can easily determine the default username for the image. - -## Get Ubuntu - -### Ubuntu 24.04 (Noble) - -``` shell -wget https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img -openstack --os-cloud default image create \ - --progress \ - --disk-format qcow2 \ - --container-format bare \ - --public \ - --file noble-server-cloudimg-amd64.img \ - --property hw_vif_multiqueue_enabled=true \ - --property hw_qemu_guest_agent=yes \ - --property hypervisor_type=kvm \ - --property img_config_drive=optional \ - --property hw_machine_type=q35 \ - --property hw_firmware_type=uefi \ - --property os_require_quiesce=yes \ - --property os_type=linux \ - --property os_admin_user=ubuntu \ - --property os_distro=ubuntu \ - --property os_version=24.04 \ - Ubuntu-24.04 -``` - -### Ubuntu 22.04 (Jammy) - -``` shell -wget https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64.img -openstack --os-cloud default image create \ - --progress \ - --disk-format qcow2 \ - --container-format bare \ - --public \ - --file jammy-server-cloudimg-amd64.img \ - --property hw_vif_multiqueue_enabled=true \ - --property hw_qemu_guest_agent=yes \ - --property hypervisor_type=kvm \ - --property img_config_drive=optional \ - --property hw_machine_type=q35 \ - --property hw_firmware_type=uefi \ - --property os_require_quiesce=yes \ - --property os_type=linux \ - --property os_admin_user=ubuntu \ - --property os_distro=ubuntu \ - --property os_version=22.04 \ - Ubuntu-22.04 -``` - -### Ubuntu 20.04 (Focal) - -``` shell -wget https://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64.img -openstack --os-cloud default image create \ - --progress \ - --disk-format qcow2 \ - --container-format bare \ - --public \ - --file focal-server-cloudimg-amd64.img \ - --property hw_vif_multiqueue_enabled=true \ - --property hw_qemu_guest_agent=yes \ - --property hypervisor_type=kvm \ - --property img_config_drive=optional \ - --property hw_machine_type=q35 \ - --property hw_firmware_type=uefi \ - --property os_require_quiesce=yes \ - --property os_type=linux \ - --property os_admin_user=ubuntu \ - --property os_distro=ubuntu \ - --property os_version=20.04 \ - Ubuntu-20.04 -``` - -## Get Debian - -### Debian 12 - -``` shell -wget https://cloud.debian.org/cdimage/cloud/bookworm/latest/debian-12-genericcloud-amd64.qcow2 -openstack --os-cloud default image create \ - --progress \ - --disk-format qcow2 \ - --container-format bare \ - --public \ - --file debian-12-genericcloud-amd64.qcow2 \ - --property hw_vif_multiqueue_enabled=true \ - --property hw_qemu_guest_agent=yes \ - --property hypervisor_type=kvm \ - --property img_config_drive=optional \ - --property hw_machine_type=q35 \ - --property hw_firmware_type=uefi \ - --property os_require_quiesce=yes \ - --property os_type=linux \ - --property os_admin_user=debian \ - --property os_distro=debian \ - --property os_version=12 \ - Debian-12 -``` - -### Debian 11 - -``` shell -wget https://cloud.debian.org/cdimage/cloud/bullseye/latest/debian-11-genericcloud-amd64.qcow2 -openstack --os-cloud default image create \ - --progress \ - --disk-format qcow2 \ - --container-format bare \ - --public \ - --file debian-11-genericcloud-amd64.qcow2 \ - --property hw_vif_multiqueue_enabled=true \ - --property hw_qemu_guest_agent=yes \ - --property hypervisor_type=kvm \ - --property img_config_drive=optional \ - --property hw_machine_type=q35 \ - --property hw_firmware_type=uefi \ - --property os_require_quiesce=yes \ - --property os_type=linux \ - --property os_admin_user=debian \ - --property os_distro=debian \ - --property os_version=11 \ - Debian-11 -``` - -## Get CentOS - -### Centos Stream 9 - -``` shell -wget http://cloud.centos.org/centos/9-stream/x86_64/images/CentOS-Stream-GenericCloud-9-latest.x86_64.qcow2 -openstack --os-cloud default image create \ - --progress \ - --disk-format qcow2 \ - --container-format bare \ - --public \ - --file CentOS-Stream-GenericCloud-9-latest.x86_64.qcow2 \ - --property hw_vif_multiqueue_enabled=true \ - --property hw_qemu_guest_agent=yes \ - --property hypervisor_type=kvm \ - --property img_config_drive=optional \ - --property hw_machine_type=q35 \ - --property os_require_quiesce=yes \ - --property os_type=linux \ - --property os_admin_user=centos \ - --property os_distro=centos \ - --property os_version=9 \ - CentOS-Stream-9 -``` - -### Centos Stream 8 - -``` shell -wget http://cloud.centos.org/centos/8-stream/x86_64/images/CentOS-Stream-GenericCloud-8-latest.x86_64.qcow2 -openstack --os-cloud default image create \ - --progress \ - --disk-format qcow2 \ - --container-format bare \ - --public \ - --file CentOS-Stream-GenericCloud-8-latest.x86_64.qcow2 \ - --property hw_vif_multiqueue_enabled=true \ - --property hw_qemu_guest_agent=yes \ - --property hypervisor_type=kvm \ - --property img_config_drive=optional \ - --property hw_machine_type=q35 \ - --property hw_firmware_type=uefi \ - --property os_require_quiesce=yes \ - --property os_type=linux \ - --property os_admin_user=centos \ - --property os_distro=centos \ - --property os_version=8 \ - CentOS-Stream-8 -``` - -## Get Fedora CoreOS - -### CoreOS 40 - -!!! note - - Make sure you get the most up to date image URL from the [upstream documentation](https://fedoraproject.org/coreos/download). - -Download the image. - -``` shell -# NOTE: CoreOS provides a compressed image. -wget https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/40.20240616.3.0/x86_64/fedora-coreos-40.20240616.3.0-openstack.x86_64.qcow2.xz -xz -d fedora-coreos-40.20240616.3.0-openstack.x86_64.qcow2.xz -``` - -Upload the image to glance. - -``` shell -openstack --os-cloud default image create \ - --progress \ - --disk-format qcow2 \ - --container-format bare \ - --public \ - --file fedora-coreos-40.20240616.3.0-openstack.x86_64.qcow2 \ - --property hw_vif_multiqueue_enabled=true \ - --property hw_qemu_guest_agent=yes \ - --property hypervisor_type=kvm \ - --property img_config_drive=optional \ - --property hw_machine_type=q35 \ - --property hw_firmware_type=uefi \ - --property os_require_quiesce=yes \ - --property os_type=linux \ - --property os_admin_user=coreos \ - --property os_distro=coreos \ - --property os_version=40 \ - fedora-coreos-40 -``` - -#### Fedora CoreOS Image Required by Magnum - -!!! note - - When configuring the ClusterTemplate, you must specify the image used to boot the servers. To do this, register the image with OpenStack Glance and ensure that the os_distro property is set to fedora-coreos. The os_distro attribute must be defined and accurately reflect the distribution used by the cluster driver. This parameter is mandatory and does not have a default value, so it must be specified explicitly. Note that the os_distro attribute is case-sensitive. Currently, only Fedora CoreOS is supported. For more detailed information, refer to the [upstream magnum documentation](https://docs.openstack.org/magnum/latest/user/index.html). - -``` shell -openstack --os-cloud default image create \ - --progress \ - --disk-format qcow2 \ - --container-format bare \ - --public \ - --file fedora-coreos-40.20240616.3.0-openstack.x86_64.qcow2 \ - --property hw_vif_multiqueue_enabled=true \ - --property hw_qemu_guest_agent=yes \ - --property hypervisor_type=kvm \ - --property img_config_drive=optional \ - --property hw_machine_type=q35 \ - --property hw_firmware_type=uefi \ - --property os_require_quiesce=yes \ - --property os_type=linux \ - --property os_admin_user=coreos \ - --property os_distro=fedora-coreos \ - --property os_version=40 \ - magnum-fedora-coreos-40 -``` - -## Get openSUSE Leap - -### Leap 15 - -``` shell -wget https://download.opensuse.org/repositories/Cloud:/Images:/Leap_15.2/images/openSUSE-Leap-15.2-OpenStack.x86_64-0.0.4-Build8.25.qcow2 -openstack --os-cloud default image create \ - --progress \ - --disk-format qcow2 \ - --container-format bare \ - --public \ - --file openSUSE-Leap-15.2-OpenStack.x86_64-0.0.4-Build8.25.qcow2 \ - --property hw_vif_multiqueue_enabled=true \ - --property hw_qemu_guest_agent=yes \ - --property hypervisor_type=kvm \ - --property img_config_drive=optional \ - --property hw_machine_type=q35 \ - --property os_require_quiesce=yes \ - --property os_type=linux \ - --property os_admin_user=opensuse \ - --property os_distro=suse \ - --property os_version=15 \ - openSUSE-Leap-15 -``` - -## Get SUSE - -!!! note - - Make sure you get the most up to date image from [here](https://www.suse.com/download/sles/). We downloaded the SLES15-SP6-Minimal-VM.x86_64-kvm-and-xen-QU1.qcow2 image. - -``` shell -openstack --os-cloud default image create \ - --progress \ - --disk-format qcow2 \ - --container-format bare \ - --public \ - --file SLES15-SP6-Minimal-VM.x86_64-kvm-and-xen-QU1.qcow2 \ - --property hw_vif_multiqueue_enabled=true \ - --property hw_qemu_guest_agent=yes \ - --property hypervisor_type=kvm \ - --property img_config_drive=optional \ - --property hw_machine_type=q35 \ - --property hw_firmware_type=uefi \ - --property os_require_quiesce=yes \ - --property os_type=linux \ - --property os_admin_user=sles \ - --property os_distro=sles \ - --property os_version=15-SP6 \ - SLES15-SP6 -``` - -## Get RHEL - -!!! note - - Make sure you download the latest available image from [here](https://access.redhat.com/downloads/content/479/ver=/rhel---9/9.4/x86_64/product-software). We used the rhel-9.4-x86_64-kvm.qcow2 image. - -``` shell -openstack --os-cloud default image create \ - --progress \ - --disk-format qcow2 \ - --container-format bare \ - --public \ - --file rhel-9.4-x86_64-kvm.qcow2 \ - --property hw_vif_multiqueue_enabled=true \ - --property hw_qemu_guest_agent=yes \ - --property hypervisor_type=kvm \ - --property img_config_drive=optional \ - --property hw_machine_type=q35 \ - --property hw_firmware_type=uefi \ - --property os_require_quiesce=yes \ - --property os_type=linux \ - --property os_admin_user=cloud-user \ - --property os_distro=rhel \ - --property os_version=9.4 \ - RHEL-9.4 -``` - -## Get Windows - -!!! note - - You will need to create a virtual disk image from your own licensed media and convert to .qcow2 format. This example uses a Windows 2022 Standard Edition installation generalized with cloud-init and sysprep, then converted the image to .qcow2 format using qemu-img. For additional information on creating a Windows image, please see the [upstream documentation](https://docs.openstack.org/image-guide/create-images-manually-example-windows-image.html). - -``` shell -openstack --os-cloud default image create \ - --progress \ - --disk-format qcow2 \ - --min-disk 50 \ - --min-ram 2048 \ - --container-format bare \ - --file Windows2022StdEd.qcow2 \ - --public \ - --property hypervisor_type=kvm \ - --property os_type=windows \ - --property os_admin_user=administrator \ - --property os_distro=windows \ - --property os_version=2022 \ - Windows-2022-Standard -``` diff --git a/docs/openstack-glance-swift-store.md b/docs/openstack-glance-swift-store.md deleted file mode 100644 index 5da1a82fe..000000000 --- a/docs/openstack-glance-swift-store.md +++ /dev/null @@ -1,84 +0,0 @@ -# Connecting Glance to External Swift - -When operating a cloud environment, it is often necessary to store images in a separate storage system. This can be useful for a number of reasons, such as: - -* To provide a scalable storage solution for images -* To provide a storage solution that is separate from the compute nodes -* To provide a storage solution that is separate from the control plane -* Offsite backups for instances and instance snapshots -* Disaster recovery for instances and instance snapshots - -In this guide, we will show you how to connect Glance to an external Swift storage system. This will allow you to store images in Swift, while still using Glance to manage the images. - -## Prerequisites - -Before you begin, you will need the following: - -* A running OpenStack environment -* A running Swift environment -* A running Glance environment -* The IP address of the Swift server -* The port number of the Swift server -* The username and password for the Swift server - -## Information Needed - -The following information is needed to configure Glance to use Swift as an external storage system. - -| Property | Value | Notes | -| -------- | ----- | ----- | -| KEYSTONE_AUTH_URL | STRING | Keystone V3 or later authentication endpoint where Swift is available within the service catalog | -| SUPER_SECRETE_KEY | STRING | Authentication password or key | -| CLOUD_DOMAIN_NAME | STRING | The domain name associated with the cloud account | -| CLOUD_PROJECT_NAME | STRING | The name of the project where objects will be stored | -| CLOUD_USERNAME | STRING | The username of that will be accessing the cloud project | - -!!! note "For Rackspace OpenStack Flex Users" - - If you're using Rackspace OpenStack Flex, you can use the following options for the swift object storage. - - * `KEYSTONE_AUTH_URL` will be defined as "https://keystone.api.${REGION}.rackspacecloud.com/v3" - * Replace `${REGION}` with the region where the Swift object storage is located, See [Rackspace Cloud Regions](api-status.md) for more information on available regions. - * `CLOUD_DOMAIN_NAME` will be defined as "rackspace_cloud_domain" - -### Step 1: Configure Glance to use Swift - -Update the Helm overrides at `/etc/genestack/helm-configs/glance/glance-helm-overrides.yaml` with the following configuration to connect Glance to Swift. - -``` yaml ---- -conf: - glance: - DEFAULT: - enabled_backends: swift:swift - glance_store: - default_backend: swift - default_store: swift - swift_store: | - [ref1] - auth_address = $KEYSTONE_AUTH_URL - auth_version = 3 - key = $SUPER_SECRETE_KEY - project_domain_id = - project_domain_name = $CLOUD_DOMAIN_NAME - swift_buffer_on_upload = true - swift_store_container = glance - swift_store_create_container_on_put = true - swift_store_endpoint_type = publicURL - swift_store_multi_tenant = false - swift_store_region = SJC3 - swift_upload_buffer_dir = /var/lib/glance/images - user = $CLOUD_PROJECT_NAME:$CLOUD_USERNAME - user_domain_id = - user_domain_name = $CLOUD_DOMAIN_NAME -``` - -### Step 2: Apply the Configuration - -Apply the configuration to the Glance Helm chart. - -``` bash -/opt/genestack/bin/install-glance.sh -``` - -Once the configuration has been applied, Glance will be configured to use Swift as an external storage system. You can now store images in Swift using Glance. diff --git a/docs/openstack-glance.md b/docs/openstack-glance.md deleted file mode 100644 index 01922873f..000000000 --- a/docs/openstack-glance.md +++ /dev/null @@ -1,101 +0,0 @@ -# Deploy Glance - -OpenStack Glance is the image service within the OpenStack ecosystem, responsible for discovering, registering, and retrieving virtual machine images. Glance provides a centralized repository where users can store and manage a wide variety of VM images, ranging from standard operating system snapshots to custom machine images tailored for specific workloads. This service plays a crucial role in enabling rapid provisioning of instances by providing readily accessible, pre-configured images that can be deployed across the cloud. In this document, we will outline the deployment of OpenStack Glance using Genestack. The deployment process is streamlined, ensuring Glance is robustly integrated with other OpenStack services to deliver seamless image management and retrieval. - -## Create secrets - -!!! note "Information about the secretes used" - - Manual secret generation is only required if you haven't run the `create-secrets.sh` script located in `/opt/genestack/bin`. - - ??? example "Example secret generation" - - ``` shell - kubectl --namespace openstack \ - create secret generic glance-rabbitmq-password \ - --type Opaque \ - --from-literal=username="glance" \ - --from-literal=password="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-64};echo;)" - kubectl --namespace openstack \ - create secret generic glance-db-password \ - --type Opaque \ - --from-literal=password="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-32};echo;)" - kubectl --namespace openstack \ - create secret generic glance-admin \ - --type Opaque \ - --from-literal=password="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-32};echo;)" - ``` - -!!! info - - Before running the Glance deployment you should configure the backend which is defined in the `helm-configs/glance/glance-helm-overrides.yaml` file. The default is a making the assumption we're running with Ceph deployed by Rook so the backend is configured to be cephfs with multi-attach functionality. While this works great, you should consider all of the available storage backends and make the right decision for your environment. - -## Define policy configuration - -!!! note "Information about the default policy rules used" - - The default policy allows only the glance_admin role to publicize images. - The default policy allows only the glance_admin role or owner role to download images. - These default policy roles are found in genestack/base-helm-configs/glance/glance-helm-overrides.yaml. - To modify these policies, follow the policy allow concepts in the - "Policy change to allow admin or owner to publicize image" example. - - ??? example "Default policy rules" - - ``` yaml - conf: - policy: - "admin_required": "role:admin or role:glance_admin" - "default": "role:admin or role:glance_admin" - "context_is_admin": "role:admin or role:glance_admin" - "publicize_image": "role:glance_admin" - "is_owner": "tenant:%(owner)s" - "download_image": "rule:is_owner or rule:context_is_admin" - ``` - - ??? example "Policy change to allow admin or owner to publicize image" - - ``` yaml - conf: - policy: - "admin_required": "role:admin or role:glance_admin" - "default": "role:admin or role:glance_admin" - "context_is_admin": "role:admin or role:glance_admin" - "is_owner": "tenant:%(owner)s" - "publicize_image": "rule:context_is_admin or role:is_owner" - "download_image": "rule:is_owner or rule:context_is_admin" - ``` - - -## Run the package deployment - -!!! example "Run the Glance deployment Script `bin/install-glance.sh`" - - ``` shell - --8<-- "bin/install-glance.sh" - ``` - -!!! tip - - You may need to provide custom values to configure your openstack services, for a simple single region or lab deployment you can supply an additional overrides flag using the example found at `base-helm-configs/aio-example-openstack-overrides.yaml`. - In other cases such as a multi-region deployment you may want to view the [Multi-Region Support](multi-region-support.md) guide to for a workflow solution. - -!!! note - - The defaults disable `storage_init` because we're using **pvc** as the image backend type. In production this should be changed to swift. - -## Validate functionality - -``` shell -kubectl --namespace openstack exec -ti openstack-admin-client -- openstack image list -``` - -!!! genestack "External Image Store" - - If glance will be deployed with an external swift storage backend, review the - [OpenStack Glance Swift Store](openstack-glance-swift-store.md) operator documentation - for additional steps and setup. - -## Demo - -[![asciicast](https://asciinema.org/a/629806.svg)](https://asciinema.org/a/629806) diff --git a/docs/openstack-gnocchi.md b/docs/openstack-gnocchi.md deleted file mode 100644 index 42311db7a..000000000 --- a/docs/openstack-gnocchi.md +++ /dev/null @@ -1,189 +0,0 @@ -# Deploy Gnocchi - -Gnocchi is used by [Ceilometer](openstack-ceilometer.md) -to aggregate and index metric data from various OpenStack services. It -consists of several components: a HTTP REST API, an optional -statsd-compatible daemon, and an asynchronous processing daemon (named -gnocchi-metricd). - -[![Gnocchi Architecture](assets/images/gnocchi-architecture.svg)](openstack-gnocchi.md) - -## Create Secrets - -!!! note "Information about the secretes used" - - Manual secret generation is only required if you haven't run the `create-secrets.sh` script located in `/opt/genestack/bin`. - - ??? example "Example secret generation" - - ``` shell - kubectl --namespace openstack create secret generic gnocchi-admin \ - --type Opaque \ - --from-literal=password="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-32};echo;)" - kubectl --namespace openstack create secret generic gnocchi-db-password \ - --type Opaque \ - --from-literal=password="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-32};echo;)" - kubectl --namespace openstack create secret generic gnocchi-pgsql-password \ - --type Opaque \ - --from-literal=password="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-32};echo;)" - ``` - -## Object Storage Options - -=== "Ceph Internal _(default)_" - - ### Create ceph-etc configmap - - While the below example should work fine for most environments, depending - on your use case it may be necessary to provide additional client - configuration options for ceph. The below simply creates the expected - `ceph-etc` ConfigMap for the `ceph.conf` needed by Gnocchi to establish a - connection to the mon host(s) via the rados client. - - ``` shell - kubectl apply -n openstack -f - < /dev/null || kubectl create ns rook-ceph - kubectl apply -n rook-ceph -f - < | sed 's/^/--trait /') - openstack --os-placement-api-version 1.6 resource provider trait set $traits --trait CUSTOM_HW_GPU -``` - -5. Set the trait on the aggregate -```shell - openstack --os-compute-api-version 2.53 aggregate set --property trait:CUSTOM_HW_GPU=required GPU -``` - -6. Assuming you have a flavor called gpu-flavor1 -```shell - openstack flavor set --property trait:CUSTOM_HW_GPU=required gpu-flavor1 -``` - -7. Set Isolating Aggregate Filtering to enabled in nova.conf -```shell - [scheduler] - enable_isolated_aggregate_filtering = true -``` diff --git a/docs/openstack-images.md b/docs/openstack-images.md deleted file mode 100644 index ec5c3b774..000000000 --- a/docs/openstack-images.md +++ /dev/null @@ -1,64 +0,0 @@ -# Openstack Images - -To read more about Openstack images please visit the [upstream docs](https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/image-v1.html#image-create). - -#### List and view images - -``` shell -openstack --os-cloud={cloud name} image list - [--sort-column SORT_COLUMN] - [--sort-ascending | --sort-descending] - [--public | --private] - [--property ] - [--long] - [--sort [:]] -``` - -#### View image details - -``` shell -openstack --os-cloud={cloud name} image show -``` - -#### Create a image - -``` shell -openstack --os-cloud={cloud name} image create - [--id ] - [--store ] - [--container-format ] - [--disk-format ] - [--size ] - [--min-disk ] - [--min-ram ] - [--location ] - [--copy-from ] - [--file | --volume ] - [--force] - [--checksum ] - [--protected | --unprotected] - [--public | --private] - [--property ] - [--project ] - -``` - -#### Delete a image - -``` shell -openstack --os-cloud={cloud name} image delete [ ...] -``` - -#### Retrieving Images - -Please visit this page for examples of retrieving images [here](https://docs.openstack.org/image-guide/obtain-images.html). - -#### Creating a server from an image - -Specify the server name, flavor ID, and image ID. - -``` shell -openstack --os-cloud={cloud name} server create --flavor FLAVOR_ID --image IMAGE_ID --key-name KEY_NAME \ - --user-data USER_DATA_FILE --security-group SEC_GROUP_NAME --property KEY=VALUE \ - INSTANCE_NAME -``` diff --git a/docs/openstack-keypairs.md b/docs/openstack-keypairs.md deleted file mode 100644 index 020266ff8..000000000 --- a/docs/openstack-keypairs.md +++ /dev/null @@ -1,66 +0,0 @@ -# Openstack Keypairs - -Read more about Openstack keypairs using the [upstream docs](https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/keypair.html). - -#### List and view Keypairs - -``` shell -openstack --os-cloud={cloud name} keypair list - [--sort-column SORT_COLUMN] - [--sort-ascending | --sort-descending] - [--user ] - [--user-domain ] - [--project ] - [--project-domain ] - [--limit ] - [--marker ] -``` - -#### Create a Keypair - -Before launching an instance, you must add a public key to the Compute service. - -``` shell -openstack --os-cloud={cloud name} keypair create - [--public-key | --private-key ] - [--type ] - [--user ] - [--user-domain ] - -``` - -!!! note - - --type Keypair type (supported by –os-compute-api-version 2.2 or above) - -This command generates a key pair with the name that you specify for KEY_NAME, writes the private key to the .pem file that you specify, and registers the public key to the Nova database. - -#### Import a Keypair - -If you have already generated a key pair and the public key is located at ~/.ssh/id_rsa.pub, run the following command to upload the public key. - -``` shell -openstack --os-cloud={cloud name} keypair create --public-key ~/.ssh/id_rsa.pub KEY_NAME -``` - -This command registers the public key at the Nova database and names the key pair the name that you specify for KEY_NAME - -#### Delete a Keypair - -``` shell -openstack --os-cloud={cloud name} keypair delete - [--user ] - [--user-domain ] - - [ ...] -``` - -#### Show Keypair Details - -``` shell -openstack --os-cloud={cloud name} keypair show - [--public-key] - [--user ] - [--user-domain ] - -``` diff --git a/docs/openstack-keystone-federation.md b/docs/openstack-keystone-federation.md deleted file mode 100644 index 2cceffc03..000000000 --- a/docs/openstack-keystone-federation.md +++ /dev/null @@ -1,57 +0,0 @@ -# Setup the Keystone Federation Plugin - -## Create the domain - -``` shell -openstack --os-cloud default domain create rackspace_cloud_domain -``` - -## Create the identity provider - -``` shell -openstack --os-cloud default identity provider create --remote-id rackspace --domain rackspace_cloud_domain rackspace -``` - -### Create the mapping for our identity provider - -You're also welcome to generate your own mapping to suit your needs; however, if you want to use the example mapping (which is suitable for production) you can. - -??? abstract "Example keystone `mapping.json` file" - - ``` json - --8<-- "etc/keystone/mapping.json" - ``` - -The example mapping **JSON** file can be found within the genestack repository at `/opt/genestack/etc/keystone/mapping.json`. - -!!! tip "Creating the `creator` role" - - The creator role does not exist by default, but is included in the example - mapping. One must create the creator role in order to prevent authentication - errors if using the mapping "as is". - - ``` shell - openstack --os-cloud default role create creator - ``` - -## Now register the mapping within Keystone - -``` shell -openstack --os-cloud default mapping create --rules /tmp/mapping.json --schema-version 2.0 rackspace_mapping -``` - -## Create the federation protocol - -``` shell -openstack --os-cloud default federation protocol create rackspace --mapping rackspace_mapping --identity-provider rackspace -``` - -## Rackspace Configuration Options - -The `[rackspace]` section can also be used in your `keystone.conf` to allow you to configure how to anchor on -roles. - -| key | value | default | -| --- | ----- | ------- | -| `role_attribute` | A string option used as an anchor to discover roles attributed to a given user | **os_flex** | -| `role_attribute_enforcement` | When set `true` will limit a users project to only the discovered GUID for the defined `role_attribute` | **false** | diff --git a/docs/openstack-keystone-readonly.md b/docs/openstack-keystone-readonly.md deleted file mode 100644 index 6d64bfd56..000000000 --- a/docs/openstack-keystone-readonly.md +++ /dev/null @@ -1,140 +0,0 @@ -# Create a Platform Services Project - -The following commands will setup a readonly user which is able to read data across domains. - -## Create the platform-services user and project - -After running the following commands, a readonly user (example: `platform-services`) will have read only access to everything under the `default` and `rackspace_cloud_domain` domains. - -### Create a project - -``` shell -openstack --os-cloud default project create --description 'platform-services enablement' platform-services --domain default -``` - -#### Create a new zamboni user - -!!! tip "Make sure to set the password accordingly" - - ``` shell - PASSWORD=SuperSecrete - ``` - -``` shell -openstack --os-cloud default user create --project platform-services --password ${PASSWORD} zamboni --domain default -``` - -##### Add the member role to the new user - -``` shell -openstack --os-cloud default role add --user zamboni --project platform-services member --inherited -``` - -##### Add the reader roles for user `zamboni` to the `default` domain - -``` shell -openstack --os-cloud default role add --user zamboni --domain default reader --inherited -``` - -##### Add the reader role for user `zamboni` to the `rackspace_cloud_domain` domain - -``` shell -openstack --os-cloud default role add --user zamboni --domain rackspace_cloud_domain reader --inherited -``` - -##### Add the reader role for user `zamboni` to the system - -``` shell -openstack --os-cloud default role add --user zamboni --system all reader -``` - -#### Create a new member user - -!!! tip "Make sure to set the password accordingly" - - ``` shell - PASSWORD=SuperSecrete - ``` - -``` shell -openstack --os-cloud default user create --project platform-services --password ${PASSWORD} platform-services --domain default -``` - -##### Add the member roles to the new platform-services user - -``` shell -openstack --os-cloud default role add --user platform-services --project platform-services member --inherited -openstack --os-cloud default role add --user platform-services --domain default member --inherited -``` - -#### Create a new core user - -!!! tip "Make sure to set the password accordingly" - - ``` shell - PASSWORD=SuperSecrete - ``` - -``` shell -openstack --os-cloud default user create --project platform-services --password ${PASSWORD} platform-services-core --domain default -``` - -##### Add the member role to the new core user - -``` shell -openstack --os-cloud default role add --user platform-services-core --project platform-services member --inherited -``` - -##### Add the reader roles for user `platform-services-core` to the `default` domain - -``` shell -openstack --os-cloud default role add --user platform-services-core --domain default reader --inherited -``` - -##### Add the reader role for user `platform-services-core` to the `rackspace_cloud_domain` domain - -``` shell -openstack --os-cloud default role add --user platform-services-core --domain rackspace_cloud_domain reader --inherited -``` - -##### Add the reader role for user `platform-services-core` to the system - -``` shell -openstack --os-cloud default role add --user platform-services-core --system all reader -``` - -#### Create a new alt user - -!!! tip "Make sure to set the password accordingly" - - ``` shell - PASSWORD=SuperSecrete - ``` - -``` shell -openstack --os-cloud default user create --project platform-services --password ${PASSWORD} platform-services-core-alt --domain default -``` - -##### Add the member role to the new core-alt user - -``` shell -openstack --os-cloud default role add --user platform-services-core-alt --project platform-services member --inherited -``` - -##### Add the reader roles for user `platform-services-core-alt` to the `default` domain - -``` shell -openstack --os-cloud default role add --user platform-services-core-alt --domain default reader --inherited -``` - -##### Add the reader role for user `platform-services-core-alt` to the `rackspace_cloud_domain` domain - -``` shell -openstack --os-cloud default role add --user platform-services-core-alt --domain rackspace_cloud_domain reader --inherited -``` - -##### Add the reader role for user `platform-services-core-alt` to the system - -``` shell -openstack --os-cloud default role add --user platform-services-core-alt --system all reader -``` diff --git a/docs/openstack-keystone.md b/docs/openstack-keystone.md deleted file mode 100644 index 8e38fdf49..000000000 --- a/docs/openstack-keystone.md +++ /dev/null @@ -1,64 +0,0 @@ -# Deploy Keystone - -OpenStack Keystone is the identity service within the OpenStack ecosystem, serving as the central authentication and authorization hub for all OpenStack services. Keystone manages user accounts, roles, and permissions, enabling secure access control across the cloud environment. It provides token-based authentication and supports multiple authentication methods, including username/password, LDAP, and federated identity. Keystone also offers a catalog of services, allowing users and services to discover and communicate with other OpenStack components. In this document, we will discuss the deployment of OpenStack Keystone using Genestack. Genestack simplifies the deployment and scaling of Keystone, ensuring robust authentication and authorization across the OpenStack architecture, and enhancing the overall security and manageability of cloud resources. - -## Create secrets - -!!! note "Information about the secretes used" - - Manual secret generation is only required if you haven't run the `create-secrets.sh` script located in `/opt/genestack/bin`. - - ??? example "Example secret generation" - - ``` shell - kubectl --namespace openstack \ - create secret generic keystone-rabbitmq-password \ - --type Opaque \ - --from-literal=username="keystone" \ - --from-literal=password="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-64};echo;)" - kubectl --namespace openstack \ - create secret generic keystone-db-password \ - --type Opaque \ - --from-literal=password="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-32};echo;)" - kubectl --namespace openstack \ - create secret generic keystone-admin \ - --type Opaque \ - --from-literal=password="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-32};echo;)" - kubectl --namespace openstack \ - create secret generic keystone-credential-keys \ - --type Opaque \ - --from-literal=password="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-32};echo;)" - ``` - -## Run the package deployment - -!!! example "Run the Keystone deployment Script `bin/install-keystone.sh`" - - ``` shell - --8<-- "bin/install-keystone.sh" - ``` - -!!! tip - - You may need to provide custom values to configure your openstack services, for a simple single region or lab deployment you can supply an additional overrides flag using the example found at `base-helm-configs/aio-example-openstack-overrides.yaml`. - In other cases such as a multi-region deployment you may want to view the [Multi-Region Support](multi-region-support.md) guide to for a workflow solution. - -!!! note - - The image used here allows the system to run with RXT global authentication federation. The federated plugin can be seen here, https://github.com/cloudnull/keystone-rxt - -Deploy the openstack admin client pod (optional) - -``` shell -kubectl --namespace openstack apply -f /etc/genestack/manifests/utils/utils-openstack-client-admin.yaml -``` - -## Validate functionality - -``` shell -kubectl --namespace openstack exec -ti openstack-admin-client -- openstack user list -``` - -## Demo - -[![asciicast](https://asciinema.org/a/629802.svg)](https://asciinema.org/a/629802) diff --git a/docs/openstack-load-balancer.md b/docs/openstack-load-balancer.md deleted file mode 100644 index 1ebd05d07..000000000 --- a/docs/openstack-load-balancer.md +++ /dev/null @@ -1,130 +0,0 @@ -# Openstack Load Balancers - -To read more about Openstack load balancers please visit the [upstream docs](https://docs.openstack.org/python-openstackclient/latest/cli/plugin-commands/octavia.html). - -### Create a Load Balancer - -``` shell -openstack --os-cloud {user cloud name} loadbalancer create - [--name ] - [--description ] - [--vip-address ] - [--vip-port-id ] - [--vip-subnet-id ] - [--vip-network-id ] - [--vip-qos-policy-id ] - [--additional-vip subnet-id=[,ip-address=]] - [--project ] - [--provider ] - [--availability-zone ] - [--enable | --disable] - [--flavor ] - [--wait] - [--tag | --no-tag] -``` - -### List Load Balancers - -``` shell -openstack --os-cloud {user cloud name} loadbalancer list - [--sort-column SORT_COLUMN] - [--sort-ascending | --sort-descending] - [--name ] - [--enable | --disable] - [--project ] - [--vip-network-id ] - [--vip-subnet-id ] - [--vip-qos-policy-id ] - [--vip-port-id ] - [--provisioning-status {ACTIVE,ERROR,PENDING_CREATE,PENDING_UPDATE,PENDING_DELETE}] - [--operating-status {ONLINE,DRAINING,OFFLINE,DEGRADED,ERROR,NO_MONITOR}] - [--provider ] - [--flavor ] - [--availability-zone ] - [--tags [,,...]] - [--any-tags [,,...]] - [--not-tags [,,...]] - [--not-any-tags [,,...]] -``` - -### Delete Load Balancers - -``` shell -openstack --os-cloud {user cloud name} loadbalancer delete [--cascade] [--wait] -``` - -### Show Load Balancer's Details - -``` shell -openstack --os-cloud {user cloud name} loadbalancer show -``` - -### Update Load Balancer - -``` shell -openstack --os-cloud {user cloud name} loadbalancer set - [--name ] - [--description ] - [--vip-qos-policy-id ] - [--enable | --disable] - [--wait] - [--tag ] - [--no-tag] - - ``` - -### Create Load Balancer Listener - -``` shell -openstack --os-cloud {user cloud name} loadbalancer listener create - [--name ] - [--description ] - --protocol - {TCP,HTTP,HTTPS,TERMINATED_HTTPS,UDP,SCTP,PROMETHEUS} - [--connection-limit ] - [--default-pool ] - [--default-tls-container-ref ] - [--sni-container-refs [ ...]] - [--insert-headers ] - --protocol-port - [--timeout-client-data ] - [--timeout-member-connect ] - [--timeout-member-data ] - [--timeout-tcp-inspect ] - [--enable | --disable] - [--client-ca-tls-container-ref ] - [--client-authentication {NONE,OPTIONAL,MANDATORY}] - [--client-crl-container-ref ] - [--allowed-cidr []] - [--wait] - [--tls-ciphers ] - [--tls-version []] - [--alpn-protocol []] - [--hsts-max-age ] - [--hsts-include-subdomains] - [--hsts-preload] - [--tag | --no-tag] - - ``` - -### List Load Balancer Listeners - -``` shell -openstack --os-cloud {user cloud name} loadbalancer listener list - [--sort-column SORT_COLUMN] - [--sort-ascending | --sort-descending] - [--name ] - [--loadbalancer ] - [--enable | --disable] - [--project ] - [--tags [,,...]] - [--any-tags [,,...]] - [--not-tags [,,...]] - [--not-any-tags [,,...]] -``` - -### Delete Load Balancer Listeners - -``` shell -openstack loadbalancer listener delete [--wait] -``` diff --git a/docs/openstack-magnum.md b/docs/openstack-magnum.md deleted file mode 100644 index a72a7bba1..000000000 --- a/docs/openstack-magnum.md +++ /dev/null @@ -1,54 +0,0 @@ -# Deploy Magnum - -OpenStack Magnum is the container orchestration service within the OpenStack ecosystem, designed to provide an easy-to-use interface for deploying and managing container clusters, such as Kubernetes. Magnum enables cloud users to harness the power of containerization by allowing them to create and manage container clusters as first-class resources within the OpenStack environment. This service integrates seamlessly with other OpenStack components, enabling containers to take full advantage of OpenStack’s networking, storage, and compute capabilities. In this document, we will outline the deployment of OpenStack Magnum using Genestac. By utilizing Genestack, the deployment of Magnum is streamlined, allowing organizations to efficiently manage and scale containerized applications alongside traditional virtual machine workloads within their cloud infrastructure. - -!!! note - - Before Magnum can be deployed, you must setup and deploy [Barbican](openstack-barbican.md) first. - -## Create secrets - -!!! note "Information about the secrets used" - - Manual secret generation is only required if you haven't run the `create-secrets.sh` script located in `/opt/genestack/bin`. - - ??? example "Example secret generation" - - ``` shell - kubectl --namespace openstack \ - create secret generic magnum-rabbitmq-password \ - --type Opaque \ - --from-literal=username="magnum" \ - --from-literal=password="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-64};echo;)" - kubectl --namespace openstack \ - create secret generic magnum-db-password \ - --type Opaque \ - --from-literal=password="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-32};echo;)" - kubectl --namespace openstack \ - create secret generic magnum-admin \ - --type Opaque \ - --from-literal=password="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-32};echo;)" - ``` - -## Run the package deployment - -!!! example "Run the Magnum deployment Script `bin/install-magnum.sh`" - - ``` shell - --8<-- "bin/install-magnum.sh" - ``` - -!!! tip - - You may need to provide custom values to configure your openstack services, for a simple single region or lab deployment you can supply an additional overrides flag using the example found at `base-helm-configs/aio-example-openstack-overrides.yaml`. - In other cases such as a multi-region deployment you may want to view the [Multi-Region Support](multi-region-support.md) guide to for a workflow solution. - -## Validate functionality - -``` shell -kubectl --namespace openstack exec -ti openstack-admin-client -- openstack coe cluster list -``` - -## Create a Public ClusterTemplate - -User must have the admin role to create the public ClusterTemplate. For instructions on creating and using it to deploy a new Kubernetes cluster, please refer to the ClusterTemplate section in the [Magnum Kubernetes Cluster Setup Guide](https://docs.rackspacecloud.com/magnum-kubernetes-cluster-setup-guide/#clustertemplate). diff --git a/docs/openstack-metrics.md b/docs/openstack-metrics.md deleted file mode 100644 index bc60247fa..000000000 --- a/docs/openstack-metrics.md +++ /dev/null @@ -1,301 +0,0 @@ -# OpenStack Metrics - -This page summarizes usage of common `openstack metric` commands, which are used -to interact with the Telemetry service (_[Gnocchi](metering-gnocchi.md)_) for -managing metrics, measures, and resources in OpenStack. - -## CLI Commands - -### **metric list** - -Lists all metrics available in the environment. - -**Usage:** - -```shell -openstack metric list -``` -**Options:** - -- `--details`: Show detailed information about each metric. - -### **metric show** - -Shows detailed information about a specific metric. - -**Usage**: - -```shell -openstack metric show -``` - -### **metric create** - -Creates a new metric for a resource - -**Usage**: - -```shell -openstack metric create \ - --resource-id \ - --archive-policy-name -``` - -**Options**: - -- `--unit `: Specify the unit of measurement (e.g., MB, GB). -- `--resource-id `: ID of the resource to associate the metric - with. -- `--archive-policy-name `: Name of the archive policy - -### **metric delete** - -Deletes a specific metric. - -**Usage**: - -```shell -openstack metric delete -``` - -### **metric measures show** - -Retrieves the measures (data points) of a metric. - -**Usage**: - -```shell -openstack metric measures show -``` - -**Options**: - -- `--aggregation `: Aggregation method to apply (e.g., mean, sum). -- `--start `: Start time for retrieving measures. -- `--stop `: End time for retrieving measures. - -### **metric resource list** - -Lists all resources that are associated with metrics. - -**Usage**: - -```shell -openstack metric resource list -``` - -**Options**: - -- `--type `: Filter by resource type (e.g., instance, volume). - -### **metric resource show** - -Shows detailed information about a specific resource, including its metrics. - -**Usage**: - -```shell -openstack metric resource show -``` - -### **metric resource create** - -Creates a new resource and associates it with metrics. - -**Usage**: - -```shell -openstack metric resource create --type -``` - -**Options**: - -- `--type `: Type of resource (e.g., instance, volume). -- `--attribute `: Name and value of an attribute separated with a ':' -- `--add-metric `: name:id of a metric to add -- `--create-metric -``` - -**Options**: - -- `--type `: Type of resource (e.g., instance, volume). -- `--attribute `: Name and value of an attribute separated with a ':' -- `--add-metric `: name:id of a metric to add -- `--create-metric `: Name of a metric to delete - -### **metric resource delete** - -Deletes a specific resource and its associated metrics. - -**Usage**: - -```shell -openstack metric resource delete -``` - -### **metric resource-type list** - -List all existing resource types - -**Usage**: - -```shell -openstack metric resource-type list -``` - -### **metric resource-type show** - -Show a specific resource type - -**Usage**: - -```shell -openstack metric resource-type show -``` - -### **metric resource-type create** - -Creates a new resource-type - -```shell -openstack metric resource-type create \ - --attribute -``` - -**Options**: - -- `--attribute `: attribute definition - > attribute_name:attribute_type:attribute_is_required:attribute_type_option_name=attribute_type_option_value - -### **metric resource-type update** - -Updates an existing resource-type - -```shell -openstack metric resource-type update \ - --attribute \ - --remove-attribute -``` - -**Options**: - -- `--attribute `: attribute definition - > attribute_name:attribute_type:attribute_is_required:attribute_type_option_name=attribute_type_option_value -- `--remove-attribute `: removes named - attribute - -### **metric archive-policy list** - -List all archive policies - -**Usage**: - -```shell -openstack metric archive-policy list -``` - -### **metric archive-policy show** - -Shows a specific archive policy - -**Usage**: - -```shell -openstack metric archive-policy show -``` - -### **metric archive-policy create** - -Creates a new archive policy - -**Usage**: - -```shell -openstack metric archive-policy create \ - --definition \ - --back-window \ - --aggregation-method -``` - -**Options**: - -- `--definition `: two attributes (comma separated) of an archive - policy definition with its name and value separated with a ':' -- `--back-window `: back window of the archive policy - > If we define a policy that specifies a granularity of 1 hour then set the - back_window to 3, Gnocchi will process data points that arrive up to 3 hours - late. -- `--aggregation-method `: aggregation method of the archive policy - -### **metric archive-policy update** - -Updates an existing archive policy - -**Usage**: - -```shell -openstack metric archive-policy update \ - --definition -``` - -**Options**: - -- `--definition `: two attributes (comma separated) of an archive - policy definition with its name and value separated with a ':' - -## Example Use Cases - -### **Show Measures of a Specific Metric** - -```shell -openstack metric measures show --aggregation mean --start 2024-01-01 --stop 2024-01-31 -``` - -### **Create a New Resource with a Metric** - -```shell -openstack metric resource create instance --name my_instance -openstack metric create cpu_usage --resource-id --unit GHz -``` - -### **Update the `image` Resource Type** - -In this example, we add a few additional useful image properties to the -image resource type that we want to store. - -```shell -openstack resource-type update image -a os_type:string:false:max_length=255 -openstack resource-type update image -a os_distro:string:false:max_length=255 -openstack resource-type update image -a os_version:string:false:max_length=255 -``` - -!!! tip "Update related Ceilometer resource type attributes" - - Note that changes to resource types to accomodate additional parameters - don't just magically work. One must update Ceilometer's resource_type - definitions. For the `image` resource_type, we do that in the ceilometer - helm chart overrides here (for example), appending the keys and populate - the values using the related resource_metadata payload: - - ```yaml - conf: - gnocchi_resources: - resources: - - resource_type: image - attributes: - os_type: resource_metadata.properties.os_type - os_distro: resource_metadata.properties.os_distro - os_version: resource_metadata.properties.os_version - ``` diff --git a/docs/openstack-networks.md b/docs/openstack-networks.md deleted file mode 100644 index b41a41980..000000000 --- a/docs/openstack-networks.md +++ /dev/null @@ -1,102 +0,0 @@ -# Openstack Networks - -To read more about Openstack networks please visit the [upstream docs](https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/network.html). - -### Create an Openstack Network - -``` shell -openstack --os-cloud {user cloud name} network create - [--extra-property type=,name=,value=] - [--share | --no-share] - [--enable | --disable] - [--project ] - [--description ] - [--mtu ] - [--project-domain ] - [--availability-zone-hint ] - [--enable-port-security | --disable-port-security] - [--external | --internal] - [--default | --no-default] - [--qos-policy ] - [--transparent-vlan | --no-transparent-vlan] - [--provider-network-type ] - [--provider-physical-network ] - [--provider-segment ] - [--dns-domain ] - [--tag | --no-tag] - --subnet - -``` - -### List Openstack Networks - -``` shell -openstack --os-cloud {user cloud name} network list - [--sort-column SORT_COLUMN] - [--sort-ascending | --sort-descending] - [--external | --internal] - [--long] - [--name ] - [--enable | --disable] - [--project ] - [--project-domain ] - [--share | --no-share] - [--status ] - [--provider-network-type ] - [--provider-physical-network ] - [--provider-segment ] - [--agent ] - [--tags [,,...]] - [--any-tags [,,...]] - [--not-tags [,,...]] - [--not-any-tags [,,...]] -``` - -### Set Openstack Network Properties - -``` shell -openstack --os-cloud {user cloud name} network set - [--extra-property type=,name=,value=] - [--name ] - [--enable | --disable] - [--share | --no-share] - [--description ] - [--mtu ] - [--enable-port-security | --disable-port-security] - [--external | --internal] - [--default | --no-default] - [--qos-policy | --no-qos-policy] - [--tag ] - [--no-tag] - [--provider-network-type ] - [--provider-physical-network ] - [--provider-segment ] - [--dns-domain ] - -``` - -### Show Openstack Network Details - -``` shell -openstack --os-cloud {user cloud name} network show -``` - -### Delete Openstack Network - -``` shell -openstack --os-cloud {user cloud name} network delete [ ...] -``` - -## Example: Creating an Openstack Network and adding Subnets - -Creating the network - -``` shell -openstack --os-cloud {cloud_name} network create {network-name} -``` - -When creating the subnet users have the option to use ipv4 or ipv6 on this example we will be using ipv4. The user will also need to specify their network name to ensure that their subnets are connected to the network they created. - -``` shell -openstack --os-cloud {cloud_name} subnet create --ip-version 4 --subnet-range 172.18.107.0/24 --network {network-name} {subnet-name} -``` diff --git a/docs/openstack-neutron-networks.md b/docs/openstack-neutron-networks.md deleted file mode 100644 index 11cb2ad8b..000000000 --- a/docs/openstack-neutron-networks.md +++ /dev/null @@ -1,82 +0,0 @@ -# Creating Different Neutron Network Types - -The following commands are examples of creating several different network types. -NOTE: When creating the subnet we are specifically limiting neutrons ability to attach -ip's from Shared Provider networks directly to instances with --service-type. If you want -to attach Shared Provider Network's ip's directly to instances, remove lines beginning with ---service-type - -## Create Shared Provider Networks - -### Flat Network - -``` shell -openstack --os-cloud default network create --share \ - --availability-zone-hint az1 \ - --external \ - --provider-network-type flat \ - --provider-physical-network physnet1 \ - flat -``` - -#### Flat Subnet - -``` shell -openstack --os-cloud default subnet create --subnet-range 172.16.24.0/22 \ - --gateway 172.16.24.2 \ - --dns-nameserver 172.16.24.2 \ - --allocation-pool start=172.16.25.150,end=172.16.25.200 \ - --dhcp \ - --network flat \ - --service-type network:floatingip \ - --service-type network:router_gateway \ - --service-type network:distributed \ - flat_subnet -``` - -### VLAN Network - -``` shell -openstack --os-cloud default network create --share \ - --availability-zone-hint az1 \ - --external \ - --provider-segment 404 \ - --provider-network-type vlan \ - --provider-physical-network physnet1 \ - vlan404 -``` - -#### VLAN Subnet - -``` shell -openstack --os-cloud default subnet create --subnet-range 10.10.10.0/23 \ - --gateway 10.10.10.1 \ - --dns-nameserver 10.10.10.1 \ - --allocation-pool start=10.10.11.10,end=10.10.11.254 \ - --dhcp \ - --network vlan404 \ - --service-type network:floatingip \ - --service-type network:router_gateway \ - --service-type network:distributed \ - vlan404_subnet -``` - -## Creating Tenant type networks - -### L3 (Tenant) Network - -``` shell -openstack --os-cloud default network create l3 -``` - -#### L3 (Tenant) Subnet - -``` shell -openstack --os-cloud default subnet create --subnet-range 10.0.10.0/24 \ - --gateway 10.0.10.1 \ - --dns-nameserver 1.1.1.1 \ - --allocation-pool start=10.0.10.2,end=10.0.10.254 \ - --dhcp \ - --network l3 \ - l3_subnet -``` diff --git a/docs/openstack-object-storage-swift.md b/docs/openstack-object-storage-swift.md deleted file mode 100644 index aeb528c98..000000000 --- a/docs/openstack-object-storage-swift.md +++ /dev/null @@ -1,465 +0,0 @@ -# What is Openstack Swift Object Storage? - -Swift Object Storage is a component of the greater Openstack ecosystem. It was one of the first core components of Openstack along side Nova in the "Austin" release. It has been used internally by Rackspace for their Object Storage offering along with many other organizations. It provides a scalable and durable storage solution for unstructured data such as backups, multimedia files and big data. - -## Why Openstack Swift Object Storage? - -**Scalability:** Swift is designed to handle vast amounts of data operating in a single or multi tenant environment. Each of the core services can be scaled up and out independently of each other. If hotspots start to happen on a single tier such as Object additional resources can be added mitigate the issue. Each service can be broken out and scaled independently of each other depending on the use case and the data rate occurring on each tier. - -**Durability**: Data placement is controlled by the operator of the cluster and Swift supports two distinctive methods of storing data. **Replica** is the most common, fastest and least efficient means to store objects. Replicated count is configured based on durability and environmental needs. Swift supports Replicated copies 2-N, and can be changed gradually on a cluster if the need arises (scale out, multi region, etc). Swift also support erasure coding support in its object storage class, powered by liberasurecode, it supports multiple K+M values to store your data. Benefits from using erasure coded objects include higher durability in the event of a disk failure, better storage efficiency of object but at the cost of higher CPU consumption. Swift also performs background audits on all data, ensuring that your data is retrievable, readable and unaltered. - -**Total Cost of Ownership:** By combining Swift's scale up and out architecture of its services we can pinpoint hotspots in a Swift deployment and be highly prescriptive in how we tackle the issue. Gone are the days of "throwing hardware" at the solution. Understanding the pedigree of the data and the use case Swift can also use that same prescriptive methodology to architecting and maintaining the right durability of your data to meet your organizations needs. - -## Use Cases for Swift Object - -**Backup:** Most popular software backup suites can use Swift/S3 endpoint natively out of the box with little to no effort. Swift Object can be used as the primary, secondary or offsite backup to meet the needs of your organization. By leveraging Swift we deliver a cost effect and durable solution to your backup data. You can also leverage multiple distinctive Swift endpoints to further separate your data and give clear distinctive regional boundaries of where your data lives at any given time. - -**Archival**: By leveraging Swift CLI's, S3 CLI's, rclone or other popular GUI based Object managers such as Cyberduck you can leverage Swift for longterm storage of archival storage of your files. If consuming a block device is more inline with your organizational needs Storage Gateways or FUSE drivers can be leveraged over changing the pipeline in your organization. Swift helps maintain automatic deletion of files when used in conjunction with Swift Object Expirer, this will help keep costs under control by setting delete-at-dates, this can be especially useful for CCTV footage. - -**Data Lakes:** Swift can serve as the underlying storage driver for data lakes. Swift's ability to store large volumes of unstructured data makes it an ideal choice for anyone looking for a durable and cost effective storage layer for any data lake layer to manage. Integrating your data lake application layer is as simple as consuming the Swift API or S3 API RESTful endpoint, creating containers/buckets and loading your unstructured data in to Swift. Data lake outputs can also be stored for further refinement or consumption into another container/bucket making Swift a one stop shop for your data transformation needs. - -**Artifact Storage:** Swift Object Storage can serve as a robust storage solution for managing artifacts. It can handle large binaries and files efficiently, providing scalability and durability. Swift allows for the storage of artifacts with associated metadata, making it easier to manage different versions of artifacts and track changes. Many CI/CD (Continuous Integration/Continuous Deployment) pipelines utilize object storage like Swift to store build artifacts. After a successful build, the artifacts can be uploaded to Swift for deployment or further testing. - -# Getting Started with Swift Object Storage - -Onboarding with Openstack Swift Object store is covered in the following trove of documents located here: - -[Rackspace OpenStack Flex Onboarding](https://docs.rackspacecloud.com/cloud-onboarding-welcome/) - -Topics include Swift CLI, S3cmd, rclone setup. - ------- - -# **Advanced Features** - - -## **Object Versioning**: - -Swift allows the end user to store multiple versions of the same object so you can recover from an unintended overwrite or rollback of an object to an earlier date in time. Object versioning works with any type of content uploaded to Swift. - -**Example Using `X-Versions-Location`** - -1. Create a container named '*current*': - - ``` - # curl -i $publicURL/current -X PUT -H "Content-Length: 0" -H "X-Auth-Token: $token" -H "X-Versions-Location: archive" - ``` - - ``` - HTTP/1.1 201 Created - Content-Length: 0 - Content-Type: text/html; charset=UTF-8 - X-Trans-Id: txb91810fb717347d09eec8-0052e18997 - X-Openstack-Request-Id: txb91810fb717347d09eec8-0052e18997 - Date: Thu, 23 Jan 2014 21:28:55 GMT - ``` - -2. Upload an object named '*my_object*' to the '*current*' container: - -``` -# curl -i $publicURL/current/my_object --data-binary 1 -X PUT -H "Content-Length: 0" -H "X-Auth-Token: $token" -``` - -``` -HTTP/1.1 201 Created -Last-Modified: Thu, 23 Jan 2014 21:31:22 GMT -Content-Length: 0 -Etag: d41d8cd98f00b204e9800998ecf8427e -Content-Type: text/html; charset=UTF-8 -X-Trans-Id: tx5992d536a4bd4fec973aa-0052e18a2a -X-Openstack-Request-Id: tx5992d536a4bd4fec973aa-0052e18a2a -Date: Thu, 23 Jan 2014 21:31:22 GMT -``` - -Nothing is written to the non-current version container when you initially **PUT** an object in the `current` container. However, subsequent **PUT** requests that edit an object trigger the creation of a version of that object in the `archive` container. - -These non-current versions are named as follows: - -``` -/ -``` - -Where `length` is the 3-character, zero-padded hexadecimal character length of the object, `` is the object name, and `` is the time when the object was initially created as a current version. - -3. Create a second version of the Object in the '*current*' container: - -``` -curl -i $publicURL/current/my_object --data-binary 2 -X PUT -H "Content-Length: 0" -H "X-Auth-Token: $token" -``` - -``` -HTTP/1.1 201 Created -Last-Modified: Thu, 23 Jan 2014 21:41:32 GMT -Content-Length: 0 -Etag: d41d8cd98f00b204e9800998ecf8427e -Content-Type: text/html; charset=UTF-8 -X-Trans-Id: tx468287ce4fc94eada96ec-0052e18c8c -X-Openstack-Request-Id: tx468287ce4fc94eada96ec-0052e18c8c -Date: Thu, 23 Jan 2014 21:41:32 GMT -``` - -4. Issue a **GET** request to the versioned object '*my_object*' to get the current version value of the object. - - List older versions of the object in the '*archive*' container: - -``` -# curl -i $publicURL/archive?prefix=009my_object -X GET -H "X-Auth-Token: $token" -``` - -``` -HTTP/1.1 200 OK -Content-Length: 30 -X-Container-Object-Count: 1 -Accept-Ranges: bytes -X-Timestamp: 1390513280.79684 -X-Container-Bytes-Used: 0 -Content-Type: text/plain; charset=utf-8 -X-Trans-Id: tx9a441884997542d3a5868-0052e18d8e -X-Openstack-Request-Id: tx9a441884997542d3a5868-0052e18d8e -Date: Thu, 23 Jan 2014 21:45:50 GMT - -009my_object/1390512682.92052 -``` - -!!! note - - A **POST** request to a versioned object updates only the metadata for the object and does not create a new version of the object. New versions are created only when the content of the object changes. - -5. Issue a **DELETE** request to a versioned object to remove the current version of the object and replace it with the next-most current version in the non-current container. - -``` -# curl -i $publicURL/current/my_object -X DELETE -H "X-Auth-Token: $token" -``` - -``` -HTTP/1.1 204 No Content -Content-Length: 0 -Content-Type: text/html; charset=UTF-8 -X-Trans-Id: tx006d944e02494e229b8ee-0052e18edd -X-Openstack-Request-Id: tx006d944e02494e229b8ee-0052e18edd -Date: Thu, 23 Jan 2014 21:51:25 GMT -``` - -List objects in the `archive` container to show that the archived object was moved back to the '*current*' container: - -``` -# curl -i $publicURL/archive?prefix=009my_object -X GET -H "X-Auth-Token: $token" -``` - -``` -HTTP/1.1 204 No Content -Content-Length: 0 -X-Container-Object-Count: 0 -Accept-Ranges: bytes -X-Timestamp: 1390513280.79684 -X-Container-Bytes-Used: 0 -Content-Type: text/html; charset=UTF-8 -X-Trans-Id: tx044f2a05f56f4997af737-0052e18eed -X-Openstack-Request-Id: tx044f2a05f56f4997af737-0052e18eed -Date: Thu, 23 Jan 2014 21:51:41 GMT -``` - -!!! note - - This next-most current version carries with it any metadata last set on it. If want to completely remove an object and you have five versions of it, you must **DELETE** it five times. - -**Example Using `X-History-Location`** - -1. Create '*current*' container: - -``` -# curl -i $publicURL/current -X PUT -H "Content-Length: 0" -H "X-Auth-Token: $token" -H "X-History-Location: archive" -``` - -``` -HTTP/1.1 201 Created -Content-Length: 0 -Content-Type: text/html; charset=UTF-8 -X-Trans-Id: txb91810fb717347d09eec8-0052e18997 -X-Openstack-Request-Id: txb91810fb717347d09eec8-0052e18997 -Date: Thu, 23 Jan 2014 21:28:55 GMT -``` - -2. Upload '*my_object*' into the '*current*' container: - -``` -# curl -i $publicURL/current/my_object --data-binary 1 -X PUT -H "Content-Length: 0" -H "X-Auth-Token: $token" -``` - -``` -HTTP/1.1 201 Created -Last-Modified: Thu, 23 Jan 2014 21:31:22 GMT -Content-Length: 0 -Etag: d41d8cd98f00b204e9800998ecf8427e -Content-Type: text/html; charset=UTF-8 -X-Trans-Id: tx5992d536a4bd4fec973aa-0052e18a2a -X-Openstack-Request-Id: tx5992d536a4bd4fec973aa-0052e18a2a -Date: Thu, 23 Jan 2014 21:31:22 GMT -``` - -Nothing is written to the non-current version container when you initially **PUT** an object in the '*current*' container. However, subsequent **PUT** requests that edit an object trigger the creation of a version of that object in the '*archive*' container. - -These non-current versions are named as follows: - -``` -/ -``` - -Where `length` is the 3-character, zero-padded hexadecimal character length of the object, `` is the object name, and `` is the time when the object was initially created as a current version. - -3. Create a second version of the object in the '*current*' container: - -``` -# curl -i $publicURL/current/my_object --data-binary 2 -X PUT -H "Content-Length: 0" -H "X-Auth-Token: $token" -``` - -``` -HTTP/1.1 201 Created -Last-Modified: Thu, 23 Jan 2014 21:41:32 GMT -Content-Length: 0 -Etag: d41d8cd98f00b204e9800998ecf8427e -Content-Type: text/html; charset=UTF-8 -X-Trans-Id: tx468287ce4fc94eada96ec-0052e18c8c -X-Openstack-Request-Id: tx468287ce4fc94eada96ec-0052e18c8c -Date: Thu, 23 Jan 2014 21:41:32 GMT -``` - -4. Issue a **GET** request to the versioned object '*my_object*' to get the current version value of the object. - - List older versions of the object in the '*archive*' container: - -``` -# curl -i $publicURL/archive?prefix=009my_object -X GET -H "X-Auth-Token: $token" -``` - -``` -HTTP/1.1 200 OK -Content-Length: 30 -X-Container-Object-Count: 1 -Accept-Ranges: bytes -X-Timestamp: 1390513280.79684 -X-Container-Bytes-Used: 0 -Content-Type: text/plain; charset=utf-8 -X-Trans-Id: tx9a441884997542d3a5868-0052e18d8e -X-Openstack-Request-Id: tx9a441884997542d3a5868-0052e18d8e -Date: Thu, 23 Jan 2014 21:45:50 GMT - -009my_object/1390512682.92052 -``` - -!!! note - - A **POST** request to a versioned object updates only the metadata for the object and does not create a new version of the object. New versions are created only when the content of the object changes. - -5. Issue a **DELETE** request to a versioned object to copy the current version of the object to the archive container then delete it from the current container. Subsequent **GET** requests to the object in the current container will return `404 Not Found`. - -``` -# curl -i $publicURL/current/my_object -X DELETE -H "X-Auth-Token: $token" -``` - -``` -HTTP/1.1 204 No Content -Content-Length: 0 -Content-Type: text/html; charset=UTF-8 -X-Trans-Id: tx006d944e02494e229b8ee-0052e18edd -X-Openstack-Request-Id: tx006d944e02494e229b8ee-0052e18edd -Date: Thu, 23 Jan 2014 21:51:25 GMT -``` - -List older versions of the object in the '*archive*' container: - -``` -# curl -i $publicURL/archive?prefix=009my_object -X GET -H "X-Auth-Token: $token" -``` - -``` -HTTP/1.1 200 OK -Content-Length: 90 -X-Container-Object-Count: 3 -Accept-Ranges: bytes -X-Timestamp: 1390513280.79684 -X-Container-Bytes-Used: 0 -Content-Type: text/html; charset=UTF-8 -X-Trans-Id: tx044f2a05f56f4997af737-0052e18eed -X-Openstack-Request-Id: tx044f2a05f56f4997af737-0052e18eed -Date: Thu, 23 Jan 2014 21:51:41 GMT - -009my_object/1390512682.92052 -009my_object/1390512692.23062 -009my_object/1390513885.67732 -``` - -!!! note - - In addition to the two previous versions of the object, the archive container has a “delete marker” to record when the object was deleted. - To permanently delete a previous version, issue a **DELETE** to the version in the archive container. - -**Disabling Object Versioning** - -To disable object versioning for the `current` container, remove its `X-Versions-Location` metadata header by sending an empty key value. - -``` -# curl -i $publicURL/current -X PUT -H "Content-Length: 0" -H "X-Auth-Token: $token" -H "X-Versions-Location: " -``` - -``` -HTTP/1.1 202 Accepted -Content-Length: 76 -Content-Type: text/html; charset=UTF-8 -X-Trans-Id: txe2476de217134549996d0-0052e19038 -X-Openstack-Request-Id: txe2476de217134549996d0-0052e19038 -Date: Thu, 23 Jan 2014 21:57:12 GMT - -

Accepted

The request is accepted for processing.

-``` - ------- - -## **Custom Object Metadata**: - -Swift allows end users the ability to tag Object metadata, this is extremely useful in identifying the source of data, notes about the object or the current processing state when the object is consumed by a data lake process. - -Using the swift CLI: - -``` -swift upload -m ``"X-Object-Meta-Security: TopSecret" HR_files payroll_information.txt -``` - -Using cURL: - -``` -curl -X POST -H "X-Auth-Token:$TOKEN" -H 'X-Object-Meta-Security: TopSecret' $STORAGE_URL/HR_files/payroll_information.txt -``` - ------- - -## **Static Web Hosting:** - -Using Swift Object you can serve static websites built in HTML to clients, this takes the need for any web servers out if your infrastructure and relies on Swift's robust infrastructure to serve web files out. - -1. Make container publicly readable: - -``` -# swift post -r '.r:*,.rlistings' web_container -``` - -2. Set site index file, in this case we will use *index.html* as the index file for our site: - -``` -# swift post -m 'web-index:index.html' web_container -``` - -3. Optional: Enable file listing, this allows the container to be browsed when an *index.html* file is not specified: - -``` -# swift post -m 'web-listings: true' web_container -``` - -4. Optional: Enable CSS for file listing when site index file is not specified: - -``` -# swift post -m 'web-listings-css:listings.css' web_container -``` - -5. Set custom error pages for any visitors accessing your static website, you may specify custom 401, 404 error pages or a catch all. - -``` -# swift post -m 'web-error:error.html' web_container -``` - -!!! note - - More information on static websites can be found here: - [Swift Create static website](https://docs.openstack.org/ocata/user-guide/cli-swift-static-website.html) - ------- - -## **Lifecycle Management** - -In OpenStack Swift, the expiration of objects can be managed using a feature called **object expiration**. This allows you to automatically delete objects after a specified period, which is useful for managing storage costs and keeping your data organized and keep in compliance with our organization data retention requirements. - -There are two ways to set the object expiration, date and time based or after N seconds have passed. - -Set an object to expire at an absolute time (in Unix time): - -``` -# swift post CONTAINER OBJECT_FILENAME -H "X-Delete-At:UNIX_TIME" -``` - -Set an object to expire after N seconds have passed: - -``` -# swift post CONTAINER OBJECT_FILENAME -H "X-Delete-After:SECONDS" -``` - -To check on the X-Delete-At/X-Delete-After header: - -``` -# swift stat CONTAINER OBJECT_FILENAME -``` - -To clear any X-Remove flags from an object: - -``` -# swift post CONTAINER OBJECT_FILENAME -H "X-Remove-Delete-At:" -``` - -Benefits of Object Expiration - -- **Storage Management:** Helps in managing and reclaiming storage space by removing outdated or unnecessary objects. -- **Cost Efficiency:** Reduces storage costs by preventing accumulation of unneeded data. - -This feature is particularly useful in scenarios like managing temporary files, logs, or any other data that has a defined lifecycle. - ------- - -## Swift S3 REST API - -S3 is a product of Amazon and AWS, Swift's S3 RESTful API is a middleware component that allows verb compatibly between a native Swift deployment and applications that only speak S3 API. While most functionality is present in the Swift S3 middleware, some verbs are lacking or there is not a like for like feature within Swift. For the current state of Swift and S3 verb compatibility please refer to the following upstream documentation: - -[S3/Swift REST API Comparison Matrix](https://docs.openstack.org/swift/latest/s3_compat.html) - ------- - -# **Best Practices** - -## Performance: - -- Keep object count under 500k per container -- Multiplex over multiple container if possible -- To increase throughput scale out the amount of API worker threads you have interacting with Swift endpoint - -## Securing data: - -Swift supports the optional encryption of object data at rest on storage nodes. The encryption of object data is intended to mitigate the risk of users’ data being read if an unauthorized party were to gain physical access to a disk. - -!!! note - - Swift’s data-at-rest encryption accepts plaintext object data from the client, encrypts it in the cluster, and stores the encrypted data. This protects object data from inadvertently being exposed if a data drive leaves the Swift cluster. If a user wishes to ensure that the plaintext data is always encrypted while in transit and in storage, it is strongly recommended that the data be encrypted before sending it to the Swift cluster. Encrypting on the client side is the only way to ensure that the data is fully encrypted for its entire lifecycle. - -The following data are encrypted while at rest in Swift: - -- Object content i.e. the content of an object PUT request’s body -- The entity tag (ETag) of objects that have non-zero content -- All custom user object metadata values i.e. metadata sent using X-Object-Meta- prefixed headers with PUT or POST requests - -Any data or metadata not included in the list above are not encrypted, including: - -- Account, container and object names -- Account and container custom user metadata values -- All custom user metadata names -- Object Content-Type values -- Object size -- System metadata - -All in-flight operations are encrypted using HTTPS and TLS encryption. - -## **Cost Management** - -Managing cost in Openstack Swift can be accomplished using object lifecycle management, usage monitoring and storage classes. - -**Object Lifecycle Management:** Use expiration policies to automatically delete outdated or unnecessary objects, reducing the volume of stored data. - -**Usage Monitoring:** Keep tabs on your Object storage spend by looking at overall container sizes for your organization, using 'swift stat container' will show you the overall usage of each container being hosted on Swift. - -**Storage Classes:** Consider implementing different storage classes based on access frequency and performance needs. For example, frequently accessed data can be stored in faster, more expensive storage, while infrequently accessed data can be moved to slower, cheaper storage. Use Swift to store archival data at lower costs, particularly for data that needs to be retained but is rarely accessed, by locking into a longer commitment on storing archival data you will save money month over month. diff --git a/docs/openstack-octavia.md b/docs/openstack-octavia.md deleted file mode 100644 index a2af026ba..000000000 --- a/docs/openstack-octavia.md +++ /dev/null @@ -1,147 +0,0 @@ -# Deploy Octavia - -OpenStack Octavia is the load balancing service within the OpenStack ecosystem, providing scalable and automated load -balancing for cloud applications. Octavia is designed to ensure high availability and reliability by distributing -incoming network traffic across multiple instances of an application, preventing any single instance from becoming a -bottleneck or point of failure. It supports various load balancing algorithms, health monitoring, and SSL termination, -making it a versatile tool for managing traffic within cloud environments. In this document, we will explore the -deployment of OpenStack Octavia using Genestack. By leveraging Genestack, the deployment of Octavia is streamlined, -ensuring that load balancing is seamlessly incorporated into both private and public cloud environments, enhancing -the performance and resilience of cloud applications. - -## Create secrets - -!!! note "Information about the secretes used" - - Manual secret generation is only required if you haven't run the `create-secrets.sh` script located in `/opt/genestack/bin`. - - ??? example "Example secret generation" - - ``` shell - kubectl --namespace openstack \ - create secret generic octavia-rabbitmq-password \ - --type Opaque \ - --from-literal=username="octavia" \ - --from-literal=password="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-64};echo;)" - kubectl --namespace openstack \ - create secret generic octavia-db-password \ - --type Opaque \ - --from-literal=password="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-32};echo;)" - kubectl --namespace openstack \ - create secret generic octavia-admin \ - --type Opaque \ - --from-literal=password="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-32};echo;)" - kubectl --namespace openstack \ - create secret generic octavia-certificates \ - --type Opaque \ - --from-literal=password="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-32};echo;)" - ``` - -## Prerequisite - -Before you can deploy octavia, it requires a few things to be setup ahead of time: - -* Quota check/update -* Certificate creation -* Security group configuration -* Amphora management network -* Port creation for health manager pods -* Amphora image creation -* and more - -In order to automate these tasks, we have provided an ansible role and a playbook. The playbook, `octavia-preconf-main.yaml`, -is located in the ansible/playbook directory. You will need to update the variables in the playbook to match your deployment. - -Make sure to udpate the octavia-preconf-main.yaml with the correct region, auth url, and password. - -!!! tip - - The playbook requires a few pip packages to run properly. While the dependencies for this playbook should be installed by - default, the playbook runtime can be isolated in a virtualenv if needed. - - !!! example - - ``` shell - apt-get install python3-venv python3-pip - mkdir -p ~/.venvs - python3 -m venv --system-site-packages ~/.venvs/octavia_preconf - source .venvs/octavia_preconf/bin/activate - pip install --upgrade pip - pip install "ansible>=2.9" "openstacksdk>=1.0.0" "python-openstackclient==6.2.0" kubernetes - ``` - -### Review the role values - -The default values are in `/opt/genestack/ansible/playbooks/roles/octavia_preconf/defaults/main.yml` - -Review the settings and adjust as necessary. Depending on the size of your cluster, you may want to adjust the -`lb_mgmt_subnet` settings or block icmp and ssh access to the amphora vms. - -### Run the playbook - -You can get the Keystone url and region with the following command. - -``` shell -openstack --os-cloud=default endpoint list --service keystone --interface public -c Region -c URL -f value -``` - -You can get the admin password by using kubectl. - -``` shell -kubectl get secrets keystone-admin -n openstack -o jsonpath='{.data.password}' | base64 -d -``` - -Run the playbook - -``` shell -cd /opt/genestack/ansible/playbooks -ansible-playbook octavia-preconf-main.yaml -``` - -!!! tip "Dynamic values" - - Running the playbook can be fully dynamic by using the following command: - - !!! example "Run the playbook with dynamic values" - - ``` shell - ansible-playbook /opt/genestack/ansible/playbooks/octavia-preconf-main.yaml \ - -e octavia_os_password=$(kubectl get secrets keystone-admin -n openstack -o jsonpath='{.data.password}' | base64 -d) \ - -e octavia_os_region_name=$(openstack --os-cloud=default endpoint list --service keystone --interface public -c Region -f value) \ - -e octavia_os_auth_url=$(openstack --os-cloud=default endpoint list --service keystone --interface public -c URL -f value) - ``` - -Once everything is complete, a new file will be created in your home directory called `octavia_amphora_provider.yaml`, this file -contains the necessary information to deploy Octavia via helm. Move this file into the `/etc/genestack/helm-configs/octavia` -directory to have it automatically included when running the Octavia deployment script. - -``` shell -mv ~/octavia_amphora_provider.yaml /etc/genestack/helm-configs/octavia/ -``` - -## Run the Helm deployment - -!!! example "Run the Octavia deployment Script `/opt/genestack/bin/install-octavia.sh`" - - ``` shell - --8<-- "bin/install-octavia.sh" - ``` - -**Make sure to include the file when you run the script by adding a `-f //octavia_amphora_provider.yaml`** - -!!! example - - ``` shell - /opt/genestack/bin/install-octavia.sh - ``` - -!!! tip - - You may need to provide custom values to configure your openstack services, for a simple single region or lab deployment - you can supply an additional overrides flag using the example found at `base-helm-configs/aio-example-openstack-overrides.yaml`. - In other cases such as a multi-region deployment you may want to view the [Multi-Region Support](multi-region-support.md) - guide to for a workflow solution. - -## Demo - -[![asciicast](https://asciinema.org/a/629814.svg)](https://asciinema.org/a/629814) diff --git a/docs/openstack-override-public-endpoint-fqdn.md b/docs/openstack-override-public-endpoint-fqdn.md deleted file mode 100644 index 7e7e94c4c..000000000 --- a/docs/openstack-override-public-endpoint-fqdn.md +++ /dev/null @@ -1,79 +0,0 @@ -# Helm Overriding public endpoint fqdn openstack services - -By default in Genestack the public endpoint fqdn for any openstack service is created with the cluster domain. For example if the cluster domain is "cluster.local" and keystone pods are in the "openstack" namespace then the fqdn for the keystone service would be "keystone-api.openstack.svc.cluster.local" which might not be ideal for production environments. There are examples provided in the documentation to override the domain for the [gateway api routes](https://docs.rackspacecloud.com/infrastructure-nginx-gateway-api-custom/#custom-routes); this however doesn't override the fqdn for the openstack services in the keystone catalog. - -Below we will discuss how to override the public endpoint fqdn in the keystone catalog using helm values - -# Providing the required overrides for public endpoints in the keystone catalog - -In order to modify the public endpoint fqdn for any openstack service then helm overrides can be used; taking an example of keystone service. - -This is the httproute for keystone service: - -``` shell -kubectl get httproute -n openstack custom-keystone-gateway-route-http -NAME HOSTNAMES AGE -custom-keystone-gateway-route-https ["keystone.cluster.local"] 78d -``` - -This although doesn't modify the public endpoint for the keystone service in the catalog; to modify the fqdn for the keystone service in the catalog we would need to create an helm overrides file: - -```yaml -endpoints: - identity: - host_fqdn_override: - public: - tls: {} - host: keystone.cluster.local - port: - api: - public: 443 - scheme: - public: https -``` - -this file needs to be moved into /etc/genestack/helm-configs/keystone/ directory and when installing the helm chart this will override the fqdn of the keystone service in the catalog. - -!!! note - The fqdn in the httproute and helm overrides must be the same - -This is an example overrides file for nova: - -!!! example "`host_fqdn_overrides.yaml`" - - ``` yaml - endpoints: - compute: - host_fqdn_override: - public: - tls: {} - host: nova.cluster.local - port: - api: - public: 443 - scheme: - public: https - compute_metadata: - host_fqdn_override: - public: - tls: {} - host: metadata.nova.cluster.local - port: - metadata: - public: 443 - scheme: - public: https - compute_novnc_proxy: - host_fqdn_override: - public: - tls: {} - host: novnc.nova.cluster.local - port: - novnc_proxy: - public: 443 - scheme: - public: https - ``` - -!!! note - gateway-api handles tls encryption on public endpoints; it is not required to specify tls parameters in helm diff --git a/docs/openstack-overview.md b/docs/openstack-overview.md deleted file mode 100644 index 1b8237a08..000000000 --- a/docs/openstack-overview.md +++ /dev/null @@ -1,29 +0,0 @@ -# Building the cloud - -![Genestack Logo](assets/images/genestack-logo.png){ align=right } - -## The DNA of our services - -The DNA of the OpenStack services has been built to scale, and be managed in a pseudo light-outs environment. We're aiming to empower operators to do more, simply and easily. The high level tenets we started our project from are simple and were written with intention. We're building Genestack not to show off how complex our platform is or how smart our engineers are, we're building systems to show how simple cloud deployment, operations, and maintenance can be. - -## Core Tenets -* All services make use of our core infrastructure which is all managed by operators. - * Rollback and versioning is present and a normal feature of our operations. -* Backups, rollbacks, and package management all built into our applications delivery. -* Databases, users, and grants are all run against a cluster which is setup for OpenStack to use a single right, and read from many. - * The primary node is part of application service discovery and will be automatically promoted / demoted within the cluster as needed. -* Queues, permissions, vhosts, and users are all backed by a cluster with automatic failover. All of the queues deployed in the environment are done with Quorum queues, giving us a best of bread queing platform which gracefully recovers from faults while maintaining performance. -* Horizontal scaling groups have been applied to all of our services. This means we'll be able to auto scale API applications up and down based on the needs of the environment. - -## Deployment choices - -When you're building the cloud, you have a couple of deployment choices, the most fundamental of which is `base` or `aio`. - -* `base` creates a production-ready environment that ensures an HA system is deployed across the hardware available in your cloud. -* `aio` creates a minimal cloud environment which is suitable for test, which may have low resources. - -The following examples all assume the use of a production environment, however, if you change `base` to `aio`, the deployment footprint will be changed for a given service. - -!!! info - - From this point forward we're building our OpenStack cloud. The following commands will leverage `helm` as the package manager and `kustomize` as our configuration management backend. diff --git a/docs/openstack-pci-passthrough.md b/docs/openstack-pci-passthrough.md deleted file mode 100644 index 8c3d474cc..000000000 --- a/docs/openstack-pci-passthrough.md +++ /dev/null @@ -1,199 +0,0 @@ -# Configuring PCI Passthrough in OpenStack - -PCI Passthrough in OpenStack allows you to assign physical PCI devices directly to virtual machine instances, enabling high-performance access to hardware resources such as GPUs and network cards. This guide walks you through the basic steps to configure PCI Passthrough. - -## Enable IOMMU on Compute Nodes - -An Input-Output Memory Management Unit (IOMMU) is essential in computing for connecting a Direct Memory Access (DMA)-capable I/O bus to the main memory. Like a traditional Memory Management Unit (MMU), which translates CPU-visible virtual addresses to physical addresses, the IOMMU maps device-visible virtual addresses (also called device addresses or memory-mapped I/O addresses) to physical addresses. Additionally, IOMMUs provide memory protection, preventing issues caused by faulty or malicious devices. This functionality is critical for enabling secure and efficient PCI Passthrough in OpenStack environments. - -### For Intel CPUs - -1. Edit the GRUB configuration file: - -``` shell -sudo vi /etc/default/grub -``` - -2. Add `intel_iommu=on` to the `GRUB_CMDLINE_LINUX_DEFAULT` line: - -``` shell -GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_iommu=on" -``` - -### For AMD CPUs - -1. Edit the GRUB configuration file: - -``` shell -sudo vi /etc/default/grub -``` - -2. Add `amd_iommu=on` to the `GRUB_CMDLINE_LINUX_DEFAULT` line: - -``` shell -GRUB_CMDLINE_LINUX_DEFAULT="quiet splash amd_iommu=on" -``` - -## Identify PCI Devices - -Identify the PCI devices you want to passthrough using the `lspci` command: - -``` shell -lspci -knn | grep NVIDIA -``` - -!!! example "lspci output" - - ``` shell - 0b:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP106GL [Quadro P2000] [10de:1c30] (rev a1) - 0b:00.1 Audio device [0403]: NVIDIA Corporation GP106 High Definition Audio Controller [10de:10f1] (rev a1) - ``` - -From the example output, we can see that we have two devices that we'll want to be able to pass through to our instances; we'll need to note `10de:1c30` and `10de:10f1` for use in the host configuration. - -### Add VFIO Configuration - - -1. Edit the GRUB configuration file: - -``` shell -sudo vi /etc/default/grub -``` - -2. Modify the `GRUB_CMDLINE_LINUX_DEFAULT` once again, extending it for `vfio-pci.ids`. - -``` shell -GRUB_CMDLINE_LINUX_DEFAULT="... vfio-pci.ids=10de:1c30,10de:10f1" -``` - -!!! note - - The value of `vfio-pci.ids` is the same as the noted from the *lspci output*. - - -### Update GRUB and reboot - -``` shell -sudo update-grub -sudo reboot -``` - -## Validate the setup - -Once the node has been rebooted, check the `lspci` output to ensure that the device being used as passthrough is using the `vfio-pci` driver. - -Re-identify the PCI devices you want to passthrough using the `lspci` command - -``` shell -lspci -knn | grep NVIDIA -``` - -!!! example "lspci output" - - ``` shell - ... - 0b:00.0 VGA compatible controller: NVIDIA Corporation GP106GL [Quadro P2000] (rev a1) - Subsystem: Dell GP106GL [Quadro P2000] - Kernel driver in use: vfio-pci - Kernel modules: nouveau - 0b:00.1 Audio device: NVIDIA Corporation GP106 High Definition Audio Controller (rev a1) - Subsystem: Dell GP106 High Definition Audio Controller - Kernel driver in use: vfio-pci - Kernel modules: snd_hda_intel - ... - ``` - -Note the "Kernel driver in use: vfio-pci" section. If the kernel driver is anything other than `vfio-pci` you many need to blacklist the referenced driver before you continue. See the following docs on how to [blacklist a kernel module](https://wiki.debian.org/KernelModuleBlacklisting). - -!!! tip - You can verify that IOMMU is loaded once the server is rebooted by running: - - sudo dmesg | grep -e IOMMU - - -!!! example "example config that uses iommu and also disables nvidia modules in favor of vfio" - - ``` shell - GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_iommu=on iommu=pt mitigations=off vfio-pci.ids=10de:1b38 vfio_iommu_type1.allow_unsafe_interrupts=1 modprobe.blacklist=nvidiafb,nouveau,nvidia,nvidia_drm rs.driver.blacklist=nouveau,nvidia,nvidia_drm,nvidiafb kvm.ignore_msrs=1" - ``` - -## Configure Nova Compute - -With the same `lspci` information used in the `vfio` setup, create a `device_spec` and `alias` in JSON string format. The `device_spec` needs the **vendor_id** and **product_id** which are within our known PCI information. For `10de:1c30` and `10de:10f1`, the left side of the `:` is the **vendor_id** and the right side is the **product_id**. - -| vendor_id | product_id | -| --------- | ---------- | -| 10de | 1c30 | -| 10de | 10f1 | - -### Example `device_spec` - -``` json -{"vendor_id": "10de", "product_id": "1c30"} -``` - -### Example `alias` - -``` json -{"vendor_id": "10de", "product_id": "1c30", "device_type": "type-PCI", "name": "p2000"} -``` - -If you are configuring a PCI passthrough for say a GPU compute follow the instruction in the Node Overrides Explanation section of the service override documentation. - -1. See the [Genestack service override documentation](openstack-service-overrides.md) on how update your compute infrastructure to use the `device_spec` and `alias`. - -1. Create a custom flavor which has your alias name as a property. See the [Genestack flavor documentation](openstack-flavors.md) on how to craft custom flavors. - -## Launch an Instance with PCI Passthrough - -1. Verify that the instance has the PCI device assigned. SSH into the instance and use the `lspci` command: - -``` shell -lspci | grep -i nvidia -``` - -!!! example "lspci output" - - ``` shell - 06:00.0 VGA compatible controller: NVIDIA Corporation GP106GL [Quadro P2000] (rev a1) - ``` - -Assuming this is running an NVIDIA GPU, you can run install the relevant drivers and run the `nvidia-smi` command to validate everything is running normally. - -!!! example "Example nvidia GPU running in a VM" - - ``` shell - +-----------------------------------------------------------------------------+ - | NVIDIA-SMI 525.147.05 Driver Version: 525.147.05 CUDA Version: 12.0 | - |-------------------------------+----------------------+----------------------+ - | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | - | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | - | | | MIG M. | - |===============================+======================+======================| - | 0 Quadro P2000 On | 00000000:06:00.0 Off | N/A | - | 50% 40C P8 6W / 75W | 1MiB / 5120MiB | 0% Default | - | | | N/A | - +-------------------------------+----------------------+----------------------+ - - +-----------------------------------------------------------------------------+ - | Processes: | - | GPU GI CI PID Type Process name GPU Memory | - | ID ID Usage | - |=============================================================================| - | No running processes found | - +-----------------------------------------------------------------------------+ - ``` - -## Common Issues - -- **Device Not Found:** Ensure the PCI device is available and not used by the host. -- **Configuration Errors:** Check `nova-compute` logs. -- **IOMMU Not Enabled:** Confirm that IOMMU is enabled in the BIOS/UEFI and in the GRUB configuration. -- **Scheduler Error:** Example errors like `Dropped device(s) due to mismatched PCI attribute(s)` or `allocation_candidate: doesn't have the required PCI devices` This and scheduler removing all compute nodes during pci filter is a sign that your **device_type** attribute on nova.conf does not correctly match the PCI device installed on the sytem. - -!!! tip - The device_type attribute must match one of type-PCI, type-PF or type-VF. If you have a SR-IOV capable device, you must set your device_type to type-PF even if you do not use the SR-IOV functionality. - -## Conclusion - -Configuring PCI Passthrough in OpenStack enhances the performance of virtual machines by providing direct access to physical hardware. This guide is aimed to be helpful on getting up and running with PCI Passthrough but it is by no means exhaustive, refer to the [OpenStack documentation](https://docs.openstack.org/nova/latest/admin/pci-passthrough.html) for more. diff --git a/docs/openstack-quota-managment.md b/docs/openstack-quota-managment.md deleted file mode 100644 index 464507eed..000000000 --- a/docs/openstack-quota-managment.md +++ /dev/null @@ -1,57 +0,0 @@ -# Quota Management - -Resouce quotas can be set in an OpenStack environment to ensure that we do not unintentionally exhaust -the capacity. In OpenStack quotas can be set to give each resource some operational limit. - -Quotas are checked in the follwing order: - -* Project specific limit - -If set for a specific resource this limit will be used first. Exmaple, for a project we can set quotas -for any resource like so: - -```shell - openstack quota set --cores 100 -``` - -* Default limits - -These are hard limit set the database under `quota_classes` for the default quota class. If project sepcific -limit is not set for a given resource and default limit is set, OpenStack uses this limit. - -To set a default limit for a resource: - -```shell - openstack quota set --cores 120 default -``` - -!!! note - Once the default limit is set via the API, it takes precedence over config limits. Once it is set, we can only - modify the limit, but it can not be deleted via the API. It can however be deleted manually from the database. - - -* Config provided limits - -We can set limits on resource through the config file under the quota config group. - - -### Useful quota commands - -```shell title="Show the default quota" - openstack quota show --default -``` - -```shell title="Show quota for a project" - openstack quota show -``` - -```shell title="Update quota for resource instance in default class" - openstack quota set --instances 15 default -``` - -```shell title="Update quota for a resource for a project" - openstack quota set --instances 20 -``` - -!!! note - Quotas class has been replaced with a new driver unified limits. Please see OpenStack docs for unified limits. diff --git a/docs/openstack-quota.md b/docs/openstack-quota.md deleted file mode 100644 index 59ec70511..000000000 --- a/docs/openstack-quota.md +++ /dev/null @@ -1,29 +0,0 @@ -# OpenStack Quotas - -To read more about Openstack quotas please visit the [upstream docs](https://docs.openstack.org/nova/rocky/admin/quotas.html). - -#### Viewing Your Quota - -You can view your quotas via Skyline or using the OpenStack CLI client. The Skyline home page is the easiest way to view your quota limits and utilization in one place. -![SkylineHome](./assets/images/SkylineHomeQuota.png) - -You can also view quota information using the OpenStack CLI, however, you'll need to use a couple of commands.
-Use the quota option to list all of your quota limits. - -```shell -openstack quota show -``` - -![quota show](./assets/images/quota_show.png) - -The limits option returns quota limits along with utilization information for most services. - -```shell -openstack limits show --absolute -``` - -![limits show](./assets/images/limits_show.png) - -#### Increasing Your Quota - -If you need to request a quota increase, please contact your Account Manager or navigate to the [MyCloud](https://mycloud.rackspace.com) portal, create a ticket, and select Account as the category. diff --git a/docs/openstack-resource-lookups.md b/docs/openstack-resource-lookups.md deleted file mode 100644 index 77045795e..000000000 --- a/docs/openstack-resource-lookups.md +++ /dev/null @@ -1,474 +0,0 @@ -# Retrieving Project and User Information from openstack --os-cloud default Resources - -As an OpenStack operator or administrator focused on support, it's essential to know how to retrieve project (tenant) and user information associated with various -resources. This document provides detailed instructions on how to obtain this information using command-line interfaces (CLIs) for the following resources. - -* Instance UUID -* Image UUID -* Volume UUID -* Load Balancer UUID -* Network UUID -* Subnet UUID -* Router UUID - -Retrieving project and user information from OpenStack resources is a fundamental skill for operators and administrators. By using the `openstack` command-line client, you can -efficiently gather necessary details to support operations, troubleshoot issues, and perform audits. - -## Prerequisites - -Access to the openstack --os-cloud default command-line client (openstack --os-cloud default command). Administrative privileges or appropriate permissions to view user and project information. -See the [documentation](openstack-clouds.md) on generating your own `clouds.yaml` file which can be used to populate the monitoring configuration file. - -## Retrieving Information from an Instance UUID - -The following command displays detailed information about an instance. - -``` shell -openstack --os-cloud default server show -``` - -!!! example - - ``` shell - openstack --os-cloud default server show 76d8fe3b-be2d-477d-9609-92d74579f948 - ``` - - Sample Output - - ``` shell - +-------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Field | Value | - +-------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | OS-DCF:diskConfig | MANUAL | - | OS-EXT-AZ:availability_zone | nova | - | OS-EXT-SRV-ATTR:host | None | - | OS-EXT-SRV-ATTR:hostname | jump-0 | - | OS-EXT-SRV-ATTR:hypervisor_hostname | None | - | OS-EXT-SRV-ATTR:instance_name | None | - | OS-EXT-SRV-ATTR:kernel_id | None | - | OS-EXT-SRV-ATTR:launch_index | None | - | OS-EXT-SRV-ATTR:ramdisk_id | None | - | OS-EXT-SRV-ATTR:reservation_id | None | - | OS-EXT-SRV-ATTR:root_device_name | None | - | OS-EXT-SRV-ATTR:user_data | None | - | OS-EXT-STS:power_state | Running | - | OS-EXT-STS:task_state | None | - | OS-EXT-STS:vm_state | active | - | OS-SRV-USG:launched_at | 2024-11-05T16:50:49.000000 | - | OS-SRV-USG:terminated_at | None | - | accessIPv4 | | - | accessIPv6 | | - | addresses | tenant-net=10.0.0.57, 65.17.193.69 | - | config_drive | | - | created | 2024-11-05T16:50:46Z | - | description | None | - | flavor | description=, disk='10', ephemeral='0', extra_specs.:architecture='x86_architecture', extra_specs.:category='general_purpose', | - | | extra_specs.hw:cpu_max_sockets='2', extra_specs.hw:cpu_max_threads='1', extra_specs.hw:mem_page_size='any', id='gp.0.1.2', is_disabled=, is_public='True', | - | | location=, name='gp.0.1.2', original_name='gp.0.1.2', ram='2048', rxtx_factor=, swap='0', vcpus='1' | - | hostId | a7fb61145d904932313274d17e5128d775e69de60f8434d081695387 | - | host_status | None | - | id | 76d8fe3b-be2d-477d-9609-92d74579f948 | - | image | Debian-12 (727958e9-d037-45d1-9716-ea7ac322fe02) | - | key_name | tenant-key | - | locked | False | - | locked_reason | None | - | name | jump-0 | - | pinned_availability_zone | None | - | progress | 0 | - | project_id | 0e32bf7ccajjjj858320995dd4a223ab | - | properties | | - | security_groups | name='talos-secgroup' | - | | name='tenant-secgroup' | - | server_groups | [] | - | status | ACTIVE | - | tags | | - | trusted_image_certificates | None | - | updated | 2024-11-19T16:26:16Z | - | user_id | fdff75fff6ace79f4sdfsdfsde96b1ba9fc5153ed8ba4570fbeca1fc67afab12 | - | volumes_attached | | - +-------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - ``` - -With the `user_id` and `project_id` fields, you can retrieve user and project details and proceed to the [Project and User Information](#project-and-user-information) section. - -## Retrieving Information from an Image UUID - -The following command displays information about an image. - -``` shell -openstack --os-cloud default image show -``` - -The owner field indicates the project ID that owns the image. - -!!! example - - ``` shell - openstack --os-cloud default image show 727958e9-d037-45d1-9716-ea7ac322fe02 - ``` - - Sample Output - - ``` shell - +------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Field | Value | - +------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | checksum | 9cc9a43ad051fda5475ca79f05df549c | - | container_format | bare | - | created_at | 2024-06-21T17:07:16Z | - | disk_format | qcow2 | - | file | /v2/images/727958e9-d037-45d1-9716-ea7ac322fe02/file | - | id | 727958e9-d037-45d1-9716-ea7ac322fe02 | - | min_disk | 0 | - | min_ram | 0 | - | name | Debian-12 | - | owner | 8fb86e74be8d49f3befde1f647d9f2ef | - | properties | hw_firmware_type='uefi', hw_machine_type='q35', hw_qemu_guest_agent='yes', hw_vif_multiqueue_enabled='True', hypervisor_type='kvm', img_config_drive='optional', | - | | os_admin_user='debian', os_distro='debian', os_hash_algo='sha512', | - | | os_hash_value='e7efdc6e0ae643b05c6d53e10efbfd4454a769e13ddd69b5fabaa3e00c0ec431e6d6022530ecc922d944875409f4db66f69f1c134f64098959ab43de321d67c7', os_hidden='False', | - | | os_require_quiesce='True', os_type='linux', os_version='12', owner_specified.openstack.md5='', owner_specified.openstack.object='images/Debian-12', | - | | owner_specified.openstack.sha256='' | - | protected | False | - | schema | /v2/schemas/image | - | size | 346670592 | - | status | active | - | tags | | - | updated_at | 2024-09-24T22:31:14Z | - | virtual_size | 2147483648 | - | visibility | public | - +------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - ``` - -The `owner` field represents the project ID for the owner of a given image, With the `owner` field, you can retrieve user and project details and proceed to -the [Project and User Information](#project-and-user-information) section. - -## Retrieving Information from a Volume UUID - -The following command displays information about a volume. - -``` shell -openstack --os-cloud default volume show -``` - -!!! example - - ``` shell - openstack --os-cloud default volume show 43ef9068-b9f9-4b5c-8da7-5f6f6999e50f - ``` - - Sample Output - - ``` shell - +------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Field | Value | - +------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | attachments | [{'id': '43ef9068-b9f9-4b5c-8da7-5f6f6999e50f', 'attachment_id': '33ea9695-a819-4253-8579-1fb2f2c1af98', 'volume_id': '43ef9068-b9f9-4b5c-8da7-5f6f6999e50f', | - | | 'server_id': '1896bf60-db4f-4312-b2f5-feccdff31a51', 'host_name': None, 'device': '/dev/vdc', 'attached_at': '2024-11-06T03:04:38.000000'}] | - | availability_zone | nova | - | bootable | false | - | consistencygroup_id | None | - | created_at | 2024-11-06T03:04:22.000000 | - | description | None | - | encrypted | True | - | id | 43ef9068-b9f9-4b5c-8da7-5f6f6999e50f | - | multiattach | False | - | name | longhorn-2 | - | os-vol-tenant-attr:tenant_id | 0e32bf7ccajjjj858320995dd4a223ab | - | properties | | - | replication_status | None | - | size | 100 | - | snapshot_id | None | - | source_volid | None | - | status | in-use | - | type | Capacity | - | updated_at | 2024-11-06T03:04:46.000000 | - | user_id | fdff75fff6ace79f4sdfsdfsde96b1ba9fc5153ed8ba4570fbeca1fc67afab12 | - +------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - ``` - -With the `os-vol-tenant-attr:tenant_id` field, you can retrieve user and project details and proceed to the [Project and User Information](#project-and-user-information) section. - -## Retrieving Information from a Load Balancer UUID - -The following command displays details about a load balancer. - -``` shell -openstack --os-cloud default loadbalancer show -``` - -The project_id field indicates the owning project. - -!!! example - - ``` shell - openstack --os-cloud default loadbalancer show 4a9a5d27-38bd-401f-8215-bba278474fe3 - ``` - - Sample Output - - ``` shell - +---------------------+--------------------------------------+ - | Field | Value | - +---------------------+--------------------------------------+ - | admin_state_up | True | - | availability_zone | None | - | created_at | 2024-11-21T17:14:10 | - | description | | - | flavor_id | None | - | id | 4a9a5d27-38bd-401f-8215-bba278474fe3 | - | listeners | 6377d5f8-5098-44b6-b735-b82e53eb75f7 | - | name | talos-control-plane-good | - | operating_status | ONLINE | - | pools | 3219e759-7fd8-40bf-98ea-beac9223ba59 | - | project_id | 0e32bf7ccajjjj858320995dd4a223ab | - | provider | ovn | - | provisioning_status | ACTIVE | - | updated_at | 2024-11-21T17:17:41 | - | vip_address | 10.0.0.10 | - | vip_network_id | 426b1280-a3e8-4bea-ab9d-e360d315be89 | - | vip_port_id | 803749df-4cae-497f-8628-b22805f45e74 | - | vip_qos_policy_id | None | - | vip_subnet_id | b4448aa6-bb7d-4e01-86c1-80e589d3fb92 | - | vip_vnic_type | normal | - | tags | | - | additional_vips | [] | - +---------------------+--------------------------------------+ - ``` - -With the `project_id` field, you can retrieve user and project details and proceed to the [Project and User Information](#project-and-user-information) section. - -## Retrieving Information from a Network UUID - -The following command provides details about a network. - -``` shell -openstack --os-cloud default network show -``` - -!!! example - - ``` shell - openstack --os-cloud default network show 426b1280-a3e8-4bea-ab9d-e360d315be89 - ``` - - Sample Output - - ``` shell - +---------------------------+--------------------------------------+ - | Field | Value | - +---------------------------+--------------------------------------+ - | admin_state_up | UP | - | availability_zone_hints | nova | - | availability_zones | nova | - | created_at | 2024-11-05T03:14:50Z | - | description | | - | dns_domain | None | - | id | 426b1280-a3e8-4bea-ab9d-e360d315be89 | - | ipv4_address_scope | None | - | ipv6_address_scope | None | - | is_default | None | - | is_vlan_transparent | None | - | l2_adjacency | True | - | mtu | 3942 | - | name | tenant-net | - | port_security_enabled | True | - | project_id | 0e32bf7ccajjjj858320995dd4a223ab | - | provider:network_type | None | - | provider:physical_network | None | - | provider:segmentation_id | None | - | qos_policy_id | None | - | revision_number | 2 | - | router:external | Internal | - | segments | None | - | shared | False | - | status | ACTIVE | - | subnets | b4448aa6-bb7d-4e01-86c1-80e589d3fb92 | - | tags | | - | updated_at | 2024-11-05T03:14:51Z | - +---------------------------+--------------------------------------+ - ``` - -With the `project_id` field, you can retrieve user and project details and proceed to the [Project and User Information](#project-and-user-information) section. - -## Retrieving Information from a Subnet UUID - -The following command displays details about a subnet. - -``` shell -openstack --os-cloud default subnet show -``` - -!!! example - - ``` shell - openstack --os-cloud default subnet show b4448aa6-bb7d-4e01-86c1-80e589d3fb92 - ``` - - Sample Output - - ``` shell - +----------------------+--------------------------------------+ - | Field | Value | - +----------------------+--------------------------------------+ - | allocation_pools | 10.0.0.2-10.0.0.254 | - | cidr | 10.0.0.0/24 | - | created_at | 2024-11-05T03:14:51Z | - | description | | - | dns_nameservers | 8.8.8.8 | - | dns_publish_fixed_ip | None | - | enable_dhcp | True | - | gateway_ip | 10.0.0.1 | - | host_routes | | - | id | b4448aa6-bb7d-4e01-86c1-80e589d3fb92 | - | ip_version | 4 | - | ipv6_address_mode | None | - | ipv6_ra_mode | None | - | name | tenant-subnet | - | network_id | 426b1280-a3e8-4bea-ab9d-e360d315be89 | - | project_id | 0e32bf7ccajjjj858320995dd4a223ab | - | revision_number | 0 | - | segment_id | None | - | service_types | | - | subnetpool_id | None | - | tags | | - | updated_at | 2024-11-05T03:14:51Z | - +----------------------+--------------------------------------+ - ``` - -With the `project_id` field, you can retrieve user and project details and proceed to the [Project and User Information](#project-and-user-information) section. - -## Retrieving Information from a Router UUID - -The following command provides details about a router. - -``` shell -openstack --os-cloud default router show -``` - -!!! example - - ``` shell - openstack --os-cloud default router show 63cce307-1476-4ada-aacd-e013226e02af - ``` - - Sample Output - - ``` shell - +---------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Field | Value | - +---------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | admin_state_up | UP | - | availability_zone_hints | nova | - | availability_zones | nova | - | created_at | 2024-11-05T03:09:07Z | - | description | | - | enable_default_route_bfd | False | - | enable_default_route_ecmp | False | - | enable_ndp_proxy | None | - | external_gateway_info | {"network_id": "723f8fa2-dbf7-4cec-8d5f-017e62c12f79", "external_fixed_ips": [{"subnet_id": "31bf7e05-be6e-4c5b-908d-abe47c80ba41", "ip_address": "X.X.X.X"}], | - | | "enable_snat": true} | - | external_gateways | [{'network_id': '723f8fa2-dbf7-4cec-8d5f-017e62c12f79', 'external_fixed_ips': [{'ip_address': 'X.X.X.X', 'subnet_id': '31bf7e05-be6e-4c5b-908d-abe47c80ba41'}]}] | - | flavor_id | None | - | id | 63cce307-1476-4ada-aacd-e013226e02af | - | interfaces_info | [{"port_id": "dd39cd69-84a1-4276-bdaa-d699a8372090", "ip_address": "10.0.0.1", "subnet_id": "b4448aa6-bb7d-4e01-86c1-80e589d3fb92"}] | - | name | tenant-router | - | project_id | 0e32bf7ccajjjj858320995dd4a223ab | - | revision_number | 5 | - | routes | | - | status | ACTIVE | - | tags | | - | tenant_id | 0e32bf7ccajjjj858320995dd4a223ab | - | updated_at | 2024-11-05T03:15:24Z | - +---------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - ``` - -With the `project_id` or `tenant_id` field, you can retrieve user and project details and proceed to the [Project and User Information](#project-and-user-information) section. - -## Project and User Information - -By using the previous command outputs, you can retrieve detailed information about the project and user associated with the resources. - -### Retrieve Project Details - -``` shell -openstack --os-cloud default project show -``` - -!!! example - - ``` shell - openstack --os-cloud default project show 0e32bf7ccajjjj858320995dd4a223ab - ``` - - Sample Output - - ``` shell - +-------------+--------------------------------------+ - | Field | Value | - +-------------+--------------------------------------+ - | description | | - | domain_id | eb6ce3086fba4luio2be7d6b23efbb95 | - | enabled | True | - | id | 0e32bf7ccajjjj858320995dd4a223ab | - | is_domain | False | - | name | 3965512c-e2c0-48a7-acef-3cdfb2b95ef8 | - | options | {} | - | parent_id | eb6ce3086fba4luio2be7d6b23efbb95 | - | tags | [] | - +-------------+--------------------------------------+ - ``` - -### Retrieve User Details - -``` shell -openstack --os-cloud default user show -``` - -!!! example - - ``` shell - openstack --os-cloud default user show fdff75fff6ace79f4sdfsdfsde96b1ba9fc5153ed8ba4570fbeca1fc67afab12 - ``` - - Sample Output - - ``` shell - +---------------------+------------------------------------------------------------------+ - | Field | Value | - +---------------------+------------------------------------------------------------------+ - | default_project_id | None | - | domain_id | eb6ce3086fba4luio2be7d6b23efbb95 | - | email | user@emailaddress.com | - | enabled | True | - | id | fdff75fff6ace79f4sdfsdfsde96b1ba9fc5153ed8ba4570fbeca1fc67afab12 | - | name | username | - | description | None | - | password_expires_at | None | - +---------------------+------------------------------------------------------------------+ - ``` - -## Notes and Tips - -Here are a few additional tips and considerations to keep in mind when retrieving project and user information from OpenStack resources. - -### Permissions - -Ensure you have administrative privileges or the necessary role assignments to access user and project information. - -### Help and Manual Pages - -Use the `--help` option with any command to get more information - -``` shell -openstack --os-cloud default server show --help -``` - -### Logging and Auditing - -If user information is not readily available, consult service logs (e.g., Nova, Neutron, Cinder logs) or audit records. OpenStack services may record operations in -logs with user and project context. - -### API Usage - -For advanced queries, consider using the [OpenStack APIs](https://docs.openstack.org/api-quick-start) directly with tools like curl or scripting with -SDKs (Python SDK, etc.). diff --git a/docs/openstack-router.md b/docs/openstack-router.md deleted file mode 100644 index 2c7031f49..000000000 --- a/docs/openstack-router.md +++ /dev/null @@ -1,146 +0,0 @@ -# Openstack Router - -Read more about Openstack Routers using the [upstream docs](https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/router.html). - -#### Get List of Routers - -``` shell -openstack --os-cloud={cloud name} router list - [--sort-column SORT_COLUMN] - [--sort-ascending | --sort-descending] - [--name ] - [--enable | --disable] - [--long] - [--project ] - [--project-domain ] - [--agent ] - [--tags [,,...]] - [--any-tags [,,...]] - [--not-tags [,,...]] - [--not-any-tags [,,...]] -``` - -#### Create a Router - -``` shell -openstack --os-cloud={cloud name} router create - [--extra-property type=,name=,value=] - [--enable | --disable] - [--distributed | --centralized] - [--ha | --no-ha] - [--description ] - [--project ] - [--project-domain ] - [--availability-zone-hint ] - [--tag | --no-tag] - [--external-gateway ] - [--fixed-ip subnet=,ip-address=] - [--enable-snat | --disable-snat] - [--enable-ndp-proxy | --disable-ndp-proxy] - [--flavor ] - [--enable-default-route-bfd] - [--disable-default-route-bfd] - [--enable-default-route-ecmp] - [--disable-default-route-ecmp] - -``` - -#### Add a Gateway to Router - -``` shell -openstack --os-cloud={cloud name} router add gateway - [--fixed-ip subnet=,ip-address=] - - -``` - -#### Add a Subnet to Router - -``` shell -openstack --os-cloud={cloud name} router add subnet -``` - -#### Add a Port to Router - -``` shell -openstack --os-cloud={cloud name} router add port -``` - -#### Set Router Properties - -``` shell -openstack --os-cloud={cloud name} router set - [--extra-property type=,name=,value=] - [--name ] - [--description ] - [--enable | --disable] - [--distributed | --centralized] - [--route destination=,gateway=] - [--no-route] - [--ha | --no-ha] - [--external-gateway ] - [--fixed-ip subnet=,ip-address=] - [--enable-snat | --disable-snat] - [--enable-ndp-proxy | --disable-ndp-proxy] - [--qos-policy | --no-qos-policy] - [--tag ] - [--no-tag] - [--enable-default-route-bfd] - [--disable-default-route-bfd] - [--enable-default-route-ecmp] - [--disable-default-route-ecmp] - -``` - -#### Delete Router - -``` shell -openstack --os-cloud={cloud name} router add subnet -``` - -#### Create Router Port - - -``` shell -openstack --os-cloud={cloud name} port create [-h] [-f {json,shell,table,value,yaml}] - [-c COLUMN] [--noindent] [--prefix PREFIX] - [--max-width ] [--fit-width] - [--print-empty] --network - [--description ] - [--device ] - [--mac-address ] - [--device-owner ] - [--vnic-type ] [--host ] - [--dns-domain dns-domain] [--dns-name ] - [--fixed-ip subnet=,ip-address= | --no-fixed-ip] - [--binding-profile ] - [--enable | --disable] - [--enable-uplink-status-propagation | --disable-uplink-status-propagation] - [--project ] - [--project-domain ] - [--extra-dhcp-option name=[,value=,ip-version={4,6}]] - [--security-group | --no-security-group] - [--qos-policy ] - [--enable-port-security | --disable-port-security] - [--allowed-address ip-address=[,mac-address=]] - [--tag | --no-tag] - -``` - -#### Creating a Router with Subnets Example - -``` shell -openstack --os-cloud={cloud name} router create {router_name} -``` - -Add subnet to the router and set the router's external gateway using PUBLICNET to allow outbound network access. - -``` shell -openstack --os-cloud={cloud name} router add subnet {router_name} {subnet_name} -``` - -Set the external gateway - -``` shell -openstack --os-cloud={cloud name} router set --external-gateway PUBLICNET {router_name} -``` diff --git a/docs/openstack-security-groups.md b/docs/openstack-security-groups.md deleted file mode 100644 index a13cbf6b1..000000000 --- a/docs/openstack-security-groups.md +++ /dev/null @@ -1,106 +0,0 @@ -# Openstack Security Groups - -To read more about Openstack Security Groups using the [upstream docs](https://docs.openstack.org/nova/queens/admin/security-groups.html). - -#### List and view current security groups - -``` shell -openstack --os-cloud={cloud name} security group list -``` - -#### Create Security Groups - -``` shell -openstack --os-cloud={cloud name} security group create SECURITY_GROUP_NAME --description GROUP_DESCRIPTION -``` - -#### Delete a specific Security Group - -``` shell -openstack --os-cloud={cloud name} security group delete SECURITY_GROUP_NAME -``` - -#### Create and manage security group rules - -To list the rules for a security group, run the following command: - -``` shell -openstack --os-cloud={cloud name} security group rule list SECURITY_GROUP_NAME -``` - -Add a new group rule: - -``` shell -openstack --os-cloud={cloud name} security group rule create SEC_GROUP_NAME \ - --protocol PROTOCOL --dst-port FROM_PORT:TO_PORT --remote-ip CIDR -``` - -The arguments are positional, and the from-port and to-port arguments specify the local port range connections are allowed to access, not the source and destination ports of the connection. - -#### To allow both HTTP and HTTPS traffic: - -``` shell -openstack --os-cloud={cloud name} security group rule create global_http \ - --protocol tcp --dst-port 443:443 --remote-ip 0.0.0.0/0 -``` - -#### To allow SSH access to the instances, choose one of the following options: - -1. Allow access from all IP addresses, specified as IP subnet 0.0.0.0/0 in CIDR notation: - - ``` shell - openstack --os-cloud={cloud name} security group rule create SECURITY_GROUP_NAME \ - --protocol tcp --dst-port 22:22 --remote-ip 0.0.0.0/0 - ``` -2. Allow access only from IP addresses from other security groups (source groups) to access the specified port: - - ``` shell - openstack --os-cloud={cloud name} security group rule create SECURITY_GROUP_NAME \ - --protocol tcp --dst-port 22:22 --remote-group SOURCE_GROUP_NAME - ``` -#### To allow pinging of the instances, choose one of the following options: - -1. Allow pinging from all IP addresses, specified as IP subnet 0.0.0.0/0 in CIDR notation - - ``` shell - openstack --os-cloud={cloud name} security group rule create --protocol icmp \ - SECURITY_GROUP_NAME - ``` - - This allows access to all codes and all types of ICMP traffic. - -2. Allow only members of other security groups (source groups) to ping instances. - - ``` shell - openstack --os-cloud={cloud name} security group rule create --protocol icmp \ - --remote-group SOURCE_GROUP_NAME SECURITY_GROUP - ``` - -#### To allow access through a UDP port, such as allowing access to a DNS server that runs on a VM, choose one of the following options: - -1. Allow UDP access from IP addresses, specified as IP subnet 0.0.0.0/0 in CIDR notation. - - ``` shell - openstack --os-cloud={cloud name} security group rule create --protocol udp \ - --dst-port 53:53 SECURITY_GROUP - ``` - -2. Allow only IP addresses from other security groups (source groups) to access the specified port. - - ``` shell - openstack --os-cloud={cloud name} security group rule create --protocol udp \ - --dst-port 53:53 --remote-group SOURCE_GROUP_NAME SECURITY_GROUP - ``` - -#### Allow RDP access only from IP addresses from other security groups - - ``` shell - openstack --os-cloud={cloud name} security group rule create SECURITY_GROUP_NAME \ - --protocol tcp --dst-port 33:89 --remote-group SOURCE_GROUP_NAME - ``` - -#### Delete a security group rule - -``` shell -openstack --os-cloud={cloud name} security group rule delete RULE_ID -``` diff --git a/docs/openstack-servers.md b/docs/openstack-servers.md deleted file mode 100644 index 2f2a573dc..000000000 --- a/docs/openstack-servers.md +++ /dev/null @@ -1,157 +0,0 @@ -# Openstack Servers - -To read more about Openstack Servers using the [upstream docs](https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/server.html). - -#### List and view servers - -``` shell -openstack --os-cloud={cloud name} server list - [--quote {all,minimal,none,nonnumeric}] - [--reservation-id ] - [--ip ] - [--ip6 ] - [--name ] - [--instance-name ] - [--status ] - [--flavor ] - [--image ] - [--host ] - [--all-projects] - [--project ] - [--project-domain ] - [--user ] - [--user-domain ] - [--long] - [-n] - [--marker ] - [--limit ] - [--deleted] - [--changes-since ] -``` - -#### Create a new server - -``` shell -openstack --os-cloud={cloud name} server create - (--image | --volume ) - --flavor - [--security-group ] - [--key-name ] - [--property ] - [--file ] - [--user-data ] - [--availability-zone ] - [--block-device-mapping ] - [--nic ] - [--network ] - [--port ] - [--hint ] - [--config-drive |True] - [--min ] - [--max ] - [--wait] - -``` - -#### Creating a Server with User Data - -You can place user data in a local file and pass it through the --user-data parameter at instance creation. - -``` shell -openstack --os-cloud={cloud name} server create --image ubuntu-cloudimage \ - --flavor 1 \ - --user-data mydata.file \ - $INSTANCE_UUID -``` - -#### Creating a Server with Config drives - -Config drives are special drives that are attached to an instance when it boots. The instance can mount this drive and read files from it to get information that is normally available through the metadata service. - -To enable the config drive for an instance, pass the --config-drive true parameter to the openstack server create command. - -The following example enables the config drive and passes a user data file and two key/value metadata pairs, all of which are accessible from the config drive: - -``` shell -openstack --os-cloud={cloud name} server create --config-drive true \ - --image my-image-name \ - --flavor 1 \ - --key-name mykey \ - --user-data ./my-user-data.txt \ - --property role=webservers \ - --property essential=false \ - $INSTANCE_UUID -``` - -Read more about Openstack Config drives using the [upstream docs](https://docs.openstack.org/nova/latest/admin/config-drive.html). - -#### Delete a server - -``` shell -openstack --os-cloud={cloud name} server delete [--wait] [ ...] -``` - -# Launch a server from a snapshot - -Please visit the Openstack Snapshot page [here](openstack-snapshot.md). - -# Launch a server from a volume - -Please visit the Openstack Volumes page [here](openstack-volumes.md). - -# Server Creation Example - -Below is a quick example of how one could set up a server. - -You will need to get your cloud name from your `clouds.yaml`. More information on this can be found [here](build-test-envs.md). Underneath "clouds:" you will find your cloud name. - -First we are going to create our network "my_network" - -``` shell -openstack --os-cloud={cloud name} network create my_network -``` - -Second create the subnet "my_subnet" - -``` shell -openstack --os-cloud={cloud name} subnet create --ip-version 4 \ - --subnet-range $CIDR \ - --network $NETWORK_NAME \ - $CIDR -``` - -Third create the router "my_router" - -``` shell -openstack --os-cloud={cloud name} router create my_router -``` - -Fourth add "my_subnet" to "my_router" and set the router's external gateway using PUBLICNET to allow outbound network access. - -``` shell -openstack --os-cloud={cloud name} router add subnet my_router my_dmz_subnet -``` - -Set the external gateway - -``` shell -openstack --os-cloud={cloud name} router set --external-gateway PUBLICNET my_router -``` - -Fifth gather the UUIDS for our image, flavor and network to create our server. - -``` shell -openstack --os-cloud={cloud name} image list -openstack --os-cloud={cloud name} flavor list -openstack --os-cloud={cloud name} network list -``` - -Lastly create your server! - -``` shell -openstack --os-cloud={cloud name} server create --flavor $FLAVOR_NAME \ - --image $IMAGE_NAME \ - --boot-from-volume 25 \ - --network $NETWORK_NAME \ - my_first_server -``` diff --git a/docs/openstack-service-overrides.md b/docs/openstack-service-overrides.md deleted file mode 100644 index 9343c578f..000000000 --- a/docs/openstack-service-overrides.md +++ /dev/null @@ -1,160 +0,0 @@ -# Setting Service Overrides for Nodes - -In cloud environments, it is sometimes necessary to define specific configuration values for unique nodes. This is particularly important for nodes with different CPU types, nodes that pass-through accelerators, and other unique hardware or configuration requirements. This document provides a comprehensive guide on how to define unique configurations for service-specific overrides using Kubernetes and OpenStack. - -## Label-Based Overrides - -Label-based overrides allow you to configure service-specific settings for an environment by defining a node or label to anchor on and specifying what will be overridden. In the following example, we override configuration values based on the "openstack-compute-cpu-type" label. - -### Example: Helm Label Overrides YAML - -The following YAML example demonstrates how to set label-based overrides for a cloud deployment that will have two different cpu types, enables some additional scheduler filters by default, and defines a set of shared CPUs that can be used on a given compute host for heterogeneous computing. - -| cpu-types | config overrides | -| ----------- | ---------- | -| default | Sets an alias for the p2000 GPU for passthrough. Enables additional scheduler filters | -| amd-3900 | Sets a single reserved core for the host. Sets a PCI device specification in support of the p2000 GPU for passthrough. | -| intel-12700 | Sets a set of shared CPUs (used to ensure nova only schedules to P-Cores). | - -``` yaml title="Configuration Overrides using Labels" -conf: - nova: - filter_scheduler: - enabled_filters: >- - ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter, - ServerGroupAffinityFilter,PciPassthroughFilter - available_filters: nova.scheduler.filters.all_filters - pci: - alias: >- - {"vendor_id": "10de", "product_id": "1c30", "device_type": "type-PCI", "name": "p2000"} - overrides: - nova_compute: # Chart + "_" + Daemonset (nova_compute) - labels: - - label: - key: openstack-compute-cpu-type # Defines a KEY - values: - - "amd-3900" # Defines a VALUE - conf: - nova: - DEFAULT: - reserved_host_cpus: "1" - pci: - device_spec: >- - {"vendor_id": "10de", "product_id": "1c30"} - - label: - key: openstack-compute-cpu-type # Defines a KEY - values: - - "intel-12700" # Defines a VALUE - conf: - nova: - compute: - cpu_shared_set: "0-15" -``` - -!!! note "PCI-Passthrough and Filters Notice" - - The above overrides are used to [passthrough a PCI](openstack-pci-passthrough.md) device in support of a GPU type. For more information on GPU passthrough, and how to interact with some of the [advanced scheduling](https://docs.openstack.org/nova/latest/admin/scheduling.html) filter capabilities found in OpenStack, have a look at the official upstream documentation. - -#### Label Overrides Explanation - -In the above example, two configurations are defined for nodes with the `openstack-compute-cpu-type` label. The system will override the default settings based on the value of this label: - -1. For nodes with the label `openstack-compute-cpu-type` and the value of `amd-3900`: the configuration sets `reserved_host_cpus` to "1" in the **default** section. -2. For nodes with the label `openstack-compute-cpu-type` and the value of `intel-12700`: the configuration sets `cpu_shared_set` to "0-15" in the **compute** section. - -If a node does not match any of the specified label values, the deployment will proceed with the default configuration. - -### Adding Node Labels - -To apply the label to a node, use the following `kubectl` command: - -``` shell -kubectl label node ${NODE_NAME} ${KEY}=${VALUE} -``` - -Replace `${NODE_NAME}`, `${KEY}`, and `${VALUE}` with the appropriate node name, key, and value. - -## Node-Specific Overrides - -Node-specific overrides allow you to configure options for an individual host without requiring additional labeling. - -### Example: Helm Node Override YAML - -The following YAML example demonstrates how to set node-specific overrides: - -``` yaml title="Configuration Overrides using Hosts" -conf: - overrides: - nova_compute: # Chart + "_" + Daemonset (nova_compute) - hosts: - - name: ${NODE_NAME} # Name of the node - conf: - nova: - compute: - cpu_shared_set: "8-15" -``` - -#### Node Overrides Explanation - -In this example, the configuration sets the `cpu_shared_set` to "8-15" for a specific node identified by `${NODE_NAME}`. - -Now, lets also look at a specific example of using pci device address to pass to nova. -Once you have validated that IOMMU is enbled: - -```shell title="Get device id" - lspci -nn | grep -i nvidia - > 3f:00.0 3D controller [0302]: NVIDIA Corporation GA103 [10de:2321] (rev a1) - > 56:00.0 3D controller [0302]: NVIDIA Corporation GA103 [10de:2321] (rev a1) -``` -In this example, `3f:00.0` and `56:00.0` is the address of the PCI device. The veendor ID is `10de` (for nvidia) and the product ID is `2321`. - -You can also confirm that the device is available for PCI passthrough: -```shell - ls -ld /sys/kernel/iommu_groups/*/devices/*3f:00.?/ -``` -We can now deploy the configuration override in nova like so: - -```yaml title="Configuration Overrides using Hosts" -conf: - nova: - pci: - alias: - type: multistring - values: - - '{"vendor_id": "10de", "product_id": "2321", "device_type": "type-PCI", "name": "h100", "numa_policy": "preferred"}' - - '{"vendor_id": "10de", "product_id": "1389", "device_type": "type-PCI", "name": "h100", "numa_policy": "preferred"}' - filter_scheduler: - enabled_filters: >- - ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter,AggregateInstanceExtraSpecsFilter,NUMATopologyFilter,PciPassthroughFilter - available_filters: nova.scheduler.filters.all_filters - overrides: - nova_compute: # Chart + "_" + Daemonset (nova_compute) - hosts: - - name: "compute001.h100.example.com" - conf: - nova: - pci: - alias: - type: multistring - values: - - '{"vendor_id": "10de", "product_id": "2321", "device_type": "type-PCI", "name": "h100", "numa_policy": "preferred"}' - - '{"vendor_id": "10de", "product_id": "1389", "device_type": "type-PCI", "name": "h100", "numa_policy": "preferred"}' - device_spec: >- - [{"address": "0000:3f:00.0"}, {"address": "0000:56:00.0"}] - filter_scheduler: - enabled_filters: >- - ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter,AggregateInstanceExtraSpecsFilter,NUMATopologyFilter,PciPassthroughFilter - available_filters: nova.scheduler.filters.all_filters -``` - -## Deploying Configuration Changes - -Once the overrides are in place, simply rerun the `helm` deployment command to apply the changes: - -``` shell -helm upgrade --install -f -``` - -## Conclusion - -By using label-based and/or node-specific overrides, you can customize the configuration of your Kubernetes and OpenStack environment to meet the specific needs of your environment. This approach ensures that each node operates with the optimal settings based on its hardware and role within the cluster. diff --git a/docs/openstack-skyline.md b/docs/openstack-skyline.md deleted file mode 100644 index 6c9242ab1..000000000 --- a/docs/openstack-skyline.md +++ /dev/null @@ -1,55 +0,0 @@ -# Deploy Skyline - -OpenStack Skyline is the next-generation web-based dashboard designed to provide a modern, responsive, and highly performant interface for managing OpenStack services. As an evolution of the traditional Horizon dashboard, Skyline focuses on improving user experience with a more streamlined and intuitive design, offering faster load times and enhanced responsiveness. It aims to deliver a more efficient and scalable way to interact with OpenStack components, catering to both administrators and end-users who require quick and easy access to cloud resources. In this document, we will cover the deployment of OpenStack Skyline using Genestack. Genestack ensures that Skyline is deployed effectively, allowing users to leverage its improved interface for managing both private and public cloud environments with greater ease and efficiency. - -## Create secrets - -!!! note "Information about the secretes used" - - Manual secret generation is only required if you haven't run the `create-secrets.sh` script located in `/opt/genestack/bin`. - - ??? example "Example secret generation" - - Skyline is a little different because there's no helm integration. Given this difference the deployment is far simpler, and all secrets - can be managed in one object. - - ``` shell - kubectl --namespace openstack \ - create secret generic skyline-apiserver-secrets \ - --type Opaque \ - --from-literal=service-username="skyline" \ - --from-literal=service-password="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-32};echo;)" \ - --from-literal=service-domain="service" \ - --from-literal=service-project="service" \ - --from-literal=service-project-domain="service" \ - --from-literal=db-endpoint="mariadb-cluster-primary.openstack.svc.cluster.local" \ - --from-literal=db-name="skyline" \ - --from-literal=db-username="skyline" \ - --from-literal=db-password="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-32};echo;)" \ - --from-literal=secret-key="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-32};echo;)" \ - --from-literal=keystone-endpoint="$(kubectl --namespace openstack get secret keystone-keystone-admin -o jsonpath='{.data.OS_AUTH_URL}' | base64 -d)" \ - --from-literal=keystone-username="skyline" \ - --from-literal=default-region="RegionOne" \ - --from-literal=prometheus_basic_auth_password="" \ - --from-literal=prometheus_basic_auth_user="" \ - --from-literal=prometheus_enable_basic_auth="false" \ - --from-literal=prometheus_endpoint="http://kube-prometheus-stack-prometheus.prometheus.svc.cluster.local:9090" - ``` - -!!! note - - All the configuration is in this one secret, so be sure to set your entries accordingly. - -## Run the deployment - -!!! tip - - Pause for a moment to consider if you will be wanting to access Skyline via the gateway-api controller over a specific FQDN. If so, adjust the gateway api definitions to suit your needs. For more information view [Gateway API](infrastructure-gateway-api.md)... - -``` shell -kubectl --namespace openstack apply -k /etc/genestack/kustomize/skyline/overlay -``` - -## Demo - -[![asciicast](https://asciinema.org/a/629816.svg)](https://asciinema.org/a/629816) diff --git a/docs/openstack-snapshot.md b/docs/openstack-snapshot.md deleted file mode 100644 index 090e651d7..000000000 --- a/docs/openstack-snapshot.md +++ /dev/null @@ -1,66 +0,0 @@ -# Openstack Snapshots - -#### Create a snapshot of the instance - -!!! note - - If necessary, list the instances to view the instance name with the list server command above. - -1. Shut down the source VM before you take the snapshot to ensure that all data is flushed to disk. Use the openstack server stop command to shut down the instance: - - ``` shell - openstack --os-cloud={cloud name} server stop myInstance - ``` - -2. Use the openstack server list command to confirm that the instance shows a SHUTOFF status. - -3. Use the openstack server image create command to take a snapshot: - - ``` shell - openstack --os-cloud={cloud name} server image create myInstance --name myInstanceSnapshot - ``` - - The above command creates the image myInstance by taking a snapshot of a running server. - -4. Use the openstack image list command to check the status until the status is active: - - ``` shell - openstack --os-cloud={cloud name} image list - ``` - -#### Show Image Details - -``` shell -openstack --os-cloud={cloud name} image show [--human-readable] -``` - -#### Download the snapshot - -!!! note - - Get the image id from the image list command (seen above). - -Download the snapshot by using the image ID: - -``` shell -openstack --os-cloud={cloud name} image save --file snapshot.raw {Image ID} -``` - -Make the image available to the new environment, either through HTTP or direct upload to a machine (scp). - -#### Import the snapshot to the new env - -In the new project or cloud environment, import the snapshot: - -``` shell -openstack --os-cloud={cloud name} image create NEW_IMAGE_NAME \ - --container-format bare --disk-format qcow2 --file IMAGE_URL -``` - -#### Boot a new sever from the snapshot - -In the new project or cloud environment, use the snapshot to create the new instance: - -``` shell -openstack --os-cloud={cloud name} server create --flavor m1.tiny --image myInstanceSnapshot myNewInstance -``` diff --git a/docs/openstack-swift-operators-guide.md b/docs/openstack-swift-operators-guide.md deleted file mode 100644 index a0ee3834f..000000000 --- a/docs/openstack-swift-operators-guide.md +++ /dev/null @@ -1,534 +0,0 @@ -# Openstack Swift Troubleshooting Guide - -## Cluster Health using swift-recon: - -```shell -# swift-recon --all -=============================================================================== ---> Starting reconnaissance on 4 hosts -=============================================================================== -[2016-11-16 15:55:21] Checking async pendings -[async_pending] low: 0, high: 5, avg: 1.2, total: 5, Failed: 0.0%, no_result: 0, reported: 4 -=============================================================================== -[2016-11-16 15:55:22] Checking auditor stats -[ALL_audit_time_last_path] low: 7169, high: 87084, avg: 57636.2, total: 230544, Failed: 0.0%, no_result: 0, reported: 4 -[ALL_quarantined_last_path] low: 0, high: 0, avg: 0.0, total: 0, Failed: 0.0%, no_result: 0, reported: 4 -[ALL_errors_last_path] low: 0, high: 0, avg: 0.0, total: 0, Failed: 0.0%, no_result: 0, reported: 4 -[ALL_passes_last_path] low: 36583, high: 72002, avg: 62929.5, total: 251718, Failed: 0.0%, no_result: 0, reported: 4 -[ALL_bytes_processed_last_path] low: 37109663, high: 73781423, avg: 64161611.5, total: 256646446, Failed: 0.0%, no_result: 0, reported: 4 -[ZBF_audit_time_last_path] low: 0, high: 22764, avg: 13134.3, total: 52537, Failed: 0.0%, no_result: 0, reported: 4 -[ZBF_quarantined_last_path] low: 0, high: 0, avg: 0.0, total: 0, Failed: 0.0%, no_result: 0, reported: 4 -[ZBF_errors_last_path] low: 0, high: 0, avg: 0.0, total: 0, Failed: 0.0%, no_result: 0, reported: 4 -[ZBF_bytes_processed_last_path] low: 0, high: 0, avg: 0.0, total: 0, Failed: 0.0%, no_result: 0, reported: 4 -=========================================================================== ==== -[2016-11-16 15:55:23] Checking updater times -[updater_last_sweep] low: 0, high: 5, avg: 2.2, total: 8, Failed: 0.0%, no_result: 0, reported: 4 -=========================================================================== ==== -[2016-11-16 15:55:24] Checking on expirers -[object_expiration_pass] low: 0, high: 2, avg: 1.5, total: 5, Failed: 0.0%, no_result: 0, reported: 4 -[expired_last_pass] low: 0, high: 0, avg: 0.0, total: 0, Failed: 0.0%, no_result: 0, reported: 4 -=========================================================================== ==== -[2016-11-16 15:55:24] Checking on replication -[replication_failure] low: 16, high: 33, avg: 22.5, total: 90, Failed: 0.0%, no_result: 0, reported: 4 -[replication_success] low: 127, high: 128, avg: 127.5, total: 510, Failed: 0.0%, no_result: 0, reported: 4 -[replication_time] low: 0, high: 0, avg: 0.8, total: 3, Failed: 0.0%, no_result: 0, reported: 4 -[replication_attempted] low: 128, high: 128, avg: 128.0, total: 512, Failed: 0.0%, no_result: 0, reported: 4 -Oldest completion was 2016-11-16 15:54:40 (44 seconds ago) by 10.240.0.61:6000. -Most recent completion was 2016-11-16 15:55:23 (1 seconds ago) by 10.240.0.60:6000. -=========================================================================== ==== -[2016-11-16 15:55:24] Getting unmounted drives from 4 hosts... -=============================================================================== -[2016-11-16 15:55:24] Checking load averages -[5m_load_avg] low: 0, high: 10, avg: 4.8, total: 19, Failed: 0.0%, no_result: 0, reported: 4 -[15m_load_avg] low: 0, high: 10, avg: 4.8, total: 19, Failed: 0.0%, no_result: 0, reported: 4 -[1m_load_avg] low: 0, high: 10, avg: 4.9, total: 19, Failed: 0.0%, no_result: 0, reported: 4 -=============================================================================== -[2016-11-16 15:55:24] Checking disk usage now -Distribution Graph: - ``0% 4 ********************************** - ``8% 8 ********************************************************************* -Disk usage: space used: 29906866176 of 601001820160 -Disk usage: space free: 571094953984 of 601001820160 -Disk usage: lowest: 0.13%, highest: 8.4%, avg: 4.97616898532% -=============================================================================== -[2016-11-16 15:55:25] Checking ring md5sums -4/4 hosts matched, 0 error[s] while checking hosts. -=============================================================================== -[2016-11-16 15:55:26] Checking swift.conf md5sum -4/4 hosts matched, 0 error[s] while checking hosts. -=============================================================================== -[2016-11-16 15:55:27] Checking quarantine -[quarantined_objects] low: 0, high: 0, avg: 0.0, total: 0, Failed: 0.0%, no_result: 0, reported: 4 -[quarantined_accounts] low: 0, high: 0, avg: 0.0, total: 0, Failed: 0.0%, no_result: 0, reported: 4 -[quarantined_containers] low: 0, high: 0, avg: 0.0, total: 0, Failed: 0.0%, no_result: 0, reported: 4 -=============================================================================== -[2016-11-16 15:55:27] Checking socket usage -[orphan] low: 0, high: 0, avg: 0.0, total: 0, Failed: 0.0%, no_result: 0, reported: 4 -[tcp_in_use] low: 14, high: 25, avg: 17.0, total: 68, Failed: 0.0%, no_result: 0, reported: 4 -[time_wait] low: 558, high: 896, avg: 750.8, total: 3003, Failed: 0.0%, no_result: 0, reported: 4 -[tcp6_in_use] low: 1, high: 1, avg: 1.0, total: 4, Failed: 0.0%, no_result: 0, reported: 4 -[tcp_mem_allocated_bytes] low: 28672, high: 380928, avg: 191488.0, total: 765952, Failed: 0.0%, no_result: 0, reported: 4 -=============================================================================== -[2016-11-16 15:55:28] Validating server type 'object' on 4 hosts... -4/4 hosts ok, 0 error[s] while checking hosts. -=============================================================================== -[2016-11-16 15:55:28] Checking drive-audit errors -[drive_audit_errors] - No hosts returned valid data. -=============================================================================== -[2016-11-16 15:55:28] Checking time-sync -!! http://10.240.1.60:6000/recon/time current time is 2016-11-16 15:55:28, but remote is 2016-11-16 15:55:28, differs by 0.00 sec -!! http://10.240.1.61:6000/recon/time current time is 2016-11-16 15:55:28, but remote is 2016-11-16 15:55:28, differs by 0.00 sec -!! http://10.240.0.61:6000/recon/time current time is 2016-11-16 15:55:28, but remote is 2016-11-16 15:55:28, differs by 0.00 sec -!! http://10.240.0.60:6000/recon/time current time is 2016-11-16 15:55:28, but remote is 2016-11-16 15:55:28, differs by 0.00 sec -0/4 hosts matched, 0 error[s] while checking hosts. -=============================================================================== -``` - -!!! note - - - **async_pending:** The amount of asyncs or updates to account/container databases, a non-zero value here is normal, if the number is increasing at an alarming rate for the cluster you may have an unmounted account/container drive, a host is down, the cluster is undersized for workload are just a few possible causes. - - **Replication (Oldest completion,Most recent):** These times should be close to each other if all services are up and no recent downtime on the cluster has occurred (down node, replaced drive). If this is not the case investigate "Oldest completion" node and inspect swift's object log for signs of "swift-object-replicator" entries that occurred recently. If there is a lack of entries restart swift-object-replicator (service swift-object-replicator), you may also wish to restart rsync daemon if /var/log/rsync.log is not being updated after restarting swift-object-replicator. - - **Getting unmounted drives**: Self explanatory drive is unmounted on server, check/repair/replace. - - **Checking load:** Check for any high values from mean average, run "swift-recon -lv" for verbose output to identify host with high load. Check node with high load for: Recently unmounted/replaced drive, XFS hang on object file system, hardware defect, read/write cache disabled, BBU drained or dead, bad SAS cable, bad SAS expander, bad JBOD, URE/Pending Sector/Read Errors (check smartctl + dmesg to identify drive) check dmesg for general warnings. - - **md5 check of swift.conf and rings:** If any nodes fail you may need to inspect configuration and ring files as one or many disagree with each other. - -## Unmounted disks: - -```shell -# swift-recon -uv -=============================================================================== ---> Starting reconnaissance on 4 hosts -=============================================================================== -[2016-11-16 15:58:37] Getting unmounted drives from 4 hosts... --> http://10.240.1.61:6000/recon/unmounted: [] --> http://10.240.1.60:6000/recon/unmounted: [{u'device': u'sdb',u'mounted': False}] --> http://10.240.0.61:6000/recon/unmounted: [] --> http://10.240.0.60:6000/recon/unmounted: [] -Not mounted: sdb on 10.240.1.60:6000 -=============================================================================== -(swift-13.3.3) root@infra1-swift-proxy-container-342199b9:~# swift-recon -u -=============================================================================== ---> Starting reconnaissance on 4 hosts -=============================================================================== -[2016-11-16 15:58:47] Getting unmounted drives from 4 hosts... -Not mounted: sdb on 10.240.1.60:6000 -=============================================================================== -``` - -!!! note - -Login to the problematic host and find the root cause of the issue, some common issues where a drive is reported unmounted: - - - Drive has XFS errors, check syslog and dmesg for XFS related issues. XFS issues are common, further triage will be needed to make sure there is not underlying hardware issues at play. - - If you find XFS errors in the logs, first try to umount (umount /srv/node/diskXX) the drive and remount (mount -a), this will replay the XFS journal and repair. - - If the drive fails to mount, you will need to try and perform XFS repair (xfs_repair /dev/sXX), if xfs_repair errors out and cannot repair drive you will be instructed to run xfs_repair with -L flag THIS IS VERY DANGEROUS! YOU ARE AT RISK OF LOOSING DATA. If sufficient replicas exist on the ring you might be better off formatting the drive and have Swift re-create the missing replica on disk. - - Check S.M.A.R.T data (Self-Monitoring, Analysis and Reporting Technology) Each hard drive has a built on diagnostics and record keeping device. You can query this data to see performance metrics on the misbehaving drive. - - Two key things to observe - - Pending Sectors/URE (Unrecoverable Read Error) When a drive attempts to read data from a block and there is underlying issues, usually mechanical or surface defects it will flag the block as a pending sector, meaning it cannot read from that block anymore, whatever data was on that block is corrupt and no longer reliable. The drive will NOT revector that sector until the block is WRITTEN to again. You will continue to have errors until the pending sector is written to. UREs will cause XFS hangs and in some causes system instability. Running badblocks on the device will cause all pending sectors to be vectored. - - Remapped Sector: There are special reserve space on all drives that user land does not have access to, part of this restricted space are reserve blocks designated by the manufacture in case they shipped the drive with surface/mechanical defects. Once the drive detects a URE and is forced to remap, the URE is "converted" into a remapped sector. Basically the drive will put a pointer from the old bad sector to its reserve space. Values over 10-20 are cause for concern as there is a high probability that there are mechanical defects. - -## Dispersion report: - -!!! note - - swift-dispersion-report should be ran on the designated dispersion proxy container in the environment. The purpose of dispersion is to strategically place container and objects along the ring to fulfill the percentage of coverage specified in the /etc/swift/swift-disperson.conf, default is 1%. If you run swift-dispersion-report and it reports no containers exist, your either on the wrong node or swift-dispersion-populate has not been ran. Dispersion is a great tool at determining ring heath and also checks for any permission issues. Permission issues on /srv/node/diskXX wont be flagged with swift-recon since the drive is not unmounted but has issues preventing reads/writes from occurring. Dispersion is very useful when rebalancing or drive replacement. The data is static so running dispersion after a node reboot or failure/remounting a failed disk will show nothing of value since the dispersion data does not reflect asyncs or missing replicas from disk or current replication lag. - -Healthy dispersion report: - -```shell -# swift-dispersion-report -Using storage policy: default -Queried 128 containers for dispersion reporting, 1s, 0 retries -100.00% of container copies found (256 of 256) -Sample represents 50.00% of the container partition space -Queried 128 objects for dispersion reporting, 14s, 0 retries -There were 128 partitions missing 0 copies. -100.00% of object copies found (256 of 256) -Sample represents 50.00% of the object partition space -``` - -Unmounted Drive: - -```shell -# swift-dispersion-report -Using storage policy: default -Queried 128 containers for dispersion reporting, 5s, 0 retries -100.00% of container copies found (256 of 256) -Sample represents 50.00% of the container partition space -ERROR: 10.240.1.60:6000/sdb is unmounted -- This will cause replicas designated for that device to be considered missing until resolved or the ring is updated. -Queried 128 objects for dispersion reporting, 20s, 0 retries -There were 93 partitions missing 0 copies. -! There were 35 partitions missing 1 copy. -86.33% of object copies found (221 of 256) -Sample represents 50.00% of the object partition space -``` - -Dispersion report after failed disk replacement: - -```shell -# swift-dispersion-report -Using storage policy: default -Queried 128 containers for dispersion reporting, 2s, 0 retries -100.00% of container copies found (256 of 256) -Sample represents 50.00% of the container partition space -Queried 128 objects for dispersion reporting, 8s, 0 retries -There were 93 partitions missing 0 copies. -! There were 35 partitions missing 1 copy. -86.33% of object copies found (221 of 256) -Sample represents 50.00% of the object partition space -``` - -Dispersion report after a failed disk replacement minutes later: - -```shell -swift-dispersion-report -Using storage policy: default -Queried 128 containers for dispersion reporting, 1s, 0 retries -100.00% of container copies found (256 of 256) -Sample represents 50.00% of the container partition space -Queried 128 objects for dispersion reporting, 2s, 0 retries -There were 120 partitions missing 0 copies. -! There were 8 partitions missing 1 copy. -96.88% of object copies found (248 of 256) -Sample represents 50.00% of the object partition space -``` - -Dispersion report errors while running: - -```shell -# swift-dispersion-report -Using storage policy: default -Queried 128 containers for dispersion reporting, 2s, 0 retries -100.00% of container copies found (256 of 256) -Sample represents 50.00% of the container partition space -ERROR: 10.240.0.61:6000/sdb: 15 seconds -ERROR: 10.240.0.61:6000/sdc: 15 seconds -ERROR: 10.240.0.61:6000/sdc: 15 seconds -ERROR: 10.240.0.61:6000/sdc: 15 seconds -ERROR: 10.240.0.61:6000/sdb: 15 seconds -``` - -!!! note - - - Out of workers for account/container/object, check load on object server for high usage, you may need to increase worker count, however increasing worker threads might over subscribe node, proceed with caution! - - Drive is having issues, login to node and check disk that is causing errors. - -## Locating Objects in Swift - -We will be uploading a file to swift, showing the account/container and object interactions and verifying account/container and object are in their correct place. - -!!! info - - Examples provided are with TWO replicas - -!!! warning - - Using swift-get-nodes will not verify the AUTH/Container/Object is valid, the use of swift-get-nodes is to provide the hash of the objects location, there is no error checking or validation used in swift-get-nodes! - - - -```shell -# swift upload iso xenial-server-cloudimg-amd64-disk1.img -xenial-server-cloudimg-amd64-disk1.img -# swift stat - Account: AUTH_0b4e002d1ab94385ab0895f2aaee33c9 - Containers: 1 - Objects: 0 - Bytes: 0 -Containers in policy "default": 1 - Objects in policy "default": 0 - Bytes in policy "default": 0 - X-Account-Project-Domain-Id: default - Accept-Ranges: bytes - X-Timestamp: 1484158003.79601 - X-Trans-Id: txe2debd9bced9408393d9d-00587674a7 - Content-Type: text/plain; charset=utf-8 -# swift list -iso -# swift list iso -xenial-server-cloudimg-amd64-disk1.img -``` - -## Consult the Account ring and verify Account DB placement is correct: - -```shell -# swift-get-nodes -a /etc/swift/account.ring.gz AUTH_0b4e002d1ab94385ab0895f2aaee33c9 - -Account AUTH_0b4e002d1ab94385ab0895f2aaee33c9 -Container None -Object None - -Partition 108 -Hash 6cc6a2e7fbc5af96512b34a75edc682e - -Server:Port Device 10.240.1.60:6002 sdd -Server:Port Device 10.240.0.61:6002 sdd -Server:Port Device 10.240.0.60:6002 sdd [Handoff] -Server:Port Device 10.240.1.61:6002 sdd [Handoff] - -curl -I -XHEAD "http://10.240.1.60:6002/sdd/108/AUTH_0b4e002d1ab94385ab0895f2aaee33c9" -curl -I -XHEAD "http://10.240.0.61:6002/sdd/108/AUTH_0b4e002d1ab94385ab0895f2aaee33c9" -curl -I -XHEAD "http://10.240.0.60:6002/sdd/108/AUTH_0b4e002d1ab94385ab0895f2aaee33c9" #[Handoff] -curl -I -XHEAD "http://10.240.1.61:6002/sdd/108/AUTH_0b4e002d1ab94385ab0895f2aaee33c9" #[Handoff] - -Use your own device location of servers: such as "export DEVICE=/srv/node" -ssh 10.240.1.60 "ls -lah ${DEVICE:-/srv/node*}/sdd/accounts/108/82e/6cc6a2e7fbc5af96512b34a75edc682e" -ssh 10.240.0.61 "ls -lah ${DEVICE:-/srv/node*}/sdd/accounts/108/82e/6cc6a2e7fbc5af96512b34a75edc682e" -ssh 10.240.0.60 "ls -lah ${DEVICE:-/srv/node*}/sdd/accounts/108/82e/6cc6a2e7fbc5af96512b34a75edc682e" # [Handoff] -ssh 10.240.1.61 "ls -lah ${DEVICE:-/srv/node*}/sdd/accounts/108/82e/6cc6a2e7fbc5af96512b34a75edc682e" # [Handoff] - -note: `/srv/node*` is used as default value of `devices`, the real value is set in the config file on each storage node. -``` - -Verify placement of the account database, account db should be on primary nodes, handoff nodes indicate a problem or overloaded cluster. - -Primary Node: - -```shell -# curl -I -XHEAD "http://10.240.1.60:6002/sdd/108/AUTH_0b4e002d1ab94385ab0895f2aaee33c9" -HTTP/1.1 204 No Content -X-Account-Sysmeta-Project-Domain-Id: default -X-Put-Timestamp: 1484158003.80108 -X-Account-Object-Count: 1 -X-Account-Storage-Policy-Default-Bytes-Used: 322371584 -X-Account-Storage-Policy-Default-Object-Count: 1 -X-Timestamp: 1484158003.79601 -X-Account-Bytes-Used: 322371584 -X-Account-Container-Count: 1 -Content-Type: text/plain; charset=utf-8 -X-Account-Storage-Policy-Default-Container-Count: 1 -Content-Length: 0 -Date: Wed, 11 Jan 2017 19:16:46 GMT -``` - - Primary Node: - -```shell -# curl -I -XHEAD "http://10.240.0.61:6002/sdd/108/AUTH_0b4e002d1ab94385ab0895f2aaee33c9" -HTTP/1.1 204 No Content -X-Account-Sysmeta-Project-Domain-Id: default -X-Put-Timestamp: 1484158003.80108 -X-Account-Object-Count: 1 -X-Account-Storage-Policy-Default-Bytes-Used: 322371584 -X-Account-Storage-Policy-Default-Object-Count: 1 -X-Timestamp: 1484158003.79601 -X-Account-Bytes-Used: 322371584 -X-Account-Container-Count: 1 -Content-Type: text/plain; charset=utf-8 -X-Account-Storage-Policy-Default-Container-Count: 1 -Content-Length: 0 -Date: Wed, 11 Jan 2017 19:16:46 GMT -``` - - Handoff (404 is expected) - -```shell -# curl -I -XHEAD "http://10.240.0.60:6002/sdd/108/AUTH_0b4e002d1ab94385ab0895f2aaee33c9" # [Handoff] -HTTP/1.1 404 Not Found -Content-Length: 0 -Content-Type: text/html; charset=utf-8 -Date: Wed, 11 Jan 2017 19:16:46 GMT -``` - - Handoff (404 is expected) - -```shell -# curl -I -XHEAD "http://10.240.1.61:6002/sdd/108/AUTH_0b4e002d1ab94385ab0895f2aaee33c9" # [Handoff] -HTTP/1.1 404 Not Found -Content-Length: 0 -Content-Type: text/html; charset=utf-8 -Date: Wed, 11 Jan 2017 19:16:46 GMT -``` - -## Consult the Container ring and verify Container DB placement is correct: - -```shell -# swift-get-nodes AUTH_0b4e002d1ab94385ab0895f2aaee33c9 iso - -Account AUTH_0b4e002d1ab94385ab0895f2aaee33c9 -Container iso -Object None - -Partition 70 -Hash 461a188566b0718ba5fa8ec057b8d78f - -Server:Port Device 10.240.1.61:6001 sdd -Server:Port Device 10.240.0.61:6001 sdd -Server:Port Device 10.240.0.60:6001 sdd [Handoff] -Server:Port Device 10.240.1.60:6001 sdd [Handoff] - -curl -I -XHEAD "http://10.240.1.61:6001/sdd/70/AUTH_0b4e002d1ab94385ab0895f2aaee33c9/iso" -curl -I -XHEAD "http://10.240.0.61:6001/sdd/70/AUTH_0b4e002d1ab94385ab0895f2aaee33c9/iso" -curl -I -XHEAD "http://10.240.0.60:6001/sdd/70/AUTH_0b4e002d1ab94385ab0895f2aaee33c9/iso" #[Handoff] -curl -I -XHEAD "http://10.240.1.60:6001/sdd/70/AUTH_0b4e002d1ab94385ab0895f2aaee33c9/iso" #[Handoff] - -Use your own device location of servers: such as "export DEVICE=/srv/node" -ssh 10.240.1.61 "ls -lah ${DEVICE:-/srv/node*}/sdd/containers/70/78f/461a188566b0718ba5fa8ec057b8d78f" -ssh 10.240.0.61 "ls -lah ${DEVICE:-/srv/node*}/sdd/containers/70/78f/461a188566b0718ba5fa8ec057b8d78f" -ssh 10.240.0.60 "ls -lah ${DEVICE:-/srv/node*}/sdd/containers/70/78f/461a188566b0718ba5fa8ec057b8d78f" #[Handoff] -ssh 10.240.1.60 "ls -lah ${DEVICE:-/srv/node*}/sdd/containers/70/78f/461a188566b0718ba5fa8ec057b8d78f" #[Handoff] - -note: `/srv/node*` is used as default value of `devices`, the real value is set in the config file on each storage node. -``` - - Primary Node: - -```shell -# curl -I -XHEAD "http://10.240.1.61:6001/sdd/70/AUTH_0b4e002d1ab94385ab0895f2aaee33c9/iso" -HTTP/1.1 204 No Content -X-Backend-Timestamp: 1484158003.81339 -X-Container-Object-Count: 1 -X-Put-Timestamp: 1484158024.33580 -X-Backend-Put-Timestamp: 1484158024.33580 -X-Backend-Delete-Timestamp: 0000000000.00000 -X-Container-Bytes-Used: 322371584 -X-Timestamp: 1484158003.81339 -X-Backend-Storage-Policy-Index: 0 -Content-Type: text/plain; charset=utf-8 -X-Backend-Status-Changed-At: 1484158003.81664 -Content-Length: 0 -Date: Wed, 11 Jan 2017 19:17:38 GMT -``` - - Primary Node: - -```shell -# curl -I -XHEAD "http://10.240.0.61:6001/sdd/70/AUTH_0b4e002d1ab94385ab0895f2aaee33c9/iso" -HTTP/1.1 204 No Content -X-Backend-Timestamp: 1484158003.81339 -X-Container-Object-Count: 1 -X-Put-Timestamp: 1484158024.33580 -X-Backend-Put-Timestamp: 1484158024.33580 -X-Backend-Delete-Timestamp: 0000000000.00000 -X-Container-Bytes-Used: 322371584 -X-Timestamp: 1484158003.81339 -X-Backend-Storage-Policy-Index: 0 -Content-Type: text/plain; charset=utf-8 -X-Backend-Status-Changed-At: 1484158003.81664 -Content-Length: 0 -Date: Wed, 11 Jan 2017 19:17:38 GMT -``` - - Handoff (404 is expected) - -```shell -# curl -I -XHEAD "http://10.240.0.60:6001/sdd/70/AUTH_0b4e002d1ab94385ab0895f2aaee33c9/iso" # [Handoff] -HTTP/1.1 404 Not Found -X-Backend-Timestamp: 0000000000.00000 -X-Backend-Put-Timestamp: 0000000000.00000 -X-Backend-Delete-Timestamp: 0000000000.00000 -X-Backend-Storage-Policy-Index: 0 -Content-Type: text/html; charset=UTF-8 -X-Backend-Status-Changed-At: 0000000000.00000 -Content-Length: 0 -Date: Wed, 11 Jan 2017 19:17:38 GMT -``` - - Handoff (404 is expected) - -```shell -# curl -I -XHEAD "http://10.240.1.60:6001/sdd/70/AUTH_0b4e002d1ab94385ab0895f2aaee33c9/iso" # [Handoff] -HTTP/1.1 404 Not Found -X-Backend-Timestamp: 0000000000.00000 -X-Backend-Put-Timestamp: 0000000000.00000 -X-Backend-Delete-Timestamp: 0000000000.00000 -X-Backend-Storage-Policy-Index: 0 -Content-Type: text/html; charset=UTF-8 -X-Backend-Status-Changed-At: 0000000000.00000 -Content-Length: 0 -Date: Wed, 11 Jan 2017 19:17:39 GMT -``` - -## Consult Object ring and verify placement of Objects - -```shell -# swift-get-nodes -a /etc/swift/object.ring.gz AUTH_0b4e002d1ab94385ab0895f2aaee33c9 iso xenial-server-cloudimg-amd64-disk1.img - -Account AUTH_0b4e002d1ab94385ab0895f2aaee33c9 -Container iso -Object xenial-server-cloudimg-amd64-disk1.img - -Partition 182 -Hash b6716383aa4a99bf3eb68c46453652d4 - -Server:Port Device 10.240.1.60:6002 sdd -Server:Port Device 10.240.0.61:6002 sdd -Server:Port Device 10.240.1.61:6002 sdd [Handoff] -Server:Port Device 10.240.0.60:6002 sdd [Handoff] - -curl -I -XHEAD "http://10.240.1.60:6002/sdd/182/AUTH_0b4e002d1ab94385ab0895f2aaee33c9/iso/xenial-server-cloudimg-amd64-disk1.img" -curl -I -XHEAD "http://10.240.0.61:6002/sdd/182/AUTH_0b4e002d1ab94385ab0895f2aaee33c9/iso/xenial-server-cloudimg-amd64-disk1.img" -curl -I -XHEAD "http://10.240.1.61:6002/sdd/182/AUTH_0b4e002d1ab94385ab0895f2aaee33c9/iso/xenial-server-cloudimg-amd64-disk1.img" #[Handoff] -curl -I -XHEAD "http://10.240.0.60:6002/sdd/182/AUTH_0b4e002d1ab94385ab0895f2aaee33c9/iso/xenial-server-cloudimg-amd64-disk1.img" #[Handoff] - -Use your own device location of servers: such as "export DEVICE=/srv/node" -ssh 10.240.1.60 "ls -lah ${DEVICE:-/srv/node*}/sdd/objects/182/2d4/b6716383aa4a99bf3eb68c46453652d4" -ssh 10.240.0.61 "ls -lah ${DEVICE:-/srv/node*}/sdd/objects/182/2d4/b6716383aa4a99bf3eb68c46453652d4" -ssh 10.240.1.61 "ls -lah ${DEVICE:-/srv/node*}/sdd/objects/182/2d4/b6716383aa4a99bf3eb68c46453652d4" #[Handoff] -ssh 10.240.0.60 "ls -lah ${DEVICE:-/srv/node*}/sdd/objects/182/2d4/b6716383aa4a99bf3eb68c46453652d4" #[Handoff] - -note: `/srv/node*` is used as default value of `devices`, the real value is set in the config file on each storage node. -``` - -Use curl commands above to verify the object is correctly placed on the primary devices. - -## Inspect Swift Object on storage disk: - -```shell -# swift-object-info sdb/objects/182/2d4/b6716383aa4a99bf3eb68c46453652d4/1484158024.61997.data -Path: /AUTH_0b4e002d1ab94385ab0895f2aaee33c9/iso/xenial-server-cloudimg-amd64-disk1.img - ``Account: AUTH_0b4e002d1ab94385ab0895f2aaee33c9 - ``Container: iso - ``Object: xenial-server-cloudimg-amd64-disk1.img - ``Object hash: b6716383aa4a99bf3eb68c46453652d4 -Content-Type: application/octet-stream -Timestamp: 2017-01-11T18:07:04.619970 (1484158024.61997) -System Metadata: - ``No metadata found -User Metadata: - ``X-Object-Meta-Mtime: 1483724080.000000 -Other Metadata: - ``No metadata found -ETag: 0924ed40babf9fa5bbfb51844c7adfbc (valid) -Content-Length: 322371584 (valid) -Partition 182 -Hash b6716383aa4a99bf3eb68c46453652d4 -Server:Port Device 10.240.0.61:6000 sdb -Server:Port Device 10.240.1.61:6000 sdb -Server:Port Device 10.240.1.60:6000 sdb [Handoff] -Server:Port Device 10.240.0.60:6000 sdc [Handoff] - -curl -I -XHEAD "http://10.240.0.61:6000/sdb/182/AUTH_0b4e002d1ab94385ab0895f2aaee33c9/iso/xenial-server-cloudimg-amd64-disk1.img" -H "X-Backend-Storage-Policy-Index: 0" -curl -I -XHEAD "http://10.240.1.61:6000/sdb/182/AUTH_0b4e002d1ab94385ab0895f2aaee33c9/iso/xenial-server-cloudimg-amd64-disk1.img" -H "X-Backend-Storage-Policy-Index: 0" -curl -I -XHEAD "http://10.240.1.60:6000/sdb/182/AUTH_0b4e002d1ab94385ab0895f2aaee33c9/iso/xenial-server-cloudimg-amd64-disk1.img" -H "X-Backend-Storage-Policy-Index: 0" # [Handoff] -curl -I -XHEAD "http://10.240.0.60:6000/sdc/182/AUTH_0b4e002d1ab94385ab0895f2aaee33c9/iso/xenial-server-cloudimg-amd64-disk1.img" -H "X-Backend-Storage-Policy-Index: 0" # [Handoff] - -Use your own device location of servers: such as "export DEVICE=/srv/node" -ssh 10.240.0.61 "ls -lah ${DEVICE:-/srv/node*}/sdb/objects/182/2d4/b6716383aa4a99bf3eb68c46453652d4" -ssh 10.240.1.61 "ls -lah ${DEVICE:-/srv/node*}/sdb/objects/182/2d4/b6716383aa4a99bf3eb68c46453652d4" -ssh 10.240.1.60 "ls -lah ${DEVICE:-/srv/node*}/sdb/objects/182/2d4/b6716383aa4a99bf3eb68c46453652d4" # [Handoff] -ssh 10.240.0.60 "ls -lah ${DEVICE:-/srv/node*}/sdc/objects/182/2d4/b6716383aa4a99bf3eb68c46453652d4" # [Handoff] - -note: `/srv/node*` is used as default value of `devices`, the real value is set in the config file on each storage node. -``` - -## Read XFS metadata of object on disk: - -Create swift-meta.py file: - -```bash -# swift-meta.py -import pickle -with open("/dev/stdin") as f: - ``print pickle.loads(f.read()) -``` - -Read file's metadata from object node: - -```bash -# getfattr -d --only-values -n user.swift.metadata /mnt/sdb/objects/182/2d4/b6716383aa4a99bf3eb68c46453652d4/1484158024.61997.data | python swift-meta.py -getfattr: Removing leading '/' from absolute path names -{'Content-Length': '322371584', 'name': '/AUTH_0b4e002d1ab94385ab0895f2aaee33c9/iso/xenial-server-cloudimg-amd64-disk1.img', 'Content-Type': 'application/octet-stream', 'ETag': '0924ed40babf9fa5bbfb51844c7adfbc', 'X-Timestamp': '1484158024.61997', 'X-Object-Meta-Mtime': '1483724080.000000’} -``` - -[More information can be found here](https://docs.openstack.org/swift/latest/) diff --git a/docs/openstack-volumes.md b/docs/openstack-volumes.md deleted file mode 100644 index 7590a21b6..000000000 --- a/docs/openstack-volumes.md +++ /dev/null @@ -1,56 +0,0 @@ -#Openstack Volumes - -#### Boot instance from volume - -You can create a bootable volume from an existing image, volume, or snapshot. This procedure shows you how to create a volume from an image and use the volume to boot an instance. - -1. List available images, noting the ID of the image that you wish to use. - - ``` shell - openstack --os-cloud={cloud name} image list - ``` - -2. Create a bootable volume from the chosen image. - - ``` shell - openstack --os-cloud={cloud name} volume create \ - --image {Image ID} --size 10 \ - test-volume - ``` - -3. Create a server, specifying the volume as the boot device. - - ``` shell - openstack --os-cloud={cloud name} server create \ - --flavor $FLAVOR --network $NETWORK \ - --volume {Volume ID}\ - --wait test-server - ``` - -4. List volumes once again to ensure the status has changed to in-use and the volume is correctly reporting the attachment. - - ``` shell - openstack --os-cloud={cloud name} volume list - ``` - - ``` shell - openstack --os-cloud={cloud name} server volume list test-server - ``` -# Additional Server Volume Commands - -#### Add Volume to Server - -``` shell -openstack --os-cloud={cloud name} server add volume - [--device ] - [--tag ] - [--enable-delete-on-termination | --disable-delete-on-termination] - - -``` - -#### Remove Volume from Server - -``` shell -openstack --os-cloud={cloud name} server remove volume -``` diff --git a/docs/overrides/stylesheets/admonition.css b/docs/overrides/stylesheets/admonition.css deleted file mode 100644 index 6cbc2ab77..000000000 --- a/docs/overrides/stylesheets/admonition.css +++ /dev/null @@ -1,25 +0,0 @@ - -/* -Custom Genestack Admonition Type -*/ - -:root { - --md-admonition-icon--genestack: url('/assets/images/genestack-mono.svg'); -} - -.md-typeset .admonition.genestack, -.md-typeset details.genestack { - border-color: rgb(158, 0, 0); -} - -.md-typeset .genestack>.admonition-title, -.md-typeset .genestack>summary { - background-color: rgba(158, 0, 0, 0.1); -} - -.md-typeset .genestack>.admonition-title::before, -.md-typeset .genestack>summary::before { - background-color: rgb(158, 0, 0); - -webkit-mask-image: var(--md-admonition-icon--genestack); - mask-image: var(--md-admonition-icon--genestack); -} diff --git a/docs/overrides/stylesheets/adr.css b/docs/overrides/stylesheets/adr.css deleted file mode 100644 index 10acc83d2..000000000 --- a/docs/overrides/stylesheets/adr.css +++ /dev/null @@ -1,232 +0,0 @@ -.adr_header { - display: grid; - grid-template-columns: fit-content(30%) auto; - width: 100%; - font-size: 0.7rem; -} - -.adr_header>dd { - margin: 0 !important; - padding: 0.1rem 0.3rem 0.1rem; -} - -.adr_header>dt { - font-weight: bold; -} - -.c-pill { - align-items: center; - font-family: "Open Sans", Arial, Verdana, sans-serif; - font-weight: bold; - font-size: 14px; - height: 100%; - white-space: nowrap; - width: auto; - position: relative; - border-radius: 100px; - line-height: 1 !important; - overflow: scroll; - padding: 0px 12px 0px 20px; - text-overflow: ellipsis; - line-height: 1.25rem; - color: #595959; - word-break: break-word; - &:before { - border-radius: 50%; - content: ''; - height: 10px; - left: 6px; - margin-top: -5px; - position: absolute; - top: 50%; - width: 10px; - } -} - -.c-pill-draft { - background: #a3a3a3; -} - -.c-pill-draft:before { - background: #505050; -} - -.c-pill-proposed { - background: #b6d8ff; -} - -.c-pill-proposed:before { - background: #0077ff; -} - -.c-pill-accepted { - background: #b4eda0; -} - -.c-pill-accepted:before { - background: #6BC167; -} - -.c-pill-rejected { - background: #ffd5d1; -} - -.c-pill-rejected:before { - background: #ff4436; -} - -.c-pill-superseded { - background: #ffebb6; -} - -.c-pill-superseded:before { - background: #ffc400; -} - -.adr_header .md-tag { - display: inline !important; - -} - -.adr_header .md-tags { - margin-bottom: 0% !important; - margin-top: unset !important; -} - -.md-grid { - max-width: 100%; - flex-grow: 1 -} - -.md-main__inner { - display: flex; - height: 100%; - margin-top: 1.5rem -} - -.md-content { - flex-grow: 1; - min-width: 0; - max-width: 1000px; -} - -@media only screen and (min-width: 1220px) { - .md-main { - flex-grow: 1; - margin-left: auto; - margin-right: auto - } -} - -@media screen { - [data-md-color-scheme=rxt] { - --md-default-fg-color: hsla(var(--md-hue),15%,90%,0.82); - --md-default-fg-color--light: hsla(var(--md-hue),15%,90%,0.56); - --md-default-fg-color--lighter: hsla(var(--md-hue),15%,90%,0.32); - --md-default-fg-color--lightest: hsla(var(--md-hue),15%,90%,0.12); - --md-default-bg-color: hsla(var(--md-hue),15%,14%,1); - --md-default-bg-color--light: hsla(var(--md-hue),15%,14%,0.54); - --md-default-bg-color--lighter: hsla(var(--md-hue),15%,14%,0.26); - --md-default-bg-color--lightest: hsla(var(--md-hue),15%,14%,0.07); - --md-code-fg-color: hsla(var(--md-hue),18%,86%,0.82); - --md-code-bg-color: hsla(var(--md-hue),15%,18%,1); - --md-code-hl-color: #2977ff; - --md-code-hl-color--light: #2977ff1a; - --md-code-hl-number-color: #e6695b; - --md-code-hl-special-color: #f06090; - --md-code-hl-function-color: #c973d9; - --md-code-hl-constant-color: #9383e2; - --md-code-hl-keyword-color: #6791e0; - --md-code-hl-string-color: #2fb170; - --md-code-hl-name-color: var(--md-code-fg-color); - --md-code-hl-operator-color: var(--md-default-fg-color--light); - --md-code-hl-punctuation-color: var(--md-default-fg-color--light); - --md-code-hl-comment-color: var(--md-default-fg-color--light); - --md-code-hl-generic-color: var(--md-default-fg-color--light); - --md-code-hl-variable-color: var(--md-default-fg-color--light); - --md-typeset-color: var(--md-default-fg-color); - --md-typeset-a-color: #9e0000; - --md-typeset-kbd-color: hsla(var(--md-hue),15%,90%,0.12); - --md-typeset-kbd-accent-color: hsla(var(--md-hue),15%,90%,0.2); - --md-typeset-kbd-border-color: hsla(var(--md-hue),15%,14%,1); - --md-typeset-mark-color: #4287ff4d; - --md-typeset-table-color: hsla(var(--md-hue),15%,95%,0.12); - --md-typeset-table-color--light: hsla(var(--md-hue),15%,95%,0.035); - --md-admonition-fg-color: var(--md-default-fg-color); - --md-admonition-bg-color: var(--md-default-bg-color); - --md-footer-bg-color: hsla(var(--md-hue),15%,10%,0.87); - --md-footer-bg-color--dark: hsla(var(--md-hue),15%,8%,1); - --md-shadow-z1: 0 0.2rem 0.5rem #0000000d,0 0 0.05rem #0000001a; - --md-shadow-z2: 0 0.2rem 0.5rem #00000040,0 0 0.05rem #00000040; - --md-shadow-z3: 0 0.2rem 0.5rem #0006,0 0 0.05rem #00000059; - color-scheme: dark - } - - [data-md-color-scheme=rxt] img[src$="#gh-light-mode-only"],[data-md-color-scheme=rxt] img[src$="#only-light"] { - display: none - } - - [data-md-color-scheme=rxt][data-md-color-primary=pink] { - --md-typeset-a-color: #eb0000 - } - - [data-md-color-scheme=rxt][data-md-color-primary=pink] { - --md-typeset-a-color: #ed5487 - } - - [data-md-color-scheme=rxt][data-md-color-primary=purple] { - --md-typeset-a-color: #c46fd3 - } - - [data-md-color-scheme=rxt][data-md-color-primary=deep-purple] { - --md-typeset-a-color: #a47bea - } - - [data-md-color-scheme=rxt][data-md-color-primary=indigo] { - --md-typeset-a-color: #5488e8 - } - - [data-md-color-scheme=rxt][data-md-color-primary=teal] { - --md-typeset-a-color: #00ccb8 - } - - [data-md-color-scheme=rxt][data-md-color-primary=green] { - --md-typeset-a-color: #71c174 - } - - [data-md-color-scheme=rxt][data-md-color-primary=deep-orange] { - --md-typeset-a-color: #ff764d - } - - [data-md-color-scheme=rxt][data-md-color-primary=brown] { - --md-typeset-a-color: #c1775c - } - - [data-md-color-scheme=rxt][data-md-color-primary=black],[data-md-color-scheme=rxt][data-md-color-primary=blue-grey],[data-md-color-scheme=rxt][data-md-color-primary=grey],[data-md-color-scheme=rxt][data-md-color-primary=white] { - --md-typeset-a-color: #eb0000 - } - - [data-md-color-switching] *,[data-md-color-switching] :after,[data-md-color-switching] :before { - transition-duration: 0ms!important - } - - .md-typeset a { - color: #eb0000; - word-break: break-word - } - - .md-nav--primary .md-nav__item--active>.md-nav__link { - color: #eb0000; - } - - .md-nav__item .md-nav__link--active,.md-nav__item .md-nav__link--active code { - color: #9e0000; - } -} - -[data-md-color-accent=red] { - --md-accent-fg-color: #eb0000; - --md-accent-fg-color--transparent: #ff19471a; - --md-accent-bg-color: #fff; - --md-accent-bg-color--light: #ffffffb3 -} diff --git a/docs/ovn-alert-claim-storm.md b/docs/ovn-alert-claim-storm.md deleted file mode 100644 index 469b308d9..000000000 --- a/docs/ovn-alert-claim-storm.md +++ /dev/null @@ -1,195 +0,0 @@ -This page explains the `OVN claim storm` alert in _Genestack_. - -# Background information - -_OVN_ has a distributed architecture without a central controller. The -_ovn-controller_ process on each chassis, in OVN terminology, meaning every k8s -node since _Genestack_ uses _Kube-OVN_, runs the same control logic, and -coordination happens through the OVN south database, but this introduces some of -the complexity of a distributed system to what often acts and appears like -centralized control. - -OVN makes use of some ports not bound to any particular chassis, especially on -the gateway nodes. OVN may move those ports to a different chassis if a gateway -node goes down, or BFD (bi-directional forwarding detection) shows poor link -quality for a chassis. In some edge cases, _ovn-controller_ on different nodes -might each determine that they should have a port, and each chassis will claim -the port as quickly as it can. That doesn't normally or usually happen, and -could have some range of edge case root causes, perhaps a NIC malfunctioning in -a way that escapes detection by BFD (bi-directional forwarding detection). The -architecture of OVN seems to make it hard to ensure that this condition could -*never* occur, even if it rarely occurs, and OVN itself implements a rate-limit -of 0.5s, so that no chassis will try to claim the same port more than once every -0.5s, as seen in -[this commit](https://github.com/ovn-org/ovn/commit/4dc4bc7fdb848bcc626becbd2c80ffef8a39ff9a). - -However, a typical production-grade _Genestack_ installation will probably have -at least 3 gateway nodes, and each public IP CIDR block added individually to -the installation will have an associated `cr-lrp` on the gateway nodes, not -bound to any particular chassis and so free to move between the gateway nodes. -These ports allow OpenStack nova instances without a floating IP to access the -Internet via NAT, which allows them to, say, pull operating system patches, etc. -without needing to assign a floating IP so that an instance only needs a -floating IP to make services available on a public Internet address. So, -consider 3 gateway nodes and 5 CIDR blocks, and a 0.5 s rate limit per port per -node. In the worst case, with each node trying to claim every port not bound to -a chassis as quickly as possible, this example could have each port getting -claimed about six times per second, and a load of 30 claims per second to commit -to the to the OVN south DB. (In fact, it only seems to take one bad node to -shoot this up to around the theoretical maximum, since the bad node might claim -it as often as possible, and every other node has equal claim.) In this -scenario, the affected ports themselves move between chassis too quickly to -actually work, and the OVN south DB itself gets overloaded. In that case, -instances without floating IPs would not have Internet access, and the high load -on the south DB would likely result in provisioning failures for new OpenStack -nova instances and new k8s pods. - -# Symptoms and identification - -The alert will normally catch this condition, however, for reference and to -identify the individual nodes with the problem: - -## network agents `Alive` status - -`openstack network agent list` usually has output like below (aside from the -made up UUIDs and node names): - -``` -+--------------------------------------+------------------------------+------------------------+-------------------+-------+-------+----------------------------+ -| ID | Agent Type | Host | Availability Zone | Alive | State | Binary | -+--------------------------------------+------------------------------+------------------------+-------------------+-------+-------+----------------------------+ -| deadbeef-dead-beef-dead-deadbeef0001 | OVN Controller agent | node01.domain.name | | :-) | UP | ovn-controller | -| deadbeef-dead-beef-dead-deadbeef0002 | OVN Controller agent | node02.domain.name | nova | :-) | UP | ovn-controller | -| deadbeef-dead-beef-dead-deadbeef0003 | OVN Metadata agent | node02.domain.name | nova | :-) | UP | neutron-ovn-metadata-agent | -| deadbeef-dead-beef-dead-deadbeef0004 | OVN Controller agent | node03.domain.name | nova | :-) | UP | ovn-controller | -| deadbeef-dead-beef-dead-deadbeef0005 | OVN Metadata agent | node03.domain.name | nova | :-) | UP | neutron-ovn-metadata-agent | -| deadbeef-dead-beef-dead-deadbeef0006 | OVN Controller agent | node04.domain.name | | :-) | UP | ovn-controller | -| deadbeef-dead-beef-dead-deadbeef0007 | OVN Controller agent | node05.domain.name | nova | :-) | UP | ovn-controller | -| deadbeef-dead-beef-dead-deadbeef0008 | OVN Metadata agent | node05.domain.name | nova | :-) | UP | neutron-ovn-metadata-agent | -| deadbeef-dead-beef-dead-deadbeef0009 | OVN Controller agent | node06.domain.name | nova | :-) | UP | ovn-controller | -``` - -For minor technical reasons, these probably don't technically qualify as real -Neutron agents, but in either case, this information gets queried from the -OVN south DB, which gets overloaded, so the output of this command will likely -show `XXX` [sic] under the alive column, although they do continue to show -state `UP`. - -Since this happens because of the south DB, this command doesn't help identify -affected nodes. All agents will likely show `XXX` for `Alive`. - -## log lines - -The alert checks log lines, but you will have to identify which gate nodes -have the issue. - -The log lines happen on the `ovs-ovn` pods of the gateway nodes, and in full, -look like this: - -``` -2024-09-05T16:38:54.711Z|19953|binding|INFO|Claiming lport cr-lrp-deadbeef-dead-beef-dead-deadbeef0001 for this chassis. -2024-09-05T16:38:54.711Z|19954|binding|INFO|cr-lrp-deadbeef-dead-beef-dead-deadbeef0001: Claiming de:ad:be:ef:de:01 1.0.1.0/24 -2024-09-05T16:39:38.870Z|19955|binding|INFO|Claiming lport cr-lrp-ddeadbeef-dead-beef-dead-deadbeef0002 for this chassis. -2024-09-05T16:39:38.870Z|19956|binding|INFO|cr-lrp-deadbeef-dead-beef-dead-deadbeef0002: Claiming de:ad:be:ef:de:02 1.0.2.0/24 -2024-09-05T16:40:32.813Z|19957|binding|INFO|Claiming lport cr-lrp-deadbeef-dead-beef-dead-deadbeef0003 for this chassis. -2024-09-05T16:40:32.813Z|19958|binding|INFO|cr-lrp-deadbeef-dead-beef-dead-deadbeef0003: Claiming de:ad:be:ef:de:03 1.0.3.0/24 -2024-09-05T16:41:52.669Z|19959|binding|INFO|Claiming lport cr-lrp-deadbeef-dead-beef-dead-deadbeef0004 for this chassis. -2024-09-05T16:41:52.669Z|19960|binding|INFO|cr-lrp-deadbeef-dead-beef-dead-deadbeef0004: Claiming de:ad:be:ef:de:04 1.0.4.0/24 -2024-09-05T16:42:33.762Z|19961|binding|INFO|Claiming lport cr-lrp-deadbeef-dead-beef-dead-deadbeef0004 for this chassis. -``` - -you will probably see these densely packed and continuously generating with no -other log lines between them with an interval of less than 1 second between -consecutive port bindings. - -Log lines like this happen during normal operation, but the ports don't tend -to move around more than once every 5 minutes, so you may see a block like this -for every `cr-lrp` port, and so one for every CIDR block of public IPs you use, -but during a claim storm, you will see the same ports and CIDRs getting bound -continuously and consecutively. - -## Remediation - -This likely happens as an aggravation of a pre-existing problem, so it may take -some investigation to identify any particular root cause, and draining and -rebooting an affected node may resolve the issue temporarily, or seemingly -permanently enough if the issue occurred due to something transient and -unidentifiable. - -Some tips and recommendations: - -- ensure you ran `host-setup.yaml` as indicated in the _Genestack_ installation - documentation which adjusts some kernel networking variables. - - This playbook works idempotently, and you can run it again on the nodes - to make sure, and mostly see `OK` tasks instead of `changed`. - - As an example, if you used `infra-deploy.yaml`, on your launcher node, - you might run something like: - - ``` - sudo su -l - - cd /opt/genestack/ansible && \ - source ../scripts/genestack.rc && \ - ansible-playbook playbooks/host-setup.yml \ - -i /etc/genestack/inventory/openstack-flex-inventory.ini \ - --limit openstack-flex-node-1.cluster.local - ``` - - adjusted for your installation and however you needed to run the playbook. - (Root on the launcher node created by `infra-deploy.yaml` normally has - a venv, etc. for Ansible when you do a root login as happens with - `sudo su -l`.) - -- Ensure you have up-to-date kernels. - - In particular, a bug in Linux 5.15-113 and 5.15-119 resolved in Linux 6.8 - resulted in a problem electing OVN north and south database (NB and SB) - leaders, although that probably shouldn't directly trigger this issue. -- Ensure you have the best and most up-to-date drivers for your NICs. -- Check BFD - - As mentioned, OVN uses BFD to help determine when it needs to move ports. - - You might run: - - ``` - kubectl ko vsctl show - ``` - - which shows BFD status on ports in-line to the OVSDB-centric overview - of OVS for the node, and/or: - - ``` - kubectl ko appctl bfd/show - ``` - - to check directly and only BFD. - - (assuming you have installed the `Kube-OVN` kubectl plugin as described - in _docs/ovn-troubleshooting.md_'s _Kube-OVN kubectl plugin_ section) and - investigate any potential BFD issues. - -- Check the health and configuration of NIC(s), bonds, etc. at the operating - system level -- Check switch and switch port configuration. -- If you have a separate interface allowing you to reach a gateway node via SSH, - you can down the interface(s) with the Geneve tunnels on individual gateway - nodes one at a time and observe whether downing the interfaces of any - particular node(s) stops the claim storm. - - OVN will take care of moving the ports to another gateway node if you - have multiple gateway nodes. When possible to do this without losing your - connection (you could perhaps even use the server OOB console), you - effectively temporarily take one gateway node out of rotation.) -- Drain and reboot any suspect (or all, one at time, if necessary) - gateway node(s): - - ``` - kubectl drain --ignore-daemonsets --delete-local-data --force - # reboot the node - kubectl uncordon # after return from reboot - ``` - -- Since the issue has strong chance of having occurred as an aggravation of an - existing, possibly even otherwise relatively benign problem, you should - perform other general and generic troubleshooting such as reading system - logs, `dmesg` output, hardware errors reported by DRAC, iLO, or other OOB - management solutions, etc. diff --git a/docs/ovn-intro.md b/docs/ovn-intro.md deleted file mode 100644 index 31c0db083..000000000 --- a/docs/ovn-intro.md +++ /dev/null @@ -1,368 +0,0 @@ -# The purpose of this introduction - -This introduction attempts to explain the basic operation of OVN and OVS, -particularly in the context of _Genestack_. However, you should refer to the -canonical upstream documentation for individual projects as necessary. - -# Assumed background information - -In sticking to introducing OVN in _Genestack_, the following got written with -some assumed knowledge: - -- Some software-defined networking (SDN) concepts -- Some OpenStack concepts -- Some database management system (DBMS) concepts - -In most cases, you will probably have to decide whether you want or need to do -further out-of-band reading based on the context in which these come up. In -some cases, a cursory explanation gets provided in passing. - -# Basic background information and terminology - -- You can find information on the general OVN architecture in - `ovn-architecture(7)`, which you can find in PDF, HTML, or plain text - [here](https://docs.ovn.org/en/latest/ref/index.html) -- While it probably contains some outdated information, you may wish to watch - [Introduction to OVN - OVS Conference 2015](https://www.youtube.com/watch?v=v1xkJjnuzhk) - - three OVN contributors created this presentation - - the basic architecture hasn't changed -- _Genestack_ installs OVN with _Kube-OVN_. - - this includes OVS, described later. -- To complete the architecture reading, you should read the - [Kube-OVN architecture](https://kubeovn.github.io/docs/stable/en/reference/architecture/) - documentation. -- Reading and understanding the two canonical architecture documentation - references above will give you more information than shown here, but this - attempts to provide a high-level overview, and covers in particular how we - use the single OVN installation from _Kube-OVN_ for both OpenStack and - Kubernetes. -- A _software-defined networking controller_ provides centralized management - for software defined networks, particularly in defining rules for how to move - network packets. -- OVN functions as a software-defined networking controller. -- OVN has good documentation: - [Open Virtual Network (OVN) Documentation](https://docs.ovn.org/en/latest/) - - The [OVN reference guide](https://docs.ovn.org/en/latest/ref/index.html) - typically gets installed as the UNIX manual pages - - although you will not find the manual pages in the _Genestack_ pods. -- OVN calls its northbound clients _Cloud Management Systems_, often - abbreviated as **CMS**. -- OVN in _Genestack_ has two CMSes: - - the _Kubernetes_ cluster - - _OpenStack Neutron_ -- [_Open vSwitch_](https://www.openvswitch.org/) provides software-defined switches. - - This usually gets abbreviated as **OVS**. - - It provides L2 switches in software. - - In _Genestack_, OVN takes care of the OVS switch programming. - - See more detailed treatment of OVS below. -- OVN works with OVS to: - - program OVS switches - - provide a higher layer of abstraction than OVS. - - In particular, OVN provides _logical entities_ -- OVN ultimately has OVS at the far south end of its data flow - - and exists to provide a logical higher layer of abstraction than OVS - -## Basic OVN operation and architecture - -- This section covers basic OVN operation abstracted from the CMS. -- We install OVN as for Kubernetes with _Kube-OVN_ - - so a section will follow on the details of installation by/for Kubernetes. -- Remember, _Genestack_ uses OVN with two CMSes: - - OpenStack - - Kubernetes - - so a section will follow with details for each respective CMS. OVN design - allows for use of more than one CMS with for an OVN installation. - -- So, this section contains an abstract description of OVS operation, followed - by installation details and per-CMS details in following sections. - -### the OVN plugin - -- Every CMS has an **OVN plugin**. - - In _Genestack_, OpenStack and Kubernetes, as the two CMSes, **both** use - their OVN plugins on the single OVN installation. -- Some details on how this works will follow in sections and subsections below. -- _OpenStack Neutron_ has - [_networking-ovn_](https://docs.openstack.org/networking-ovn/latest/) for the - OVN plugin. - - This gets developed in Neutron as a first-party ML2 plugin for using OVN - - So _Genestack_ implicitly uses this. -- The plugin allows the CMS to control OVN for its needs. - - e.g., creating a network in Neutron will result in _networking-ovn_, - the OpenStack OVN plugin, writing a logical switch into the NB DB. - - One of the main functions of the OVN plugin is to translate network - components from the CMS into _logical entities_ based on standard - networking concepts such as switches and routers into the OVN north - database - -### Central OVN components - -- OVN has three central components below the CMS/OVN plugin architecturally: - - the _ovn-northd_ daemon - - The north database, often referred to as **NB** or NB DB. - - The south database, often referred to as **SB** or SB DB. - - As a group, these often informally get referred to collectively as **OVN - central**. -- OVN doesn't generally vary in implementation below the CMS/OVN plugin - - The CMS/OVN plugin must get implemented separately for each CMS. - - However, _Kube-OVN_, in use in _Genestack_, actually has made some minor - modifications as described - [here](https://kubeovn.github.io/docs/stable/en/reference/ovs-ovn-customized/) - - so you might need to know about that relative to stock OVN. - -#### OVN databases and _ovn-northd_ - -- As mentioned, OVN has the NB and SB. - - both are centrally located in the OVN architecture - - It has no other databases (unless you count the OVS databases at the far - south end of the data flow) - -##### OVSDB DBMS - -- OVSDB started as the DBMS for OVS, which also uses it. -- The OVS developers (who also developed OVN) originally designed OVSDB for OVS. -- NB and SB run **OVSDB** as the DBMS. - - OVS does as well. -- As an aside, in various sources, the term "OVSDB" sometimes gets used in a - way that makes it look like an application layer network protocol, a - database, or a DBMS. - - When used like a protocol, it refers to accessing the OVSDB by the OVSDB - procotol - - etc. (e.g., used as a database, refers to an OVSDB DBMS database). -- OVSDB works transactionally, like InnoDB for MySQL or MariaDB. - - So you can expect [ACID](https://en.wikipedia.org/wiki/ACID) semantics - or behavior - - However, it lacks many features of larger general-purpose DBMSes - - e.g., sharding -- OVSDB uses the Raft algorithm for high availability (HA). - -###### Raft algorithm - -- In **Raft** HA algorithms, a cluster elects a leader. -- All writes go only to the leader. -- If you lose a leader, a new leader gets elected. -- It takes a majority of nodes connected together to elect a new leader. -- The cluster remains fully functional as long as you have a majority of nodes - connected together. - - This allows the cluster to maintain consistency. - - A connected minority of nodes will not elect a leader and will not take - writes - - so a reunited cluster can consistently reconcile the data from - all nodes because anything written to a majority of nodes should - get written to all nodes -- The cluster functions in read-only mode when you don't have a leader. - -##### _ovn-northd_ - -- _ovn-northd_ translates logical entities from the NB DB into logical flows, - and writes the logical flows into the SB DB -- So, _ovn-northd_ talks with the NB and SB DBs. -- _ovn-northd_ doesn't talk with anything south of the SB DB, but the logical - flows it writes there influence the southbound _ovn-controller_ component - -##### OVN NB - -- The CMS or CMSes (e.g., _OpenStack_ and _Kubernetes_) drives OVN with its OVN - plugin -- The OVN plugins write OVN logical entities directly into the NB DB -- The NB contains OVN's logical entities - - written there by the OVN plugin, based on actions taken by the CMS - - e.g., logical switches, logical routers, etc. - - It generally doesn't contain much of anything else. -- OVN plugins perform CRUD-type (create, read, update, delete) operations on - the NB DB directly. -- _ovn-northd_ automatically acts on the state of the database, so the OVN - plugin doing CRUD operations plays a major and direct role in driving OVN's - operation. - - So the OVN plugin doesn't do anything like API calls or use a message - queue. It modifies the NB DB, and OVN continually treats the NB DB as - canonical. _ovn-northd_ will start propagating updates applied by the OVN - plugin or by anything else to the NB DB southward (SB DB) automatically - and immediately. - -##### OVN SB - -- The OVN SB contains OVN logical flows based on the logical entities in the NB - DB. -- The SB DB gets read by the _ovn-controller_ component described below. -- The SB DB holds information on the physical infrastructure - - e.g., the existence of compute nodes and k8s nodes - -### Distributed OVN components - -#### OVS - -- While included here as an architectural component of OVN, you can use OVS - without OVN. -- A _network flow_ refers to a sequence of packets from a source to a - destination that share some characteristics, like protocol, such as TCP or - UDP, destination address, port number, and other such things. -- OVS resembles Linux-bridge in providing L2 switches in software - - but OVS switches have greater programmability with the OpenFlow protocol. - - - OVS switches get programmed with [_OpenFlow_](https://en.wikipedia.org/wiki/OpenFlow), which define the network flows. -- OVS runs on all forwarding-plane nodes - - "Forwarding plane" from SDN terminology also sometimes gets called the - data-plane - - e.g., all Kubernetes nodes in _Genestack_ and Kubernetes clusters using - _Kube-OVN_. -- OVN manages the OVS switches. -- (Incidentally, OVS came first, and the OVS developers also wrote OVN as the - logical continuation of OVS) - -#### _ovn-controller_ - -- The [_ovn-controller(8)_](https://www.ovn.org/support/dist-docs/ovn-controller.8.html) component runs on anywhere OVS runs in any - or all types of OVN installations. -- The _ovn-controller_ reads logical flows from the SB DB and implements with - OpenFlow flows on OVS. -- _ovn-controller_ also reports hardware information to the SB DB. - -## OVN installation via _Kube-OVN_ in _Genestack_ - -- _Genestack_ installs OVN via _Kube-OVN_ "for" the Kubernetes cluster. -- _Genestack_ does not install OVN separately for _OpenStack_. -- You should see the [_Kube-OVN architecture page_](https://kubeovn.github.io/docs/stable/en/reference/architecture/) - for more detailed explanation - -### `ovn-central` in _Kube-OVN_ and _Genestack_ - -- In _Kube-OVN_ and _Genestack_, - [OVN central](https://kubeovn.github.io/docs/stable/en/reference/architecture/#ovn-central): - - as described in the documentation, "runs the control plane components of OVN, including ovn-nb, ovn-sb, and ovn-northd." - - runs in the `kube-system` namespace - - runs on three pods: - - with a name starting with `ovn-central`, and - - labelled `app=ovn-central` - - each pod runs one copy of each of the three OVN central components: - - NB - - DB - - _ovn-northd_ - - so the informal name "OVN central" for these centralized components - matches what you find running on the pods. - - these pods get labelled with what each pod serves as the master for: - - so you find one each of the following labels across the three pods: - - `ovn-nb-leader=true` - - `ovn-northd-leader=true` - - `ovn-sb-leader=true` - - although one pod might have more than one of the labels. - - - these labels indicate which pod has the leader for the service - in question. - - With the raft HA algorithm described previously, OVN should continue - working normally when losing one of these pods. - - Losing two of these pods, with one still running, should result in OVN - working in read-only mode. - -### `kube-ovn-controller` - -- [`kube-ovn-controller` pods](https://kubeovn.github.io/docs/stable/en/reference/architecture/#kube-ovn-controller) - - the linked documentation describes, in part (see the documentation link for - further details): - - > This component performs the translation of all resources within Kubernetes - > to OVN resources and acts as the control plane for the entire Kube-OVN - > system. The kube-ovn-controller listens for events on all resources - > related to network functionality and updates the logical network within - > the OVN based on resource changes. - -### `kube-ovn-monitor` - -- [`kube-ovn-monitor`](https://kubeovn.github.io/docs/stable/en/reference/architecture/#kube-ovn-monitor) - - the linked documentation describes it: - - > This component collects OVN status information and the monitoring metrics - -### per-node components - -- Each _Kubernetes_ node has pods for OVN as well. - -#### Components on all nodes - -A number of components run on all nodes as a _DaemonSet_. - -##### `ovs-ovn` pods - -- [`ovs-ovn` pods](https://kubeovn.github.io/docs/stable/en/reference/architecture/#ovs-ovn) - - the linked documentation describes it: - - > ovs-ovn runs as a DaemonSet on each node, with openvswitch, ovsdb, and - > ovn-controller running inside the Pod. These components act as agents for - > ovn-central to translate logical flow tables into real network - > configurations - -##### `kube-ovn-cni` pods - -- [`kube-ovn-cni`](https://kubeovn.github.io/docs/stable/en/reference/architecture/#kube-ovn-cni) pods: - - the linked documentation describes it, in part (see the documentation link - for further details): - - > This component runs on each node as a DaemonSet, implements the CNI - > interface, and operates the local OVS to configure the local network. - > - > This DaemonSet copies the kube-ovn binary to each machine as a tool for - > interaction between kubelet and kube-ovn-cni. This binary sends the - > corresponding CNI request to kube-ovn-cni for further operation. The - > binary will be copied to the /opt/cni/bin directory by default. - > - > kube-ovn-cni will configure the specific network to perform the - > appropriate traffic operations - - - see the documentation in full for more details - -##### `kube-ovn-pinger` pods - -- [`kube-ovn-pinger` pods](https://kubeovn.github.io/docs/stable/en/reference/architecture/#kube-ovn-pinger) - - the linked documentation describes it: - - > This component is a DaemonSet running on each node to collect OVS status - > information, node network quality, network latency, etc. The monitoring - > metrics collected can be found in Metrics. - -##### `kube-ovn-speaker` - -- Included only for completeness. _Genestack_ does not use these by default. - -#### `ovn-metadata-agent` on compute-nodes only - -- `ovn-metadata-agent` pods: - - run only on compute nodes - - uniquely amongst all pods mentioned, _Genestack_ installs these from the - _OpenStack Helm_ chart, and they don't come from _Kube-OVN_ - - These provide the metadata service associated with _Openstack Neutron_ - for instances. - -### OVN and OpenStack - -- _networking-ovn_ serves as the OVN plugin for _OpenStack Neutron_. -- As mentioned above, _OpenStack Neutron_ has - [_networking-ovn_](https://docs.openstack.org/networking-ovn/latest/) for the - OVN plugin. - - This gets developed in Neutron as a first-party ML2 plugin for using OVN -- To drive an OVN installation via _networking-ovn_, Neutron only requires: - - NB DB connection information - - SB DB connection information -- _Genestack_ supplies _Neutron_ with the NB and SB DB connection information - - So you see and find OVN components installed for Kubernetes via - _Kube-OVN_ as described above instead of what you would find - for a conventional OVN installation installed for and servicing OpenStack - as its sole CMS. -- Neutron has the ability to automatically repair the OVN database to match - Neutron - - the setting `neutron_sync_mode` in `neutron.conf` or override - `conf.neutron.ovn.neutron_sync_mode` in _Genestack_ or _OpenStack Helm_ - overrides control whether Neutron does this. - - **_Genestack_ turns `neutron_sync_mode` off because it doesn't work when - you use a second CMS on the same OVN installation** - - presumably because _Neutron_ can't assume everything in the NB should - belong to it to modify; in particular, entries that appear extraneous - from the perspective of Neutron may belong to another CMS - - In particular, a fresh _Genestack_ installation already shows 6 - unknown ACLs when Neutron runs this check diff --git a/docs/ovn-kube-ovn-openstack.md b/docs/ovn-kube-ovn-openstack.md deleted file mode 100644 index 1bb6554b5..000000000 --- a/docs/ovn-kube-ovn-openstack.md +++ /dev/null @@ -1,35 +0,0 @@ -# OVN Post Deployment Updates - -Updates to the OVN environment can be made post deployment. All of the required OVN annotations are applied to the nodes in the cluster and can be changed at any time. However, in order to apply the changes, the label `ovn.openstack.org/configured` must be removed to permit the **ovn-setup** daemonset to reapply the configuration. - -!!! tip - - Review the the OVN Deployment Guide for more information on how to manage your OVN environment post deployment. The guide can be found [here](infrastructure-ovn-setup.md). - -## Label Overview - -|
key
| type |
value
| notes | -|:-----|--|:----------------:|:------| -| **ovn.openstack.org/configured** | int | `EPOC` | The EPOC time when the confirguration was last applied | - -### `ovn.openstack.org/configured` - -When the **ovn-setup** Daemonset runs, the `ovn.openstack.org/configured` label is applied to the nodes in the cluster. This label is used to determine if the configuration has been applied to the node. If the label is present, the **ovn-setup** Daemonset will not reapply the configuration to the node. If the label is removed, the **ovn-setup** Daemonset will reapply the configuration to the node. - -## Removing the `ovn.openstack.org/configured` label - -To remove the `ovn.openstack.org/configured` label from all nodes. - -``` shell -kubectl label nodes ${NODE_NAME} ovn.openstack.org/configured- -``` - -!!! note "Global Configuration Updates" - - The `ovn-setup` daemonset will reapply the configuration to the nodes in the cluster. If you need to reapply changes to all nodes within the cluster, you can remove the label from all nodes at the same time with the following command: - - ``` shell - kubectl label nodes --all ovn.openstack.org/configured- - ``` - -Once the label is removed, the **ovn-setup** Daemonset will immediately reapply the configuration to the nodes in the cluster automatically. diff --git a/docs/ovn-monitoring-introduction.md b/docs/ovn-monitoring-introduction.md deleted file mode 100644 index 59c717de9..000000000 --- a/docs/ovn-monitoring-introduction.md +++ /dev/null @@ -1,197 +0,0 @@ -# Background - -- This page describes OVN monitoring in _Genestack_. -- Most OVN monitoring in _Genestack_ comes from _Kube-OVN_'s model - - As the _Kube-OVN_ documentation indicates, this includes both: - - control plane information - - data plane network quality information - - _Kube-OVN_ has - [instrumention](https://prometheus.io/docs/practices/instrumentation/) - for _Promethus_ - - so _Genestack_ documentation directs installing the k8s _ServiceMonitors_ - so that _Promethus_ can discover these metrics. - -## Links - -- [_Genestack_ documentation on installing _Kube-OVN_ monitoring](./prometheus-kube-ovn.md) - - As mentioned above, this simply installs the _ServiceMonitors_ so that - _Prometheus_ in _Genestack_ can discover the metrics exported by _Kube-OVN_. - - you can see the _ServiceMonitors_ installed - [here](https://github.com/rackerlabs/genestack/tree/main/base-kustomize/prometheus-ovn) - - in particular, it has _ServiceMonitors_ for components: - - _kube-ovn-cni_ - - _kube-ovn-controller_ - - _kube-ovn-monitor_ - - _kube-ovn-pinger_ - - You can see a architectural descriptions of these components - [here](https://kubeovn.github.io/docs/stable/en/reference/architecture/#core-controller-and-agent) - -- [_Kube-OVN User Guide's "Monitor and Dashboard"_ section](https://kubeovn.github.io/docs/stable/en/guide/prometheus-grafana/) - - the information runs a bit sparse in the User Guide; note the reference - manual link (in the User Guide itself, and next link here below) for more - detailed information on the provided metrics. -- [_Kube-OVN Reference Manual "Metrics"_](https://kubeovn.github.io/docs/stable/en/reference/metrics/) - - This describes the monitoring metrics provided by _Kube-OVN_ - -# Metrics - -## Viewing the metrics - -In a full _Genestack_ installation, you can view Prometheus metrics: - -- by using _Prometheus_' UI -- by querying _Prometheus_' HTTPS API -- by using _Grafana_ - - In particular, _Kube-OVN_ provides pre-defined Grafana dashboards - installed in _Genestack_. - -Going in-depth on these would go beyond the scope of this document, but sections -below provide some brief coverage. - -### Prometheus' data model - -_Prometheus_' data model and design-for-scale tends to make interactive -[_PromQL_](https://prometheus.io/docs/prometheus/latest/querying/basics/) -queries cumbersome. In general usage, you will find that _Prometheus_ data works -better for feeding into other tools, like the _Alertmanager_ for alerting, and -_Grafana_ for visualization. - -### Prometheus UI - -A full _Genestack_ installation includes the _Prometheus UI_. The _Prometheus_ -UI prominently displays a search bar that takes _PromQL_ expressions. - -You can easily see the available _Kube-OVN_ metrics by opening the Metrics -Explorer (click the globe icon) and typing `kube_ovn_`. - -While this has some limited utility for getting a low-level view of individual -metrics, you will generally find it more useful to look at the Grafana -dashboards as described below. - -As mentioned above, the _Kube-OVN_ documentation details the collected metrics -[here](https://kubeovn.github.io/docs/stable/en/reference/metrics) - -### Prometheus API - -You will probably need a strong understanding of the Prometheus data model and -_PromQL_ to use the _Prometheus_ API directly, and will likely find little use -for using the API interactively. - -However, where you have a working `kubectl`, you can do something like the -following to use `curl` on the Prometheus API with minor adaptations for your -installation: - -``` -# Run kubectl proxy in the background -kubectl proxy & - -# You will probably find the -g/--globoff option to curl useful to stop curl -# itself from interpreting the characters {} [] in URLs. -# -# Additionally, these characters technically require escaping in URLs, so you -# might want to use --data-urlencode - -curl -sS -gG \ -http://localhost:8001/api/v1/namespaces/prometheus/services/prometheus-operated:9090/proxy/api/v1/query \ ---data-urlencode 'query=kube_ovn_ovn_status' | jq . -``` - -### Grafana - -As mentioned previously, _Kube-OVN_ provides various dashboards with -information on both the control plane and the data plane network quality. - -These dashboards contain a lot of information, so in many cases, you will likely -use them for troubleshooting by expanding to a large timeframe to see when -irregularities may have started occurring. - -You can see the documentation from _Kube-OVN_ on these dashboards -[here](https://kubeovn.github.io/docs/stable/en/guide/prometheus-grafana/) - -Some additional details on each of these dashboards follows. - -#### Controller dashboard - -In a typical _Genestack_ installation, you should see 3 controllers up here. -The dashboard displays the number of up controllers prominently. - -The graphs show information about the `kube-ovn-controller` pods in the -`kube-system` namespace, mostly identified by their ClusterIP on the k8s -service network. You can typically see them along with the ClusterIPs that -identify them individually on the dashboard like: - -``` -kubectl -n kube-system get pod -l app=kube-ovn-controller -o wide -``` - -#### Kube-OVN-CNI dashboard - -In this case, CNI refers to k8s' _container network interface_ which allows -k8s to use various plugins (such as _Kube-OVN_) for cluster networking, as -described [here](https://kubeovn.github.io/docs/stable/en/reference/architecture/#kube-ovn-cni) - -Like the Controller dashboard, it displays the number of pods up prominently. -It should have 1 pod for each k8s node, so it should match the count of your -k8s nodes: - -``` -# tail to skip header lines -kubectl get node | tail -n +2 | wc -l -``` - -These metrics belong to the 'control plane' metrics, and this dashboard will -probably work well by using a large timeframe to find anomalous behavior as -previously described. - -#### OVN dashboard - -This dashboard displays some metrics from the OVN, like the number of logical -switches and logical ports. It shows a chassis count that should match the -number of nodes in your cluster, and a flag (or technically a count, but you -will see "1") for "OVN DB Up". - -This dashboard looks useful as previously described for looking for anomalous -behavior that emerged across a timeframe. - -#### OVS dashboard - -This dashboard displays information from OVS from each k8s node. - -It sometimes uses names, but sometimes pod IPs. - -OVS activity across nodes might not necessarily have a strong correlation, so -on this dashboard, you might take particular note that you can click the node -of interest on the legend for each graph, or choose a particular instance for -all of the graphs at the top. - -You may need to collate the ClusterIPs with a node, which you can do with -something like: - -``` -kubectl get node -n kube-system -o wide | grep 10.10.10.10 -``` - -which will display the name of the node with the pinger pod. -[kube-ovn-pinger](https://kubeovn.github.io/docs/stable/en/reference/architecture/#kube-ovn-pinger) -collects OVS status information, so while you see the `pinger` pod when checking -the IP, the information from the dashboard may *come from* the pinger pod, but -*pertains to* OVS, *not* the pinger pod. - -#### Pinger dashboard - -This dashboard prominently displays the OVS up count, OVN-Controller up count, -and API server accessible count. These should all have the same number, equal to -your number of nodes. - -##### Inconsistent port binding nums - -The _Kube-OVN_ documentation for this metric says "The number of mismatch port -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_ 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. diff --git a/docs/ovn-traffic-flow-intro.md b/docs/ovn-traffic-flow-intro.md deleted file mode 100644 index e8a682cbd..000000000 --- a/docs/ovn-traffic-flow-intro.md +++ /dev/null @@ -1,92 +0,0 @@ -# Purpose - -This document introduces traffic flow in _Genestack_ using OVN with DVR - (distributed virtual routing). _Genestack_ has DVR on by default. - -The analysis here assumes you have the public Internet configured as a Neutron -provider network directly routable from each compute node. This configuration -helps route network traffic efficiently because it doesn't mostly need to send -all Internet traffic through some centralized point, like a logical router that -exists only on one gateway node. - -# Distributed Virtual Routing (DVR) - -- OVN supports DVR. - - This works similarly to DVR-type functionality for other Neutron ML2 - plugins, like ML2/OVS. -- _Genestack_ uses DVR by default. -- DVR works by distributing the functionality to implement OVN components like - switches and routers (which get used to implement Neutron networks, etc.) - - So you may have a logical router in OVN and find each compute nodes - implements OVS flows so that the software-defined network infrastructure - behaves as if the router exists - - It places flows so that one compute node using the router could - send traffic to another compute node using the router without using - something like a gateway node. - - Each compute node has the appropriate flows to send traffic that - logically goes through the router straight from compute-to-compute - - So the router itself doesn't exist in one single place (e.g., a - gateway node, so the traffic doesn't get centralized and - re-routed.) - -# Creating a server on a private network and talking to another server on that network - -- If you start by creating a network and a subnet, and then don't add an - external gateway to the network, and put two instances on the network, you - can see the traffic between the two instances go straight between the - computes in the _Geneve_ tunnel between the computes. -- This doesn't involve running traffic through a gateway node. - -# Routing of public Internet traffic - -## Attaching a provider network with internet access straight to an instance - -- You can create an instance directly attached to a Neutron provider network - with Internet access, referred to here as "publicnet" for short. -- In this case, the instance directly has the publicnet IP. - - Creating an instance directly attached to the publicnet at creation time - bypasses the step of manually or separately creating a floating IP, as - you see PUBLICNET= (or the network name) on the instance - immediately after it gets created. - - however, you don't have the ability to move the IP around as you - would with a floating IP. -- When the instance sends publicnet traffic: - - it doesn't route any traffic through a gateway node. - - the traffic leaves the compute node's NICs un-encapsulated - - traffic going to the instance's publicnet IP come to the compute node's - NICs unencapulated -- This doesn't involve NAT like a floating IP. - -## Creating a server on a private network attached to a router with a publicnet gateway without a floating IP - -- Instances on a private network attached to a router with a gateway can reach - the Internet that way. - - While they don't have a public IP for incoming connections, you can still - use this to send traffic bound for the Internet. - - This could help with running updates (like `apt update`) for a lot - lot of servers that don't really need a public IP for accepting - connections. -- In this case, public traffic logically goes through the router, but - - The traffic does get relayed through the gateway nodes - - You can see it leaving the bond or public interfaces on the gateway - node. - -## Adding a floating IP to a server on a private network - -- You must have the instance attached to a switch or network attached to a - router with an external publicnet gateway to add a floating IP to the - instance. - - which you can contrast with specifying publicnet as a network attached to - the server at creation time - - which means you also need to add the private subnet to the router -- This effectively sets up 1:1 NAT between the floating IP and the private IP - on the instance so that you can directly receive external traffic on the - instance, although you haven't attached a port on publicnet itself to the - instance. - - The 1:1 NAT doesn't bypass anything like security group rules. -- In this case, you can see traffic with the public IP directly on the compute - node's NICs - - so OVS for the compute does the NAT - - You can also see the traffic without the NAT when dumping the tap for - the instance itself. -- Using a floating IP like this allows you to move the IP to another instance. diff --git a/docs/ovn-troubleshooting.md b/docs/ovn-troubleshooting.md deleted file mode 100644 index ce9d29b6d..000000000 --- a/docs/ovn-troubleshooting.md +++ /dev/null @@ -1,374 +0,0 @@ -# Purpose - -This page contains various troubleshooting tasks. - -## Find node for an instance - -You might want to check that the node has the required pods running, or do other -troubleshooting tasks. - -This will tell you what node an instance runs on. - -``` shell -openstack server show ${INSTANCE_UUID} -c hypervisor_hostname -``` - -## Kube-OVN kubectl plugin - -- Kube-OVN has a `kubectl` plugin. -- You can see documentation at [the Kube-OVN documentation](https://kubeovn.github.io/docs/v1.12.x/en/) -- You should install it from wherever you would like to use `kubectl` from, as described - [here](https://kubeovn.github.io/docs/v1.12.x/en/ops/kubectl-ko/#plugin-installation) - - However, you will also find it already on installed on _Genestack_ Kubernetes - nodes, so you can use it with `kubectl` there, if desired. -- You can use this to run many OVS commands for a particular node - - if, for instance, you've found a node for a particular instances as - discussed above - -You can get help like: - -``` shell -kubectl ko help -``` - -``` shell -kubectl ko {subcommand} [option...] -Available Subcommands: - [nb|sb] [status|kick|backup|dbstatus|restore] ovn-db operations show cluster status, kick stale server, backup database, get db consistency status or restore ovn nb db when met 'inconsistent data' error - nbctl [ovn-nbctl options ...] invoke ovn-nbctl - sbctl [ovn-sbctl options ...] invoke ovn-sbctl - vsctl {nodeName} [ovs-vsctl options ...] invoke ovs-vsctl on the specified node - ofctl {nodeName} [ovs-ofctl options ...] invoke ovs-ofctl on the specified node - dpctl {nodeName} [ovs-dpctl options ...] invoke ovs-dpctl on the specified node - appctl {nodeName} [ovs-appctl options ...] invoke ovs-appctl on the specified node - tcpdump {namespace/podname} [tcpdump options ...] capture pod traffic - trace ... trace ovn microflow of specific packet - trace {namespace/podname} {target ip address} [target mac address] {icmp|tcp|udp} [target tcp/udp port] trace ICMP/TCP/UDP - trace {namespace/podname} {target ip address} [target mac address] arp {request|reply} trace ARP request/reply - diagnose {all|node} [nodename] diagnose connectivity of all nodes or a specific node - env-check check the environment configuration - tuning {install-fastpath|local-install-fastpath|remove-fastpath|install-stt|local-install-stt|remove-stt} {centos7|centos8}} [kernel-devel-version] deploy kernel optimisation components to the system - reload restart all kube-ovn components -``` - -For instance, - -```shell -kubectl ko vsctl ${K8S_NODE_NAME} show -``` - -works as if had ran `ovs-vsctl show` when logged into the `ovs-ovn` or - `kube-ovn-cni` pod for the specified node. - -Usefully, you can check the status of the NB and SB: - -```shell -kubectl ko nb status -kubectl ko sb status -``` - -and check `dbstatus`: - -```shell -kubectl ko nb dbstatus -``` - -See the full documentation for more details, for _Kube-OVN_, OVN, and OVS, -as applicable. - -## List all pods on a node - -- You may want to list all pods on a node. You may have found an instance above - and now want to check the pods on the host. - - you can use `kubectl ko` to run OVS commands for particular nodes as - described above without identifying the node for a pod manually as - described here. -- This will show all pods running on a given _Kubernetes_ node. -- You can use this to see if a node has all of the pods it should running, - or to see their status, or find them to check their logs. -- As described in the "Introduction and Overview" page, you find several pods - on a node relevant to operation of OVN, OVS, and Neutron, like: - - `kube-ovn-cni` - - `kube-ovn-pinger` - - `ovs-ovn` - - `neutron-ovn-metadata-agent-default` - - this one only runs on compute nodes - - other pods that run on all nodes or all computes not directly to OVN. - - (e.g., `kube-proxy`, and several others.) - -You can use a command like: - -```shell -kubectl get pods --all-namespaces --field-selector spec.nodeName=${NODE} -``` - -where you can use a value found from following steps like those outlined in -"Find node for an instance" to see what node you wanted to list the pods for, -and use that instead of `$node`, if, for instance, you wanted to check on the -node that has a particular instance. - -## Finding OVN and OVS pods - -- In addition to the list of pods on each node for OVS and OVN operation, - _Kube-OVN_ has several centralized pods, which all run in the `kube-system` - namespace, that you should ensure as running normally - when troubleshooting: - - `ovn-central` pods - - `kube-ovn-controller` pods - - `kube-ovn-monitor` pods - - although this only collects metrics, so may not adversely affect - normal operation -- You may want to find the OVS and OVN pods to use commands on or - in them. - - but, as noted above, you can often use `kubectl ko` to execute - relevant commands for a particular node without manually identifying - it as show here, and it seems less confusing to stick with running OVS - and OVN commands that way. - - additionally, note that OVS appears the same from the Kubernetes - node itself, `ovs-ovn` pods, and `kube-ovn-cni` pods, but the - Kubernetes nodes themselves don't have the OVS and OVN commands, - while the pods do. - - (e.g., same process IDs, same UUID identifiers. OVS runs on the - Kubernetes nodes without a pod, but appears visible in - certain pods.) -- Nodes have OVS pods as indicated above in the "List all pods on a node" - section - - only compute nodes have `neutron-ovn-metadata-agent` pods, but you should - find `kube-ovn-cni`, `kube-ovn-pinger`, and `ovs-ovn` on all nodes. -- _Kube-OVN_ has some central pods that don't run per node: - - You can find these all in the `kube-system` namespace - - ovn-central - - these have the NB and SB DB and _ovn-northd_ as described in - the "Introduction and Overview" page. - - kube-ovn-controller - - acts as control plane for _Kube-OVN_ - - kube-ovn-monitor - - collects OVN status information and the monitoring metrics -- You can list pods for a node as shown above in "List all pods on a node". - -You can list OVN-central pods like: - -```shell -kubectl -n kube-system get pod -l app=ovn-central -``` - -## Getting a shell or running commands on the OVS/OVN pods - -- As mentioned, you will probably find it easier to use `kubectl ko` to run - OVS and OVN commands instead of finding pods. - - For some rare cases, you may wish to do something like run `ovsdb-client` - to dump the OVSDB (although or do some other thing not supported directly from - `kubectl ko`. -- You may want to check the status of OVS or OVN pods for a node found by - following steps like "Find node for an instance" and "List all pods on a - node" above, if you have networking trouble with an instance - - to see if it has all necessary pods running, or check logs for a pod -- Within the `ovs-ovn` and `kube-ovn-cni` pods for a node, you can use OVS - commands if needed. - -You can get a shell in the `ovs-ovn` pod like: - -``` shell -kubectl -n kube-system exec -it ovs-ovn-XXXXX -- /bin/bash -``` - -You will probably have 5 lower case letters in place of `XXXXX` because each -node has a copy of this pod. You may also have used an OVN central pod instead -of an `ovs-ovn-XXXXX` pod. - -Additionally, while mostly not shown here, many OVS commands can and do -simply return results, so you might not want or need to spawn an interactive -shell as above. As an example: - -``` shell -kubectl -n kube-system exec -it ovs-ovn-XXXX -- ovs-vsctl list manager -``` - -gives you the output just like you would get if you executed it from an -interactive shell. - -You can find all OVS and OVN commands from bin directories in the pod like this: - -``` shell -dpkg -l | perl -lane '$package=$F[1]; - next unless /ovn/ or /openv/; - chomp(@FILES = `dpkg -L $package`); - for (@FILES) { - next unless /bin/; - -f and print - }' -``` - -These rarely change, so the list produced will look similar to this: - -``` shell -/usr/bin/ovs-appctl -/usr/bin/ovs-docker -/usr/bin/ovs-ofctl -/usr/bin/ovs-parse-backtrace -/usr/bin/ovs-pki -/usr/bin/ovsdb-client -/usr/sbin/ovs-bugtool -/usr/bin/ovs-dpctl -/usr/bin/ovs-dpctl-top -/usr/bin/ovs-pcap -/usr/bin/ovs-tcpdump -/usr/bin/ovs-tcpundump -/usr/bin/ovs-vlan-test -/usr/bin/ovs-vsctl -/usr/bin/ovsdb-tool -/usr/sbin/ovs-vswitchd -/usr/sbin/ovsdb-server -/usr/bin/ovn-ic -/usr/bin/ovn-northd -/usr/bin/ovn-appctl -/usr/bin/ovn-ic-nbctl -/usr/bin/ovn-ic-sbctl -/usr/bin/ovn-nbctl -/usr/bin/ovn-sbctl -/usr/bin/ovn-trace -/usr/bin/ovn_detrace.py -/usr/bin/ovn-controller -``` - -- Different commands work in different pods - - You can expect `ovs-{app,of,vs}ctl` to work in `ovs-ovn` pods, but not - `ovn-*` commands, mostly. Similarly, in `ovn-central` pods, some `ovn-*` - commands will work, but OVS commands probably won't. - -full usage of these goes beyond the scope of this page. However, you can find -more information: - -- You can read the [OVS manual pages online](https://docs.openvswitch.org/en/latest/ref/#man-pages) -- You can read the - [OVN manual pages online](https://docs.ovn.org/en/latest/ref/index.html) - -## Run ovs-vsctl list manager - -For an OVS pod, you can check that it has a manager connection. Nodes -should have an OVS manager connection for normal operation. - -```shell -kubectl ko vsctl ${NODE} list manager -``` - -``` yaml -_uuid : 43c682c2-a6c3-493f-9f6c-079ca55a5aa8 -connection_mode : [] -external_ids : {} -inactivity_probe : [] -is_connected : true -max_backoff : [] -other_config : {} -status : {bound_port="6640", n_connections="2", sec_since_connect="0", sec_since_disconnect="0"} -target : "ptcp:6640:127.0.0.1" -``` - -## Run ovs-vsctl show - -This shows various useful output, such as ports on the bridges, including: - -- `br-int`, which has the tap devices (instance network interfaces) -- `br-ext`, usually for the public Internet - -``` shell -kubectl ko vsctl ${NODE} show -``` - -As an aside, you can just list the bridges without the more verbose output -of `ovs-vsctl show`: - -``` shell -kubectl ko vsctl ${NODE} list-br -``` - -You will probably have a `br-int` for things like instance tap devices, and -`br-ex` for a public Internet connection, but the names could vary depending on -how you installed _Genestack_. - -## Find the tap devices for an instance - -KVM creates tap devices for the instance NICs. You might want to identify the -tap device on the correct bridge from the output of `ovs-vsctl show` described -above. In that case, you need to find the name of the tap device and which -Kubernetes node you can find it on. You can also `tcpdump` the interface from -the Kubernetes node when you find it this way. - -This shows you the instance name as used by KVM, which does not match the nova -UUID, and the Kubernetes node as the hypervisor hostname: - -``` shell -openstack server show ${UUID} -c OS-EXT-SRV-ATTR:instance_name -c hypervisor_hostname -f json -``` - -Thereafter, you can get the tap devices from `virsh` in the -`libvirt-libvirt-default` pod for the Kubernetes node, using the `instance_name` -from the previous command by first getting the domain ID: - -``` shell -kubectl -n openstack exec libvirt-libvirt-default-25vcr -- virsh domid instance-000014a6 -``` - -and then the tap devices for the domain ID: - -``` shell -kubectl -n openstack exec libvirt-libvirt-default-25vcr -- virsh domiflist 1025 -``` - -`virsh domiflist` also provides the MAC address. - -Then, you can see that the integration bridge has ports: - -``` shell -kubectl ko ${NODE} ofctl show br-int | grep -iE 'tap28144317-cd|tap3e6fb108-a4' -``` - -where the tap devices from `grep` com from the `virsh domiflist`. You should -also see the MAC addresses match. If `grep` finds this, you have identified -the network interface(s) for the instance on the integration bridge on the -correct Kubernetes node. - -This information will tell you what to look for regarding the instance in OVS, -and you can see these in the output of `ip a sh` on the compute node itself: - -``` shell -ip a sh -``` - -and you can use `tcpdump` on it there, e.g., `tcpdump -i tap28144317-cd`. - -## Use the the MySQL command line client for the DB - -Neutron has a pretty comprehensive API, but you might want or need to see the -database sometimes. In very bad cases, you may need to adjust the schema. - -You need to use a node with access to the service network (with the Kubernetes -cluster IPs), e.g., use one of your Kubernetes nodes - -If you don't have it, you will need to install a `mysql` command line client -(on a Kubernetes node or a node on the Kubernetes service network): - -``` shell -# On Ubuntu -sudo apt install mariadb-client-core-10.6 -``` - -Then you can connect to the database: - -``` shell -mysql -u root \ --p$(kubectl --namespace openstack get secret mariadb -o jsonpath='{.data.root-password}' | base64 -d) \ --h mariadb-cluster-primary.openstack.svc.cluster.local -``` - -Make sure to change `svc.cluster.local` if you have set the name of your cluster -away from this default value. - -Maria has databases for Neutron, etc, so you may want `use neutron;` after -starting the client, or add `neutron` to the MySQL command. - -``` sql -use neutron; -``` - -From here, you can use MySQL client commands on the database. diff --git a/docs/prometheus-blackbox-exporter.md b/docs/prometheus-blackbox-exporter.md deleted file mode 100644 index 59054d060..000000000 --- a/docs/prometheus-blackbox-exporter.md +++ /dev/null @@ -1,16 +0,0 @@ -# Prometheus Blackbox Exporter - -Using the blackbox exporter we can gather metrics around uptime, latency, cert expiry and more for our public endpoints. -The blackbox exporter ideally would be ran outside the cluster but can still provide useful information when deployed within it when combined with alerting and visualizations. - - -#### Install Blackbox Exporter Helm Chart - - -``` shell -source /opt/genestack/scripts/genestack.rc -bin/install-chart.sh prometheus-blackbox-exporter -``` - -!!! success - If the installation is successful, you should see the related blackbox exporter pods in the prometheus namespace. diff --git a/docs/prometheus-custom-node-metrics.md b/docs/prometheus-custom-node-metrics.md deleted file mode 100644 index ad4505674..000000000 --- a/docs/prometheus-custom-node-metrics.md +++ /dev/null @@ -1,26 +0,0 @@ -# Deploy Custom Metrics - -We can utilize the Node Exporter deployed by Prometheus to collect custom metrics that may not be available from other exporters. - -For more information visit: [Node Exporter Textfile Collectors](https://github.com/prometheus/node_exporter?tab=readme-ov-file#textfile-collector) - -You can also view example scripts here: [Textfile Collector Scripts](https://github.com/prometheus-community/node-exporter-textfile-collector-scripts) - - -#### Example custom exporter playbook - -``` shell -ansible-playbook custom_exporters.yml -``` - -#### Example custom exporter playbook with overrides - -Confirm `inventory.yaml` matches what is in /etc/genestack/inventory. If it does not match update the command to match the file names. - -``` shell -# Example overriding things on the CLI -source /opt/genestack/scripts/genestack.rc -ansible-playbook custom_exporters.yml --private-key ${HOME}/.ssh/openstack-keypair.key -``` - -Once the scripts run the node exporter will collect your metrics and supply them to prometheus for you to view. diff --git a/docs/prometheus-kube-ovn.md b/docs/prometheus-kube-ovn.md deleted file mode 100644 index 75337df39..000000000 --- a/docs/prometheus-kube-ovn.md +++ /dev/null @@ -1,14 +0,0 @@ -# Kube-OVN Monitoring - -Kube-OVN exposes a lot of important metrics about the controller, pinger and cni plugin. We simply -create a service monitor to pull these metrics into Prometheus. - - -## Installation - -``` shell -kubectl apply -k /etc/genestack/kustomize/prometheus-ovn/base -``` - -!!! success - If the installation is successful, you should see metrics with `kube_ovn_*` in Prometheus. diff --git a/docs/prometheus-memcached-exporter.md b/docs/prometheus-memcached-exporter.md deleted file mode 100644 index f82a28310..000000000 --- a/docs/prometheus-memcached-exporter.md +++ /dev/null @@ -1,28 +0,0 @@ -# Memcached Exporter - -Memcached Exporter is used to expose metrics from a running Memcached deployment. The memcached exporter is an integrated part -of the memcached deployment in Genestack but will need to be enabled. - -!!! note - - To deploy metric exporters you will first need to deploy the Prometheus Operator, see: ([Deploy Prometheus](prometheus.md)). - -## Deploy the Memcached Cluster With Monitoring Enabled - -Edit the Helm overrides file for memcached at `/etc/genestack/helm-configs/memcached/memcached-helm-overrides.yaml` and add the following values -to enable the memcached exporter: - -``` yaml -metrics: - enabled: true - serviceMonitor: - enabled: true -``` - -Once the changes have been made, apply the changes to the memcached deployment with the `bin/install-memcached.sh` script: - -!!! example "`bin/install-memcached.sh`" - - ``` shell - --8<-- "bin/install-memcached.sh" - ``` diff --git a/docs/prometheus-monitoring-overview.md b/docs/prometheus-monitoring-overview.md deleted file mode 100644 index d46c3b259..000000000 --- a/docs/prometheus-monitoring-overview.md +++ /dev/null @@ -1,31 +0,0 @@ -# Prometheus Monitoring Overview - -Genestack utilizes Prometheus for monitoring, alerting and metrics collection. To read more about Prometheus please take a look at the [upstream docs](https://prometheus.io). - - -Components used to monitor and provide alerting and visualization mechanisms for genestack include: - -* Prometheus -* AlertManager -* Grafana - -Prometheus makes use of various metric exporters used to collect monitoring data related to specific services: - -* Node Exporter(Hardware metrics) -* Kube State Exporter(Kubernetes cluster metrics) -* Mysql Exporter(MariaDB/Galera metrics) -* RabbitMQ Exporter(RabbitMQ queue metrics) -* Postgres Exporter(Postgresql metrics) -* Memcached Exporter(Memcached metrics) -* Openstack Exporter(Metrics from various Openstack products) -* Pushgateway (metrics from short-lived jobs) -* SNMP exporter (for monitoring with SNMP) - -
- ![Prometheus Monitoring Diagram](assets/images/prometheus-monitoring.png){ style="filter:drop-shadow(#3c3c3c 0.5rem 0.5rem 10px);" } -
high level visual of Prometheus and the various monitoring and alerting components within genestack
-
- -### Getting started with genestack monitoring - -To get started using monitoring within the genestack ecosystem begin with the [getting started](monitoring-getting-started.md) page diff --git a/docs/prometheus-mysql-exporter.md b/docs/prometheus-mysql-exporter.md deleted file mode 100644 index 57ccb3e37..000000000 --- a/docs/prometheus-mysql-exporter.md +++ /dev/null @@ -1,36 +0,0 @@ -# Mariadb Exporter - -Mysql Exporter is used to expose metrics from a running mysql/mariadb server. The type of metrics exposed is controlled -by the exporter and expressed in values.yaml file. - -!!! note - - To deploy metric exporters you will first need to deploy the Prometheus Operator, see: ([Deploy Prometheus](prometheus.md)). - -## Installation - -First create secret containing password for monitoring user - -``` shell -kubectl --namespace openstack \ - create secret generic mariadb-monitoring \ - --type Opaque \ - --from-literal=username="monitoring" \ - --from-literal=password="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-64};echo;)" -``` - -Then add the config to a secret that'll be used within the container for our shared services -``` shell -kubectl -n openstack create secret generic mariadb-monitor --type Opaque --from-literal=my.cnf="[client.monitoring] -user=monitoring -password=$(kubectl --namespace openstack get secret mariadb-monitoring -o jsonpath='{.data.password}' | base64 -d)" -``` - -Next, install the exporter - -``` shell -bin/install-chart.sh prometheus-mysql-exporter -``` - -!!! success - If the installation is successful, you should see the exporter pod in the openstack namespace. diff --git a/docs/prometheus-nginx-gateway.md b/docs/prometheus-nginx-gateway.md deleted file mode 100644 index f30dae4d1..000000000 --- a/docs/prometheus-nginx-gateway.md +++ /dev/null @@ -1,14 +0,0 @@ -# NGINX Gateway Fabric Monitoring - -NGINX Gateway Fabric exposes a lot of important metrics about the gateway. We simply -create a pod monitor to pull these metrics into Prometheus. - - -## Installation - -``` shell -kubectl apply -f /etc/genestack/kustomize/prometheus-nginx-gateway/base -``` - -!!! success - If the installation is successful, you should see metrics with `nginx_gateway_fabric_*` in Prometheus. diff --git a/docs/prometheus-openstack-metrics-exporter.md b/docs/prometheus-openstack-metrics-exporter.md deleted file mode 100644 index 689ed52c6..000000000 --- a/docs/prometheus-openstack-metrics-exporter.md +++ /dev/null @@ -1,92 +0,0 @@ -# Openstack Exporter - -We are using Prometheus for monitoring and metrics collection along with the openstack exporter to gather openstack specific resource metrics. -For more information see: [Prometheus docs](https://prometheus.io) and [Openstack Exporter](https://github.com/openstack-exporter/openstack-exporter) - -## Deploy the Openstack Exporter - -!!! note - - To deploy metric exporters you will first need to deploy the Prometheus Operator, see: [Deploy Prometheus](prometheus.md). - -### Create clouds-yaml secret - -Modify genestack/helm-configs/monitoring/openstack-metrics-exporter/clouds-yaml with the appropriate settings and create the secret. - -!!! tip - - See the [documentation](openstack-clouds.md) on generating your own `clouds.yaml` file which can be used to populate the monitoring configuration file. - -From your generated `clouds.yaml` file, create a new manifest for your cloud config: - -``` shell -printf -v m "$(cat ~/.config/openstack/clouds.yaml)"; \ - m="$m" yq -I6 -n '."clouds.yaml" = strenv(m)' | \ - tee /tmp/generated-clouds-yaml -``` - -!!! example "generated file will look similar to this" - - ``` yaml - --8<-- "base-helm-configs/monitoring/openstack-metrics-exporter/clouds-yaml" - ``` - -If you're using self-signed certs then you may need to add keystone certificates to the generated clouds yaml: - -``` shell -ks_cert="$(kubectl get secret -n openstack keystone-tls-public -o json | jq -r '.data."tls.crt"' | base64 -d)" \ - yq -I6 '."clouds.yaml" |= (from_yaml | .clouds.default.cacert = strenv(ks_cert) | to_yaml)' \ - The process is broken down into 6 distinct phases: -
__Scope__, __Implement__, __Document__, __Test__, __Deployment__, and __Maintain__. - -### Scope - -The scope phase is where new work is identified, based off the stated objective, and the level of effort determined. The plan portion of scope is where the work is assigned to various sprints to ensure timely completion. This step is vital to ensure we are meeting stated goals for the business and the community. - -### Implement - -In the implement phase, development teams use the requirements gathered in the scope phase to create code or process that meets the deliverable ask. - -### Document - -Documentation must reflect the current state of the codebase for any deployed application, service or process. If functionality has been added, removed, or changed the documentation is updated to reflect the change. - -Tl;dr changed something, added something, removed something -- document it. - -### Test - -The test phase is used to ensure that the deliverable is free from defects and meets the specified requirements. This is accomplished via a three-step or phased approach: -
1. Github pre-commit checks -
2. Unit testing against development environment -
3. Functional checks using [Rally](https://opendev.org/openstack/rally) - against our Development and Staging environments - -### Deployment - -In the deployment phase, the development team deploys deliverables using a multi-environment deployment process. This ensures deliverables are tested through a staging environment for functionality and reliability before reaching production. - -### Maintenance - -In the maintenance phase, the team focuses on monitoring the various environments, fixing bugs, and addressing any issues brought forth by customers or stakeholders. diff --git a/docs/sealed-secrets.md b/docs/sealed-secrets.md deleted file mode 100644 index 7c635cd9b..000000000 --- a/docs/sealed-secrets.md +++ /dev/null @@ -1,79 +0,0 @@ -!!! Danger "This section is still underdevelopment and experimental" - - None of the vault components are required to run a Genestack environment. - -# Sealed Secrets Introduction and Installation Guide - -Sealed Secrets is a Kubernetes-native solution for securely storing and managing sensitive information within Kubernetes Secrets. It ensures secure secret management by encrypting Kubernetes Secrets and storing them as SealedSecret resources, which can only be decrypted by the cluster itself. - -Sealed Secrets utilizes public-key cryptography to encrypt secrets, enabling safe storage in your version control system. - - -## Installation - -``` shell -cd kustomize/sealed-secrets/base -``` - -- Modify the `values.yaml` file with your desired configurations. Refer to the sample configuration in this directory, already updated for installation. - -``` shell -vi values.yaml -``` - -- Perform the installation: - -``` shell -kubectl kustomize . --enable-helm | kubectl apply -f - -``` - -!!! note - Ensure to take a backup of the `sealed-secrets-keyxxxx` Kubernetes Secret from the sealed-secrets namespace, as it will be required for the restoration process if needed. - -``` -kubectl get secret -n sealed-secrets -l sealedsecrets.bitnami.com/sealed-secrets-key=active -o yaml > sealed-secrets-key.yaml -``` - -## Usage Example: -In this example, we will use Sealed Secrets to encrypt a Grafana certificate from Kubernetes Secret yaml file. - -### Encrypting Kubernetes Secret: -- Kubernetes Secret yaml file containing Grafana certificate: -``` -# cat grafana-cert.yaml -apiVersion: v1 -data: - ca.crt: - LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUJjVENDQVJhZ0F3SUJBZ0lRYjBYbHp2d3JIWTd0MjNBREJ5Y2NnekFLQmdncWhrak9QUVFEQWpBWU1SWXcKRkFZRFZRUURFdzF5WVdOcmMzQmhZMlV1WTI5dE1CNFhEVEkwTURJeU5ERXdOVFExT0ZvWERUTTBNREl5TVRFdwpOVFExT0Zvd0dERVdNQlFHQTFVRUF4TU5jbUZqYTNOd1lXTmxMbU52YlRCWk1CTUdCeXFHU000OUFnRUdDQ3FHClNNNDlBd0VIQTBJQUJPd0owMU1ZTWw4MUNyV1dMODlQQkhvVG5telZCT2xRMkdMMDFTd2JjYXZQVmRCWnVHamIKeFlwR3VKVDd1UG5xdVp4eFZ4djhUSFlPcVVVL1ZYT2ZtdkNqUWpCQU1BNEdBMVVkRHdFQi93UUVBd0lDcERBUApCZ05WSFJNQkFmOEVCVEFEQVFIL01CMEdBMVVkRGdRV0JCUU5weXZnNk1CSWFnZENuOVR1ejZ3SkZDMVIvekFLCkJnZ3Foa2pPUFFRREFnTkpBREJHQWlFQTY5T25ScUZ5SHZQbjJkWFZ6YjBTVFRZY2UxUUZGUEphWXFVYnQrc2kKdG13Q0lRRDE2ODV0UDBKcnZRRnB6NVlPNFdYQ2xEQWxabTgxUWRwN1lWY0FJS1RhbWc9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== - tls.crt: - LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNUVENDQWZLZ0F3SUJBZ0lSQUxieTRuVUJoTWlvYkVTS01yVmwrbEl3Q2dZSUtvWkl6ajBFQXdJd0dERVcKTUJRR0ExVUVBeE1OY21GamEzTndZV05sTG1OdmJUQWVGdzB5TkRBek1UVXhNakk0TUROYUZ3MHlPVEF6TVRReApNakk0TUROYU1BQXdnZ0VpTUEwR0NTcUdTSWIzRFFFQkFRVUFBNElCRHdBd2dnRUtBb0lCQVFEUStvcVhlUVZWCmRSWkFWclM2ekZwMDlONXpDWUJRcS9HRjNNS1NyWnNkK3VNVlFXakIwcXlJcWJRdm9kL0N0NFhMdWx3a3UyWkIKQlg1MFN4NHJMVGhKQ3ExY2VIQ3lnRUZRa1gyekl6dlBkaCtTcFhWUnhMdzhHZW1ramZ5R3VXeVdydkVEa1cxKwpaM0dYOFc0ZzRZVkwyUEhSLzBIOWxSaVVhK2lYMmM0ZkJhVWoyTUQ3bkF6eWRKaEpneU5rQVZqUHFkRGpGay90CmdIS3pDTGhRTjd0d083ZzluU1UwdTJ1aWI4Z0FZeng0aHl1SWtwR3dCL3JNQkFWb0pxV3Y5eFFkVWd2S2w4a0EKbDFydngwaFlveWZETUprWVQ3SkFYZExEWTJRTUNyY0Y3d0poQUMzYThhYXJqRlUwWXFiQ0Z4TCtvRGw3OGxDbwp2akt2NG0wUmliU1ZBZ01CQUFHamFqQm9NQTRHQTFVZER3RUIvd1FFQXdJRm9EQU1CZ05WSFJNQkFmOEVBakFBCk1COEdBMVVkSXdRWU1CYUFGQTJuSytEb3dFaHFCMEtmMU83UHJBa1VMVkgvTUNjR0ExVWRFUUVCL3dRZE1CdUMKR1dkeVlXWmhibUV0YkdGaUxtUmxiVzh1YldzNGN5NXVaWFF3Q2dZSUtvWkl6ajBFQXdJRFNRQXdSZ0loQU9lRwp4d1l0S1ZUTjVMcmpwbGR6YlVOLzQ3NnFqM0t4NXdZcGlCL0VaalY5QWlFQXRHU3ZJZlJ2R0JGY1lqaWRyNFl1Ckw1S0Rwd21rZkt0eFhuNi9xamF0eG1jPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== - tls.key: - LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFcFFJQkFBS0NBUUVBMFBxS2wza0ZWWFVXUUZhMHVzeGFkUFRlY3dtQVVLdnhoZHpDa3EyYkhmcmpGVUZvCndkS3NpS20wTDZIZndyZUZ5N3BjSkx0bVFRVitkRXNlS3kwNFNRcXRYSGh3c29CQlVKRjlzeU03ejNZZmtxVjEKVWNTOFBCbnBwSTM4aHJsc2xxN3hBNUZ0Zm1keGwvRnVJT0dGUzlqeDBmOUIvWlVZbEd2b2w5bk9Id1dsSTlqQQorNXdNOG5TWVNZTWpaQUZZejZuUTR4WlA3WUJ5c3dpNFVEZTdjRHU0UFowbE5MdHJvbS9JQUdNOGVJY3JpSktSCnNBZjZ6QVFGYUNhbHIvY1VIVklMeXBmSkFKZGE3OGRJV0tNbnd6Q1pHRSt5UUYzU3cyTmtEQXEzQmU4Q1lRQXQKMnZHbXE0eFZOR0ttd2hjUy9xQTVlL0pRcUw0eXIrSnRFWW0wbFFJREFRQUJBb0lCQVFDR2x0VnJlS1hXdy9Idwp2ZWJuNTNUYW5sb2wvSmlIWERYUTRMenZlcC9NVHlpeEo4OHdCVjdaSlhMR3VwcEI3YkJkNVVneTMvNmJJYzZ2ClZ6RzIzUWpEQWYxazhLeWtTYlhIRGV6RzBvcFNzdURpc1cwOW5GY2UzaEY3eVhZNXpuSUJHZXBmUWVvaTNyeHAKL3pQT09YQi95TmoxUmxCWjRReFRpcXZpSUlSL3RSZmNQcFp2RWFRRHo5RDBwcm5VTG5raXdqZ1FsUVhnWXdITwpFYjRBZTlwaWwzZ3plNnVoeGxOWEc3bE1nYjFoOHZFa0RNOURJK0tqd25tYjF3eEZCSkZEQ2E4dm15ZDZZTThRCnU1bU5JbVc3bmh1bTA3akRid0tXSDgySE5kTWEwT2g4T0RCWENSSkVhMTZ2YXd0NVNCWjJLcVdlbmpaTlUycmwKTzJ2UmRZUUJBb0dCQVAxUzhEeTVWRkVQUHB4RCtLZHJzWGlVcER6Rzl2VGZmS3ZLQ2NBNExpVEJNYTdEdlRNTwpMeFRJaldMekhmZUFPbXBzVngrK3U4S1kzd2txbTBDcWpabzZ3eVpXcWZhZkJ6bUluK3p3Zm9tQmlIazJwZ2tCCjlTdU95VW9Bb0djYSt6TUtyZXpJRjVrc2FaUmlJbERsL2dheWFlVUZyWGhLZUJTbDF0Q3lOVTlOQW9HQkFOTXYKcmkxcllLZkVPeGxOTlpTbVczQzRiZ2RJZlNoRXNYaVcrUkxFYkdqamgwRWN5Vy92SCtrMU5TdU5aZERpUk9BRwpVQmhmT29YSnVYbzJkTlRXdXFuSE9QL2pxUG1tYWRhU3dpejNtUFNqRUppU3hUbFBQMGEyb0Jpa3VTVlAybDFVCkxxa0MrZ1ZEWHhoaXlXUXlKMUNnY0dNb0IyTVI4R0RaZkVXSm9lWnBBb0dCQU9EdjBWUUtPRjFWelFHU3RXdHMKREFVRzc2THNCUU5Bb3dJamYyOElNNmo5UnpGb3EwcDNjTVRpby9EVjhha0FXbDUvWHdsWUluN1RvVkFSWGhRWQpuVzN5ZWJCRVNkMHNMbzBlek9ybVRXV3ArRld4ZWRNTHd2aHZiRHJpdll0d0FOZTh4dDAyZXdYTzB0MG9HbEo5Ck5vZ1p5ai9MUDlKTlJiMEgyT3d0SVhzTkFvR0FNaXRrbEhPcTNaQVhmaFpDZ1ZMWDdEcFVJVFRPVHMrcTNYdjQKSmNZMS91RDJrN2hUL2x4dlYwYUZvQmdTTlFKYjNHQ0RqSmFxMzNlaHNXL1laMnV2b24rcWdkZkNuN1F4OW9DYwowblByaVVwbnVlYzhKVFkzVVFRM21rTWZuTWFRbUpWVUZHQ1pwc0J2aWVxRjcyQ2V5RitrODFsaUQ5NEdIZXZzCnd0UkVldWtDZ1lFQSt1ZExMZllCRitFaDZIVldvT3NXU2lqZCtrTnh4ajhaK2VSMWhOaWxtN1I5RlNkVzJHVEoKY2lvMlIrSDhWU0xudnFjZ29oWXNxZ0N0VXViTnpNbjdlbEt4RkNOOHRaS1lUYnhHcU5IUHJ4WE43M3RQNy83WAp2MWF4UXQvbm5lcDEvaVYzODVBcUZLdGZ6UU9Ua25sdGJBcmxyZzRvRFk4d0NtUmcwTi9aLzJFPQotLS0tLUVORCBSU0EgUFJJVkFURSBLRVktLS0tLQo= -kind: Secret -metadata: - annotations: - cert-manager.io/alt-names: grafana-lab.demo.mk8s.net - name: grafana - namespace: rackspace-system -type: kubernetes.io/tls -``` -- Download [kubeseal](https://github.com/bitnami-labs/sealed-secrets/releases) binary. -- Use `kubeseal` for the Kuberntes Secret entryption: -``` shell -kubeseal --scope cluster-wide --allow-empty-data -o yaml --controller-namespace rackspace-system < ~/grafana-cert.yaml > encrypted_grafana-cert.yaml -cat encrypted_grafana-cert.yaml -``` -For more options around `kubeseal` please check help page. - -- Upload the encrypted Sealed Secret resource(`encrypted_grafana-cert.yaml`) to your version control system. It can only be decrypted using the secret created during the Sealed Secrets installation. - -### Deploying Kubernetes Secret from Sealed Secret Resource: -- Apply sealed-secret resource(`encrypted_grafana-cert.yaml`): -```shell -kubectl apply -f encrypted_grafana-cert.yaml -``` -- Verify that the Sealed Secret has been created and the Kubernetes Secret has been decrypted: -```shell -kubectl get sealedsecret/grafana -n rackspace-system -kubectl get secret grafana -n rackspace-system -``` diff --git a/docs/security-introduction.md b/docs/security-introduction.md deleted file mode 100644 index cc05367c6..000000000 --- a/docs/security-introduction.md +++ /dev/null @@ -1,65 +0,0 @@ -# Genestack Secure Development Practices - -Genestack is a complete operation and deployment ecosystem for OpenStack services that heavily utilizes cloud native application like -Kubernetes. While developing, publishing, deploying and running OpenStack services based on Genestack we aim to ensure that our engineering teams follow -security best practices not just for OpenStack components but also for k8s and other cloud native applications used within the Genestack ecosystem. - -This security primer aims to outline layered security practices for Genestack, providing actionable security recommendations at every level to mitigate -risks by securing infrastructure, platform, applications and data at each layer of the development process. -This primer emphasizes secure development practices that complement Genestack's architecture and operational workflows. - - -## Layered Security Approach - -Layered security ensures comprehensive protection against evolving threats by addressing risks at multiple levels. The approach applies security measures -to both physical infrastructure and also provides security focus to the development of the application itself. The aim is to minimize a single point -of failure compromising the entire system. This concept aligns with the cloud native environments by catagorizing security measures across the lifecycle and stack of the cloud native technologies. - -The development team follow a set of practices for Genestack: Rackspace OpenStack Software Development Life Cycle (Rax-O-SDLC). The SDLC practice aims to produce -software that meets or exceeds customer expectation and reach completion within a time and cost estimate. SDLC process is divided into six distinct phases: `Scope`, `Implement`, -`Document`, `Test`, `Deployment` and `Maintain`. - -For each of the above stages fall within the security guidelines from CNCF that models security into four distince phases. - -Security is then injected at each of these phases: - -1. **Develop:** Applying security principles during application development - -2. **Distribute:** Security practices to distribute code and artifacts - -3. **Deploy:** How to ensure security during application deployment - -4. **Runtime:** Best practices to secure infrastructure and interrelated components - - -Lets look at it from OpenStack side of things. We want to see security across: - -1. **Infrastructure:** Both physical and virtual resources - -2. **Platform:** Services that support workloads - -3. **Applications:** Containerized workloads and instances that run the services - -4. **Data:** Security of data at rest and in transit - - -CNCF defines its security principles as: - -1. Make security a design requirement - -2. Applying secure configuration has the best user experience - -3. Selecting insecure configuration is a conscious decision - -4. Transition from insecure to secure state is possible - -5. Secure defaults are inherited - -6. Exception lists have first class support - -7. Secure defaults protect against pervasive vulnerability exploits - -8. Security limitations of a system are explainable - - -These guidelines can be adopted to have a secure foundation for Genestack based cloud. diff --git a/docs/security-lifecycle.md b/docs/security-lifecycle.md deleted file mode 100644 index f3c03d03e..000000000 --- a/docs/security-lifecycle.md +++ /dev/null @@ -1,308 +0,0 @@ -# Layered Security - -Layered security in cloud-native environments involves applying protection measures across all lifecycle stages: development, distribution, deployment, and runtime. Each stage incorporates specific controls to address security risks and maintain a robust defense. For example, during development, practices like secure coding and dependency scanning are emphasized. The distribution stage focuses on verifying artifacts, such as container images, with cryptographic signatures. Deployment involves infrastructure hardening and policy enforcement, ensuring secure configuration. Finally, runtime security includes monitoring and detecting anomalies, enforcing least privilege, and safeguarding active workloads to mitigate threats dynamically. - -Lets look at each stage in detail. - -## Develop - -The Develop phase in cloud-native security emphasizes integrating security into the early stages of application development. It involves secure coding practices, managing dependencies by scanning for vulnerabilities, and incorporating security testing into CI/CD pipelines. Developers adopt tools like static and dynamic analysis to identify risks in source code and applications. This proactive approach helps prevent vulnerabilities from progressing further down the lifecycle, reducing risks in later stages. - -
- ![CNCF Develop](assets/images/CNCF_develop.jpg){ width="700" height="400"} -
Ref: CNCF Cloud Native Security Develop Phase
-
- - -=== "Infrastructure Layer" - - * **CNCF Context** - - Ensure infrastructure as code (IaC) is secure and scanned for vulnerabilities using tools like Checkov or Terraform Validator. - - * **Recommendations** - - Have separate development, staging and production environments. - - Securely configure physical and virtual resources (e.g., OpenStack nodes, Kubernetes nodes) during the development of IaC templates. - - Implement CI pipelines that test and validate infrastructure configurations against security benchmarks. - - -=== "Platform Layer" - - * **CNCF Context** - - Harden platform components like OpenStack services or Kubernetes clusters in the configuration stage. - - * **Recommendations** - - Use security-focused configurations for platforms supporting workloads (e.g., hardened Helm charts, secured Nova and Neutron configurations). - - Audit configuration files for misconfigurations using tools like kube-score. - - -=== "Applications Layer" - - * **CNCF Context** - - Use secure coding practices and dependency scans to mitigate risks in application code. - - * **Recommendations** - - Ensure failures in CI is fixed and that tests exists for failure scenarios. - - Develop application with 12 factor app concept. - - Review code before merging. Follow pre-production and production branching. - - Containerize workloads using scanned, validated images. - - Integrate static application security testing (SAST) into CI pipelines. - - -=== "Data Layer" - - * **CNCF Context** - - Secure sensitive data early by implementing encryption strategies. - - * **Recommendations** - - Ensure sensitive configuration data (e.g., Secrets, keys) is managed securely using Vault or Barbican. - - Use tools like Snyk to scan code for data exposure risks. - - - -## Distribute - -The Distribute phase in cloud-native security focuses on ensuring that all software artifacts, such as container images and binaries, are securely handled during distribution. Key practices include signing artifacts with cryptographic signatures to verify their integrity and authenticity, scanning artifacts for vulnerabilities, and employing policies to prevent the distribution of untrusted or non-compliant components. A secure artifact registry, access controls, and monitoring of repository activity are essential to maintain trust and protect the supply chain. These measures help reduce risks of tampered or malicious artifacts being deployed in production environments. - - -
- ![CNCF Distribute](assets/images/CNCF_distribute.jpg){ width="700" height="400"} -
Ref: CNCF Cloud Native Security Distribute Phase
-
- - -=== "Infrastructure Layer" - - * **CNCF Context** - - Securely distribute infrastructure artifacts such as VM images or container runtimes. - - * **Recommendations** - - Build secure image building pipelines. - - Use image signing (e.g., Sigstore, Notary) for OpenStack or Kubernetes. - - Validate VM images against OpenStack Glance hardening guidelines. - - -=== "Platform Layer" - - * **CNCF Context** - - Ensure platform components are securely distributed and deployed. - - * **Recommendations** - - Apply signed configuration files and use secure channels for distributing Helm charts. - - Use integrity validation tools to verify signed manifests. - - Use secure registry for container images. - - -=== "Applications Layer" - - * **CNCF Context** - - Harden containers and validate their integrity before deployment. - - * **Recommendations** - - Leverage tools like Harbor to enforce vulnerability scans for container images. - - Ensure SBOM (Software Bill of Materials) generation for all containerized workloads. - - Cryptographically sign images. - - Have container manifest scanning and hardening policies enforced. - - Develop security tests for applications. - - -=== "Data Layer" - - * **CNCF Context** - - Secure data movement and prevent exposure during distribution. - - * **Recommendations** - - Encrypt data at rest and enforce TLS for data in transit between distribution systems. - - Periodically rotate encryption keys to ensure freshness. - - Use secure container image registry with RABC policy. - - - -## Deploy - -The Deploy phase in cloud-native security focuses on securely setting up and configuring workloads and infrastructure in production environments. This phase emphasizes using tools like Infrastructure as Code (IaC) to define secure, consistent configurations. Security controls include enforcing policies such as mandatory access controls, network segmentation, and compliance with deployment best practices. Additionally, ensuring that only trusted artifacts, verified in the "Distribute" phase, are deployed is critical. Continuous validation of deployments and automated scanning help maintain security posture and prevent misconfigurations or vulnerabilities from affecting the runtime environment. - -
- ![CNCF Deploy](assets/images/CNCF_deploy.jpg){ width="700" height="400"} -
Ref: CNCF Cloud Native Security Deploy Phase
-
- -=== "Infrastructure Layer" - - * **CNCF Context** - - Use hardened deployment practices for nodes, ensuring compliance with security policies. - - * **Recommendations** - - Deploy OpenStack nodes and Kubernetes clusters with minimal services and secure configurations. - - Automate security testing for production deployments. - - Do pre-deploy infrastructure checks. (Example: host state, kerel version, patch status) - - Setup secure log storage. - - -=== "Platform Layer" - - * **CNCF Context** - - Secure APIs and runtime configurations for platforms. - - - * **Recommendations:** - - Enable TLS for OpenStack APIs and enforce RBAC in Kubernetes clusters. - - Use tools like OpenStack Security Groups and Kubernetes NetworkPolicies to isolate workloads. - - Have strong observability and metrics for the platform. - - Setup log aggregration. - - -=== "Applications Layer" - - * **CNCF Context:** - - Apply runtime policies for containerized applications. - - * **Recommendations:** - - Enforce PodSecurity policies for Kubernetes workloads and hypervisor-level security for OpenStack instances. - - Continuously monitor applications for compliance with runtime security policies. - - Have a strong Incident Management policy. - - Have a strong Alert/Event Management and Automation policy. - - -=== "Data Layer" - - * **CNCF Context:** - - Protect sensitive data as it enters the runtime environment. - - * **Recommendations:** - - Encrypt data in transit using SSL/TLS and secure APIs with rate-limiting and authentication. - - Perform regular audits of access logs for sensitive data. - - Ensure data protection before deploy. (Example: make sure database backup exist) - - - -## Runtime - -The Runtime phase in cloud-native security focuses on protecting active workloads and infrastructure against threats while applications are operational. Key practices include continuous monitoring for anomalous behavior, enforcing runtime policies to restrict actions beyond predefined boundaries, and using tools like intrusion detection systems (IDS) and behavioral analytics. Securing runtime environments also involves employing least-privilege access controls, managing secrets securely, and isolating workloads to contain potential breaches. These proactive measures help maintain the integrity and confidentiality of applications in dynamic cloud-native ecosystems. - -
- ![CNCF Runtime](assets/images/CNCF_runtime.jpg){ width="700" height="400"} -
Ref: CNCF Cloud Native Security Runtime Phase
-
- - -=== "Infrastructure Layer" - - * **CNCF Context** - - Monitor nodes for anomalies and ensure compliance with runtime configurations. - - - * **Recommendations** - - Use tools like Prometheus and Falco to detect anomalies in OpenStack and Kubernetes nodes. - - Automate incident response with tools like StackStorm. - - -=== "Platform Layer" - - * **CNCF Context** - - Continuously secure platform services during operation. - - - * **Recommendations** - - Apply monitoring tools to detect unusual API or service behaviors in OpenStack and Kubernetes. - - Set up alerting for deviations in usage patterns or API calls. - - -=== "Applications Layer" - - * **CNCF Context** - - Monitor containerized workloads for malicious or unexpected behavior. - - - * **Recommendations** - - Use runtime security tools like Aqua Security or Sysdig to secure containerized applications. - - Enforce network policies to restrict communication between workloads. - - -=== "Data Layer" - - * **CNCF Context** - - Secure data throughout its lifecycle in runtime. - - - * **Recommendations** - - Encrypt data streams and apply access controls to sensitive information. - - Use backup solutions and test recovery mechanisms to ensure data availability. - - -The Runtime phase encompasses several key components that form the foundation of a secure and highly available cloud environment. These components include: - -- Orchestration -- Compute -- Storage -- Access Control - -Each of these components involves complex interdependencies and is critical to the stability and security of your cloud infrastructure. Ensuring their security not only requires adherence to best practices during the Develop, Distribute, and Deploy phases but also relies heavily on the overall cloud environment's design. - -## Building a Secure and Resilient Cloud Environment - -Our objective is to provide comprehensive guidelines for designing a secure and highly available cloud. Start by reviewing the recommendations outlined in our Cloud Design Documentation to understand best practices for structuring your cloud infrastructure. With this foundation, we can establish security principles tailored to each critical component, ensuring they are robust and resilient against potential threats. diff --git a/docs/security-stages.md b/docs/security-stages.md deleted file mode 100644 index 147c2ae0a..000000000 --- a/docs/security-stages.md +++ /dev/null @@ -1,215 +0,0 @@ -# Securing Private Cloud Infrastructure - -To ensure a secure and highly available cloud, the security framework must address orchestration, compute, storage, and access control in the context of a larger cloud design. This guide builds on a multi-layered, defense-in-depth approach, incorporating best practices across physical, network, platform, and application layers, aligned with a region -> multi-DC -> availability zone (AZ) design. Each component is discussed below with actionable strategies for robust protection. - -## Orchestration Security -Orchestration platforms, such as OpenStack and Kubernetes, are fundamental to managing resources in a cloud environment. Securing these platforms ensures the stability and integrity of the overall cloud infrastructure. Below, we outline security considerations for both OpenStack and Kubernetes. - -### Securing OpenStack -OpenStack offers a robust framework for managing cloud resources, but its complexity requires careful security practices. - -- Implement software-defined networking (SDN) with micro-segmentation and zero-trust principles. -- Leverage OpenStack Neutron for VXLAN/VLAN isolation, network function virtualization (NFV), and dynamic security group management. -- Deploy next-generation firewalls (NGFWs) and intrusion prevention systems (IPS) to monitor and secure network traffic. -- Use stateful packet inspection and machine learning-based anomaly detection to identify threats in real time. - -- Secure OpenStack Keystone with multi-factor authentication (MFA) and federated identity management (SAML, OAuth, or LDAP). -- Enforce the principle of least privilege using RBAC and automated access reviews. - -- Integrate logs with a Security Information and Event Management (SIEM) system for real-time analysis. -- Use machine learning-powered threat hunting and anomaly detection to enhance monitoring capabilities. - -### Securing Kubernetes -Kubernetes is widely used for container orchestration, and securing its components is essential for maintaining a resilient cloud environment. - -Pod Security Standards (PSS) - -- Adopt Kubernetes' Pod Security Standards, which define three security profiles: - - - Privileged: Allows all pod configurations; use sparingly. - - Baseline: Enforces minimal restrictions for general-purpose workloads. - - Restricted: Applies the most stringent security controls, suitable for sensitive workloads. - -Pod Security Admission (PSA) - -- Enable Pod Security Admission to enforce Pod Security Standards dynamically. -- Configure namespaces with PSA labels to define the allowed security profile for pods in that namespace (e.g., restricted or baseline). - -Service Account Security - -- Avoid default service accounts for workload pods. -- Use Kubernetes RBAC to restrict the permissions of service accounts. -- Rotate service account tokens regularly and implement short-lived tokens for increased security. - -Network Policies - -- Use Network Policies to define pod-to-pod communication and restrict access. -- Allow only necessary traffic between services -- Block external traffic to sensitive pods unless explicitly required. -- Implement micro-segmentation within namespaces to isolate workloads. - -Kubernetes API Access - -- Restricting access to the control plane with network security groups. -- Enabling RBAC for granular access control. -- Securing API communication with mutual TLS and enforcing short-lived certificates. -- Logging all API server requests for auditing purposes. - - -## Compute Security -Compute resources, including hypervisors and virtual machines (VMs), must be hardened to prevent unauthorized access and ensure isolation. - -### Hypervisor and Host Security - -- Use hardware-assisted virtualization security features. -- Enable Secure Boot, Trusted Platform Module (TPM), and kernel hardening (ASLR, DEP). -- Leverage SELinux/AppArmor and hypervisor-level isolation techniques. -- Use Intel SGX or AMD SEV for confidential computing. - -### Virtual Machine Security - -- Perform image security scanning and mandatory signing. -- Enforce runtime integrity monitoring and ephemeral disk encryption. -- Ensure robust data-at-rest encryption via OpenStack Barbican. -- Secure all communications with TLS and automate key management using HSMs. - - -## Storage Security -Protecting data integrity and availability across storage systems is vital for cloud resilience. - -- Encrypt data-at-rest and data-in-transit. -- Implement automated key rotation and lifecycle management. -- Use immutable backups and enable multi-region replication to protect against ransomware and data loss. -- Establish encrypted, immutable backup systems. -- Conduct regular RPO testing to validate recovery mechanisms. -- Geographically distribute backups using redundant availability zones. - - -## Access Control Security -Access control ensures only authorized users and systems can interact with the cloud environment. - -- Implement multi-factor physical security mechanisms. -- Biometric authentication and mantrap entry systems. -- Maintain comprehensive access logs with timestamped and photographic records. -- Redundant sensors for temperature, humidity, and fire. -- UPS with automatic failover and geographically distributed backup generators. -- Use IAM policies to manage user and system permissions. -- Automate identity lifecycle processes and align access policies with regulatory standards. - -## Network and Infrastructure Security - -### Network Segmentation and Isolation Network Design Principles - -Implement software-defined networking (SDN) with - -- Micro-segmentation Zero-trust network architecture Granular traffic control policies. -- Use OpenStack Neutron advanced networking features. -- VXLAN/VLAN isolation Network function virtualization (NFV) Dynamic security group management. -- Deploy next-generation firewall (NGFW) solutions. -- Implement intrusion detection/prevention systems (IDS/IPS). -- Configure stateful packet inspection. -- Utilize machine learning-based anomaly detection. - - -## Larger Cloud Design: Integrating Region -> Multi-DC -> AZ Framework -To enhance the security of orchestration, compute, storage, and access control components, the design must consider: - -- Regions: Isolate workloads geographically for regulatory compliance and disaster recovery. -- Data Centers: Enforce physical security at each location and implement redundant power and environmental protection mechanisms. -- Availability Zones (AZs): Segment workloads to ensure fault isolation and high availability. - - -Effective OpenStack private cloud security requires a holistic, proactive approach. Continuous adaptation, rigorous implementation of multi-layered security controls, and commitment to emerging best practices are fundamental to maintaining a resilient cloud infrastructure. We can summarize the main cloud security principles in terms of the following: - - -| **Pillar** | **Definition** | **Key Point(s)** | -|---------------------|-------------------------------------------------------------------------------|----------------------------------------------------| -| **Accountability** | Clear ownership and responsibility for securing cloud resources. | Track actions with detailed logs and use IAM tools.| -| **Immutability** | Ensures resources are not altered post-deployment to preserve integrity. | Use immutable infrastructure and trusted pipelines.| -| **Confidentiality** | Protects sensitive data from unauthorized access or exposure. | Encrypt data (e.g., TLS, AES) and enforce access control.| -| **Availability** | Ensures resources are accessible when needed, even under stress. | Implement redundancy and DDoS protection. | -| **Integrity** | Keeps systems and data unaltered except through authorized changes. | Verify with hashes and use version control. | -| **Ephemerality** | Reduces exposure by frequently replacing or redeploying resources. | Use short-lived instances and rebase workloads regularly. | -| **Resilience** | Builds systems that withstand and recover from failures or attacks. | Design for high availability and test disaster recovery. | -| **Auditing and Monitoring** | Continuously observes environments for threats or violations. | Centralize logs and conduct regular security audits. | - - -## Security Standards - -## NIST SP 800-53 (National Institute of Standards and Technology Special Publication 800-53) - -NIST SP 800-53 is a comprehensive catalog of security and privacy controls designed to protect federal information systems and organizations. -It is widely adopted by public and private organizations to implement robust security frameworks. - -Main Focus Areas: - -- Access Control -- Incidence Response -- Risk assessment -- Continuous monitoring - -## PCI DSS (Payment Card Industry Data Security Standard) - -PCI DSS is a security standard designed to ensure that organizations processing, storing, or transmitting credit card information maintain a secure environment. -It is mandatory for entities handling payment card data. - -Main Focus Areas: - -- Secure Network Configurations -- Encryption of Sensitive Data -- Regular Monitoring and Testing -- Strong Access Control Measures - -## ISO/IEC 27001 (International Organization for Standardization) - -ISO/IEC 27001 is a globally recognized standard for establishing, implementing, and maintaining an information security management system (ISMS). -It helps organizations systematically manage sensitive information to keep it secure. - -Main Focus Areas: - -- Risk Management -- Security Policies -- Asset Management -- Compliance and Audits - -## CIS Controls (Center for Internet Security) - -The CIS Controls are a prioritized set of actions to defend against the most common cyber threats. -They provide actionable guidance for organizations of all sizes to enhance their security posture. - -Main Focus Areas: - -- Inventory and Control of Assets -- Secure Configurations for Hardware and Software -- Continuous Vulnerability Management -- Data Protection - -## FedRAMP (Federal Risk and Authorization Management Program) - -FedRAMP is a U.S. federal program that provides a standardized approach to assessing, authorizing, and monitoring cloud service providers. -It leverages NIST SP 800-53 as its foundation and ensures compliance for cloud services used by federal agencies. - -Main Focus Areas: - -- Security Assessments -- Continuous Monitoring -- Cloud Service Provider Authorization - -## GDPR (General Data Protection Regulation) - -GDPR is a European Union regulation focused on protecting personal data and ensuring privacy for EU citizens. -It applies to all organizations processing or storing the personal data of individuals within the EU, regardless of location. - -Main Focus Areas: - -- Data Subject Rights (e.g., right to access, right to be forgotten) -- Data Protection by Design and Default -- Data Breach Notifications -- Cross-Border Data Transfer Restrictions - - -## Recommended References - -- OpenStack Security Guide -- CIS OpenStack Benchmarks -- SANS Cloud Security Best Practices diff --git a/docs/security-summary.md b/docs/security-summary.md deleted file mode 100644 index 7da01ec46..000000000 --- a/docs/security-summary.md +++ /dev/null @@ -1,15 +0,0 @@ -# Summary - -GeneStack's multi-region and hybrid design, leveraging OpenStack and Kubernetes, provides a robust foundation for cloud-native workloads. By integrating layered security practices, you can enhance resilience against evolving threats. Regular audits, continuous improvement, and adherence to cloud-native security principles are vital for maintaining a secure environment. - -Lets summarize our layered security approach in a table: - -| Lifecycle Phase | Infrastructure | Platform | Application | Data | -| :---------: | :----------------------------------: | :-----------------------------------:| :-----------------------------:|:---------------------------------------:| -| **Develop** | Secure IaC, Validate Nodes | Harden Platform Configs | Secure code, container images |Encrypt sensitive configuration and data | -| **Distribute** | Validate Container/VM Images | Secure API and configuration delivery| Verify container integrity |Protect data during distribution | -| **Deploy** | Handen Deployed Nodes | Enforce RBAC and security policies | Apply runtime policies |Encrypt data in transit | -| **Runtime** | Monitor and Remediate Issues | Detect API issues and misuse | Monitor and secure workloads |Protect sensitive data streams | - - -By integrating these practices our security approach ensures comprehensive protection across the entire lifecycle of Genestack based OpenStack cloud. diff --git a/docs/storage-ceph-rook-external.md b/docs/storage-ceph-rook-external.md deleted file mode 100644 index 343b22753..000000000 --- a/docs/storage-ceph-rook-external.md +++ /dev/null @@ -1,95 +0,0 @@ ---- -hide: - - footer ---- - -# Cephadm/ceph-ansible/Rook (Ceph) - External - -We can use an external ceph cluster and present it via rook-ceph to your cluster. - -## Prepare pools on external cluster - -``` shell -ceph osd pool create general 32 -ceph osd pool create general-multi-attach-data 32 -ceph osd pool create general-multi-attach-metadata 32 -rbd pool init general -ceph fs new general-multi-attach general-multi-attach-metadata general-multi-attach-data -``` - -!!! info - - You must have a MDS service running, in this example I am tagging my 3 ceph nodes with MDS labels and creating a MDS service for the general-multi-attach Cephfs Pool - -``` shell -ceph orch host label add genestack-ceph1 mds -ceph orch host label add genestack-ceph2 mds -ceph orch host label add genestack-ceph3 mds -ceph orch apply mds myfs label:mds -``` - -!!! note - - From your ceph deploymenty node, We will now download create-external-cluster-resources.py and create exports to run on your controller node. Using cephadm in this example: - -``` shell -./cephadm shell -yum install wget -y ; wget https://raw.githubusercontent.com/rook/rook/release-1.16/deploy/examples/create-external-cluster-resources.py -python3 create-external-cluster-resources.py --rbd-data-pool-name general --cephfs-filesystem-name general-multi-attach --namespace rook-ceph-external --format bash -``` - -!!! example "Example create-external-cluster-resources.py output" - - The script generates a lot of output, you will need to capture all of the exports. These exports will be used in the next command. Copy these exports to your genestack deployment node. - - ``` shell - root@genestack-ceph1:/# python3 create-external-cluster-resources.py --rbd-data-pool-name general --cephfs-filesystem-name general-multi-attach --namespace rook-ceph-external --format bash - export NAMESPACE=rook-ceph-external - export ROOK_EXTERNAL_FSID=d45869e0-ccdf-11ee-8177-1d25f5ec2433 - export ROOK_EXTERNAL_USERNAME=client.healthchecker - export ROOK_EXTERNAL_CEPH_MON_DATA=genestack-ceph1=10.1.1.209:6789 - export ROOK_EXTERNAL_USER_SECRET=AQATh89lf5KiBBAATgaOGAMELzPOIpiCg6ANfA== - export ROOK_EXTERNAL_DASHBOARD_LINK=https://10.1.1.209:8443/ - export CSI_RBD_NODE_SECRET=AQATh89l3AJjBRAAYD+/cuf3XPdMBmdmz4iWIA== - export CSI_RBD_NODE_SECRET_NAME=csi-rbd-node - export CSI_RBD_PROVISIONER_SECRET=AQATh89l9dH4BRAApBKzqwtaUqw9bNcBI/iGGw== - export CSI_RBD_PROVISIONER_SECRET_NAME=csi-rbd-provisioner - export CEPHFS_POOL_NAME=general-multi-attach-data - export CEPHFS_METADATA_POOL_NAME=general-multi-attach-metadata - export CEPHFS_FS_NAME=general-multi-attach - export CSI_CEPHFS_NODE_SECRET=AQATh89lFeqMBhAAJpHAE5vtukXYuRj2+WTh2g== - export CSI_CEPHFS_PROVISIONER_SECRET=AQATh89lHB0dBxAA7CHM/9rTSs79SLJSKVBYeg== - export CSI_CEPHFS_NODE_SECRET_NAME=csi-cephfs-node - export CSI_CEPHFS_PROVISIONER_SECRET_NAME=csi-cephfs-provisioner - export MONITORING_ENDPOINT=10.1.1.209 - export MONITORING_ENDPOINT_PORT=9283 - export RBD_POOL_NAME=general - export RGW_POOL_PREFIX=default - ``` - -Run the following commands to import the cluster after pasting in exports from external cluster - -``` shell -kubectl apply -k /etc/genestack/kustomize/rook-operator/base -/opt/genestack/scripts/import-external-cluster.sh -helm repo add rook-release https://charts.rook.io/release -kubectl -n rook-ceph set image deploy/rook-ceph-operator rook-ceph-operator=rook/ceph:v1.13.7 -wget https://raw.githubusercontent.com/rook/rook/refs/tags/v1.16.5/deploy/charts/rook-ceph-cluster/values-external.yaml -O /etc/genestack/helm-configs/rook-values-external.yaml -helm install --create-namespace --namespace rook-ceph-external rook-ceph-cluster --set operatorNamespace=rook-ceph rook-release/rook-ceph-cluster -f /etc/genestack/helm-configs/rook-values-external.yaml -kubectl patch storageclass general -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}' -``` - -## Monitor progress - -``` shell -kubectl --namespace rook-ceph-external get cephcluster -w -``` - -## Validate the Connection - -When the monitor shows the message "Cluster connected successfully" the cluster is connected and ready for use. - -``` shell -NAME DATADIRHOSTPATH MONCOUNT AGE PHASE MESSAGE HEALTH EXTERNAL FSID -rook-ceph-external /var/lib/rook 3 3m24s Connected Cluster connected successfully HEALTH_OK true d45869e0-ccdf-11ee-8177-1d25f5ec2433 -``` diff --git a/docs/storage-ceph-rook-internal.md b/docs/storage-ceph-rook-internal.md deleted file mode 100644 index de51aa90d..000000000 --- a/docs/storage-ceph-rook-internal.md +++ /dev/null @@ -1,73 +0,0 @@ ---- -hide: - - footer ---- - -# Rook (Ceph) - In Cluster - -## Deploy the Rook operator - -``` shell -kubectl apply -k /etc/genestack/kustomize/rook-operator/base -``` - -!!! tip "Manually specifying the rook-operator image" - - Under certain circumstances it may be required to do this, below is an - example of how one can pin the operator version if so desired. - - ``` shell - kubectl -n rook-ceph set image deploy/rook-ceph-operator rook-ceph-operator=rook/ceph:v1.16.5 - ``` - -### Label the Storage Nodes - -|
key
| type |
value
| notes | -|:-----|--|:----------------:|:------| -| **role** | str | `storage-node` | When set to "storage-node" the node will be used for Ceph OSDs | - -Use the following command to label a node to be part of the Ceph storage cluster: - -``` shell -kubectl label node ${NODE_NAME} role=storage-node -``` - -Replace `${NODE_NAME}` with the name of your node. If you have multiple storage nodes, run this command against each one. - -## Deploy the Rook cluster - -!!! note - - Rook will deploy against nodes labeled `role=storage-node`. Make sure to have a look at the `/etc/genestack/kustomize/rook-cluster/rook-cluster.yaml` file to ensure it's setup to your liking, pay special attention to your `deviceFilter` settings, especially if different devices have different device layouts. - -``` shell -kubectl apply -k /etc/genestack/kustomize/rook-cluster/overlay -``` - -## Validate the cluster is operational - -``` shell -kubectl --namespace rook-ceph get cephclusters.ceph.rook.io -``` - -!!! note - - You can track the deployment with the following command `kubectl --namespace rook-ceph get pods -w`. - -## Create Storage Classes - -Once the rook cluster is online with a HEALTH status of `HEALTH_OK`, deploy the filesystem, storage-class, and pool defaults. - -``` shell -kubectl apply -k /etc/genestack/kustomize/rook-defaults/base -``` - -!!! note - - If installing prometheus after rook-ceph is installed, you may patch a running rook-ceph cluster with the following command. - -``` shell -kubectl -n rook-ceph patch CephCluster rook-ceph --type=merge -p "{\"spec\": {\"monitoring\": {\"enabled\": true}}}" -``` - -Ensure you have 'servicemonitors' defined in the rook-ceph namespace. diff --git a/docs/storage-external-block.md b/docs/storage-external-block.md deleted file mode 100644 index 031411e97..000000000 --- a/docs/storage-external-block.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -hide: - - footer ---- - -# External Block - Bring Your Own Storage - -For some Topo/Ceph/NFS are not great fits, Genestack allows for external block devices to be used in the stand up and operation of Openstack. - -## Deploy External CSI driver in Genestack - -Follow Documentation on getting a storage class presented to k8s, name it "general" and mark that storage class as default, in this example storage is provided by democratic csi driver over iscsi. - -``` shell -(genestack) root@genestack-controller1:# kubectl get sc -NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE -general (default) org.democratic-csi.iscsi Delete Immediate true 3h15m -``` - -!!! info - - OSD placement is done on nodes with label ‘openstack-control-plane’, a minimum of 3 nodes is required for a healthy Ceph cluster. - -Deploy Ceph operator - -``` shell -kubectl apply -k /etc/genestack/kustomize/rook-operator/base -kubectl -n rook-ceph set image deploy/rook-ceph-operator rook-ceph-operator=rook/ceph:v1.13.7 -``` - -Deploy Ceph on PVC - -``` shell -kubectl apply -k /etc/genestack/kustomize/rook-cluster-external-pvc/base -``` - -Monitor cluster state, once cluster HEALTH_OK proceed to the next step - -``` shell -(genestack) root@genestack-controller1:# kubectl --namespace rook-ceph get cephclusters.ceph.rook.io -NAME DATADIRHOSTPATH MONCOUNT AGE PHASE MESSAGE HEALTH EXTERNAL FSID -rook-ceph /var/lib/rook 3 129m Ready Cluster created successfully HEALTH_OK 9a6657cd-f3ab-4d70-b276-a05e2ca03e1b -``` - -Deploy cephfs filesystem named 'general-multi-attach' for Glance consumption - -``` shell -kubectl apply -k /etc/genestack/kustomize/rook-defaults-external-pvc/base -``` - -You should now have two storage class providers configured for Genestack - -``` shell -(genestack) root@genestack-controller1:# kubectl get sc -A -NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE -general (default) org.democratic-csi.iscsi Delete Immediate true 3h25m -general-multi-attach rook-ceph.cephfs.csi.ceph.com Delete Immediate true 85m -``` diff --git a/docs/storage-longhorn.md b/docs/storage-longhorn.md deleted file mode 100644 index face94141..000000000 --- a/docs/storage-longhorn.md +++ /dev/null @@ -1,234 +0,0 @@ -# Longhorn - -Longhorn is a lightweight, reliable, and highly available distributed block storage solution designed for Kubernetes. By default, it stores -its data in `/var/lib/longhorn` on each host node, keeping volumes close to where the workloads are running. This local-path approach can reduce -latency and boost performance, making Longhorn a fantastic choice for hyperconverged environments. In a hyperconverged setup, compute, networking, -and storage resources are consolidated on the same nodes, eliminating the need for separate storage servers. With Longhorn’s default storage path -and straightforward deployment, clusters become simpler to manage and scale while maintaining robust data protection, snapshots, and backups across -the infrastructure. - -## Setup and Installation of the Longhorn Storage Provider - -This guide walks through installing and configuring Longhorn, a lightweight, reliable, and powerful distributed block storage system for Kubernetes. -By following these steps, you'll set up the necessary host prerequisites, configure the Helm chart values, deploy Longhorn via Helm, and optionally -create an encrypted StorageClass. - -### Storage Node Setup - -Longhorn will create volumes under the `/var/lib/longhorn` directory on each node. Ensure that this directory has -enough space to accommodate the volumes you plan to create. If you have a separate disk or partition that you want -to use for Longhorn volumes, you can mount it at `/var/lib/longhorn` before installing Longhorn. - -### Label the Storage Nodes - -Longhorn can run on all of your cluster nodes, or you can restrict it to specific nodes. Labeling nodes helps control where Longhorn components (managers, drivers, etc.) -are scheduled. By labeling only certain nodes, you ensure that these nodes handle storage-related operations. - -|
key
| type |
value
| notes | -|:-----|--|:----------------:|:------| -| **longhorn.io/storage-node** | str | `enabled` | When set to "enabled" the node will be used within the Longhorn deployment | - -Use the following command to label a node to be part of the Longhorn storage cluster: - -``` shell -kubectl label node -l node-role.kubernetes.io/control-plane longhorn.io/storage-node=enabled -``` - -!!! note - - It is possible to replace `-l node-role.kubernetes.io/control-plane` with the name of your node. If you have multiple storage nodes, that are not also controllers. - -### Create the Helm Values File - -Before deploying Longhorn, it’s best practice to customize the chart’s values to suit your environment. One of the most common customizations is telling Longhorn where to run -its services and components—in this case, on nodes that have the label `longhorn.io/storage-node=enabled`. - -1. Create the override file at `/etc/genestack/helm-configs/longhorn/longhorn.yaml`. -2. Copy the following YAML content into that file. (Adapt as needed.) - -!!! example "longhorn.yaml" - - ``` yaml - --8<-- "base-helm-configs/longhorn/longhorn-helm-overrides.yaml" - ``` - - - `nodeSelector` ensures that the respective component is only scheduled onto nodes labeled `longhorn.io/storage-node=enabled`. - - This configuration helps separate storage responsibilities from other workloads if you have a mixed cluster. - -For additional customization, you can review the full list of supported values in Longhorn’s -[values.yaml](https://raw.githubusercontent.com/longhorn/charts/master/charts/longhorn/values.yaml). - -!!! tip - - While Longhorn can be used as a isolated storage cluster, it is also possible, and in some cases recommended, to run Longhorn on the same nodes as your worker nodes. To run Longhorn everywhere, remove the `nodeSelector` fields from the `longhorn.yaml` file. - -### Create The Longhorn Namespace - -!!! example "longhorn-namespace.yaml" - - ``` yaml - --8<-- "manifests/longhorn/longhorn-namespace.yaml" - ``` - -``` shell -kubectl apply -f /etc/genestack/manifests/longhorn/longhorn-namespace.yaml -``` - -### Run the Deployment - -With your values file in place, you can now deploy Longhorn using the `/opt/genestack/bin/install-longhorn.sh` -command. This command will install Longhorn if it is not installed yet, or upgrade it if an older version is -already present. - -??? example "Run the Longhorn deployment Script `/opt/genestack/bin/install-longhorn.sh`" - - ``` shell - --8<-- "bin/install-longhorn.sh" - ``` - -## Validate the Deployment - -After the Helm deployment finishes, you’ll want to verify that everything is running correctly. - -1. **Check the Longhorn pods** - - ``` shell - kubectl -n longhorn-system get pod - ``` - - This should show multiple pods such as `longhorn-manager`, `longhorn-driver`, `longhorn-ui`, etc. They should eventually report a `Running` or `Ready` status. - -2. **Check the Longhorn Nodes** - - ``` shell - kubectl -n longhorn-system get nodes.longhorn.io - ``` - - This will show the nodes known to the Longhorn system, verifying that Longhorn has recognized and is managing them. - -3. **Run a test Pod with a Longhorn Persistent Volume** - - ``` shell - kubectl create -f https://raw.githubusercontent.com/longhorn/longhorn/v1.8.0/examples/pod_with_pvc.yaml - ``` - - This sample manifest creates a test Pod that uses a PersistentVolumeClaim (PVC) managed by Longhorn. It helps confirm that Longhorn can successfully provision and attach storage. - -4. **Validate the Volume State** - - ``` shell - kubectl -n longhorn-system get volumes.longhorn.io - ``` - -You should see an entry for the newly created volume, and it should be in an attached, healthy state if everything is working. - -!!! example "Example Output" - - ``` shell - NAME DATA ENGINE STATE ROBUSTNESS SCHEDULED SIZE NODE AGE - pvc-42c89b53-f08e-4d69-9d4d-cd2297f2c280 v1 attached healthy 2147483648 compute-0.cloud.cloudnull.dev.local 54s - ``` - -Once you verify the test deployment, you can remove the Pod and related resources if you like. This helps keep your cluster clean if the test is no longer needed. - -## StorageClass Configuration - -The Longhorn StorageClass is a Kubernetes resource that defines how PersistentVolumeClaims (PVCs) are provisioned. -By creating a StorageClass, you can specify the default settings for Longhorn volumes, such as the number of -replicas, data locality, and more. This section will guide you through creating a general-purpose StorageClass and -an optional encrypted StorageClass. - -For a generic StorageClass and an overview of common properties, review the upstream -[example](https://github.com/longhorn/longhorn/blob/master/examples/storageclass.yaml). You can also review the Longhorn -[documentation](https://longhorn.io/docs/1.7.2/references/storage-class-parameters/#longhorn-specific-parameters) -for more information on StorageClasses. - -!!! note - - The Longhorn StorageClass created here will use two custom parameters: `numberOfReplicas` and `dataLocality`. While these have default values, they can be adjusted to better suit the needs of the cloud environment. - - - The `numberOfReplicas` parameter specifies the number of replicas for built PVC. While the common default is "3" for redundancy, you can adjust this value - based on your requirements. - - - The `dataLocality` parameter controls how Longhorn places replicas. - - For "**disabled**", replicas are placed on different nodes. - - For "**best-effort**", a replica will be co-located if possible, but is permitted to find another node if not. - - For "**strict-local**" the Replica count should be **1**, or volume creation will fail with a parameter validation error. This option enforces Longhorn keep the only one replica on the same node as the attached volume, and therefore, it offers higher IOPS and lower latency performance. - -### General StorageClass - -Longhorn will provide two default StorageClasses: `longhorn` and `longhorn-static`. - -- The `longhorn` StorageClass is marked as **default** and is suitable for most use cases. It dynamically provisions volumes with the default settings. -- The `longhorn-static` StorageClass is for users who want to manually specify the number of replicas for a volume. This StorageClass is useful for - workloads that require a specific number of replicas for data redundancy. - -For the purposes of Genestack, it is recommended that you create the `general` StorageClass to avoid deployment confusion. - -!!! example "longhorn-general-storageclass.yaml" - - ``` yaml - --8<-- "manifests/longhorn/longhorn-general-storageclass.yaml" - ``` - -Apply the general storage class manifest to create the StorageClass. - -``` shell -kubectl apply -f /etc/genestack/manifests/longhorn/longhorn-general-storageclass.yaml -``` - -With the `general` StorageClass in place, you can now create PVCs that reference it to dynamically provision Longhorn volumes with the desired settings. - -### (Optional) Create an Encrypted StorageClass - -If you want to enable data encryption, you can create an encrypted StorageClass. This feature encrypts the data at rest within the Longhorn volumes. Opting for the -encryption feature, your data remains secure and encrypted on the underlying disks. - -#### Steps to Create an Encrypted StorageClass - -1. **Generate a global secret** containing the encryption passphrase (or key). -2. **Create the encrypted StorageClass** that references this secret, ensuring that volumes created using this StorageClass are automatically encrypted. - -Below is an example combined manifest. Save this content to `/etc/genestack/manifests/longhorn-encrypted-storageclass.yaml`. - -!!! example "longhorn-encrypted-storageclass.yaml" - - ``` yaml - --8<-- "manifests/longhorn/longhorn-encrypted-storageclass.yaml" - ``` - -!!! info "Explanation of Key Fields" - - **Secret References**: Points to the `longhorn-crypto` secret so that the driver can retrieve encryption keys. - - **Secret** - - - `CRYPTO_KEY_VALUE`: The encryption passphrase/string. - - `CRYPTO_KEY_PROVIDER`: Specifies which key provider Longhorn uses (in this case, `secret`). - - `CRYPTO_KEY_CIPHER`: The cipher algorithm (e.g., `aes-xts-plain64`). - - `CRYPTO_KEY_SIZE`: The encryption key size in bits. - - `CRYPTO_PBKDF`: Determines the password-based key derivation function. - - **StorageClass** - - - `provisioner: driver.longhorn.io`: Uses the Longhorn CSI driver. - - `allowVolumeExpansion: true`: Allows you to resize volumes after creation. - - `reclaimPolicy: Delete`: Automatically deletes the underlying volume when the PVC is deleted. - - `encrypted: "true"`: Ensures volumes are encrypted. - -Apply the encrypted storage class manifest to create the StorageClass. - -``` shell -kubectl apply -f /etc/genestack/manifests/longhorn/longhorn-encrypted-storageclass.yaml -``` - -After applying this manifest, a new `StorageClass` named `general-encrypted` will be available. Any PVC you create referencing this StorageClass will -automatically generate an encrypted Longhorn volume. - -## Conclusion - -With Longhorn deployed and the StorageClass created, you can now use it in your PVCs to dynamically provision Longhorn volumes with the desired settings. -Longhorn should now be operating as a high-availability, cloud-native storage solution in your Kubernetes environment. You can use Longhorn’s UI or CLI -to manage and monitor volumes, snapshots, backups, and more. - -Review the upstream Longhorn [documentation](https://longhorn.io/docs) for more information on how to use the Longhorn UI and CLI. diff --git a/docs/storage-nfs-external.md b/docs/storage-nfs-external.md deleted file mode 100644 index 55d5ab379..000000000 --- a/docs/storage-nfs-external.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -hide: - - footer ---- - -# NFS - External - -While NFS in K8S works great, it's not suitable for use in all situations. - -!!! warning - - NFS is officially not supported by MariaDB and will fail to initialize the database backend when running on NFS. - -In Genestack, the `general` storage class is used by default for systems like RabbitMQ and MariaDB. If you intend to use NFS, you will need to ensure your use cases match the workloads and may need to make some changes within the manifests. - -## Install Base Packages - -NFS requires utilities to be installed on the host. Before you create workloads that require NFS make sure you have `nfs-common` installed on your target storage hosts (e.g. the controllers). - -### Add the NFS Provisioner Helm repo - -``` shell -helm repo add nfs-subdir-external-provisioner https://kubernetes-sigs.github.io/nfs-subdir-external-provisioner/ -``` - -## Install External NFS Provisioner - -This command will connect to the external storage provider and generate a storage class that services the `general` storage class. - -``` shell -helm install nfs-subdir-external-provisioner nfs-subdir-external-provisioner/nfs-subdir-external-provisioner \ - --namespace nfs-provisioner \ - --create-namespace \ - --set nfs.server=172.16.27.67 \ - --set nfs.path=/mnt/storage/k8s \ - --set nfs.mountOptions={"nolock"} \ - --set storageClass.defaultClass=true \ - --set replicaCount=1 \ - --set storageClass.name=general \ - --set storageClass.provisionerName=nfs-provisioner-01 -``` - -This command will connect to the external storage provider and generate a storage class that services the `general-multi-attach` storage class. - -``` shell -helm install nfs-subdir-external-provisioner-multi nfs-subdir-external-provisioner/nfs-subdir-external-provisioner \ - --namespace nfs-provisioner \ - --create-namespace \ - --set nfs.server=172.16.27.67 \ - --set nfs.path=/mnt/storage/k8s \ - --set nfs.mountOptions={"nolock"} \ - --set replicaCount=1 \ - --set storageClass.name=general-multi-attach \ - --set storageClass.provisionerName=nfs-provisioner-02 \ - --set storageClass.accessModes=ReadWriteMany -``` diff --git a/docs/storage-object-store-openstack-cli.md b/docs/storage-object-store-openstack-cli.md deleted file mode 100644 index a3c6c4f6e..000000000 --- a/docs/storage-object-store-openstack-cli.md +++ /dev/null @@ -1,208 +0,0 @@ -# Object Store Management using the OpenStack client - -## Goal - -Use the command-line utility `openstack` to perform operations on your object store. - -## Prerequisites - -Ensure you have followed the instructions in [OpenStack Getting Started with CLI](openstack-getting-started-cli.md) and ensure that you can authenticate. - -## OpenStack client documentation - -``` shell -openstack --help --os-cloud $CLOUD container $COMMAND - -openstack --help --os-cloud $CLOUD object $COMMAND -``` - -### Useful commands - -| commands | description | -|------------------|---------------------------------| -| container list | List containers | -| container set | Set container properties | -| container unset | Unset container properties | -| container show | Display container details | -| container create | Create new container | -| container save | Save container contents locally | -| container delete | Delete container | -| object list | List objects | -| object set | Set object properties | -| object unset | Unset object properties | -| object show | Display object details | -| object create | Upload object to container | -| object save | Save (download) object locally | -| object delete | Delete object from container | - -For a more detailed explanation of any specific command, add `--help`: - -``` shell -openstack --help --os-cloud $CLOUD object $COMMAND -``` - -!!! example - - ``` shell - $ openstack --help --os-cloud $CLOUD object list - - usage: openstack object list [-h] [-f {csv,df-to-csv,json,table,value,yaml}] - [-c COLUMN] [--format-config-file FORMAT_CONFIG] - [--quote {all,minimal,none,nonnumeric}] [--noindent] - [--max-width ] [--fit-width] [--print-empty] - [--sort-column SORT_COLUMN] [--sort-ascending | - --sort-descending] [--prefix ] - [--delimiter ] [--limit ] - [--marker ] [--end-marker ] [--long] - [--all] - - - List objects - - positional arguments: - Container to list - - options: - -h, --help show this help message and exit - --prefix - Filter list using - --delimiter - Roll up items with - --limit - The maximum number of entries to return. If the value exceeds the server- - defined maximum, then the maximum value will be used. - --marker - The first position in the collection to return results from. This should be a - value that was returned in a previous request. - --end-marker - End anchor for paging - --long List additional fields in output - --all List all objects in container (default is 10000) - ... (continues) - - ``` - -### Create an object container - -Create the container named "flex-container01": -``` shell -openstack --os-cloud $CLOUD container create flex-container01 -``` - -If you like, make the container public: - -!!! note - - Note that it's much simpler to create a public container than to attempt to set it public after it's created. - -However, you can use either the [swift client](storage-object-store-swift-cli.md), or the [skyline GUI](storage-object-store-skyline-gui.md) to accomplish this. - -``` shell -openstack --os-cloud $CLOUD container create --public flex-container01 -``` - -Verify the container's configuration: -``` shell -openstack --os-cloud $CLOUD container show flex-container01 -``` - -### Upload a file to the container - -Upload the entire contents of a folder to the container: -``` shell -openstack --os-cloud $CLOUD object create flex-container01 example/* -``` - -!!! example - - ``` shell - $ openstack --os-cloud $CLOUD object create flex-container01 example/* - +---------------------+------------------+------------------------------------+ - | obje | container | etag | - +---------------------+------------------+------------------------------------+ - | example/example.txt | flex-container01 | "f5222fe12bc675311e17201856a10219" | - +---------------------+------------------+------------------------------------+ - ``` - -Uploading an entire folder will add that prefix to your filenames inside the container. -``` shell -openstack --os-cloud $CLOUD object list flex-container01 -``` - -!!! example - - ``` shell - $ openstack --os-cloud $CLOUD object list flex-container01 - +---------------------+ - | Name | - +---------------------+ - | example.rtf | - | example/example.txt | - +---------------------+ - ``` - -Filter the display of files only with the prefix by using the `--prefix` argument: -``` shell -openstack --os-cloud $CLOUD object list flex-container01 --prefix example -``` - -!!! example - - ``` shell - $ openstack --os-cloud $CLOUD object list flex-container01 --prefix example - +---------------------+ - | Name | - +---------------------+ - | example/example.txt | - +---------------------+ - ``` - -### Downloading files -When the container is public, you can access each file using a specific URL, made up of your region's endpoint, the name of your container, the prefix (if any) of your object, and finally, the object name. -``` shell -/storage/container/detail/flex-container01/example.rtf -``` - -Download a single file from the container: -``` shell -openstack --os-cloud $CLOUD object save flex-container01 example.rtf -``` - -### Deleting containers or objects -``` shell -openstack --os-cloud $CLOUD object delete flex-container01 example.rtf -``` - -!!! example - - ``` shell - $ openstack --os-cloud $CLOUD object delete flex-container01 example.rtf - ``` - -Deleting a container: -``` shell -openstack --os-cloud $CLOUD container delete flex-container01 -``` - -!!! example - - ``` shell - $ openstack --os-cloud $CLOUD container delete flex-container01 - ``` - -If you need to delete a non-empty container, you'll need to issue the `--recursive` flag. Without this flag, the container must already be empty. - -!!! example - - ``` shell - $ openstack --os-cloud $CLOUD container --recursive delete flex-container01 - ``` - -### Setting and removing object expiration -At this time, setting and removing object expiration can be done using the the [swift client](storage-object-store-swift-cli.md). - -## Additional documentation - -Additional documentation can be found at the official openstack client site, on the Openstack Documentation Site.\ -https://docs.openstack.org/python-openstackclient/ussuri/cli/command-objects/container.html\ -https://docs.openstack.org/python-openstackclient/ussuri/cli/command-objects/object.html diff --git a/docs/storage-object-store-s3-cli.md b/docs/storage-object-store-s3-cli.md deleted file mode 100644 index 26441974c..000000000 --- a/docs/storage-object-store-s3-cli.md +++ /dev/null @@ -1,107 +0,0 @@ - -# Object Store Management using the S3 client - -## Goal - -Use the command-line utility `aws` to perform operations on your object store. - -!!! note - - Before getting started, generate credentials that will be used to authenticate the S3 API provided by OpenStack Flex Object Storage. - -## Install the `awscli` package - -Before we get started, we need to install the `awscli` package. You can install it using the following command: - -``` shell -pip install awscli awscli-plugin-endpoint -``` - -## Generate the S3 credentials - -The following credentials will be used to authenticate the S3 API provided by OpenStack Flex Object Storage. - -``` shell -openstack --os-cloud default ec2 credentials create -``` - -!!! example "The output should look similar to the following" - - ``` shell - +------------+---------------------------------------------------------------------------------------------------------+ - | Field | Value | - +------------+---------------------------------------------------------------------------------------------------------+ - | access | $ACCESS_ID | - | links | {'self': 'http://keystone.api.sjc3.rackspacecloud.com/v3/users/$USER_ID/credentials/OS-EC2/$ACCESS_ID'} | - | project_id | $PROJECT_ID | - | secret | $SECRET_VALUE | - | trust_id | None | - | user_id | $USER_ID | - +------------+---------------------------------------------------------------------------------------------------------+ - ``` - -## Create the AWS CLI Configuration Files - -Create an aws-config file. Be sure to replace `sjc3` with the region of your object store. - -!!! example "`~/aws-config` file" - - ``` conf - [plugins] - endpoint = awscli_plugin_endpoint - - [profile default] - region = sjc3 - s3 = - endpoint_url = https://swift.api.sjc3.rackspacecloud.com - signature_version = s3v4 - s3api = - endpoint_url = https://swift.api.sjc3.rackspacecloud.com - ``` - -Create an aws-credentials file. Be sure to replace `ACCESS` and `SECRET` with the values from the credential generation command. - -!!! example "`~/aws-credentials` file" - - ``` conf - [default] - aws_access_key_id = $ACCESS_ID - aws_secret_access_key = $SECRET_VALUE - ``` - -## Using the `aws` CLI and Validating the Configuration - -To validate the configuration, run the following command to create a `newbucket` in the object store. - -``` shell -aws --profile default s3api create-bucket --bucket newbucket -``` - -Ensure the new bucket exists by listing all buckets. - -``` shell -aws --profile default s3api list-buckets -``` - -!!! example "Output" - - ``` json - { - "Buckets": [ - { - "Name": "newbucket", - "CreationDate": "2009-02-03T16:45:09.000Z" - } - ], - "Owner": { - "DisplayName": "$USER_ID:$USER_NAME", - "ID": "$USER_ID:$USER_NAME" - }, - "Prefix": null - } - -For more information on the `awscli` tooling use the `help` flag for a detailed breakdown. - -``` shell -aws --profile default help -``` diff --git a/docs/storage-object-store-skyline-gui.md b/docs/storage-object-store-skyline-gui.md deleted file mode 100644 index 0caedb9c6..000000000 --- a/docs/storage-object-store-skyline-gui.md +++ /dev/null @@ -1,105 +0,0 @@ -# Object Store Management using the Skyline GUI - -## Goal - -Use the `Skyline` GUI to perform operations on your object store. - -## Prerequisites - -Ensure you have access to your OpenStack Skyline GUI. - -## Documentation - -### Create an object container - -Create the container named "flex-container01": - -- Navigate to Storage > Object Storage using the left-hand menu. -- Using the right-hand section, you can now click Create Container. - -![Skyline GUI NAV](assets/images/storage-object-store-skyline-gui-01-navigate.png){ align=left : style="filter:drop-shadow(#3c3c3c 0.5rem 0.5rem 10px);" } - -- Enter the name for your container in the resulting dialog box. Please note that the container name cannot be changed once created. If you need a different name, you'll need to create another container. If you'd like the container to be made Public, you can switch the slider on here. - -![Skyline GUI NAV](assets/images/storage-object-store-skyline-gui-02-create-dialog.png){ align=left : style="filter:drop-shadow(#3c3c3c 0.5rem 0.5rem 10px);" } - -- Click OK. - -![Skyline GUI NAV](assets/images/storage-object-store-skyline-gui-03-container-list.png){ align=left : style="filter:drop-shadow(#3c3c3c 0.5rem 0.5rem 10px);" } - -If you'd like to make the container public after it's created: - -- Navigate to Storage > Object Storage using the left-hand menu. -- Using the right-hand section, under the Action heading, click Update. -- Switch the slider on or off here. -- Click OK. - -View the container's detail: - -- Navigate to Storage > Object Storage using the left-hand menu. -- Using the right-hand section, under the Detail Info heading, click Detail Info. -- Click somewhere else on the page to dismiss the Detail Info box. - -### Upload a file to the container - -Upload a file to the container: - -- Navigate to Storage > Object Storage using the left-hand menu. -- Using the right-hand section, under the Name heading, click on your container's name. -- Click Upload File - -![Skyline GUI NAV](assets/images/storage-object-store-skyline-gui-04-in-container.png){ align=left : style="filter:drop-shadow(#3c3c3c 0.5rem 0.5rem 10px);" } - -- Using your file chooser, navigate and select a file. -- Click OK. Depending on the size of your file, you may see a progress bar, while your file is uploaded. - -![Skyline GUI NAV](assets/images/storage-object-store-skyline-gui-05-file-list.png){ align=left : style="filter:drop-shadow(#3c3c3c 0.5rem 0.5rem 10px);" } - -!!! Note - - Note that at this time, the Skyline GUI cannot upload entire folders. - -To accomplish this you can use either the [openstack client](storage-object-store-openstack-cli.md) or the [swift client](storage-object-store-swift-cli.md). - -### Downloading files -When the container is public, you can access each file using a specific URL, made up of your region's endpoint, the name of your container, the prefix (if any) of your object, and finally, the object name. -``` shell -/storage/container/detail/flex-container01/example.rtf -``` - -Download a single file from the container: - -- Navigate to Storage > Object Storage using the left-hand menu. -- Using the right-hand section, under the Name heading, click on your container's name. -- Locate the file you wish to download. -- On the far right, click More, then Download File. -- Click Confirm. - -### Deleting objects - -- Navigate to Storage > Object Storage using the left-hand menu. -- Using the right-hand section, under the Name heading, click on your container's name. -- Locate the file you wish to delete. -- Click Delete. -- Click Confirm. - -### Deleting a containers - -- Navigate to Storage > Object Storage using the left-hand menu. -- Using the right-hand section, locate the container you wish to delete. -- Click Delete. -- Click Confirm. - -!!! Note - - Note that at this time, the Skyline GUI cannot delete non-empty containers. - -To accomplish this you can use either the [openstack client](storage-object-store-openstack-cli.md) or the [swift client](storage-object-store-swift-cli.md). - -### Setting and removing object expiration -At this time, setting and removing object expiration can be done using the the [swift client](storage-object-store-swift-cli.md). - -## Additional documentation - -Additional documentation can be found at the official skyline site, on the Openstack Documentation Site.\ -https://wiki.openstack.org/wiki/Skyline diff --git a/docs/storage-object-store-swift-3rd-party.md b/docs/storage-object-store-swift-3rd-party.md deleted file mode 100644 index 9a1aa3af9..000000000 --- a/docs/storage-object-store-swift-3rd-party.md +++ /dev/null @@ -1,59 +0,0 @@ -# Swift 3rd party clients, SDK's and API - -## Openstack Swift SDK and Projects - -A complete list of SDKs, integrations and libraries can be found here [Swift Associated Projects](https://docs.openstack.org/swift/latest/associated_projects.html) - -## Getting started with S3 - -Using the openstack CLI issue the following command to generate a S3 token - -``` shell -openstack ec2 credentials create -``` - -To view all ec2 credentials use issue the following command: - -``` shell -openstack credential list -``` - -To view access and secret keys issue the following command: - -``` shell -openstack credential show -``` - -!!! note -credential-id is obtained from credentials list command - -## Using S3 boto3 - -S3 boto3 is a python library that can be imported into your python code to perform object tasks such as, uploading, deleting and reading objects from a Flex Object endpoint. - -Using the access and secret keys from the commands above you can start using Flex Object storage in your python application. An example of using S3 Boto3 in python can be found here: - -``` python -import boto3 -import botocore -boto3.set_stream_logger(name='botocore') # this enables debug tracing -session = boto3.session.Session() -s3_client = session.client( - service_name='s3', - aws_access_key_id='ACCESS', - aws_secret_access_key='SECRET', - endpoint_url='https://YOUR.ENDPOINT.HOST/', - # The next option is only required because my provider only offers "version 2" - # authentication protocol. Otherwise this would be 's3v4' (the default, version 4). - config=botocore.client.Config(signature_version='s3'), -) -s3_client.list_objects(Bucket='bucket_name') -``` - -More information on boto3 can be found here: [S3 Boto3 Reference](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/s3.html) - -## Rclone - -Rclone is a powerful sync tool, much like rsync, Rclone can sync local and remote containers and buckets. - -Setup is simple, download rclone from [Rclone Download](https://rclone.org/downloads/) Once downloaded configuration for Flex Object / Swift can be found here: [Rclone setup for Swift](https://rclone.org/swift/) diff --git a/docs/storage-object-store-swift-cli.md b/docs/storage-object-store-swift-cli.md deleted file mode 100644 index 88ff1070e..000000000 --- a/docs/storage-object-store-swift-cli.md +++ /dev/null @@ -1,235 +0,0 @@ -# Object Store Management using the Swift client - -## Goal - -Use the command-line utility `swift` to perform operations on your object store. - -## Swift client documentation - -``` shell -swift --help -``` - -### Useful commands - -| command | description | -|--------------|------------------------------------------------------------------------------------------------------------------------------------| -| list | Lists the containers for the account or the objects for a container. | -| capabilities | Retrieve capability of the proxy. | -| post | Updates meta information on the account, container, or object.
If the container is not found, it will be created automatically. | -| stat | Displays information for the account, container, or object. | -| upload | Uploads specified files and directories to the given container. | -| download | Download objects from containers. | -| tempurl | Generates a temporary URL for a Swift object. | -| delete | Delete a container or objects within a container. | - -For a more detailed explanation of any specific command, add `--help` after it: - -``` shell -swift list --help -``` - -!!! example - - ``` shell - $ swift list --help - - Usage: swift list [--long] [--lh] [--totals] [--prefix ] - [--delimiter ] [--header ] - [--versions] [] - - Lists the containers for the account or the objects for a container. - - Positional arguments: - [] Name of container to list object in. - - Optional arguments: - -l, --long Long listing format, similar to ls -l. - --lh Report sizes in human readable format similar to - ls -lh. - -t, --totals Used with -l or --lh, only report totals. - -p , --prefix - Only list items beginning with the prefix. - -d , --delimiter - Roll up items with the given delimiter. For containers - only. See OpenStack Swift API documentation for what - this means. - -j, --json Display listing information in json - --versions Display listing information for all versions - -H, --header - Adds a custom request header to use for listing. - ``` - -### Create an object container - -Create the container named "flex-container01": -``` shell -swift post flex-container01 -``` - -If you like, make the container public: -``` shell -swift post --header "X-Container-Read: .r:*" flex-container01 -``` - -Verify the container's configuration: -``` shell -swift stat flex-container01 -``` - -### Upload files to the container - -Upload the entire contents of a folder to the container: -``` shell -swift upload flex-container01 example-files/ -``` - -!!! example - - ``` shell - $ swift upload flex-container01 example-files/ - example-docs/readme.md - example-docs/image01.jpg - example-docs/image02.png - ``` - -Uploading an entire folder will add that prefix to your filenames inside the container. -``` shell -swift list flex-container01 -``` - -!!! example - - ``` shell - $ swift list flex-container01 - example-docs/readme.md - example-docs/image01.jpg - example-docs/image02.png - document01.rtf - document02.rtf - ``` - -Filter the display of files only with the prefix by using the `--prefix` argument: -``` shell -swift list flex-container01 --prefix example-docs -``` - -!!! example - - ``` shell - $ swift list flex-container01 --prefix example-docs - example-docs/readme.md - example-docs/image01.jpg - example-docs/image02.png - ``` - -### Downloading files -When the container is public, you can access each file using a specific URL, made up of your region's endpoint, the name of your container, the prefix (if any) of your object, and finally, the object name. -``` shell -/v1/AUTHxxx/flex-container01/example-docs/readme.md -``` - -Download a single file from the container: -``` shell -swift download flex-container01 document01.rtf -``` - -Using the swift client to download multiple files with the same prefix: -``` shell -swift download flex-container01 --prefix example-docs -``` - -### Deleting containers or objects -``` shell -swift delete flex-container01 document01.rtf -``` - -!!! example - - ``` shell - $ swift delete flex-container01 document01.rtf - document01.rtf - ``` - -Similar to downloading, you can delete multiple files with the same prefix: -``` shell -swift delete flex-container01 example-docs/* -``` - -!!! example - - ``` shell - $ swift delete flex-container01 example-docs/* - example-docs/readme.md - example-docs/image01.jpg - example-docs/image02.png - ``` - -Deleting a container: -``` shell -swift delete flex-container01 -``` - -!!! example - - ``` shell - $ swift delete flex-container01 - document01.rtf - document02.rtf - ``` - -Deleting a container will delete all files in the container. - -### Setting and removing object expiration -Swift objects can be scheduled to expire by setting either the `X-Delete-At` or `X-Delete-After` header. - -Once the object expires, swift will no longer serve the object, and it will be deleted. - -#### Expire at a specific time -Obtain the current Unix epoch timestamp by running `date +%s`. - -Set an object to expire at an absolute Unix epoch timestamp: -``` shell -swift post flex-container01 document01.rtf -H "X-Delete-At:UNIX_EPOCH_TIMESTAMP" -``` - -!!! example - - ``` shell - $ swift post flex-container01 document01.rtf -H "X-Delete-At:1711732649" - ``` - -Verify the header has been applied to the object: -``` shell -swift stat flex-container01 document01.rtf -``` - -#### Expire after a number of seconds -Set an object to expire after a relative amount of time, in seconds: -``` shell -swift post flex-container01 document01.rtf -H "X-Delete-After:SECONDS" -``` - -!!! example - - ``` shell - $ swift post flex-container01 document01.rtf -H "X-Delete-After:42" - ``` - -The `X-Delete-After` header will be converted to `X-Delete-At`. - -Verify the header has been applied to the object: -``` shell -swift stat flex-container01 document01.rtf -``` - -#### Remove the expire header -If you no longer want the object to expire, you can remove the `X-Delete-At` header: -``` shell -swift post flex-container01 document01.rtf -H "X-Delete-At:" -``` - -## Additional documentation - -Additional documentation can be found at the official swift client site, on the Openstack Documentation Site.\ -https://docs.openstack.org/python-openstackclient/latest/ diff --git a/docs/storage-overview.md b/docs/storage-overview.md deleted file mode 100644 index c4c7497f1..000000000 --- a/docs/storage-overview.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -hide: - - footer ---- - -# Persistent Storage Overview - -For the basic needs of our Kubernetes environment, we need some basic persistent storage. Storage, like anything good in life, -is a choose your own adventure ecosystem, so feel free to ignore this section if you have something else that satisfies the need. - -## Deploying Your Persistent Storage - -The basis needs of Genestack are the following storage classes - -| Storage Type | Description | -|--------------|-------------| -| general | A general storage cluster which is set as the deault | -| general-multi-attach | A multi-read/write storage backend | - -These `StorageClass` types are needed by various systems; however, how you get to these storage classes is totally up to you. -The following sections provide a means to manage storage and provide our needed `StorageClass` types. While there may be many -persistent storage options, not all of them are needed. - -| Backend Storage Options | -|----------------| -| [Cephadm/ceph-ansible/Rook (Ceph) - External](storage-ceph-rook-external.md) | -| [Rook (Ceph) - In Cluster](storage-ceph-rook-internal.md) | -| [External Block - Bring Your Own Storage](storage-external-block.md) | -| [NFS - External](storage-nfs-external.md) | -| [TopoLVM - In Cluster](storage-topolvm.md) | -| [Longhorn - In Cluster](storage-longhorn.md) | - -## Storage Deployment Demo - -[![asciicast](https://asciinema.org/a/629785.svg)](https://asciinema.org/a/629785) diff --git a/docs/storage-topolvm.md b/docs/storage-topolvm.md deleted file mode 100644 index 6772de4c1..000000000 --- a/docs/storage-topolvm.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -hide: - - footer ---- - -# TopoLVM - In Cluster - -[TopoLVM](https://github.com/topolvm/topolvm) is a capacity aware storage provisioner which can make use of physical volumes. - -The following steps are one way to set it up, however, consult the [documentation](https://github.com/topolvm/topolvm/blob/main/docs/getting-started.md) for a full breakdown of everything possible with TopoLVM. - -## Create the target volume group on your hosts - -TopoLVM requires access to a volume group on the physical host to work, which means we need to set up a volume group on our hosts. By default, TopoLVM will use the controllers as storage hosts. The genestack Helm solution sets the general storage volume group to `vg-general`. This value can be changed within Helm overrides file found at `/opt/genestack/base-helm-configs/topolvm/helm-topolvm-overrides.yaml`. - -!!! example "Simple example showing how to create the needed volume group" - - ``` shell - # NOTE sdX is a placeholder for a physical drive or partition. - pvcreate /dev/sdX - vgcreate vg-general /dev/sdX - ``` - -Once the volume group is on your storage nodes, the node is ready for use. - -### Deploy the TopoLVM Provisioner - -!!! example "Run the topolvm deployment Script bin/install-topolvm.sh" - - ``` shell - --8<-- "bin/install-topolvm.sh" - ``` diff --git a/docs/sync-fernet-keys.md b/docs/sync-fernet-keys.md deleted file mode 100644 index d1848ee34..000000000 --- a/docs/sync-fernet-keys.md +++ /dev/null @@ -1,176 +0,0 @@ -# Fernet Key Synchronization in Keystone - -## Overview -With Genestack's multi region support, administrators might want to run multiple keystone servcies that can all validate the user token. In order to -do this we can sync Fernet Keys between keystone nodes. Keystone uses fernet keys to generate tokens. These keys are rotated using the `keystone-manage` command to generate a new set of keys. -When the keys are rotated, the primary key is relegated to secondary, and a new primary key is issued. Secondary keys can only be used to decrypt tokens that were created with previous primary keys, and cannot issue new ones. - -Lets take a look at what each key type does: - -**Primary Key** is used to encrypt and decrypt tokens. There is only one primary key at any given moment. Primary key is delegated into secondary key. - -**Secondary Key** was at some point the primary but is not demoted to a secondary state. It can only decrypt tokens. - -**Staged Keys** is a special key staged to become the next primary. They can also decrypt tokens, and will become the next primary. - -In deployments where multiple Keystone instances exist, these keys need to be distributed across all instances to ensure consistent authentication. - -For **Genestack-based OpenStack** deployments, these keys can be distributed across multiple clusters by syncing the **Kubernetes Secret** that holds these keys. - -## Purpose -A deployment is created with python app that reads the primary key from one main Keystone deployment and synchronizes it to the same secret name across multiple Remote clusters. - -## Architecture - - -``` - / ──> API ──> | Remote K8s Cluster | - / - / - / -Main K8s Cluster | ──> API ──> | Remote K8s Cluster | - \ - \ - \ - \ ──> API ──> | Remote K8s Cluster | -``` - -## How It Works -1. The main Keystone cluster stores **Fernet keys** in a Kubernetes Secret. -2. The application retrieves the keys from the primary cluster. -3. The retrieved keys are synchronized to multiple remote clusters via the **Kubernetes API**. - -## How can we sync keys? -- Ensure that each cluster has the correct permissions to read and write Kubernetes Secrets. -- Use tools such as [External Secret](https://external-secrets.io/latest/api/pushsecret/) to sync the keystone-ferent-keys. -- Make sure to have service account token by reading the above secret. - -## Using PushSecret (external-secrets) to sync secrets - -Lets look at how we can setup pushsecrets to sync fernet keys between two or more clusters. -First, install external-secrets operator - -```shell -helm repo add external-secrets https://charts.external-secrets.io -helm install external-secrets external-secrets/external-secrets -n external-secrets --create-namespace -``` - -Now, in order for secrets to sync, we will use a serviceaccount token with access only to a particular secret. -So, in the target cluster create a new service account and give it appropriate permissions -``` -apiVersion: v1 -kind: ServiceAccount -metadata: - name: keystone-sync-external - namespace: openstack ---- -apiVersion: rbac.authorization.k8s.io/v1 -kind: Role -metadata: - namespace: openstack - name: keystone-sync-external-role -rules: - - apiGroups: [""] - resources: ["secrets"] - verbs: ["get", "list", "create", "update", "patch"] - resourceNames: ["keystone-fernet-keys"] ---- -apiVersion: rbac.authorization.k8s.io/v1 -kind: RoleBinding -metadata: - name: keystone-sync-external-rolebinding - namespace: openstack -subjects: - - kind: ServiceAccount - name: keystone-sync-external - namespace: openstack -roleRef: - kind: Role - name: keystone-sync-external-role - apiGroup: rbac.authorization.k8s.io -``` - -Here, we create a new role keystone-sync-external and bind it to role that allows access to our secret `keystone-fernet-keys` - -Next, create a new token associated with this account - -``` -apiVersion: v1 -kind: Secret -type: kubernetes.io/service-account-token -metadata: - name: keystone-sync-external-secret - annotations: - kubernetes.io/service-account.name: keystone-sync-external -``` - -then get the token assoicated with this by running - -``` -kubectl get secret keystone-sync-external-secret -o yaml -n openstack -``` - -next, on the source cluster create credentials for the target - -``` -apiVersion: v1 -kind: Secret -metadata: - name: target-credentials - namespace: openstack -data: - token: -``` - -next, create a secret store for pushsecret to use - -``` -apiVersion: external-secrets.io/v1beta1 -kind: SecretStore -metadata: - name: target-store - namespace: openstack -spec: - provider: - kubernetes: - remoteNamespace: openstack - server: - url: - caBundle: - auth: - token: - bearerToken: - name: target-credentials - key: token -``` - -Now, you can create a pushsecret to sync (any secret but in our case we have restricted to) keystone-fernet-keys. - -Lets create that pushsecret definition - -``` -apiVersion: external-secrets.io/v1alpha1 -kind: PushSecret -metadata: - name: pushsecret-target-store - namespace: openstack -spec: - # Replace existing secrets in provider - updatePolicy: Replace - # Resync interval - refreshInterval: 300s - # SecretStore to push secrets to - secretStoreRefs: - - name: target-store - kind: SecretStore - # Target Secret - selector: - secret: - name: keystone-fernet-keys # Source cluster Secret name - data: - - match: - remoteRef: - remoteKey: keystone-fernet-keys # Target cluster Secret name -``` - -This will sync keystone-fernet-keys from source to destination and refresh it every 300sec. diff --git a/docs/vault-secrets-operator.md b/docs/vault-secrets-operator.md deleted file mode 100644 index e95522116..000000000 --- a/docs/vault-secrets-operator.md +++ /dev/null @@ -1,175 +0,0 @@ -!!! Danger "This section is still underdevelopment and experimental" - - None of the vault components are required to run a Genestack environment. - -# HashiCorp Vault Secret Operators for Genestack Installation - -The Vault Secrets Operator (VSO) enables Pods to seamlessly consume Vault secrets from Kubernetes Secrets. This guide outlines the process of consuming secrets stored in Vault for Genestack installation. This is continuation of [vault.md](https://docs.rackspacecloud.com/vault/) where we have created few secrets in the Vault - -## Prerequisites - -!!! note - - Before starting the installation, ensure HashiCorp Vault is installed in the cluster. You can refer [vault.md](https://docs.rackspacecloud.com/vault/) for more details. - -## Installation - -Navigate to the Vault Secrets Operator base directory: - -``` shell -cd kustomize/vault-secrets-operator/base -``` - -Modify the `values.yaml` file with your desired configurations. Refer to the sample configuration in this directory, already updated for installation. - -``` shell -vi values.yaml -``` - -Perform the installation. - -``` shell -kubectl kustomize . --enable-helm | kubectl apply -f - -``` - -Validate if all the pods are up. -``` shell -kubectl get pods -n vault-secrets-operator -``` - -## Consume secrets from the Vault - -After installing the `vault-secrets-operator`, create the necessary resources to consume secrets stored in Vault. - -### Connect to the vault - -Create a `VaultConnection` resource to establish a connection to Vault. - -``` yaml -apiVersion: secrets.hashicorp.com/v1beta1 -kind: VaultConnection -metadata: -namespace: openstack -name: vault-connection -spec: -# required configuration -# address to the Vault server. -address: https://vault.vault.svc.cluster.local:8200 - -# optional configuration -# HTTP headers to be included in all Vault requests. -# headers: [] -# TLS server name to use as the SNI host for TLS connections. -# tlsServerName: "" -# skip TLS verification for TLS connections to Vault. -skipTLSVerify: false -# the trusted PEM encoded CA certificate chain stored in a Kubernetes Secret -caCertSecretRef: "vault-ca-secret" -``` - -`vault-ca-secret`: CA certificate used to sign the Vault certificate for internal communication. - -### Authenticate with vault: - -Create a `VaultAuth` resource to authenticate with Vault and access secrets. - -``` yaml -apiVersion: secrets.hashicorp.com/v1beta1 -kind: VaultAuth -metadata: -name: keystone-auth -namespace: openstack -spec: -method: kubernetes -mount: genestack -kubernetes: - role: osh - serviceAccount: default - audiences: - - vault -vaultConnectionRef: vault-connection -``` - -### Create Vault static: - -Define a `VaultStaticSecret` resource to fetch a secret from Vault and create a Kubernetes Secret resource. - -``` yaml -apiVersion: secrets.hashicorp.com/v1beta1 -kind: VaultStaticSecret -metadata: -name: keystone-rabbitmq-password -namespace: openstack -spec: -type: kv-v2 - -# mount path -mount: 'osh/keystone' - -# path of the secret -path: keystone-rabbitmq-password - -# dest k8s secret -destination: - name: keystone-rabbitmq-password - create: true - -# static secret refresh interval -refreshAfter: 30s - -# Name of the CRD to authenticate to Vault -vaultAuthRef: keystone-auth -``` - -This `VaultStaticSecret` resource fetches the `keystone-rabbitmq-password` secret from Vault and creates a Kubernetes Secret named `keystone-rabbitmq-password` in the openstack namespace which you can further use in the Genestack running on Kubernetes. - -!!! example "Example usage workflow" - - ``` shell - # From Vault: - vault kv get osh/keystone/keystone-rabbitmq-password - ================ Secret Path ================ - osh/keystone/data/keystone-rabbitmq-password - - ======= Metadata ======= - Key Value - --- ----- - created_time 2024-02-21T12:13:20.961200482Z - custom_metadata - deletion_time n/a - destroyed false - version 1 - - ====== Data ====== - Key Value - --- ----- - password EENF1SfKOVkILTGVzftJhdj5A6mwnbcCLgdttahhKsQVxCWHrIrhc0theCG3Tzrr - ``` - - Apply the reuired configuration files. - - ``` shell - # From Kubernetes: - kubectl apply -f vaultconnection.yaml - kubectl apply -f vault-auth.yaml - kubectl apply -f keystone-rabbitmq-password-vault.yaml - ``` - - Return the secret in YAML - - ``` shell - kubectl get secret keystone-rabbitmq-password -n openstack -o yaml - apiVersion: v1 - data: - _raw: eyJkYXRhIjp7InBhc3N3b3JkIjoiRUVORjFTZktPVmtJTFRHVnpmdEpoZGo1QTZtd25iY0NMZ2R0dGFoaEtzUVZ4Q1dIcklyaGMwdGhlQ0czVHpyciJ9LCJtZXRhZGF0YSI6eyJjcmVhdGVkX3 RpbWUiOiIyMDI0LTAyLTIxVDEyOjEzOjIwLjk2MTIwMDQ4MloiLCJjdXN0b21fbWV0YWRhdGEiOm51bGwsImRlbGV0aW9uX3RpbWUiOiIiLCJkZXN0cm95ZWQiOmZhbHNlLCJ2ZXJzaW9uIjox fX0= - password: RUVORjFTZktPVmtJTFRHVnpmdEpoZGo1QTZtd25iY0NMZ2R0dGFoaEtzUVZ4Q1dIcklyaGMwdGhlQ0czVHpycg== - kind: Secret - [...] - ``` - - Check the return password. - - ``` shell - echo "RUVORjFTZktPVmtJTFRHVnpmdEpoZGo1QTZtd25iY0NMZ2R0dGFoaEtzUVZ4Q1dIcklyaGMwdGhlQ0czVHpycg==" | base64 -d - EENF1SfKOVkILTGVzftJhdj5A6mwnbcCLgdttahhKsQVxCWHrIrhc0theCG3Tzrr - ``` diff --git a/docs/vault.md b/docs/vault.md deleted file mode 100644 index da46bc116..000000000 --- a/docs/vault.md +++ /dev/null @@ -1,196 +0,0 @@ -!!! Danger "This section is still underdevelopment and experimental" - - None of the vault components are required to run a Genestack environment. - -# HashiCorp Vault Setup for Genestack Installation - -HashiCorp Vault is a versatile tool designed for secret management and data protection. It allows you to securely store and control access to various sensitive data, such as tokens, passwords, certificates, and API keys. In this guide, we will use HashiCorp Vault to store Kubernetes Secrets for the Genestack installation. - -## Prerequisites - -Before starting the installation, ensure the following prerequisites are met: -- **Storage:** The Kubernetes Cluster should have available storage to create a PVC for data storage, especially when using integrated storage backend and storing audit logs. We will be using local storage located at /opt/vault on nodes labeled with `vault-storage: enabled`. Ensure that the nodes contain the `/opt/vault` directory. -- **Ingress Controller:** An Ingress Controller should be available as Vault's UI will be exposed using Ingress. -- **Sealed-secret:** If the Vault UI URL will use a domain certificate then, the Kubernetes secret should be deployed in the vault namespace. Make sure the secret manifest is encrypted using sealed-secret for secure storage in a Git repository. -- **Cert-Manager:** The installation will use end-to-end TLS generated using cert-manager. Hence, cert-manager should be available. - -## Installation - -``` shell -cd kustomize/vault/base -``` - -- Modify the `values.yaml` file with your desired configurations. Refer to the sample configuration in this directory, already updated for installation. - -``` shell -vi values.yaml -``` - -- Specify the size of the PV and the PVC(dataStorage and auditStorage) in `kustomization.yaml`. Since we are utilizing local storage from the nodes, consider this as a placeholder. Vault will be able to utilize the available storage based on the size of /opt/vault on the nodes. - -``` shell -vi kustomization.yaml -``` -- Perform the installation: - -``` shell -kubectl kustomize . --enable-helm | kubectl apply -f - -``` - -## Configure Vault - -After installing Vault, the Vault pods will initially be in a not-ready state. Initialization and unsealing are required. - -``` shell -NAME READY STATUS RESTARTS AGE -vault-0 0/1 Running 0 55s -vault-1 0/1 Running 0 55s -vault-2 0/1 Running 0 55s -vault-agent-injector-7f9f668fd5-wk7tm 1/1 Running 0 55s -``` - -### Initialize Vault - -``` shell -kubectl exec vault-0 -n vault -- vault operator init -key-shares=3 -key-threshold=2 -format=json > cluster-keys.json -``` - -This command provides unseal keys and a root token in cluster-keys.json. Keep this information secure. - - -### Unseal Vault(vault-0) - -On vault-0 pod, use any of the 2 unseal keys obtained during initialization: -``` shell -kubectl exec -it vault-0 -n vault -- vault operator unseal -``` -Repeat the unseal command as needed with different unseal keys. - -### Join Vault Pods to Form a Cluster - -``` shell -kubectl exec -it vault-1 -n vault -- vault operator raft join -leader-ca-cert=@/vault/userconfig/vault-server-tls/ca.crt https://vault-0.vault-internal:8200 -``` - -``` shell -kubectl exec -it vault-2 -n vault -- vault operator raft join -leader-ca-cert=@/vault/userconfig/vault-server-tls/ca.crt https://vault-0.vault-internal:8200 -``` - -### Unseal Vault(vault-1, vault-2) - -On each Vault pod (vault-1, vault-2), use any of the 2 unseal keys obtained during initialization: -``` shell -kubectl exec -it vault-1 -n vault -- vault operator unseal -``` -``` shell -kubectl exec -it vault-2 -n vault -- vault operator unseal -``` - -Repeat the unseal command as needed with different unseal keys. - -### Authenticate to Vault - -Use the root token obtained during initialization to authenticate: - -``` shell -kubectl exec -it vault-0 -n vault -- vault login -``` -### Enable audit logging -``` -kubectl exec -it vault-0 -n vault -- vault audit enable file file_path=/vault/audit/audit.log -``` - -## Validation - -Login to vault-0 and list the raft peers: - -``` shell -kubectl exec vault-0 -n vault -it -- vault operator raft list-peers -Node Address State Voter ----- ------- ----- ----- -vault-0 vault-0.vault-internal:8201 leader true -vault-1 vault-1.vault-internal:8201 follower true -vault-2 vault-2.vault-internal:8201 follower true -``` - ---- - -## Example to create secrets in Vault for Keystone: - -- Enable Kubernetes auth method: - -``` shell -kubectl exec --stdin=true --tty=true vault-0 -n vault -- vault auth enable -path genestack kubernetes -``` - -- Define Kubernetes connection: - -``` shell -kubectl exec --stdin=true --tty=true vault-0 -n vault -- sh -vault write auth/genestack/config kubernetes_host="https://$KUBERNETES_PORT_443_TCP_ADDR:443" -``` - -- Define secret path for keystone: - -``` shell -kubectl exec --stdin=true --tty=true vault-0 -n vault -- vault secrets enable -path=osh/keystone kv-v2 -``` - -- Create a policy to access `osh/*` path: - -``` shell -vault policy write osh - <- - Rackspace OpenStack Flex, a Rackspace solution, is open-source technologies that provide a - flexible, scalable, and cost-effective infrastructure solution for your business. This documentation provides - information on how to deploy and manage Open-Infrastructure in your environment. It also provides information on how - to onboard and manage your workloads on OpenStack, Kubernetes, and other open-source technologies. - -site_url: https://docs.rackspacecloud.com - -theme: - name: material - logo: assets/images/rackspace_logo-white.svg - favicon: assets/images/pngegg.png - icon: - logo: logo - palette: - - media: "(prefers-color-scheme)" - toggle: - icon: material/link - name: Switch to dark mode - - media: "(prefers-color-scheme: light)" - scheme: default - primary: black - accent: red - toggle: - icon: material/toggle-switch - name: Switch to dark mode - - media: "(prefers-color-scheme: dark)" - scheme: rxt - primary: black - accent: red - toggle: - icon: material/toggle-switch-off - name: Switch to system preference - - font: - text: Roboto - code: Roboto Mono - - features: - - announce.dismiss - - header.autohide - - content.action.edit - - content.action.view - - content.code.annotate - - content.code.copy - - content.tooltips - - navigation.footer - - navigation.indexes - - navigation.instant - - navigation.instant.progress - - navigation.instant.preview - - navigation.prune - - navigation.path - - navigation.sections - - navigation.tabs - - navigation.top - - navigation.tracking - - search.highlight - - search.share - - search.suggest - - toc.follow - -copyright: Copyright © 2024 RACKSPACE TECHNOLOGY - -extra: - social: - - icon: fontawesome/brands/linkedin - link: https://linkedin.com/company/rackspace - name: Rackspace on LinkedIn - - icon: fontawesome/brands/x-twitter - link: https://twitter.com/rackspace - name: Rackspace on X - - icon: fontawesome/brands/github - link: https://github.com/rackerlabs - name: Rackspace on github - - icon: fontawesome/brands/discord - link: https://discord.gg/2mN5yZvV3a - name: Rackspace on Discord - - icon: fontawesome/solid/blog - link: https://blog.rackspacecloud.com/ - -extra_css: - - overrides/stylesheets/adr.css - - overrides/stylesheets/admonition.css - -plugins: - - search - - swagger-ui-tag - - mkdocs-material-adr/adr - - glightbox - -markdown_extensions: - - admonition - - attr_list - - md_in_html - - def_list - - footnotes - - pymdownx.tasklist: - custom_checkbox: true - - pymdownx.superfences: - custom_fences: - - name: python - class: python - validator: !!python/name:markdown_exec.validator - format: !!python/name:markdown_exec.formatter - - name: mermaid - class: mermaid - format: !!python/name:pymdownx.superfences.fence_code_format - - pymdownx.emoji: - emoji_index: !!python/name:material.extensions.emoji.twemoji - emoji_generator: !!python/name:material.extensions.emoji.to_svg - - pymdownx.highlight: - anchor_linenums: true - line_spans: __span - pygments_lang_class: true - - pymdownx.inlinehilite - - pymdownx.details - - pymdownx.tabbed: - alternate_style: true - - pymdownx.snippets: - restrict_base_path: false - -repo_name: rackerlabs/genestack -repo_url: https://github.com/rackerlabs/genestack -dev_addr: "127.0.0.1:8001" -edit_uri: "edit/main/docs" - -nav: - - Welcome: index.md - - Overview: - - Architecture: genestack-architecture.md - - Components: genestack-components.md - - Swift Object Storage: openstack-object-storage-swift.md - - Release Notes: release-notes.md - - Design Guide: - - Introduction: openstack-cloud-design-intro.md - - SDLC: sdlc.md - - Cloud Design: - - Cloud Topology: openstack-cloud-design-topology.md - - Regions: openstack-cloud-design-regions.md - - Availability Zones: openstack-cloud-design-az.md - - Host Aggregates: openstack-cloud-design-ha.md - - Accelerated Computing: - - Overview: accelerated-computing-overview.md - - Infrastructure: accelerated-computing-infrastructure.md - - Other Design Documentation: - - Disaster Recovery for OpenStack Clouds: openstack-cloud-design-dr.md - - Genestack Infrastructure Design: openstack-cloud-design-genestack-infra.md - - Style Guide: documentation-standards.md - - Deployment Guide: - - What is Genestack?: deployment-guide-welcome.md - - Getting Started: - - Building Virtual Environments: build-test-envs.md - - Getting the code: genestack-getting-started.md - - Open Infrastructure: - - Kubernetes: - - k8s-overview.md - - Providers: - - Kubespray: k8s-kubespray.md - - Post Deployment: - - Kubernetes Labels: k8s-labels.md - - Kubernetes Dashboard: k8s-dashboard.md - - Kubernetes Taint: k8s-taint.md - - Plugins and Tools: k8s-tools.md - - Container Network Interface: - - Kube-OVN: k8s-cni-kube-ovn.md - - Retrieve kube config: k8s-config.md - - Prometheus: prometheus.md - - Storage: - - storage-overview.md - - Ceph Internal: storage-ceph-rook-internal.md - - Ceph External: storage-ceph-rook-external.md - - NFS External: storage-nfs-external.md - - TopoLVM: storage-topolvm.md - - External Storage CSI: storage-external-block.md - - Longhorn: storage-longhorn.md - - Infrastructure: - - infrastructure-overview.md - - Namespace: infrastructure-namespace.md - - MetalLB: infrastructure-metallb.md - - Gateway API: - - Gateway API Overview: infrastructure-gateway-api.md - - Envoy Gateway: infrastructure-envoy-gateway-api.md - - NGINX Gateway: infrastructure-nginx-gateway-api.md - - MariaDB: - - infrastructure-mariadb.md - - RabbitMQ: - - infrastructure-rabbitmq.md - - Memcached: infrastructure-memcached.md - - Libvirt: infrastructure-libvirt.md - - OVN: infrastructure-ovn-setup.md - - FluentBit: infrastructure-fluentbit.md - - Loki: infrastructure-loki.md - - Sealed Secrets: infrastructure-sealed-secrets.md - - OpenStack: - - openstack-overview.md - - OpenStack Services: - - Keystone: openstack-keystone.md - - Glance: openstack-glance.md - - Heat: openstack-heat.md - - Barbican: openstack-barbican.md - - Block Storage: - - Cinder: openstack-cinder.md - - LVM iSCSI: openstack-cinder-lvmisci.md - - NETAPP: - - Worker: openstack-cinder-netapp-worker.md - - Containerized: openstack-cinder-netapp-container.md - - FIPS Cinder Encryption: openstack-cinder-fips-encryption.md - - Compute Kit: - - Compute Overview: openstack-compute-kit.md - - Secrets: openstack-compute-kit-secrets.md - - Placement: openstack-compute-kit-placement.md - - Nova: openstack-compute-kit-nova.md - - Neutron: openstack-compute-kit-neutron.md - - Dashboards: - - Horizon: openstack-horizon.md - - skyline: openstack-skyline.md - - Octavia: openstack-octavia.md - - Magnum: openstack-magnum.md - - Metering: - - PostgreSQL: infrastructure-postgresql.md - - Gnocchi: openstack-gnocchi.md - - Ceilometer: openstack-ceilometer.md - - Monitoring: - - Monitoring Overview: prometheus-monitoring-overview.md - - Getting Started: monitoring-getting-started.md - - Grafana: grafana.md - - Kube-OVN Monitoring: prometheus-kube-ovn.md - - NGINX Gateway Fabric Monitoring: prometheus-nginx-gateway.md - - RabbitMQ Exporter: prometheus-rabbitmq-exporter.md - - Memcached Exporter: prometheus-memcached-exporter.md - - MariaDB Exporter: prometheus-mysql-exporter.md - - Postgres Exporter: prometheus-postgres-exporter.md - - Openstack Exporter: prometheus-openstack-metrics-exporter.md - - Blackbox Exporter: prometheus-blackbox-exporter.md - - Pushgateway: prometheus-pushgateway.md - - SNMP Exporter: prometheus-snmp-exporter.md - - Custom Node Metrics: prometheus-custom-node-metrics.md - - Alert Manager Examples: - - alertmanager-slack.md - - alertmanager-msteams.md - - alertmanager-pagerduty.md - - Operational Guide: - - Genestack: - - Supporting multi-region: multi-region-support.md - - Sync Keystone Fernet Keys: sync-fernet-keys.md - - Running Upgrades: genestack-upgrade.md - - Resource Metering: - - Metering Overview: metering-overview.md - - Ceilometer: metering-ceilometer.md - - Gnocchi: metering-gnocchi.md - - Billing Tenants: metering-billing.md - - Chargebacks: metering-chargebacks.md - - Infrastructure: - - Kubernetes: - - Etcd Backup: etcd-backup.md - - Adding New Nodes: adding-new-node.md - - Running Kubespray Upgrades: k8s-kubespray-upgrade.md - - OVN: - - Introduction: ovn-intro.md - - Troubleshooting: ovn-troubleshooting.md - - Traffic flow introduction: ovn-traffic-flow-intro.md - - Database Backup: infrastructure-ovn-db-backup.md - - Monitoring introduction: ovn-monitoring-introduction.md - - Claim Storm alert: ovn-alert-claim-storm.md - - Updating Kube OVN to OpenStack Configuration: ovn-kube-ovn-openstack.md - - Updating Kube OVN IP Space: infrastructure-kube-ovn-re-ip.md - - Updating Kube OVN to Helm: k8s-cni-kube-ovn-helm-conversion.md - - MariaDB: - - Operations: infrastructure-mariadb-ops.md - - Gateway API: - - NGINX Gateway: - - Custom Routes: infrastructure-nginx-gateway-api-custom.md - - Rackspace Example Gateway Overview: rackspace-infrastructure-nginx-gateway-api.md - - Creating self-signed CA issuer for Gateway API: infrastructure-nginx-gateway-api-ca-issuer.md - - Observability: - - Observability Overview: observability-info.md - - Monitoring Overview: monitoring-info.md - - Alerting Overview: alerting-info.md - - Logging Overview: genestack-logging.md - - OpenStack: - - CLI Access: - - Generating Clouds YAML: openstack-clouds.md - - Block Storage: - - Cinder Volume Provisioning Specs: openstack-cinder-volume-provisioning-specs.md - - Cinder Volume QoS Policies: openstack-cinder-volume-qos-policies.md - - Cinder Volume Type Specs: openstack-cinder-volume-type-specs.md - - Compute: - - Nova Flavor Creation: openstack-flavors.md - - Nova CPU Allocation Ratio: openstack-cpu-allocation-ratio.md - - Nova PCI Passthrough: openstack-pci-passthrough.md - - Host Aggregates: openstack-host-aggregates.md - - Instance Data Recovery: openstack-data-disk-recovery.md - - Quota Management: - - Quota Management: openstack-quota-managment.md - - Images: - - Glance Images Creation: openstack-glance-images.md - - Glance External Swift Image Store: openstack-glance-swift-store.md - - Identity: - - Keystone Federation to Rackspace: openstack-keystone-federation.md - - Keystone Readonly Users: openstack-keystone-readonly.md - - Networking: - - Creating Networks: openstack-neutron-networks.md - - Containers: - - Creating kubernetes clusters: magnum-kubernetes-cluster-setup-guide.md - - Loadbalancers: - - Creating Flavor Profiles and Flavors: octavia-flavor-and-flavorprofile-guide.md - - Creating Cloud Load Balancers: octavia-loadbalancer-setup-guide.md - - Object Storage: - - Operating Swift Object Storage: openstack-swift-operators-guide.md - - Override Public Endpoint fqdn for service catalog: openstack-override-public-endpoint-fqdn.md - - Service Overrides: openstack-service-overrides.md - - Resource and Project Lookups: openstack-resource-lookups.md - - Working locally With Docs: mkdocs-howto.md - - Cloud Onboarding: - - Cloud Onboarding Welcome: cloud-onboarding-welcome.md - - Openstack Installing CLI Tools: openstack-deploy-cli.md - - OpenStack Getting Started: openstack-getting-started-cli.md - - Openstack Security Groups: openstack-security-groups.md - - Openstack Floating Ips: openstack-floating-ips.md - - Openstack Keypairs: openstack-keypairs.md - - Openstack Servers: openstack-servers.md - - Openstack Routers: openstack-router.md - - Openstack Images: openstack-images.md - - Openstack Metrics: openstack-metrics.md - - Openstack Object Store: - - Openstack CLI: storage-object-store-openstack-cli.md - - Swift CLI: storage-object-store-swift-cli.md - - S3 CLI: storage-object-store-s3-cli.md - - Skyline GUI: storage-object-store-skyline-gui.md - - 3rd Party SDK, Tools: storage-object-store-swift-3rd-party.md - - Openstack Snapshot: openstack-snapshot.md - - Openstack Volumes: openstack-volumes.md - - Openstack Load Balancers: openstack-load-balancer.md - - Openstack Networks: openstack-networks.md - - Openstack Quotas: openstack-quota.md - - Security Primer: - - Introduction: security-introduction.md - - Security In Phases: security-lifecycle.md - - Cloud Security: security-stages.md - - Summary: security-summary.md - - Blog: https://blog.rackspacecloud.com/blog - - Regions: - - Availability: api-status.md - - SJC3: - - "": https://status.api.sjc3.rackspacecloud.com - - "Control Panel": https://skyline.api.sjc3.rackspacecloud.com - - DFW3: - - "": https://status.api.dfw3.rackspacecloud.com - - "Control Panel": https://skyline.api.dfw3.rackspacecloud.com diff --git a/outcomes/openstack.outcome b/outcomes/openstack.outcome new file mode 100644 index 000000000..aa7dc7e27 --- /dev/null +++ b/outcomes/openstack.outcome @@ -0,0 +1,3 @@ +# Stub file for the OpenStack outcome. We need to be able to define what openstack services and additional +# services to be installed here. Think, do we need a mariadb cluster, how to we create one using the operator +# here etc etc etc diff --git a/requirements.txt b/requirements.txt index 7a1538248..3317e2ac3 100644 --- a/requirements.txt +++ b/requirements.txt @@ -10,5 +10,3 @@ pbr==5.11.1 ruamel.yaml==0.18.6 ruamel.yaml.clib==0.2.8 kubernetes>=24.2.0 -openstacksdk>=1.0.0 -python-openstackclient==7.4.0 diff --git a/submodules/openstack-exporter b/submodules/openstack-exporter deleted file mode 160000 index fe6942189..000000000 --- a/submodules/openstack-exporter +++ /dev/null @@ -1 +0,0 @@ -Subproject commit fe6942189cbc5d836716235ff20e89f9d1dd5ed4 diff --git a/submodules/postgres-operator b/submodules/postgres-operator deleted file mode 160000 index 7c7aa9693..000000000 --- a/submodules/postgres-operator +++ /dev/null @@ -1 +0,0 @@ -Subproject commit 7c7aa969350bef67d0283d93589499ae3d114edb