[openstack-ko] [or_kr] Mitaka Design Series

potopro at gmail.com potopro at gmail.com
Sun Jan 17 10:30:13 UTC 2016


¸Å¹ø ¼­¹ÔÀÌ ³¡³ª°í ³­µÚ 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

from OpenStack Çѱ¹ Ä¿¹Â´ÏƼ http://ift.tt/1naU47s
-------------- next part --------------
HTML ÷ºÎ¸¦ ¾ø¾Ö¹ö·È½À´Ï´Ù...
URL: <http://lists.openstack.org/pipermail/openstack-ko/attachments/20160117/f4e602c0/attachment.html>