원 페이지

철지난 소식이긴하지만 읽을 거리가 많아서 번역해둔다.

SuccessBot Says

역: 해당 파트는 무언가 릴리즈가되면 메일링으로 메일을 쏘아주는 사람들의 글들을 모아둔 것.

  • odyssey4me: OpenStack Ansible Liberty 12.0.5 릴리즈.
  • stevemar: Devstack에서 Keystone API v3로 구성을 바꿈.
  • boris-42: osprofiler 기능 잡 통과^1.
  • odyssey4me: OpenStack Ansible Kilo 11.2.9 릴리즈^2.
  • odyssey4me: OpenStack Ansible Liberty 12.0.6 릴리즈[^3[(https://launchpad.net/openstack-ansible/+milestone/12.0.6).
  • 전체보기: Successes - wiki

Cross-Project Specs

  • 모든 프로젝트에 접근할 수 있는 공통 정책 시나리오^4
  • Web UI에서의 쿼리 구성^5

API Guidelines

  • 더이상 서버 쪽의 traceback을 리턴하지 않습니다^6.
  • 더 이상 서버쪽으로 tracebacks/stacktraces에 대한 반환값을 사용자에게 반환하지 않도록 안내 추가.

Service Type vs. Project Name For Use In Headers

  • Header를 서비스 타입으로 할지, 프로젝트 이름으로 할지에 대한 논의가 있었습니다.
  • API 마이크로버전에 대한 버전 추가에 대한 가이드라인 추가^7
  • 실험 단계의 API에 대한 가이드라인 추가^8
  • API 마이크로버전에 대한 클라이언트 상호작용 가이드라인 추가^9
  • 텀에 대한 각 프로젝트의 일반 이름 추가^10
  • API 사용자에게 더 좋게 제공할 수 있으며, Dean Troyer에 의하면 API 워킹 그룹과 같이 올바른 방향으로 갈 수 있도록 선택해야합니다.
  • 엔트포인트와 API 서비스에 대한 기본 식별자(identifier)로서 서비스 타입은 잘 확립되어있고, 서비스 카탈로그가 제대로 작동하는 방법입니다. 서비스 타입에 따라 이동하는 방법이 있어야합니다.
  • 메일 쓰레드: service type vs. project name for use in headers
  • 역: 뭔가 짧게 줄인게 더 이해가 안되네…

OpenStack Ansible Without Containers

  • Gyorgy가 새로운 OpenStack installer로 GPLv3 라이센스로 Ansible을 사용해서 발표했으며 여기에는 컨테이너는 빠져있다.
  • 이미 OpenStack에는 Ansible 프로젝트와 Kolla 가 있는데 왜 새로운 installer를 만들었을까?:
    • 컨테이너에 불필요한 복잡성 추가.
    • 패키지: pip 패키지와 배포판 패키지를 섞어 사용하고 있지 않음. 배포판 패키지는 init 스크립트, 적당한 시스템 사용자, 업그레이드 가능한 것들…이 포함되어있는 것을 말함.
    • Kevin Carter의 답장에서는 이 내용은 OpenStack Ansible 프로젝트에 포함되어있는 내용이라고 발혔다고…
  • 컨테이너를 사용하지 않고 동시에 모든 서비스를 업그레이드를 한뒤 하나의 컨트롤러를 업데이트 하는건 까다롭고 깨질수도 있습니다. 롤백도 쉽구요.
  • 역: 제대로 번역을 못하겠어서 원본을 같이 첨부
  • 원: Without containers, upgrading a single controller can be tricky and disruptive since you have to upgrade every service at the same time. Rollbacks are also easier.
  • OpenStack Ansible 프로젝트에서 오늘(?) is_metal=true 값을 이용해서 컨테이너 없이 배포가 가능합니다.
  • 메일 쓰레드: OpensTack installer

Release Countdown for Week R-8, Feb 8-12

  • 집중:
  • 2주정도 전에 이번 사이클에서 non-client 라이브러리에 대한 릴리즈 완료
  • 3주정도 전에 클라이언트 라이브러리 릴리즈 완료
  • 프로젝트들은 모든 라이브러리 기능 작업 마무리에 집중.
  • 릴리즈 작업:
  • 릴리즈팀에서 업격하게 3주에서 M3전에 라이버리를 릴리즈 프리징을 할 것입니다.
  • 주요 일정:
  • Non-client 라이브러리 릴리즈 완료: 2월 24일
  • 클라이언트 라이브러리 릴리즈 완료: 3월 2일
  • Mitaka 3: 2월 29일 - 3월 4일 ( 기능 프리징과 소프트 문자 프리징 포함해서)
  • 메일 쓰레드: Release countdown for week R-8, Feb 8-12

“No Open Core” in 2016

  • OpenStack은 이름을 가지기 전, “four opens”라는 신념은 우리가 커뮤니티를 운영하는 방법을 정의하는데 만들어졌습니다.
  • OpenStack이 시작하였던 2010년, 우리는 제품 코어를 오픈소스화하는 방법으로 불편한 커뮤니티 에디션과 “엔터프라이즈 버전”으로 내놓는 다른 오픈소스 클라우드 플랫폼(Eucalyptus)과는 달랐습니다.
  • 오늘날 우리는 “엔터프라이즈 에디션”을 할 수 없는 비영리 독립 재단입니다.
  • 현재 화원사들은 아파치 라이센스인 업스트림 프로젝트 위에 “기업 제품”을 만들 수 있습니다. 일부는 고유 구성요소에서 기능들을 보여줘야되는 드라이버로 되어있습니다.
  • 그럼 2016년 “not do open core”는 뭔가요? 어떤것은 가능하고 어떤것은 안되는 것인가요?
  • Thierry Carrez는 OpenStack 공식 프로젝트들이 새롭게 변화하는 시간으로 받아 들일 것이라 믿습니다.
  • 그것은 제품에 대한 모든 기능들을 오픈 소스로 구현해야합니다.
  • 여러분이 모든 프로젝트를 사용하는 상용 기업의 독점 소프트웨어가 필요하다면, OpenStack 공식 프로젝트로 허용되지 않을 것입니다.
    • 하지만 이 프로젝트는 비공식 프로젝트로는 허용되며, 여전히 OpenStack 인프라에서 호스팅이 가능합니다.
  • Doug Hellmann은 공식 OpenStack 프로젝트로 적용되는 Poppy를 제출 하였습니다.
  • 컨텐트 제공 네트워크의 렙퍼인데, 오픈소스 솔루션이 없었스니다.
  • 공식 프로젝트가 될 수 있을까? 그럼 이게 오픈 코어인가?
  • 메일 쓰레드: “No Open Core” in 2016

The Trouble with Names

  • A few issues have crept up recently with the service catalog, API headers, API end points, and even similarly named resources in different resources (e.g. backup), that are all circling around a key problem. Distributed teams and naming collision.
  • 각 프로젝트는 OpenStack 네임스페이스에 git 저장소에의해 보장되는 고유 이름이 있습니다.
  • Nova/Compute 와 같은 일반적인 이름을 가진 프로젝트 이름을 대체하려는 움직임이 있습니다:
  • Service catalog
  • API headrs
  • 우리가 가질 수 있는 선택사항들:
  • 코드 이름을 사용하는 것: nova, glance, swift 과 같은.
    • 장점: 충돌 문제는 해결
    • 프로젝트에서 알고 있는 비밀 디코더 링이 필요합니다.
  • 공통된 이름에 대한 저장소.
    • 장점: 공통된 이름을 사용해서 어디서든 안전하게 사용할 수 있으며, 충돌에 대한 공포를 줄일 수 있습니다.
    • 단점: 다른 논쟁점이 있을 수도…
  • 커뮤니티의 사람들은 공통 이름을 가지고서 저장소를 만들기를 바라고 있다. 어쩌면 가버넌트 projects.yaml에 있지 않을까?
  • 이 목록은 기술 커밋들이 공식 프로젝트들에서 사용되는 것들만 포함하고 있습니다. 따라서 프로젝트에서만 공통 이름을 예약할 수 있습니다.
  • OpenStack 클라이언트들은 이미 프로젝트에서 공통 이름으로 인코드했습니다.
  • 메일 쓰레드: the trouble with names

Annuncing Ekko - Scalable Block-Based Backup for OpenStack

  • Ekko의 목적은 Nova 인스턴스의 증분 블록 레벨 백업과 복원을 제공합니다.
  • 중복되는 목표가 있습니다:
  • 증분 백업에 의존하지 않는 Cinder 볼륨
  • Nova 인스턴스
    • OpenStack Freezer 에서는 노바 스냅샷 기능을 사용합니다.
    • Ekko는 Nova 인스턴스의 실시간 증분 블록 레벨 백업을 활용하는 것.
  • Jay Pipes는 REST API 엔드포인트가 중복되는지 확인하기위한 것과 두개의 프로젝트(Freezer와 Ekko)에 대해서 논의를 시작함. 거의 동일한 백업을 수행하기위해 두개의 API를 가지는 것은 좋지 않다고…
  • Ekko 젝작자는 다른 백업 프로젝트와 동일한 API를 호출할 경우에도 “실제 구현체와 최종 결과물은 완전히다르다”고 밝혔다.
  • Jay는 다음 엔트포인트가 존재하는 지금을 이해할 수 없다고:
  • Freezer /backups
  • Cinder /{tenant_id}/backups
  • 이 엔드포인트로 나쁜 사용자 경험을 만들어 혼란을 마들고 있다고…
  • 현재 거버넌스 모델에서는 프로젝트간 경쟁을 하길 바라지 않습니다. 두 프로젝트는 API 엔트포인트가 겹치는 경우, 논의를 하여 협력하는 방법으로 나가야한다.
  • 메일 쓰레드: Announcing Ekko – Scalable block-based backup for OpenStack

먼가 번역을 하다보니 2주가 지났다… 이런 내용들이 매주 업데이트가 되고있으니.. 언제 다 보나.ㅡ.ㅡ;; 따라가는 것도 힘들고. 몇몇 내용은 봐도 모르겠고.

그래도 봐야지 흐름이라도 알지…