이번 Red Hat OpenStack Platform 릴리스에는 다음과 같은 개선된 기능이 포함되어 있습니다.

BZ#1419556

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

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

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

BZ#1540239

이 개선 사항은 매트릭스 데이터를 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

이 섹션에 나열된 항목은 기술 프리뷰로 제공됩니다. 기술 프리뷰 상태 범위에 대한 자세한 내용 및 관련된 지원 영향은 https://access.redhat.com/support/offerings/techpreview/에서 참조하십시오.

BZ#1488095

RHOS-12 이상에서 OpenStack 서비스는 컨테이너화되어 있습니다. 이번 릴리스에서는 OpenStack Tempest도 컨테이너화되었습니다. 컨테이너화된 OpenStack Tempest는 기술 프리뷰로 사용할 수 있습니다.

본 섹션에서는 Red Hat OpenStack Platform에 대한 권장 사항 및 중요한 변경 사항을 포함하여 이번 릴리스 관련 중요한 세부 사항을 간단히 설명합니다. 배포에 대해 가능한 최상의 결과를 얻으려면 이 정보를 반드시 숙지하셔야 합니다.

BZ#1468020

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

따라서 Shared File System 서비스는 이제 IPv6 네트워크에서 NetApp ONTAP 백엔드가 지원하는 내보내기 공유를 지원합니다. 내보내기된 공유에 대한 액세스는 IPv6 클라이언트 주소에서 제어됩니다.

BZ#1469208

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

BZ#1496584

Neutron 서비스가 컨테이너화되면 네트워크 네임스페이스에서의 명령 실행 시도는 다음 오류와 함께 실패할 수 있습니다.

# ip netns exec qrouter...
RTNETLINK answers: Invalid argument

네트워크 네임스페이스 내부에서 명령을 실행하려면 해당 네임스페이스를 생성한 neutron 컨테이너에서 명령을 수행해야 합니다. 예를 들어 l3-agent는 라우터에 대한 네트워크 네임스페이스를 생성하므로 명령을 다음과 같이 변경합니다.

# docker exec neutron_l3_agent ip netns exec qrouter...

'qdhcp'로 시작하는 네트워크 네임스페이스와 유사하게 'neutron_dhcp' 컨테이너에서 명령을 실행해야 합니다.

BZ#1503521

이 버전은 networking-ovn에서 내부 DNS 변환을 지원합니다. 두 개의 알려진 제한이 있으며
하나는 내부 DNS를 통해 내부 FQDN 요청이 제대로 해결되지 않는 bz#1581332입니다.

GA 릴리스에서 tripleo는 기본적으로 이러한 확장 기능이 설정되지 않습니다. bz#1577592에서 해결 방법을 참조하십시오.

BZ#1533206

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

BZ#1556933

버전 2.1부터 python-cryptography는 인증서에 사용된 CNS 이름이 IDN 표준에 부합하는지 확인합니다. 검색된 이름이 이 사양을 따르지 않는 경우 cryptography는 인증서를 검증할 수 없게 되며 OpenStack 명령줄 인터페이스를 사용하는 경우 또는 OpenStack 서비스 로그에서 다른 오류가 발견될 수 있습니다.

BZ#1563412

OpenStack Compute(nova) 용으로 예약된 호스트 메모리가 2048MB에서 4096MB로 증가했습니다. 이는 환경의 용량 추정에 영향을 줄 수 있습니다. 필요한 경우 환경 파일에서 'NovaReservedHostMemory' 매개 변수를 사용하여 예약된 메모리를 다시 설정할 수 있습니다. 예를 들면 다음과 같습니다.

parameter_defaults:
  NovaReservedHostMemory: 2048

BZ#1564176

python-mistralclient는 지원되는 오버클라우드 사용 사례에 포함되어 있지 않으므로 OSP 13 릴리스의 -tools 채널에서 삭제되었습니다.

BZ#1567735

OVN을 네트워킹 백엔드로 사용하는 OSP13의 첫 번째 릴리스에는 IPv6 지원이 포함되지 않습니다. 따라서 게스트 VM의 Neighbor Solicitation 요청에 대한 응답에 문제가 있어 기본 경로가 손실됩니다.

BZ#1575752

이전 버전에서 *NetName 매개 변수(예: InternalApiNetName)는 기본 네트워크의 이름을 변경했습니다. 이는 현재 더 이상 지원되지 않습니다.

