4.4. Ceph Object Gateway

AWS CLI를 사용한 멀티 파트 업로드로 인해 더 이상 Ceph Object Gateway가 충돌하지 않음

이전 버전에서는 AWS CLI를 사용한 멀티 파트 업로드 중에 RGW가 체크섬 알고리즘과 AWS S3 및 AWS SDK에 도입된 보고 동작, 특히 새로운 CRC64NVME 체크섬 알고리즘으로 인해 충돌했습니다.

삭제된 오브젝트가 버킷 목록에 더 이상 표시되지 않음

이전에는 CompleteMultipart 와 AbortMultipart 업로드 간의 경쟁으로 인해 일관성 없는 결과가 발생할 수 있었습니다. 결과적으로 더 이상 존재하지 않는 경우에도 버킷 목록에 오브젝트가 표시될 수 있었습니다.

오브젝트 삭제 중에 Ceph Object Gateway가 더 이상 충돌하지 않음

이전 버전에서는 초기화되지 않은 check_objv 매개변수 변수가 오브젝트 삭제 경로의 잘못된 메모리 주소에 액세스할 수 있는 경우도 있었습니다. 그 결과 세그먼트 오류가 발생했습니다.

tail 개체가 더 이상 copy-object로 잘못 삭제되지 않음

이전에는 개체가 자체적으로 복사될 때 유지 관리되지 않은 tail 오브젝트에 대한 참조 수의 불변성이 있었습니다. 이로 인해 기존 오브젝트가 복사되지 않고 변경되었습니다. 결과적으로 tail 오브젝트에 대한 참조가 감소되었습니다. tail 개체의 refcount가 0으로 삭제되면 다음 가비지 컬렉션(GC) 사이클 중에 삭제되었습니다.

잘못된 지문이 추가되면 AssumeRoleWithWebIdentity 작업이 예상대로 실패합니다.

이전에는 코드에서 부울 플래그가 잘못 설정되었기 때문에 CreateOIDCProvider 호출에 잘못된 지문이 등록된 경우에도 AssumeRoleWithWebIdentity 작업이 성공했습니다. 결과적으로 AssumeRoleWithWebIdentity 가 실패했을 때 성공할 수 있었습니다.

RADOS가 최대 풀 용량인 경우 Ceph Object Gateway에서 오브젝트를 삭제할 수 있습니다.

이전에는 RADOS 풀이 최대 할당량에 도달하면 Ceph Object Gateway에서 오브젝트를 삭제할 수 없었습니다.

이제 사용자 Put 오브젝트 권한이 복사된 버킷에서 인식됩니다.

이전에는 Put 오브젝트에 대한 액세스 권한이 있는 복사 소스 버킷의 버킷 정책이 복사된 버킷에서 인식되지 않았습니다. 결과적으로 복사된 버킷에 액세스할 때 액세스 거부 오류가 발생했습니다.

Parquet 오브젝트에 대한 대규모 쿼리는 더 이상 Out of memory 오류를 발송하지 않음

이전에는 Parquet 오브젝트에서 쿼리를 처리할 때 해당 오브젝트를 큰 청크에서 읽은 경우도 있었습니다. 이로 인해 Ceph Object Gateway가 더 큰 버퍼를 메모리에 로드하여 하위 시스템의 크기가 너무 커졌습니다. Ceph Object Gateway가 많은 양의 메모리를 사용하는 OSD 프로세스와 함께 배치된 경우 메모리는 특히 영향을 받습니다. 메모리 부족 오류가 발생하면 OS에서 Ceph Object Gateway 프로세스를 종료했습니다.

radosgw-admin 이 더 이상 양수가 아닌 값에 의해 충돌하지 않음

이전 버전에서는 radosgw-admin 버킷 reshard 명령을 실행할 때 0 또는 음수와 같은 비positive --num-shards 값을 사용하여 이로 인해 radosgw-admin 이 충돌했습니다.

서명 검증 중에 Ceph Object Gateway가 더 이상 실패하지 않음

이전 버전에서는 서명 검증을 위해 첫 번째 x5c 인증을 사용하여 JSON 웹 토큰(JWT)에 서명하지 않은 경우 서명 검증에 실패했습니다.

버킷 버전 관리가 일시 중지될 때 라이프사이클 규칙에 따라 오브젝트가 설정됨

이전 버전에서는 라이프사이클 코드의 오류로 인해 버킷 버전 관리 상태가 일시 중지된 경우 라이프사이클 프로세스에서 개체를 제거하지 않았습니다. 결과적으로 오브젝트는 버킷 목록에 계속 표시되었습니다.

다중 파트 업로드에서 오브젝트 태그를 추가할 수 있음

이전에는 클라이언트에서 전송할 때 Ceph Object Gateway S3 multipart upload 오브젝트 태그가 인식되지 않았습니다. 결과적으로 클라이언트는 다중 파트 업로드 중에 초기 오브젝트 생성 중에 오브젝트 태그를 성공적으로 적용할 수 없었습니다.

