4장. 기술 노트

이 장에서는 콘텐츠 전송 네트워크를 통해 제공되는 Red Hat OpenStack Platform "Queens" 에라타 권고의 추가 정보를 제공합니다.

4.1. RHEA-2018:2086 — Red Hat OpenStack Platform 13.0 강화 권고

이 섹션에 포함된 버그는 RHEA-2018:2086 권고에 의해 해결되었습니다. 이 권고에 대한 자세한 내용은 https://access.redhat.com/errata/RHEA-2018:2086 링크에서 확인하십시오.

ceph-ansible

ceph-ansible 유틸리티는 ceph-create-keys 컨테이너를 생성된 동일한 노드에서 항상 삭제하지 않습니다.

따라서 "Error response from daemon: No such container: ceph-create-keys." 메세지가 표시되고 배포에 실패할 수 있습니다. 이로 인해 다음의 새로운 배포가 포함된 ceph-ansible 실행에 영향을 줄 수 있습니다.
* 다중 compute 노드 또는
* ceph를 사용하는 서비스를 호스팅하는 ceph 클라이언트로 동작하는 사용자 지정 역할

gnocchi

openstack-gnocchi 패키지 이름이 gnocchi로 변경되었습니다. openstack- 접두사는 업스트림 프로젝트 범위 변경으로 인해 삭제되었습니다. Gnocchi는 OpenStack의 산하에서 벗어나 독립형 프로젝트로 유지됩니다.

opendaylight

유동 IP를 인스턴스에 연결한 다음 유동 IP 연결을 해제하는 경우 외부 IP에 대한 연결에 오류가 발생합니다. 이 상황은 다음의 경우 테넌트 VLAN 네트워크에서 발생합니다.
* 비 NAPT 스위치에서 생성된 VM이 유동 IP와 연결된 경우
* 유동 IP가 삭제된 경우
이를 통해 NAPT 스위치의 FIB 테이블에서 누락된 흐름이 (산발적으로) 발생합니다. 

누락된 FIB 테이블 항목 때문에 VM에서는 공용 네트워크에 대한 연결이 손실됩니다.

유동 IP를 VM에 연결하면 공용 네트워크에 대한 연결을 복원합니다. 유동 IP가 VM에 연결되는 있는 한 인터넷에 연결할 수 있지만 외부 네트워크의 공용 IP/유동 IP가 손실됩니다.

openstack-cinder

이전에는 롤링 업그레이드 메커니즘 때문에 오프라인으로 업그레이드할 때 cinder 서비스를 두 번 다시 시작해야 했습니다.

"--bump-versions"라는 새로운 선택 매개 변수를 cinder-manage db sync 명령에 추가하여 두 시스템 재부팅을 건너뛸 수 있습니다.
Block Storage Service(cinder)는 동기화 잠금을 사용하여 볼륨 이미지 캐시의 항목이 중복되는 것을 방지합니다. 하지만 이러한 유형의 잠금은 범위가 광범위하므로 이미지 캐시가 활성화되지 않은 경우에도 이미지에서 볼륨 생성 요청이 동시에 발생하면 잠금 작업을 위해 경쟁할 수 있습니다. 

이미지에서 볼륨을 생성하는 동시 요청은 연속적으로 실행되며 동시에 실행되지 않습니다.

이를 해결하기 위해 동기화 잠금은 잠금 범위를 최소화하고 볼륨 이미지 캐시가 활성화된 경우에만 적용되도록 업데이트되었습니다.

이번 릴리스에서는 이미지에서 볼륨 생성 동시 요청은 볼륨 이미지 캐시가 비활성화된 경우 동시에 실행됩니다. 볼륨 이미지 캐시가 활성화되면 단일 항목만 캐시에서 생성되도록 잠금을 최소화할 수 있습니다.

openstack-manila

Shared File System 서비스(manila)는 이제 NetApp ONTAP cDOT 드라이버가 포함된 IPv6 액세스 규칙을 지원하여 IPv6 환경으로 manila를 사용할 수 있습니다.