기본 네트워크의 이름을 변경하려면 구성 가능한 사용자 지정 네트워크 파일(network_data.yaml)을 사용하여 'openstack overcloud deploy' 명령에 '-n' 옵션을 포함합니다. 이 파일에서 "name_lower" 필드를 변경하려는 네트워크의 사용자 지정 네트워크 이름으로 설정해야 합니다. 자세한 내용은 오버클라우드 고급 사용자 지정 가이드에서 "구성 가능한 네트워크 사용"을 참조하십시오.

또한 ServiceNetMap 테이블에 대한 로컬 매개 변수를 network_environment.yaml에 추가하고 이전 네트워크 이름에 대한 모든 기본값을 새 사용자 지정 이름으로 덮어쓰기 해야 합니다. 기본값은 /usr/share/openstack-tripleo-heat-templates/network/service_net_map.j2.yaml에서 확인할 수 있습니다. 향후 OSP-13 릴리스에서는 ServiceNetMap을 수정할 필요가 없습니다.

BZ#1577537

OSP 13 베타에서 일부 컨테이너 이미지를 사용할 수 없는 문제가 수정되었습니다.

BZ#1578312

OVSDB 서버가 다른 컨트롤러 노드에서 오류가 발생하면 이 상태가 감지되지 않기 때문에 neutron-server/metadata-agent에서 다시 연결되지 않습니다.

그 결과 VM 부팅은 metadata-agent로 작동할 수 없으며 새 메타데이터 네임스페이스를 프로비저닝하지 않고 클러스터링이 예상대로 동작하지 않습니다.

이 문제는 새 컨트롤러가 OVN 데이터베이스에 대한 마스터로 승격된 후 모든 Compute 노드에서 ovn_metadata_agent 컨테이너를 다시 시작하여 해결할 수 있습니다. 또한 plugin.ini에서 ovsdb_probe_interval을 600000밀리초의 값으로 증가하여 해결할 수 있습니다.

BZ#1589849

OVN 메타데이터 에이전트가 Compute 노드에서 중지되면 해당 노드에 있는 모든 VM가 메타데이터 서비스에 액세스할 수 없습니다. 그 영향으로 새 VM이 생성되거나 기존 Vm이 재부팅되는 경우 OVN 메타데이터 에이전트를 다시 가져올 때까지 VM이 메타데이터에 액세스할 수 없게 됩니다.

BZ#1592528

극히 드물게 컨트롤러 노드를 여러 번 재부팅한 후 RabbitMQ의 상태가 일정하지 않게되어 오버클라우드의 API 작업이 차단될 수 있습니다.

이 문제의 증상은 다음과 같습니다.
 -  OpenStack 서비스 로그에 다음과 같은 항목이 표시됩니다:
 DuplicateMessageError: Found duplicate message(629ff0024219488499b0fac0cacaa3a5). Skipping it.
 - "openstack network agent list"는 일부 에이전트가 정지(DOWN)상태로 반환됩니다.

일반 작업을 복구하려면 컨트롤러 노드에서 다음 명령을 실행합니다(하나의 컨트롤러에서만 이를 수행해야 함).
 pcs resource restart rabbitmq-bundle

현재 Red Hat OpenStack Platform에 있는 알려진 문제는 다음과 같습니다.

BZ#1321179

`python-requests`를 사용하는 OpenStack 명령행 클라이언트는 현재 SAN 필드에 IP 주소가 있는 인증서를 확인할 수 없습니다.

BZ#1461132

Cinder 볼륨 및 Cinder 백업에 대한 Block Storage 백엔드로 Red Hat Ceph Storage를 사용하는 경우 증분 백업을 시도하면 아무런 경고 없이 전체 백업이 대신 수행됩니다. 이는 알려진 문제입니다.

BZ#1508449

OVN은 compute 노드에서 직접 ovn-controller를 사용하는 DHCP를 openflow 컨트롤러로 사용합니다. 하지만 SR-IOV 인스턴스는 VF/PF를 통해 네트워크에 직접 연결됩니다. 이와 같이 SR-IOV 인스턴스는 어디에서도 DHCP 응답을 얻을 수 없게 됩니다.

이 문제를 해결하려면 OS::TripleO::Services::NeutronDhcpAgent를 다음으로 변경합니다.

   OS::TripleO::Services::NeutronDhcpAgent: docker/services/neutron-dhcp.yaml