STS 구현에서는 1024바이트보다 큰 암호화 키 지원

이전에는 Ceph Object Gateway STS 구현에서 1024바이트보다 큰 암호화 키를 지원하지 않았습니다.

버킷 로깅 구성에서 더 이상 동일한 소스 및 대상 버킷 설정을 허용하지 않음

이전에는 버킷 로깅 구성을 설정할 때 소스 및 대상 버킷이 다른지 확인하지 않았습니다.

잘못된 kafka 오류 메시지로 인해 Ceph Object Gateway가 더 이상 충돌하지 않음

이전에는 kafka 메시지 브로커의 오류 조건이 올바르게 처리되지 않았습니다. 그 결과 Ceph Objet Gateway가 충돌하는 경우도 있습니다.

ACL 버킷 작업이 이제 예상대로 작동함

이전에는 로컬 변수 'uri'가 동일한 이름의 멤버 변수를 섀도우했습니다. 결과적으로 버킷 ACL 작업의 하위 집합이 실패했습니다.

대상 버킷에는 사용자가 로그를 작성할 수 있는 버킷 정책이 필요합니다.

이전에는 버킷 로깅을 위해 대상 버킷에서 권한 검사를 실행하지 않았습니다. 결과적으로 모든 사용자가 특정 권한 없이도 대상 버킷에 로그를 작성할 수 있었습니다.

인증 순서에 대해 external 앞에 local이 나열되어 있는 경우 S3 요청이 더 이상 거부되지 않음

이전에는 로컬 인증 엔진에서 요청이 성공적으로 인증되지 않은 경우 S3 요청이 거부되었습니다. 결과적으로 S3은 인증 순서가 외부 전에 로컬인 경우 OpenStack Keystone EC2 인증 정보를 사용하여 인증하지 못했습니다.

오브젝트를 Cloud로 전환하는 동안 Ceph Object Gateway 내부 HTTP 헤더가 더 이상 전송되지 않습니다.

이전에는 오브젝트를 Cloud로 전환할 때 일부 Ceph Object Gateway 내부 HTTP 헤더 값이 Cloud 엔드포인트로 전송되었습니다. 그 결과 일부 S3 클라우드 서비스에서 헤더를 인식하지 못하고 전환에 실패했거나 오브젝트 작업을 복원하지 못했습니다.

radosgw-admin 버킷 로깅 플러시 명령 제공

이전에는 radosgw-admin 버킷 로깅 플러시 명령을 사용하면 다음 lob 오브젝트 이름이 반환되었습니다. 결과적으로 사용자는 로그 버킷을 나열하지 않고 플러시된 로그 오브젝트의 이름을 알 수 없었습니다.

클러스터 업그레이드에서 notification_v2 주제를 올바르게 가져옵니다.

이전에는 클러스터를 notification_v2로 업그레이드한 버킷 알림을 업그레이드했습니다. 결과적으로 notification_v2의 주제가 예상대로 검색되지 않았습니다.

이제 olh get completes as expected

이전에는 버전 관리 관련 버그에 대한 2023 수정으로 인해 내부 코드 경로가 개체 논리 헤드(OLH)의 잘못된 속성 이름을 참조했습니다. 그 결과 radosgw-admin olh get 명령을 실행할 때 오류가 발생했습니다.

Swift 컨테이너 목록에서 마지막으로 수정된 오브젝트를 보고

이전에는 Ceph Object Gateway Swift 컨테이너 목록 구현에 last_modified JSON 필드를 보내는 논리가 누락되었습니다. 그 결과 Swift 컨테이너 목록에서 오브젝트의 마지막으로 수정된 시간을 보고하지 않았습니다.

Ceph Object Gateway는 체크섬 유형 특정 헤더 및 차고의 추가 체크섬을 인식합니다.

이전 버전에서는 aws-sdk-go-v2 체크섬 동작이 다른 SDK와 달랐습니다. 이는 x-amz-checksum 또는 x- amz-sdk-checksum 을 보내지 않았으며 AWS 문서에 필요한 x-amz-decoded-content-length 을 포함하지 않았기 때문입니다. 결과적으로 전송 시 추가 체크섬을 인식하지 못했으며 일부 AWS-chunked 요청은 InvalidArgument 오류를 사용하여 디코딩된 콘텐츠 길이에 대한 어설션 검사에 실패했습니다.

이제 AssumeRoleWithWebIdentity 호출의 shadow 사용자가 oidc 네임 스페이스 내에 생성됨

이전에는 버킷 통계를 로드하는 데 잘못된 방법이 사용되어 oidc 네임스페이스 내에 AssumeRoleWithWebIdentity 호출에 대한 shadow 사용자가 생성되지 않았습니다. 결과적으로 사용자는 섀도우 사용자와 로컬 rgw 사용자를 구별할 수 없었습니다.