따라서 Shared File System 서비스는 이제 IPv6 네트워크에서 NetApp ONTAP 백엔드가 지원하는 내보내기 공유를 지원합니다. 내보내기된 공유에 대한 액세스는 IPv6 클라이언트 주소에서 제어됩니다.
Shared File System 서비스(manila)는 NFSv4 프로토콜을 통해 CephFS(Ceph File System)에서 지원하는 공유 파일 시스템 마운트를 지원합니다. 컨트롤러 노드에서 실행되는 NFS-Ganesha 서버는 CephFS를 고가용성(HA)의 테넌트로 내보내는 데 사용됩니다. 테넌트는 서로 격리되며 제공된 NFS 게이트웨이 인터페이스를 통해서만 CephFS에 액세스할 수 있습니다. 이 새로운 기능은 director에 모두 통합되어 CephFS 백엔드 배포 및 Shared File System 서비스의 설정을 가능하게 합니다.

openstack-neutron

라우터에서 인터페이스를 추가하거나 삭제할 때 격리된 메타데이터가 DHCP 에이전트에서 활성화되는 경우 해당 네트워크에 대한 메타데이터 프록시는 업데이트되지 않습니다.

이와 같이 인스턴스가 라우터에 연결되지 않은 네트워크에 있다면 메타데이터를 가져올 수 없습니다.

라우터 인터페이스가 추가되거나 삭제되면 메타데이터 프록시를 업데이트해야 합니다. 그러면 인스턴스는 사용하는 네트워크가 격리된 경우 DHCP 네임스페이스에서 메타데이터를 가져올 수 있게 됩니다.

openstack-selinux

이전 릴리스에서는 게스트 가상 머신이 시작되면 virtlogd 서비스가 중복 AVC 거부 오류를 기록했습니다. 이번 업데이트를 통해 virtlogd 서비스는 더 이상 systemd에 종료 비활성화 호출을 전송하지 않으므로 위의 오류가 더 이상 발생하지 않습니다.

openstack-swift

Object Store 서비스(swift)는 이제 Barbican과 통합하여 저장된(미사용) 개체를 투명하게 암호화하고 해독할 수 있습니다. 미사용 암호화는 전송중인 암호화와는 다르며 디스크에 저장되는 동안 암호화되는 개체를 참조합니다.

Swift 개체는 디스크에서 일반 텍스트로 저장됩니다. 이러한 디스크는 라이프 사이클 종료에 도달했을 때 적절히 폐기되지 않으면 보안 위험을 발생시킬 수 있습니다. 개체 암호화는 이러한 위험을 완화합니다.

Swift는 swift에 업로드 시 자동으로 암호화되고 사용자에게 제공 시 자동으로 해독되는 개체를 사용하여 암호화 작업을 투명하게 수행합니다. 이 암호화 및 해독은 Barbican에 저장되는 동일한(symmetric) 키를 사용하여 처리됩니다.

openstack-tripleo-common

Octavia는 "service" 프로젝트에 설정된 기본 쿼터가 오버클라우드에서 생성될 수 있는 Octavia 로드 밸런서의 개수를 제한하므로 실제 워크로드로 확장되지 않습니다.

이 문제를 해결하려면 오버클라우드 admin 사용자로서 필요한 쿼터를 무제한 또는 충분히 큰 값으로 설정합니다. 예를 들어 언더클라우드에서 다음 명령을 실행합니다.

# source ~/overcloudrc
#  openstack quota set --cores -1 --ram -1 --ports -1 --instances -1 --secgroups -1 service
tripleo.plan_management.v1.update_roles 워크플로는 오버클라우드 계획 이름(swift 컨테이너 이름) 또는 zaqar 대기열 이름을 트리거된 하위 워크플로에 전달할 수 없습니다. 이로 인해 기본값('overcloud')이 아닌 오버클라우드 계획 이름을 사용하면 잘못된 동작이 발생했습니다. 이번 수정을 통해 이러한 매개 변수를 올바르게 전달하고 올바른 동작을 복구합니다.
'docker kill' 명령은 컨테이너가 자동으로 다시 시작하도록 설정된 경우 종료되지 않습니다. 사용자가 'docker kill <container>'를 시도하면 무기한으로 중단될 수 있습니다. 이 경우 CTRL+C로 명령을 중지합니다.