BZ#1515815

라우터 게이트웨이가 지워지면 식별된 IP 주소와 관련된 Layer 3 흐름이 삭제되지 않습니다. 식별된 IP 주소에는 PNF 및 외부 게이트웨이 IP 주소가 포함됩니다. 이로 인해 흐름이 오래되지만, 기능적 문제는 발생하지 않습니다. 외부 게이트웨이 및 IP 주소는 자주 변경되지 않습니다. 오래된 흐름은 외부 네트워크가 삭제될 때 삭제됩니다.

BZ#1518126

Redis는 TLS를 활성화된 HA 배포 노드에서 데이터를 올바르게 복제할 수 없습니다. Redis 팔로워 노드는 리더 노드의 데이터를 포함하지 않습니다. Redis 배포에 대해 TLS를 비활성화하는 것이 좋습니다.

BZ#1519783

Neutron은 Quota가 Neutron 라우터 생성에 대해 초과하였음을 나타내는 오류가 표시될 수 있습니다. 이는 알려진 문제로써 networking-odl이 포함된 버그로 인해 다중 라우터 리소스가 Neutron DB의 단일 생성 요청으로 생성되는 문제입니다. 이 문제는 OpenStack Neutron CLI를 사용하여 중복된 라우터를 삭제하고 라우터를 다시 생성하여 단일 인스턴스의 결과를 가져와 해결할 수 있습니다.

BZ#1557794

회귀가 director 언더클라우드의 백업 및 복구 절차에서 식별되었습니다. 그 결과, 프로세스를 수정 및 검증해야 릴리즈할 수 있습니다.

따라서 문서 'Director 언더클라우드 백업 및 복구'는 Red Hat OpenStack Platform 13의 일반 릴리스 버전에서 제공되지 않습니다.  프로세스는 일반 릴리스 이후 우선순위로 업데이트되며 확인되는 즉시 게시됩니다.

BZ#1559055

OpenDaylight 로깅에서 이전 로그가 누락될 수 있습니다. 이는 OpenDaylight의 journald 로깅으로 알려진 문제입니다(“docker logs opendaylght_api” 명령 사용). 현재 컨테이너의 내부에서 /opt/opendaylight/data/logs/karaf.log에 로그할 “file” 메커니즘으로 OpenDaylight 로깅을 전환하여 해결할 수 있습니다. 문제 해결을 위해 다음 heat 매개 변수를 설정합니다. OpenDaylightLogMechanism: ‘file’.

BZ#1562035

Docker는 nsenter 호출에 대한 커널 오류로 인해 docker-puppet 또는 paunch 컨테이너를 실행하는 동안 실행에 실패합니다. 이는 fork 함수의 unshare 호출 사용과 관련된 커널 문제로 식별되었습니다. 수정 사항은 RHEL 7.5.2 릴리스와 관련된 다음 커널 릴리스에서 제공됩니다(6월 말로 예정). BZ #1577745와 관련된 커널 핫픽스는 요청에 따라 제공될 수 있습니다.

또는 다음 해결 방법을 사용할 수 있습니다.
1) 환경 파일에서 "TunedProfileName" 매개 변수를 삭제하고 배포합니다. cpu-partitioning없이 배포하는 경우 재현성이 더 낮은 것으로 확인되고 있습니다. 배포가 완료되면 다음 단계로 tuned 프로파일을 활성화합니다.
  * "isolated_cores" in /etc/tuned/cpu-partitioning-variables.conf 설정
  * "tuned-adm profile cpu-partitioning" 명령 실행
  * 노드 다시 시작
참고: 이 해결 방법을 사용하면 문제가 발생할 가능성이 낮은 것으로 확인되고 있습니다.

2) 코멘트에 지정된 명령을 따릅니다. https://bugzilla.redhat.com/show_bug.cgi?id=1562035#c27 및https://bugzilla.redhat.com/show_bug.cgi?id=1562035#c31
참고: 원하는 결과가 아닌 호스트 PID를 컨테이너에 노출하면 컨테이너가 실행됩니다. 자세한 단계는 OSP13의 다음 마이너 릴리스에 제공되므로 이 문제를 해결하기 위해 "pid=host" 방법이 더 이상 필요하지 않습니다.

BZ#1568012

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


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

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

BZ#1568311

