<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<html><body>
<p>매번 서밋이 끝나고 난뒤 PTL들이 나와서 발표하는 내용들이 올라오죠. 이번에 나오는 Mitaka에서 추가되는 것들에 대한 이야기입니다.</p>
<p>OpenStack Superuser 사이트에 올라온 글들입니다. 그냥 발표자료에 나온것들만 정리했습니다. 더 자세한 내용은 들어가서 동영상과 함께 작성해놓은 글을 보시면 됩니다.</p>
<h3>Swift, Ironic</h3>
<ul>
<li><a href="http://ift.tt/1Oyt48G">OpenStack Mitaka release: what’s next for swift and Ironic</a></li>
</ul>
<h4>Swift</h4>
<ul>
<li>Burning issues
<ul>
<li>Data at Rest Encryption</li>
<li>Continuing the work on erasure coding</li>
<li>Request for resource usage data (disk utilisation, etc.)</li>
<li>Improving docs and auth for Swift SDK and CLI Tools</li>
</ul>
</li>
<li>What’s next
<ul>
<li>Encryption</li>
<li>Improving the overall experience for end users and operators in various ways</li>
<li>Lowering and smoothing latency</li>
</ul>
</li>
<li>What matters in Mitaka
<ul>
<li>Continued focus on scalability and performance</li>
<li>Interoperability: adding Keystone policy support for role-based access control</li>
</ul>
</li>
</ul>
<h4>Ironic</h4>
<ul>
<li>Burning issues
<ul>
<li>General stability: testing, Nova integration</li>
<li>Improving HA for Nova integration</li>
</ul>
</li>
<li>What’s next
<ul>
<li>Better testing</li>
<li>Nova integration: supporting multiple compute nodes</li>
<li>Networking support with Neutron</li>
<li>RAID Support</li>
</ul>
</li>
<li>What matters in Mitaka
<ul>
<li>Scalability</li>
<li>Resiliency</li>
<li>Third-party testing for all drivers</li>
</ul>
</li>
</ul>
<h3>Ansible, Oslo, Designate</h3>
<ul>
<li><a href="http://ift.tt/1la8wei">OpenStack Mitaka release: what’s next for Ansible, Oslo and Designate</a></li>
</ul>
<h4>Ansible</h4>
<ul>
<li>Burning issues
<ul>
<li>Upgrading OpenStack</li>
<li>Image-based deployment of OpenStack</li>
<li>Focusing on providing a toolset for operators</li>
</ul>
</li>
<li>What’s next
<ul>
<li>Breaking out repository into composable parts</li>
<li>Increased focus on quality of testing</li>
<li>Provide examples for use cases that are important to deployers</li>
<li>Production-ready upgrade framework for OpenStack</li>
</ul>
</li>
<li>What matters in Mitaka
<ul>
<li>Reducing complexity</li>
<li>Improve modularity by implementing everything</li>
</ul>
</li>
</ul>
<h4>Oslo</h4>
<ul>
<li>Burning issues
<ul>
<li>Both old and new Oslo projects were discussed at Summit</li>
<li>Focused on operator feedback and ongoing feedback through bug reports</li>
<li>Discussed how to work closely with logging and security working groups</li>
</ul>
</li>
<li>What’s next
<ul>
<li>Promoting existing projects built over last few cycles (e.g. TaskFlow)</li>
<li>Oslo-privsep: New privilege mechanism based on python functions</li>
<li>Oslo-tooz: distributed lock management, leader elections, etc.</li>
</ul>
</li>
<li>What matters in Mitaka
<ul>
<li>Hardening the messaging infrastructure</li>
<li>New Oslo messaging driver using Pika</li>
<li>New driver for ZeroMQ and adding driver for Kafka</li>
</ul>
</li>
</ul>
<h4>Designate</h4>
<ul>
<li>Burning issues
<ul>
<li>Gaps remaining from the refactoring that occurred between Kilo and Liberty</li>
<li>DNSSEC (DNS Security Extensions)</li>
<li>Verification that returned records have not been tampered</li>
<li>Integration with Nova and neutron for automatic record creation</li>
</ul>
</li>
<li>What’s next
<ul>
<li>Incremental zone transfers (IXFR)</li>
<li>Enabling pool scheduler</li>
</ul>
</li>
<li>What matters in Mitaka
<ul>
<li>Increasing number of DNS server types, breaking down services into smaller services enhances:
<ul>
<li>Modularity (모듈성)</li>
<li>Resiliency (탄력성)</li>
<li>Scalability (확장성)</li>
</ul>
</li>
</ul>
</li>
</ul>
<h3>OpenStackClient, Documentation</h3>
<ul>
<li><a href="http://ift.tt/1Nd0Pim">OpenStack Mitaka release: what’s next for OpenStackClient and Documentation</a></li>
</ul>
<h4>OpenStackClient</h4>
<ul>
<li>Burning issues
<ul>
<li>Help output from tool (feel and heavier)</li>
<li>Name spacing of commands
<ul>
<li>Only includes 5 services in repo; others are plugins</li>
<li>Some plugins want to use the same resource name</li>
</ul>
</li>
<li>Making command set consistent</li>
</ul>
</li>
<li>What’s next
<ul>
<li>Adding more sets of commands
<ul>
<li>Neutron networking is missing currently</li>
</ul>
</li>
<li>switch to using the OpenStack SDK</li>
</ul>
</li>
<li>What matters in Mitaka
<ul>
<li>Performance improvements</li>
</ul>
</li>
</ul>
<h4>Documentation</h4>
<ul>
<li>Burning issues
<ul>
<li>Information architecture and data typing</li>
<li>Moving towards a task-based approach rather than role-based to make approach rather</li>
<li>Impact Big Tent on docs approach</li>
<li>Rethinking approach to API documentation</li>
<li>A lot of feedback on release notes</li>
</ul>
</li>
<li>What’s planned for Mitaka
<ul>
<li>Data typing</li>
<li>Role to task centric approach: stating with user guides</li>
<li>Re-order index pages</li>
<li>Ongoing conversion to RST (Restructured Text)</li>
<li>Modifying DocImpact tool</li>
</ul>
</li>
</ul>
<h3>Nova, Kuryr</h3>
<ul>
<li><a href="http://ift.tt/1ItXStB">OpenStack Mitaka release: what’s next for Nova, Kuryr</a></li>
</ul>
<h4>Nova</h4>
<ul>
<li>Burning issues
<ul>
<li>Focused on resource model for Nova and scheduler interactions</li>
<li>Held several unconference sessions to drill into specific items raised by community members</li>
<li>Plan to reduce the number of configuration options available for Nova</li>
</ul>
</li>
<li>What’s next
<ul>
<li>Improved live migrate</li>
<li>API docs and functionality with service catalog</li>
<li>OS VIF: interface between Nova and Neutron for VIF plugins (in support of Neutron Stadium)</li>
<li>Continue evolution of scheduler interface</li>
</ul>
</li>
<li>What matters in Mitaka
<ul>
<li>Cells V2 impacts scalability and manageability</li>
<li>Live migrate work will improve resiliency</li>
<li>OS VIF will help with modularity</li>
<li>Nova has work planned in all themes (scalability, resiliency, manageability, modularity, interoperability)</li>
</ul>
</li>
</ul>
<h4>Kuryr</h4>
<ul>
<li>Burning issues
<ul>
<li>Focused on identifying pain-points around user deployments with container networking</li>
<li>Investigating how the flexibility of Neutron could help with the container networking experience</li>
<li>Integration work with Magnum and Kolla</li>
</ul>
</li>
<li>What’s next
<ul>
<li>Stabilisation through functional tests, CI, gate testing</li>
<li>Nested containers use case with Magnum</li>
<li>Deployment and packaging</li>
<li>Stretch goal: multi-node environments; Docker Swarm, Mesos, Kubernetes support</li>
</ul>
</li>
</ul>
<h3>Neutron, Cinder, Ceilometer</h3>
<ul>
<li><a href="http://ift.tt/1IUzLza">OpenStack Mitaka release: what’s next for Neutron, Cinder and Ceilometer</a></li>
</ul>
<h4>Neutron</h4>
<ul>
<li>Burning issues
<ul>
<li>Network Function Virtualisation</li>
<li>Container networking support</li>
<li>Advanced services (LBaaS, FWaaS, etc.)</li>
<li>Discussions on overall performance, reliability and operability</li>
</ul>
</li>
<li>What’s next
<ul>
<li>Better protocol support for L3 (IPv6, BGP, etc.)</li>
<li>Continue NFV and container networking work through Neutron Stadium</li>
</ul>
</li>
<li>What matters in Mitaka
<ul>
<li>Scalability: continuing the work on distributed virtual routing (DVR)</li>
<li>Resiliency</li>
<li>Manageability: continuing work towards minimally disruptive upgrades</li>
<li>Modularity: continue to build software modules that are loosely coupled (Neutron Stadium)</li>
</ul>
</li>
</ul>
<h4>Ceilometer</h4>
<ul>
<li>Burning issues
<ul>
<li>Collaborating with other project (Vitrage and CloudKitty)</li>
<li>Requirement for real-time alarms: creating more flexible alarm rules and support for horizontal scaling</li>
<li>User Interface (UI) discussions and prototypes</li>
<li>Sample configuration files</li>
</ul>
</li>
<li>What’s next
<ul>
<li>Aodh: add multiple worker support</li>
<li>Ceilometer: add caching and batch support for write performance improvement</li>
<li>Gnocchi: metric archive sharing to improve scalability for large data-sets</li>
</ul>
</li>
<li>What matters in Mitaka
<ul>
<li>Scalability: alarming and storage</li>
<li>Modularity: continue to break down services further to allow for better integration from external projects</li>
</ul>
</li>
</ul>
<h4>Cinder</h4>
<ul>
<li>Burning issues
<ul>
<li>how to balance being a general-purpose block storage service and taking advantage of features found in SAN arrays</li>
<li>Object inheritance for drivers</li>
<li>Expanded functional testing and third-party CI</li>
</ul>
</li>
<li>What’s next
<ul>
<li>Replication V2 API</li>
<li>API micro-versioning</li>
<li>Continued focus on Third-Party CI and functional testing</li>
</ul>
</li>
<li>What matters in Mitaka
<ul>
<li>Interoperability: API micro-versioning</li>
<li>Resiliency: Investigating Active/Active Cinder</li>
</ul>
</li>
</ul>
<br><br>
from OpenStack 한국 커뮤니티 http://ift.tt/1naU47s
</body></html>