이 문제를 해결하려면 'docker stop'('docker kill' 대신)을 사용하여 컨테이너화된 서비스를 중지합니다.
원인: "openstack overcloud node configure" 명령은 "deploy-kernel" 및 "deploy-ramdisk" 매개 변수에 대해 이미지 ID가 아닌 이미지 이름만 가져옵니다. 이번 수정 후 이미지 ID가 허용됩니다.

openstack-tripleo-heat-templates

이번 기능 개선으로 "regular" compute 노드를 통해 director에서 compute 노드가 활성화된 RT 배포를 추가 지원합니다.

1. tripleo-heat-templates/environments/compute-real-time-example.yaml을 기반으로 compute-real-time.yaml 환경 파일을 생성합니다. 이 파일은ComputeRealTime 역할의 매개 변수 중 최소한 다음 매개 변수를 올바른 값으로 설정합니다.

 * IsolCpusList 및 NovaVcpuPinSet: 실시간 워크로드에 대해 예약되어야 하는 CPU 코어의 목록입니다. 이는 실시간 compute 노드에 있는 CPU 하드웨어에 따라 달라집니다.

 * KernelArgs: "default_hugepagesz=1G hugepagesz=1G hugepages=X"로 설정합니다.  X는 게스트 수 및 예약할 메모리 양에 따라 달라집니다. 

2. overcloud-realtime-compute 이미지를 빌드하고 업로드합니다.

 * 리포지토리 준비(CentOS용):
   - sudo yum install -y https://trunk.rdoproject.org/centos7/current/python2-tripleo-repos-XXX.el7.centos.noarch.rpm
   - sudo -E tripleo-repos current-tripleo-dev
   - export DIB_YUM_REPO_CONF="/etc/yum.repos.d/delorean* /etc/yum.repos.d/quickstart*"

 * openstack overcloud image build --image-name overcloud-realtime-compute --config-file /usr/share/openstack-tripleo-common/image-yaml/overcloud-realtime-compute.yaml --config-file /usr/share/openstack-tripleo-common/image-yaml/overcloud-realtime-compute-centos7.yaml

 * openstack overcloud image upload --update-existing --os-image-name overcloud-realtime-compute.qcow2

3. ComputeRealTime 및 다른 모든 필수 역할로 roles_data.yaml을 생성하고(예: openstack overcloud roles generate -o ~/rt_roles_data.yaml Controller ComputeRealTime ...) ComputeRealTime 역할을 일반적인 방법의 하나로 실시간 노드에 할당합니다. https://docs.openstack.org/tripleo-docs/latest/install/advanced_deployment/custom_roles.html을 참조하십시오.

4. 오버클라우드를 배포합니다.
openstack overcloud deploy --templates -r ~/rt_roles_data.yaml -e ./tripleo-heat-templates/environments/host-config-and-reboot.yaml -e ./compute-real-time.yaml [...]
HA 설정에서 glance-direct 방식을 사용 시 공유 준비 영역이 필요합니다. 일반 준비 영역이 없으면 HA 환경에서 'glance-direct' 방식을 사용한 이미지 업로드가 실패할 수 있습니다. 컨트롤러 노드에서 수신하는 요청은 사용 가능한 컨트롤러 노드에 배포됩니다. 하나의 컨트롤러가 첫 번째 단계를 처리하며 다른 컨트롤러는 이미지를 다른 준비 영역에 작성하는 컨트롤러를 모두 사용하여 두 번째 요청을 처리합니다. 두 번째 컨트롤러에는 첫 번째 단계를 처리하는 컨트롤러가 사용하는 동일한 준비 영역에 대한 액세스 권한이 없습니다.