유동 IP가 할당되지 않은 인스턴스가 다른 라우터에서 유동 IP가 할당된 다른 인스턴스에 연결 시도하는 경우 다중 서브넷의 Nova 인스턴스 간 Layer 3 연결이 실패할 수 있습니다.  이는 Nova 인스턴스가 다중 compute 노드에 분산되는 경우 발생합니다.  현재 이 문제에 적합한 해결 방법은 없습니다.

BZ#1568976

하나 이상의 OpenDaylight 인스턴스는 배포 또는 기능적 오류로 이어질 수 있는 기능 로딩 버그 때문에 배포 동안 올바르게 시작하지 못할 수 있습니다.

이 상황에서는 다음 작업을 실행하십시오.
 * HA 배포에서 두 개 이상의 OpenDaylight 인스턴스가 올바른 부팅에 필요하며 그렇지 않으면 배포가 실패할 수 있습니다.  이 경우 현재 'docker ps' 명령을 사용하여 각 컨테이너의 상태를 확인하는 방법으로 문제를 해결할 수 있습니다.  상태가 비정상이라면 컨테이너를 다시 시작합니다(`docker restart opendaylight_api`).

 * TLS 기반의 배포에서 모든 OpenDaylight 인스턴스를 올바르게 부팅하지 않으면 배포에 실패합니다.  이로 인해 모든 OpenDaylights가 성공적으로 부팅될 때까지 배포를 다시 시작해야 합니다.

BZ#1571864

빠른 업그레이드 준비 동안 Heat 스택 리소스의 임시 삭제는 RHEL 등록 취소를 트리거합니다.
그 결과 Heat 소프트웨어 배포 시그널링이 적절하게 작동하지 않으므로 RHEL 등록 취소가 정지됩니다.

이 문제를 해결하려면 오버클라우드가 아직 OSP 10에 있는 동안 최신 오버클라우드 마이너 버전 업데이트를 수행할 준비를 하십시오.
1. 템플릿 파일 /usr/share/openstack-tripleo-heat-templates/extraconfig/pre_deploy/rhel-registration/rhel-registration.yaml을 편집합니다.
2. 템플릿에서 RHELUnregistration 및 RHELUnregistrationDeployment 리소스를 삭제합니다.
3. 마이너 업데이트 및 빠른 업그레이드 절차를 진행합니다.

BZ#1573597

Gnocchi 백엔드로 성능이 낮은 Swift 클러스터가 사용되면 collectd 로그에서 503 오류를 생성하고 gnocchi-metricd.conf에서 "ConnectionError: ('Connection aborted.', CannotSendRequest())" 오류를 출력할 수 있습니다.
이 문제를 해결하려면 CollectdDefaultPollingInterval 매개 변수의 값을 증가시키거나 Swift 클러스터 성능을 개선합니다.

BZ#1574708

OpenDaylight 인스턴스가 클러스터에서 삭제되고 다시 연결되면 인스턴스가 클러스터에 성공적으로 참여할 수 없는 경우가 있습니다. 노드는 결과적으로 클러스터에 다시 참여하게 됩니다.

이러한 상황에서 다음 작업을 수행해야 합니다.
 * 문제가 있는 노드를 다시 시작합니다.
 * REST 엔드포인트를 모니터링하여 클러스터 구성원이 정상인지 상태를 확인합니다. http://$ODL_IP:8081/jolokia/read/org.opendaylight.controller:Category=ShardManager,name=shard-manager-config,type=DistributedConfigDatastore
 * 응답에는 “SyncStatus” 필드가 포함되어야 하며 값이 “true”인 경우 클러스터 구성원이 정상적임을 나타냅니다.

BZ#1574725

VLAN 공급자의 동일한 서브넷에서 다중 VM이 두 개의 다른 Compute 노드에 스케줄링되면 VM 간 ARP가 실패하는 경우가 있습니다.

이러한 VM 간 ARP 패킷 전송이 실패하므로 두 개의 VM 간에는 실질적으로 네트워킹이 없는 것입니다.

BZ#1575023

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 서비스는 적절히 초기화됩니다.

BZ#1575118

Ceph 릴리스 12.2.1은 각 OSD에 허용된 최대 PG 개수를 낮춥니다. 한도를 낮추면 모니터가 HEALTH_WARN 메시지를 조기에 제기할 수 있습니다.

