[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>