Glance는 'glance-direct' 방식을 포함한 다중 이미지 가져오기 방식을 지원합니다. 이 방식은 3단계 방식을 사용합니다(이미지 레코드 생성, 준비 영역에 이미지 업로드, 이미지를 사용할 수 있도록 준비 영역에서 스토리지 백엔드로 이미지 전송). HA 설정에서(예: 3개의 컨트롤러 노드 사용) glance-direct 방식은 컨트롤러 노드 전반에 공유 파일 시스템을 사용하는 일반 준비 영역이 필요합니다.

활성화된 Glance 가져오기 방식 목록을 이제 설정할 수 있습니다. 기본 설정은 'glance-direct' 방식을 활성화하지 않습니다 (웹 다운로드는 기본적으로 활성화됨). 이 문제를 해결하여 HA 환경에서 이미지를 Glance에 안정적으로 가져오려면 'glance-direct' 방식을 활성화하지 마십시오.
openvswitch systemd 스크립트는 호스트에서 정지 시 /run/openvswitch 폴더를 삭제합니다.
ovn-controller 컨테이너 내 /run/openvswitch 경로는 이전 디렉토리입니다. 서비스를 다시 시작하는 경우 폴더를 다시 생성합니다. ovn-controller에서 이 폴더로 다시 액세스하려면 폴더를 다시 마운트하거나 ovn-controller 컨테이너를 다시 시작해야 합니다.
Cinder 용 RBD 백엔드로 사용하는 Ceph 풀 목록을 지정하는 새로운 CinderRbdExtraPools Heat 매개 변수가 추가되었습니다. 추가 Cinder RBD 백엔드 드라이버는 목록에서 각 풀에 대해 생성됩니다. 이는 CinderRbdPoolName과 연결된 표준 RBD 백엔드 드라이버에 추가됩니다. 새로운 매개 변수는 선택 사항이며 기본적으로 빈 목록입니다. 모든 풀은 단일 Ceph 클러스터와 연결됩니다.
Redis는 TLS를 활성화된 HA 배포 노드에서 데이터를 올바르게 복제할 수 없습니다. Redis 팔로워 노드는 리더 노드의 데이터를 포함하지 않습니다. Redis 배포에 대해 TLS를 비활성화하는 것이 좋습니다.
이번 개선 사항으로 매트릭스 데이터를 Gnocchi DB 인스턴스에 보내는 기능을 추가 지원합니다.

collectd 구성 가능한 서비스에 대해 다음의 새 매개 변수가 추가되었습니다. CollectdGnocchiAuthMode가 'simple'로 설정되면 CollectdGnocchiProtocol, CollectdGnocchiServer, CollectdGnocchiPort 및 CollectdGnocchiUser가 설정에 고려됩니다.

CollectdGnocchiAuthMode가 'keystone'으로 설정되면 CollectdGnocchiKeystone* 매개 변수가 설정에 고려됩니다.