모니터 경고 임계값은 OSD당 300PG에서 200PG로 줄어들었습니다. 200은 OSD당 100PG의 일반 권장 대상의 두 배입니다. 이 한도는 모니터에서 mon_max_pg_per_osd 옵션을 통해 조정할 수 있습니다. 이전 mon_pg_warn_max_per_osd 옵션은 삭제되었습니다.

풀에서 사용하는 PG의 양은 줄일 수 없습니다. 업그레이드로 인해 기존에 존재하는 배포가 최대한도에 도달하면 ceph-upgrade 단계 동안 한도를 사전 업그레이드 값으로 올릴 수 있습니다. 환경 파일에서 다음과 같은 매개 변수 설정을 추가하십시오.

  parameter_defaults:
    CephConfigOverrides:
      mon_max_pg_per_osd: 300

이 설정은 ceph.conf에 적용되며 클러스터는 HEALTH_OK 상태로 유지됩니다.

BZ#1575150

OpenDaylight 클러스터 구성원이 (오류 등의 이유로 인해) 중지된 경우 최대 30분 간 OpenDaylight 클러스터가 응답하지 않는 알려진 문제가 있습니다. 이 문제를 해결하려면 클러스터가 다시 활성화될 때까지 기다려야 합니다.

BZ#1575496

Director로 외부 네트워크에 대한 물리적 호스트 인터페이스를 사용하는 경우 인터페이스가 OVS 브릿지에 연결되지 않으면 인터페이스가 OpenDaylight 설정에서 트래픽을 통과하지 않으므로 이러한 설정을 피해야 합니다.

오버클라우드 외부 네트워크 용 NIC 템플릿에서 OVS 브릿지를 항상 사용합니다.  이 브릿지는 어떤 이름도 사용할 수 있지만 Director에서 기본적으로 "br-ex"입니다.  외부 네트워크에 사용되는 물리적 호스트 인터페이스를 OVS 브릿지에 연결해야 합니다.

OVS 브릿지에 연결된 인터페이스를 사용하는 경우 배포는 올바르게 기능하며 테넌트에 대한 외부 네트워크 트래픽이 올바르게 작동합니다.

BZ#1577975

OpenDaylight는 일정 기간 동안 CPU 사용량이 매우 높아질 수 있습니다. 이 문제는 잠재적으로 다른 시스템 서비스에 영향을 줄 수 있지만 OpenDaylight의 기능에 영향을 미치지 않습니다.

BZ#1579025

OVN Pacemaker RA(Resource Agent) 스크립트에서는 Pacemaker가 슬레이브 노드 승격을 시도할 때 프로모션 작업을 적절하게 처리하지 않는 경우가 있습니다. 이는 마스터 IP가 노드로 이동할 때 ovsdb-servers가 RA 스크립트의 상태를 마스터로 보고하여 발생합니다. 해당 문제는 업스트림에서 수정되었습니다.

문제가 발생하면 neutron 서버가 OVN North 및 South DB 서버에 연결할 수 없게 되며 neutron 서버에 대한 모든 Create/Update/Delete API에 오류가 발생합니다.

ovn-dbs-bundle 리소스를 다시 시작하면 문제가 해결됩니다. 컨트롤러 노드 중 하나에서 아래 명령을 실행하십시오.

"pcs resource restart ovn-dbs-bundle"

BZ#1579417

SNAT 지원에는 테넌트 네트워크에서 사용되는 캡슐화와 상관없이 VXLAN 터널 설정이 필요합니다. 또한 VXLAN 터널 헤더가 페이로드에 추가되어 패킷이 기본 MTU(1500바이트)를 초과할 수 있으므로 VLAN 테넌트 네트워크를 사용하는 경우 MTU를 올바르게 설정해야 합니다.

VXLAN 터널은 SNAT 트래픽을 통과시키기 위해서 올바르게 구성해야 합니다.
VLAN 테넌트 네트워크를 사용하는 경우 SNAT 트래픽이 VXLAN 터널을 통해 흐를 수 있도록 다음 방식 중 하나를 사용하여 MTU를 설정합니다.
 * VLAN 테넌트 기반 네트워크를 설정하여 네트워크 설정당 1450의 MTU를 사용합니다.
 * NeutronGlobalPhysnetMtu heat 매개 변수를 1450으로 설정합니다. 참고: 이는 모든 flat/VLAN공급자 네트워크가 1450MTU가 되는 것을 의미하므로 바람직하지 않을 수 있습니다. (특히 외부 공급자 네트워크의 경우)
 * 1550(또는 이상)의 MTU로 테넌트 네트워크 언더레이를 설정합니다. 여기에는 테넌트 네트워크 NIC에 대해 NIC 템플릿에서 MTU를 설정하는 작업이 포함됩니다.

