매번 서밋이 끝나고 난뒤 PTL들이 나와서 발표하는 내용들이 올라오죠. 이번에 나오는 Mitaka에서 추가되는 것들에 대한 이야기입니다.

OpenStack Superuser 사이트에 올라온 글들입니다. 그냥 발표자료에 나온것들만 정리했습니다. 더 자세한 내용은 들어가서 동영상과 함께 작성해놓은 글을 보시면 됩니다.

Swift, Ironic

• OpenStack Mitaka release: what’s next for swift and Ironic

Swift

• Burning issues
  • Data at Rest Encryption
  • Continuing the work on erasure coding
  • Request for resource usage data (disk utilisation, etc.)
  • Improving docs and auth for Swift SDK and CLI Tools
• What’s next
  • Encryption
  • Improving the overall experience for end users and operators in various ways
  • Lowering and smoothing latency
• What matters in Mitaka
  • Continued focus on scalability and performance
  • Interoperability: adding Keystone policy support for role-based access control

Ironic

• Burning issues
  • General stability: testing, Nova integration
  • Improving HA for Nova integration
• What’s next
  • Better testing
  • Nova integration: supporting multiple compute nodes
  • Networking support with Neutron
  • RAID Support
• What matters in Mitaka
  • Scalability
  • Resiliency
  • Third-party testing for all drivers

Ansible, Oslo, Designate

• OpenStack Mitaka release: what’s next for Ansible, Oslo and Designate

Ansible

• Burning issues
  • Upgrading OpenStack
  • Image-based deployment of OpenStack
  • Focusing on providing a toolset for operators
• What’s next
  • Breaking out repository into composable parts
  • Increased focus on quality of testing
  • Provide examples for use cases that are important to deployers
  • Production-ready upgrade framework for OpenStack
• What matters in Mitaka
  • Reducing complexity
  • Improve modularity by implementing everything

Oslo

• Burning issues
  • Both old and new Oslo projects were discussed at Summit
  • Focused on operator feedback and ongoing feedback through bug reports
  • Discussed how to work closely with logging and security working groups
• What’s next
  • Promoting existing projects built over last few cycles (e.g. TaskFlow)
  • Oslo-privsep: New privilege mechanism based on python functions
  • Oslo-tooz: distributed lock management, leader elections, etc.
• What matters in Mitaka
  • Hardening the messaging infrastructure
  • New Oslo messaging driver using Pika
  • New driver for ZeroMQ and adding driver for Kafka

Designate

• Burning issues
  • Gaps remaining from the refactoring that occurred between Kilo and Liberty
  • DNSSEC (DNS Security Extensions)
  • Verification that returned records have not been tampered
  • Integration with Nova and neutron for automatic record creation
• What’s next
  • Incremental zone transfers (IXFR)
  • Enabling pool scheduler
• What matters in Mitaka
  • Increasing number of DNS server types, breaking down services into smaller services enhances:
    • Modularity (모듈성)
    • Resiliency (탄력성)
    • Scalability (확장성)

OpenStackClient, Documentation

• OpenStack Mitaka release: what’s next for OpenStackClient and Documentation

OpenStackClient

• Burning issues
  • Help output from tool (feel and heavier)
  • Name spacing of commands
    • Only includes 5 services in repo; others are plugins
    • Some plugins want to use the same resource name
  • Making command set consistent
• What’s next
  • Adding more sets of commands
    • Neutron networking is missing currently
  • switch to using the OpenStack SDK
• What matters in Mitaka
  • Performance improvements

Documentation

• Burning issues
  • Information architecture and data typing
  • Moving towards a task-based approach rather than role-based to make approach rather
  • Impact Big Tent on docs approach
  • Rethinking approach to API documentation
  • A lot of feedback on release notes
• What’s planned for Mitaka
  • Data typing
  • Role to task centric approach: stating with user guides
  • Re-order index pages
  • Ongoing conversion to RST (Restructured Text)
  • Modifying DocImpact tool

Nova, Kuryr

• OpenStack Mitaka release: what’s next for Nova, Kuryr

Nova

• Burning issues
  • Focused on resource model for Nova and scheduler interactions
  • Held several unconference sessions to drill into specific items raised by community members
  • Plan to reduce the number of configuration options available for Nova
• What’s next
  • Improved live migrate
  • API docs and functionality with service catalog
  • OS VIF: interface between Nova and Neutron for VIF plugins (in support of Neutron Stadium)
  • Continue evolution of scheduler interface
• What matters in Mitaka
  • Cells V2 impacts scalability and manageability
  • Live migrate work will improve resiliency
  • OS VIF will help with modularity
  • Nova has work planned in all themes (scalability, resiliency, manageability, modularity, interoperability)

Kuryr

• Burning issues
  • Focused on identifying pain-points around user deployments with container networking
  • Investigating how the flexibility of Neutron could help with the container networking experience
  • Integration work with Magnum and Kolla
• What’s next
  • Stabilisation through functional tests, CI, gate testing
  • Nested containers use case with Magnum
  • Deployment and packaging
  • Stretch goal: multi-node environments; Docker Swarm, Mesos, Kubernetes support

Neutron, Cinder, Ceilometer

• OpenStack Mitaka release: what’s next for Neutron, Cinder and Ceilometer

Neutron

• Burning issues
  • Network Function Virtualisation
  • Container networking support
  • Advanced services (LBaaS, FWaaS, etc.)
  • Discussions on overall performance, reliability and operability
• What’s next
  • Better protocol support for L3 (IPv6, BGP, etc.)
  • Continue NFV and container networking work through Neutron Stadium
• What matters in Mitaka
  • Scalability: continuing the work on distributed virtual routing (DVR)
  • Resiliency
  • Manageability: continuing work towards minimally disruptive upgrades
  • Modularity: continue to build software modules that are loosely coupled (Neutron Stadium)

Ceilometer

• Burning issues
  • Collaborating with other project (Vitrage and CloudKitty)
  • Requirement for real-time alarms: creating more flexible alarm rules and support for horizontal scaling
  • User Interface (UI) discussions and prototypes
  • Sample configuration files
• What’s next
  • Aodh: add multiple worker support
  • Ceilometer: add caching and batch support for write performance improvement
  • Gnocchi: metric archive sharing to improve scalability for large data-sets
• What matters in Mitaka
  • Scalability: alarming and storage
  • Modularity: continue to break down services further to allow for better integration from external projects

Cinder

• Burning issues
  • how to balance being a general-purpose block storage service and taking advantage of features found in SAN arrays
  • Object inheritance for drivers
  • Expanded functional testing and third-party CI
• What’s next
  • Replication V2 API
  • API micro-versioning
  • Continued focus on Third-Party CI and functional testing
• What matters in Mitaka
  • Interoperability: API micro-versioning
  • Resiliency: Investigating Active/Active Cinder