다음은 추가된 매개 변수에 대한 자세한 설명입니다.

  CollectdGnocchiAuthMode:
    유형: 문자열
    설명: >
      Gnocchi 서버가 사용하는 인증 유형입니다. 지원되는 값은
      'simple' 및 'keystone'입니다.
    기본값: 'simple'
  CollectdGnocchiProtocol:
    유형: 문자열
    설명:  Gnocchi 서버가 사용하는 API 프로토콜입니다.
    기본값: 'http'
  CollectdGnocchiServer:
    유형: 문자열
    설명: >
    매트릭스를 보내야 하는 gnocchi 엔드포인트의 이름 또는 주소입니다.
    기본값: nil
  CollectdGnocchiPort:
    유형: 숫자
    설명: Gnocchi 서버에서 연결할 포트입니다.
    기본값: 8041
  CollectdGnocchiUser:
    유형: 문자열
    설명: >
      simple 인증을 사용하여 원격 Gnocchi 서버에 인증을 위한 사용자 이름입니다.
    기본값: nil
  CollectdGnocchiKeystoneAuthUrl:
    유형: 문자열
    설명: 인증할 Keystone 엔드포인트 URL입니다.
    기본값: nil
  CollectdGnocchiKeystoneUserName:
    유형: 문자열
    설명: Keystone에 대해 인증을 위한 사용자 이름입니다.
    기본값: nil
  CollectdGnocchiKeystoneUserId:
    유형: 문자열
    설명: Keystone에 대해 인증을 위한 사용자 ID입니다.
    기본값: nil
  CollectdGnocchiKeystonePassword:
    유형: 문자열
    설명: Keystone에 대해 인증을 위한 암호입니다.
    기본값: nil
  CollectdGnocchiKeystoneProjectId:
    유형: 문자열
    설명: Keystone에 대해 인증을 위한 프로젝트 ID입니다.
    기본값: nil
  CollectdGnocchiKeystoneProjectName:
    유형: 문자열
    설명: Keystone에 대해 인증을 위한 프로젝트 이름입니다.
    기본값: nil
  CollectdGnocchiKeystoneUserDomainId:
   유형: 문자열
   설명: Keystone에 대해 인증을 위한 사용자 도메인 ID입니다.
   기본값: nil
  CollectdGnocchiKeystoneUserDomainName:
    유형: 문자열
    설명: Keystone에 대해 인증을 위한 사용자 도메인 이름입니다.
    기본값: nil
  CollectdGnocchiKeystoneProjectDomainId:
    유형: 문자열
    설명: Keystone에 대해 인증을 위한 프로젝트 도메인 ID입니다.
    기본값: nil
  CollectdGnocchiKeystoneProjectDomainName:
    유형: 문자열
    설명: Keystone에 대해 인증을 위한 프로젝트 도메인 이름입니다.
    기본값: nil
  CollectdGnocchiKeystoneRegionName:
    유형: 문자열
    설명: Keystone에 대해 인증을 위한 지역 이름입니다.
    기본값: nil
  CollectdGnocchiKeystoneInterface:
    유형: 문자열
    설명: 인증할 Keystone 엔드포인트의 유형입니다.
    기본값: nil
  CollectdGnocchiKeystoneEndpoint:
    유형: 문자열
    설명: >
     Keystone 값을 덮어쓰기하려는 경우 명백하게 Gnocchi 서버 URL을 지정합니다.
    기본값: nil
  CollectdGnocchiResourceType:
    유형: 문자열  
    설명: >
      호스트를 저장하기 위해 Gnocchi에서 collectd-gnocchi 플러그인으로 생성된 기본 리소스 유형입니다.
    기본값: 'collectd'
  CollectdGnocchiBatchSize:
    유형: 숫자
    설명: Gnocchi에서 일괄 처리해야 하는 값의 최소 개수입니다.
   기본값: 10
OVN 메타데이터 서비스는 DVR 기반 환경에 배포되지 않았습니다. 따라서 인스턴스는 인스턴스 이름, 공개 키 등의 메타데이터를 가져올 수 없었습니다.

이 패치는 부팅된 인스턴스가 메타데이터를 가져오도록 위의 서비스를 활성화합니다.
Cinder 백엔드 서비스의 Heat 템플릿은 서비스가 컨테이너에 배포되어야 하는지 여부와 상관없이 Puppet을 트리거하고 오버클라우드 호스트에 cinder-volume 서비스를 배포하도록 했습니다. 이로 인해 cinder-volume 서비스가 컨테이너와 호스트에 두 번 배포되었습니다.

이 때문에 호스트에서 실행 중인 독자적인 cinder-volume 서비스에서 작업을 처리한 경우 OpenStack 볼륨 작업(볼륨 생성 및 연결)이 일반적으로 실패할 수도 있었습니다.