BZ#1581337

PING 유형 상태 모니터를 사용하려면 HAProxy(드라이버에서 네트워크 로드 밸런싱에 사용하는 기본 소프트웨어) 버전은 1.6 이상이어야 합니다. 이전 HAProxy 버전을 사용하면 사용자 확인 없이 TCP 연결 상태가 확인됩니다.

업스트림 커뮤니티에서는 코드에 확인을 추가하여 사용 중인 HAProxy 버전을 확인하고 그에 따라 작동하도록 수정했습니다.
HAProxy 버전이 1.6 이상이면 PING를 사용할 수 있습니다.
그렇지 않은 경우 TCP 연결을 계속 사용합니다(이러한 HAProxy 버전에 대한 다른 솔루션이 없으면 이 방법이 효과적입니다).

OSP13 GA의 문제는 이전 버전의 HAProxy를 사용하는 RHEL 채널 일부로 HAProxy를 탑재하는 것입니다. 따라서 OSP13 사용자가 PING 유형 상태 모니터를 설정하는 경우 TCP 연결을 대신 가져옵니다.

BZ#1583541

SRIOV 기반 Compute 인스턴스는 서로 다른 네트워크에 있는 경우 OVS Compute 인스턴스에 연결되지 않습니다. VLAN 공급자 네트워크 모두에 연결된 외부 라우터를 사용하여 이 문제를 해결할 수 있습니다.

BZ#1584518

RHOSP는 nova에서 기본적으로 DifferentHostFilter/SameHostFilter의 가용성을 설정하지 않으며 해당 설정은 일부 테스트를 완료하는 데 필요합니다. 따라서 일부 보안 그룹 테스트는 무작위로 실패할 수 있습니다.

이러한 테스트를 건너뛰거나 이러한 필터를 nova 설정에 추가해야 합니다.

BZ#1584762

Telemetry가 언더클라우드에서 수동으로 활성화되면 `hardware.*` 매트릭스는 각 노드에 있는 잘못된 방화벽 설정으로 인해 작동하지 않습니다.

이를 해결하기 위해 다음과 같이 언더클라우드 배포에 여분의 템플릿을 추가하여 컨트롤 플레인 네트워크에서 `snmpd` 서브넷을 수동으로 설정해야 합니다.

parameter_defaults:
  SnmpdIpSubnet: 192.168.24.0/24

BZ#1588186

경합 조건으로 인해 Open vSwitch는 Opendaylight openflowplugin에 연결되지 않습니다. 이 제품의 13.z 릴리스에서 이 문제를 해결할 예정입니다.

BZ#1590114

Telemetry가 언더클라우드에서 수동으로 활성화되면 `hardware.*` 매트릭스는 각 노드에 있는 잘못된 방화벽 설정으로 인해 작동하지 않습니다.

이를 해결하기 위해 다음과 같이 언더클라우드 배포에 여분의 템플릿을 추가하여 컨트롤 플레인 네트워크에서 `snmpd` 서브넷을 수동으로 설정해야 합니다.

parameter_defaults:
  SnmpdIpSubnet: 192.168.24.0/24

BZ#1590560

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

이 때문에 배포는 "Error response from daemon: No such container: ceph-create-keys." 메시지와 함께 실패할 수 있습니다. 이로 인해 하나 이상의 compute 노드가 있는 새로운 배포나 ceph 클라이언트로 작동하는 사용자 지정 역할을 포함하여 Ceph를 사용하는 서비스를 호스팅하는 ceph-ansible 실행에 영향을 미칠 수 있습니다.

BZ#1590938

