Openstack SLURP

OpenStack 업그레이드 방식: 기존 방식 vs SLURP 적용 방식

OpenStack은 주기적으로 새로운 버전을 릴리스하며, 이를 업그레이드하는 방식은 기존 방식과 SLURP(Skip Level Upgrade Release Process) 방식으로 나뉩니다. SLURP 정책은 기존 업그레이드 방식에 비해 훨씬 더 간소화된 업그레이드를 가능하게 하여, 운영자들에게 더 나은 유연성을 제공합니다. 이 글에서는 두 가지 업그레이드 방식을 비교하고, 향후 릴리스에 대한 예시도 함께 살펴보겠습니다.

1. 기존 방식: 순차적 업그레이드

기존 방식에서는 Openstack의 각 릴리스를 다음 릴리즈로 순차적으로 업그레이드해야 했습니다. 예를 들어, Wallaby 릴리즈를 사용 중이라면, 업그레이드 경로는 아래와 같이 진행됩니다:

Wallaby → Xena → Yoga → Zed → Antalope → Babcat → Caracal → Dalmatian

각 버전은 한 번에 하나씩 업그레이드해야 했기 때문에, 여러 번의 업그레이드를 거쳐야 했습니다. 이 방식은 중간에 릴리스가 많아져 시간이 오래 걸리고, 버전 간 호환성 문제나 리소스 소모가 커질 수 있습니다.

2. SLURP 적용 방식: 두 버전씩 건너뛰기

SLURP 정책은 Antelope 버전 이후부터 적용되며, 매년 두 개의 릴리스를 건너뛰는 방식으로 업그레이드가 가능합니다. SLURP는 업그레이드 주기를 연 1회로 설정하고, 각 릴리스를 2개씩 건너뛰며 이동할 수 있게 해 줍니다. 예를 들어, Antelope 이후의 업그레이드는 아래와 같이 진행됩니다:

• Antelope → Caracal
• Caracal → Epoxy

이 방식은 각 릴리스를 순차적으로 업그레이드할 필요 없이, 더 적은 횟수의 업그레이드를 통해 최신 버전으로 이동할 수 있게 합니다.

향후 릴리스 업데이트 예시

SLURP 방식이 적용되면서, 향후 릴리스는 2개씩 건너뛰어 진행될 예정입니다. 예를 들어, 2025년부터는 Caracal → Epoxy처럼 한 번에 두 개의 버전이 건너뛰어집니다. 이렇게 되면, SLURP를 적용하는 경우, 운영자는 매년 업그레이드를 진행하면서 두 개의 릴리스를 건너뛰는 방식으로 효율적인 관리를 할 수 있게 됩니다.

예시:

1. 2024년: Antelope → Caracal
2. 2025년: Caracal → Epoxy
3. 2026년: Epoxy → G-naming (예상)

따라서 릴리즈 선택과 고려사항

SLURP는 오픈스택 업그레이드의 효율성을 크게 개선하고, 오픈스택 운영자의 부담을 줄이는 유용한 방법입니다. 기존 방식은 릴리스를 하나씩 업그레이드해야 했지만, SLURP 방식은 2개 릴리스를 건너뛰어 업그레이드할 수 있어 시간과 리소스를 절약할 수 있습니다. 향후 릴리스들은 SLURP를 기반으로 연간 업그레이드가 가능하며, 두 개의 버전을 한 번에 건너뛰는 방식으로 진행됩니다.

그렇다면 어떤 릴리즈를 선택하는 것이 좋을지 생각을 해봤습니다. 현재 2025년 1월 기준으로 선택해보겠습니다.

OpenStack Releases: OpenStack Releases

위 링크에 접속하면 오픈스택의 공식 릴리즈 정책 및 지원기간을 확인해볼 수 있습니다. epoxy 릴리즈가 3개월 후 정식 릴리즈 되며, babcat 릴리즈의 경우 3개월 후 unmaintained 상태가 됩니다.

Stable Branches — OpenStack Project Team Guide documentation

Maintenance phases과 관련된 내용으로 참고하기 바라며, SLURP의 경우 unmaintained 가 되더라도 일부 버그픽스가 진행되는 것으로 보입니다. 물론 babcat 릴리즈는 해당사항이 없습니다.

그렇다면 선택지로 남은건 Caracal 릴리즈와 Dalmatian 릴리즈인데, 이중 SLURP에 해당되는 Caracal 릴리즈가 상대적으로 낮은 릴리즈이지만 좀 더 수월한 업그레이드와 유지보수기간을 갖으므로, 현 시점 선택지로 Caracal 릴리즈가 합리적이겠습니다.