문제 해결을 위해 Cinder 백엔드 heat 템플릿은 cinder-volume 서비스의 두 번째 인스턴스를 배포하지 않도록 업데이트되었습니다.
Gnocchi 백엔드로 성능이 낮은 Swift 클러스터가 사용되면 collectd 로그에서 503 오류를 생성하고 gnocchi-metricd.conf에서 "ConnectionError: ('Connection aborted.', CannotSendRequest())" 오류를 출력할 수 있습니다.
이 문제를 해결하려면 CollectdDefaultPollingInterval 매개 변수의 값을 증가시키거나 Swift 클러스터 성능을 개선합니다.
ceph-ansible의 복잡한 ceph-key 작업을 변경하면 /etc/ceph/ceph.client.manila.keyring 파일에서 잘못된 콘텐츠를 생성하므로 manila-share 서비스가 초기화에 실패합니다.

manila-share 서비스 초기화를 허용하려면 다음을 수행합니다.
1) 오버클라우드 배포에 사용할 /usr/share/openstack/tripleo-heat-templates의 사본을 만듭니다.

2) 295행에서 모든 삼중 백슬래시를 단일 백슬래시로 변경하도록 .../tripleo-heat-templates/docker/services/ceph-ansible/ceph-base.yaml 파일을 편집합니다.
편집 전:
mon_cap: 'allow r, allow command \\\"auth del\\\", allow command \\\"auth caps\\\", allow command \\\"auth get\\\", allow command \\\"auth get-or-create\\\"'
편집 후:
mon_cap: 'allow r, allow command \"auth del\", allow command \"auth caps\", allow command \"auth get\", allow command \"auth get-or-create\"'

3) /usr/share/openstack-tripleo-heat 템플릿이 기존 overcloud-deploy 명령에서 발생하는 위치마다 tripleo-heat-templates의 사본에 대한 경로를 대체하는 오버클라우드를 배포합니다.

ceph 키 /etc/ceph/ceph.client.manila.keyring 파일에는 알맞은 콘텐츠가 있으며 manila-share 서비스는 적절히 초기화됩니다.
HA 용으로 cinder-volume 서비스를 구성할 때 cinder의 DEFAULT/host 설정이 "hostgroup"으로 설정되었습니다. 다른 cinder 서비스 (cinder-api, cinder-scheduler, cinder-backup)는 서비스를 실행하는 오버클라우드 노드와 상관없이 설정에 "hostgroup"을 사용했습니다. 이러한 서비스의 로그 메시지는 모두 동일한 "hostgroup" 호스트에서 시작된 것 같이 표시되어 메시지를 생성한 노드를 판단하기가 어려웠습니다. 

HA를 배포할 때 cinder-volume의 backend_host는 DEFAULT/host를 해당 값으로 설정하는 대신 "hostgroup"으로 설정합니다. 이렇게 하면 각 노드의 DEFAULT/host 값이 고유한지 확인할 수 있습니다.

결과적으로 cinder-api, cinder-scheduler 및 cinder-backup의 로그 메시지는 메시지를 생성한 노드와 올바르게 연결됩니다.
새 릴리스로 업그레이드한 후 Block Storage Service(cinder)는 이전 릴리스에서 이전 RPC 버전을 사용하면 중단되었습니다. 이 때문에 최신 RPC 버전이 있어야 하는 모든 cinder API 요청은 실패했습니다.

새 릴리스로 업그레이드하는 경우 모든 cinder RPC 버전은 최신 릴리스와 일치하도록 업데이트됩니다.

python-cryptography

버전 2.1부터 python-cryptography는 인증서에 사용된 CNS 이름이 IDN 표준에 부합하는지 확인합니다. 검색된 이름이 이 사양을 따르지 않는 경우 cryptography는 인증서를 검증할 수 없게 되며 OpenStack 명령줄 인터페이스를 사용하는 경우 또는 OpenStack 서비스 로그에서 다른 오류가 발견될 수 있습니다.
python-cryptography 빌드를 설치한 후 Obsoletes의 누락으로 인해 RDO에서 초기에 가져오기를 실행할 때 실패했습니다.  이 패키지의 RHEL 7 빌드는 적합한 Obsoletes 항목이 있습니다.

이번 수정에서 python-cryptography에 Obsoletes가 추가되었습니다.

python-ironic-tests-tempest