RHCS3에서 세 개 이상의 OSD를 배포하고 pgcalc(https://access.redhat.com/labs/cephpgc)에서 결정한 대로 풀에 PG 개수를 설정하면 모든 OSD가 활성화되기 전에 ceph-ansible이 풀을 생성하므로 배포에 실패합니다.

이 문제를 해결하려면 기본 PG 개수를 32로 설정하고 배포가 완료되면 Storage Strategies Guide (https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/3/html/storage_strategies_guide/placement_groups_pgs#set_the_number_of_pgs)에 설명된 대로 PG 개수를 수동으로 올립니다.

BZ#1590939

ceph-ansible OpenStack 풀 작업에 잘못된 컨테이너 이름이 있으므로 아직 Ceph MON 및 OSD를 같이 배치할 수 없습니다.
표준 HCI(Compute + OSD)는 영향을 받지 않습니다.

BZ#1593290

SR-IOV 기반 네트워크 인터페이스가 연결된 게스트가 실행 중인 상태에서 nova-compute 서비스를 다시 시작한 후 게스트를 삭제하면 해당 노드에서 SR-IOV VF를 게스트에 더 이상 연결할 수 없습니다. 이는 서비스 시작 시 사용 가능한 장치가 열거되지만 장치가 게스트에 연결되므로 호스트 장치 목록에 포함되지 않기 때문입니다.

게스트를 삭제하고 나면 'nova-compute' 서비스를 다시 시작해야 합니다. 게스트를 삭제하고 서비스를 다시 시작한 후에 사용 가능한 SR-IOV 장치 목록이 올바르게 나열됩니다.

BZ#1593715

비보안 레지스트리 목록은 주요 업그레이드 동안 일부 컨테이너 이미지를 가져온 이후에 업데이트되기 때문에 새로 도입된 비보안 레지스트리의 컨테이너 이미지는 `openstack overcloud upgrade run` 명령 동안 다운로드할 수 없습니다.

다음 해결 방법을 사용할 수 있습니다.

옵션 A: Pacemaker에서 관리하는 컨테이너가 있는 노드에서 수동으로 /etc/sysconfig/docker 파일을 업데이트하고 새로 도입된 비보안 레지스트리를 추가합니다.

옵션 B: 업그레이드 직전에 `openstack overcloud deploy` 명령을 실행하고 DockerInsecureRegistryAddress 매개 변수가 포함된 환경 파일을 사용하여 원하는 새로운 비보안 레지스트리 목록을 제공합니다.

모든 컨테이너 이미지는 업그레이드 동안 성공적으로 다운로드해야 합니다.

BZ#1593757

기존 오버클라우드 배포에서 Octavia를 활성화하면 성공으로 보고하지만 컨트롤러 노드에서 방화벽 규칙이 잘못 설정되어 Octavia API 엔드포인트에는 연결할 수 없습니다.

해결 방법:

모든 컨트롤러 노드에서 방화벽 규칙을 추가하고 DROP 규칙 전에 삽입되었는지 확인합니다.

IPv4:
  # iptables -A INPUT -p tcp -m multiport --dports 9876 -m state --state NEW -m comment --comment "100 octavia_api_haproxy ipv4" -j ACCEPT
  # iptables -A INPUT -p tcp -m multiport --dports 13876 -m state --state NEW -m comment --comment "100 octavia_api_haproxy_ssl ipv4" -j ACCEPT
  # iptables -A INPUT -p tcp -m multiport --dports 9876,13876 -m state --state NEW -m comment --comment "120 octavia_api ipv4" -j ACCEPT


IPv6:
  # ip6tables -A INPUT -p tcp -m multiport --dports 9876 -m state --state NEW -m comment --comment "100 octavia_api_haproxy ipv6" -j ACCEPT
  # ip6tables -A INPUT -p tcp -m multiport --dports 13876 -m state --state NEW -m comment --comment "100 octavia_api_haproxy_ssl ipv6" -j ACCEPT
  # ip6tables -A INPUT -p tcp -m multiport --dports 9876,13876 -m state --state NEW -m comment --comment "120 octavia_api ipv6" -j ACCEPT

HAProxy를 다시 시작합니다:
  # docker restart haproxy-bundle-docker-0

BZ#1595363

빠른 업그레이드 프로세스 동안 사용자는 언더클라우드를 버전 10에서 버전 11로 업그레이드합니다. 일부 상황에서는 nova-api.log가 다음 오류를 보고할 수 있습니다.

`Unexpected API Error. Table 'nova_cell0.instances' doesn't exist`

다음 명령을 실행하여 이 오류를 해결할 수 있습니다.

$ sudo nova-manage api_db sync

이 문제는 중요하지 않으며 빠른 업그레이드 프로세스에 큰 영향을 주지 않아야 합니다.