업그레이드 전에 설치된 tempest 플러그인(-tests) rpm은 OSP Release 13 업그레이드 이후에 실패합니다. 초기 업그레이드 패키징에는 이전 rpm을 사용하지 않는 데 필요한 epoch 명령이 포함되지 않았습니다. sub-rpm은 OSP 13에 탑재되어 있지 않으며 새 플러그인 rpm의 Obsoletes는 적절한 rpm을 올바르게 폐기 처리하지 못했습니다.

이 문제를 해결하려면 Obsoletes를 수정하거나 이전 -rpm을 수동으로 설치 제거하고 교체 플러그인 python2-*-tests-tempest를 수동으로 설치합니다.

python-networking-ovn

Neutron과 OVN 데이터베이스 간 일관성을 유지하기 위해 변경된 설정 내용이 내부에서 비교되며 백엔드에서 확인됩니다. 각 설정 변경에는 개정 번호가 할당되며 스케줄링된 작업은 데이터베이스에 추가된 모든 생성, 업데이트 및 삭제 작업을 확인합니다.
이 버전은 networking-ovn에서 내부 DNS 변환을 지원합니다. 두 개의 알려진 제한이 있으며
하나는 내부 DNS를 통해 내부 FQDN 요청이 제대로 해결되지 않는 bz#1581332입니다.

GA 릴리스에서 tripleo는 기본적으로 이러한 확장 기능이 설정되지 않습니다. bz#1577592에서 해결 방법을 참조하십시오.
게이트웨이 없이 서브넷이 생성되는 경우 DHCP 옵션이 추가되지 않으며 이러한 서브넷의 인스턴스는 DHCP를 가져올 수 없습니다.

인스턴스가 IP 주소를 가져오도록 Metadata/DHCP 포트가 이 작업에 사용됩니다. 메타데이터 서비스를 활성화해야 합니다.
서브넷의 인스턴스는 이제 외부 게이트웨이 없이 OVN Metadata/DHCP 포트를 통해 DHCP에서 IP 주소를 가져올 수 있습니다.
현재 L3 HA 스케줄러는 노드의 우선순위를 고려하고 있지 않습니다. 따라서 모든 게이트웨이는 동일한 노드에서 호스트되며 로드는 후보 노드에 배분되지 않았습니다.

이 수정은 게이트웨이 라우터를 스케줄링할 때 가장 적게 로드된 노드를 선택하도록 알고리즘을 구현합니다. 이제 시스템은 가장 적게 로드된 네트워크 노드에 스케줄링되어 게이트웨이 포트는 노드간 로드를 균등하게 배분합니다.
하위 포트가 다른 하이퍼바이저의 다른 트렁크에 다시 할당된 경우 업데이트된 바인딩 정보를 가져오지 않으며 하위 포트가 ACTIVE로 전환되지 않았습니다.

이번 수정에서는 하위 포트가 트렁크에서 삭제되는 경우 바인딩 정보를 삭제합니다. 이제 하위 포트는 다른 하이퍼바이저에 있는 다른 트렁크에 다시 할당되는 경우 ACTIVE로 전환됩니다.

python-os-brick

iSCSI 검색을 사용하는 경우 노드 시작 설정이 "automatic"에서 "default"로 설정되어 재부팅 시 서비스가 시작되지 않았습니다. 이 문제는 각 검색 후 모든 시작 값을 복구하여 수정됩니다.

python-zaqar-tests-tempest

Queens 주기 동안 tempest 플러그인의 컬렉션이 openstack-*-tests rpm 하위 패키지에서 추출되었으므로 업그레이드에 종속성 문제가 있었습니다. 그러나 모든 패키징이 Provides 및 Obsoletes를 적합하게 결합한 것은 아닙니다. OSP 13에는 -tests(unittest sub-rpms)가 없습니다.

이전 릴리스에서 설치된 -tests로 업그레이드를 시도하는 경우 종속성 문제로 인해 업그레이드에 실패합니다.

이 문제를 해결하기 위해 추출되었던 -tests rpm의 이전 버전에 대한 Obsoletes가 다시 추가되었습니다.