SlideShare a Scribd company logo
OPENSTACK TORONTO: COMMUNITY UPDATE 
1 OPENSTACK TORONTO | STEPHEN GORDON 
Photo Credit paulbica https://www.flickr.com/pho Photo Credit paulbica https://www.flickr.com/phototoss/9/999777711550066@@NN0000/2/2449977007700886611/ /- -C CCC-B-BYY 2 2.0.0
SERVICE PROVIDER CHALLENGES 
OPENSTACK TORONTO 2 | STEPHEN GORDON
WORKLOADS ARE EVOLVING 
TRADITIONAL 
WORKLOADS 
● Typically resides on a single large 
physical or virtual Machine 
● Cannot tolerate any downtime 
● Needs expensive high availability tools 
found in VMware vSphere 
● Application scales up rather than out 
OPENSTACK TORONTO 3 | STEPHEN GORDON 
CLOUD 
FUNCTIONS 
● Workload resides on multiple Virtual 
Machines 
● Tolerates VM failure – if one fails, another 
quickly replaces it 
● Fault tolerance often built into workload 
● Application scales out rather than up
WHY OPENSTACK 
● Brings public cloud-like capabilities into your datacenter 
● Provides massive on-demand (scale-out) capacity 
● 1,000's → 10,000's → 100k's of VMs 
● It's OPEN! 
● Provides flexibility to customize and interoperate 
● Open APIs for interacting with interchangeable 
backends 
● Community development = higher “feature velocity” 
● Features and functions you need, faster to market over 
proprietary software 
OPENSTACK TORONTO 4 | STEPHEN GORDON
OPENSTACK MISSION STATEMENT 
“To produce the ubiquitous Open Source Cloud 
Computing platform that will meet the needs of 
public and private clouds regardless of size, by 
being simple to implement and massively 
scalable.” 
OPENSTACK TORONTO 5 | STEPHEN GORDON
OPENSTACK CIRCA “ICEHOUSE” 
CLOUD INFRASTRUCTURE FOR CLOUD WORKLOADS 
● Modular architecture, designed to easily scale out 
● Based on (growing) set of core services 
OPENSTACK TORONTO 6 | STEPHEN GORDON
TROVE 
● OpenStack Database-as-a-Service (Trove) 
● Provides scalable and reliable Cloud Database as a 
Service provisioning functionality 
● Supports relational and non-relational database engines 
● Provision and manage multiple database instances as 
needed 
● API supports JSON and XML to provision and manage 
instances 
OPENSTACK TORONTO 7 | STEPHEN GORDON
EXAMPLE: COMPUTE LOGICAL ARCHITECTURE 
OPENSTACK TORONTO 8 | STEPHEN GORDON
OPENSTACK SUMMIT 
● Six monthly User and Developer conference. 
● Nov 2013 – “Icehouse” summit in Hong Kong. 
● May 2014 – “Juno” summit in Atlanta. 
● Nov 2014 – “Kilo” summit in Paris. 
● General track provides venue for traditional presentations 
on user stories, new features, and vendor solutions. 
● Developer track provides less structured slots for 
discussing features and roadmap for coming release. 
OPENSTACK TORONTO 9 | STEPHEN GORDON
JUNO SUMMIT RE-CAP 
● Held at Georgia World Congress Center in Atlanta in 
May 
● ~4,500 attendees (~3,500 in Hong Kong 6 months prior) 
10 OPENSTACK TORONTO | STEPHEN GORDON
TECH PREVIEW: TROVE 
● OpenStack Database-as-a-Service (Trove) 
● Provides scalable and reliable Cloud Database as a 
Service provisioning functionality 
● Supports relational and non-relational database engines 
● Provision and manage multiple database instances as 
needed 
● API supports JSON and XML to provision and manage 
instances 
*Tech Preview features are subject to change in GA 
OPENSTACK TORONTO 11 | STEPHEN GORDON
JUNO SUMMIT RE-CAP – SUPERUSERS 
● Increased visibility of “superusers” 
● Keynotes including content from: 
● AT&T 
● Sony 
● Wells Fargo 
● ...and others 
● Operators track in the design summit 
● Neutron vs nova-network 
● Upgrades 
● Launch of http://superuser.openstack.org/ 
12 OPENSTACK TORONTO | STEPHEN GORDON
JUNO SUMMIT RE-CAP – SUPERUSERS 
13 OPENSTACK TORONTO | STEPHEN GORDON
JUNO SUMMIT RE-CAP – NFV 
14 OPENSTACK TORONTO | STEPHEN GORDON
JUNO SUMMIT RE-CAP – NFV 
● Aim to decouple network functions from physical 
infrastructure while maintaining performance. 
● Increased presence from Communication Service 
Providers (CSPs), Network Equipment Providers 
(NEPs) etc. 
● Formation of NFV subgroup to gather and work on 
requirements. 
● Similar to “win the enterprise” working group 
launched at the Juno summit as well. 
15 OPENSTACK TORONTO | STEPHEN GORDON
JUNO RELEASE SCHEDULE 
● Feature proposal freeze 
● Sept 21 – Today! 
● Juno-3 release and Feature Freeze 
● Sept 4 
● Release candidates 
● Sep 25 onwards 
● Project release 
● Oct 16 
16 OPENSTACK TORONTO | STEPHEN GORDON
JUNO RELEASE PROJECTS 
● Integrated: 
● Sahara – Formerly Savanna - Big Data service 
● Incubated: 
● Ironic – Baremetal Hypervisor Driver 
● Zaqar – Formerly Marconi, multi-tenant cloud 
messaging service like Amazon SQS 
● Designate – DNS-as-a-Service 
● Barbican - Secure storage, provisioning and 
management of secrets. 
● Applied: Manila – Filesystem-as-a-Service 
17 OPENSTACK TORONTO | STEPHEN GORDON
INTEGRATED: SAHARA 
● OpenStack Data Processing (Sahara) 
● Provisioning and management of Hadoop clusters 
● Help identify and improve utilization of unused compute 
power from general purpose OpenStack IaaS cloud 
● Pluggable system of Hadoop installation engines for 
different distros 
● Predefined templates of Hadoop configurations with 
ability to modify parameters. 
OPENSTACK TORONTO 18 | STEPHEN GORDON
TECHNICAL COMMITEE FOCUS AREAS 
● Neutron feature parity with nova-network 
● Migration strategy for moving between the two 
(live/cold) 
● Scalability – multi-host versus distributed virtual 
router 
● Test coverage in Tempest 
● Retrospectively was integrated too early, policy 
changes since applied. 
● Which leads to... 
19 OPENSTACK TORONTO | STEPHEN GORDON
TECHNICAL COMMITEE FOCUS AREAS 
● Heat and Ceilometer gap coverage 
● Updated integration requirements being applied 
retrospectively to integrated projects. 
● Scaling issues with both projects in some scenarios. 
● Not abstraction layers in the same fashion as some 
of the other projects (e.g. Nova and Neutron). 
● Documentation coverage improving. 
20 OPENSTACK TORONTO | STEPHEN GORDON
BOARD FOCUS AREAS 
● “Win the Enterprise” working group 
● “Engaging hidden influencers” effort 
● Both aim to determine how non-developers 
effectively contribute to and collaborate on 
OpenStack. 
● DefCore – Attempt to define what is core and in turn 
how the OpenStack trademark can be used by 
vendors. 
21 OPENSTACK TORONTO | STEPHEN GORDON
ARCHITECTURE DESIGN GUIDE 
● 12 writers over 5 days @ Vmware HQ in Palo Alto 
● Compute, Storage, Network focused architectures 
among others. 
● Apache License 2.0 
● On-line: 
● http://docs.openstack.org/arch-design/content/ 
● Print: 
● http://www.lulu.com/ca/en/shop/openstack-foundation/openstack-22 OPENSTACK TORONTO | STEPHEN GORDON
OPENSTACK JUNO (TENTATIVE) 
● Ironic driver for Nova, replaces nova-baremetal. 
● SR-IOV support 
● Extend PCI passthrough support for SR-IOV 
OPENSTACK TORONTO 23 | STEPHEN GORDON
OPENSTACK JUNO 
● Scheduler NUMA awareness 
● Extend compute driver to track NUMA nodes 
● Aim to: 
● Ensure colocation of guest CPU and RAM (CPU only initially). 
● Avoid floating guest CPU and RAM across nodes . 
● Enable intelligent scheduling in guest by exposing topology. 
OPENSTACK TORONTO 24 | STEPHEN GORDON
OPENSTACK JUNO (TENTATIVE) 
● ML2 as the standard for Neutron plugins. 
● ML2 was introduced in Icehouse. 
● Traditional plug-ins deprecated for removal in Juno. 
● Provides more freedom for heterogeneous 
environments. 
● Distributed virtual router (DVR). 
● Further improvements to IPv6 support. 
OPENSTACK TORONTO 25 | STEPHEN GORDON

More Related Content

OpenStack Toronto: Juno Community Update

  • 1. OPENSTACK TORONTO: COMMUNITY UPDATE 1 OPENSTACK TORONTO | STEPHEN GORDON Photo Credit paulbica https://www.flickr.com/pho Photo Credit paulbica https://www.flickr.com/phototoss/9/999777711550066@@NN0000/2/2449977007700886611/ /- -C CCC-B-BYY 2 2.0.0
  • 2. SERVICE PROVIDER CHALLENGES OPENSTACK TORONTO 2 | STEPHEN GORDON
  • 3. WORKLOADS ARE EVOLVING TRADITIONAL WORKLOADS ● Typically resides on a single large physical or virtual Machine ● Cannot tolerate any downtime ● Needs expensive high availability tools found in VMware vSphere ● Application scales up rather than out OPENSTACK TORONTO 3 | STEPHEN GORDON CLOUD FUNCTIONS ● Workload resides on multiple Virtual Machines ● Tolerates VM failure – if one fails, another quickly replaces it ● Fault tolerance often built into workload ● Application scales out rather than up
  • 4. WHY OPENSTACK ● Brings public cloud-like capabilities into your datacenter ● Provides massive on-demand (scale-out) capacity ● 1,000's → 10,000's → 100k's of VMs ● It's OPEN! ● Provides flexibility to customize and interoperate ● Open APIs for interacting with interchangeable backends ● Community development = higher “feature velocity” ● Features and functions you need, faster to market over proprietary software OPENSTACK TORONTO 4 | STEPHEN GORDON
  • 5. OPENSTACK MISSION STATEMENT “To produce the ubiquitous Open Source Cloud Computing platform that will meet the needs of public and private clouds regardless of size, by being simple to implement and massively scalable.” OPENSTACK TORONTO 5 | STEPHEN GORDON
  • 6. OPENSTACK CIRCA “ICEHOUSE” CLOUD INFRASTRUCTURE FOR CLOUD WORKLOADS ● Modular architecture, designed to easily scale out ● Based on (growing) set of core services OPENSTACK TORONTO 6 | STEPHEN GORDON
  • 7. TROVE ● OpenStack Database-as-a-Service (Trove) ● Provides scalable and reliable Cloud Database as a Service provisioning functionality ● Supports relational and non-relational database engines ● Provision and manage multiple database instances as needed ● API supports JSON and XML to provision and manage instances OPENSTACK TORONTO 7 | STEPHEN GORDON
  • 8. EXAMPLE: COMPUTE LOGICAL ARCHITECTURE OPENSTACK TORONTO 8 | STEPHEN GORDON
  • 9. OPENSTACK SUMMIT ● Six monthly User and Developer conference. ● Nov 2013 – “Icehouse” summit in Hong Kong. ● May 2014 – “Juno” summit in Atlanta. ● Nov 2014 – “Kilo” summit in Paris. ● General track provides venue for traditional presentations on user stories, new features, and vendor solutions. ● Developer track provides less structured slots for discussing features and roadmap for coming release. OPENSTACK TORONTO 9 | STEPHEN GORDON
  • 10. JUNO SUMMIT RE-CAP ● Held at Georgia World Congress Center in Atlanta in May ● ~4,500 attendees (~3,500 in Hong Kong 6 months prior) 10 OPENSTACK TORONTO | STEPHEN GORDON
  • 11. TECH PREVIEW: TROVE ● OpenStack Database-as-a-Service (Trove) ● Provides scalable and reliable Cloud Database as a Service provisioning functionality ● Supports relational and non-relational database engines ● Provision and manage multiple database instances as needed ● API supports JSON and XML to provision and manage instances *Tech Preview features are subject to change in GA OPENSTACK TORONTO 11 | STEPHEN GORDON
  • 12. JUNO SUMMIT RE-CAP – SUPERUSERS ● Increased visibility of “superusers” ● Keynotes including content from: ● AT&T ● Sony ● Wells Fargo ● ...and others ● Operators track in the design summit ● Neutron vs nova-network ● Upgrades ● Launch of http://superuser.openstack.org/ 12 OPENSTACK TORONTO | STEPHEN GORDON
  • 13. JUNO SUMMIT RE-CAP – SUPERUSERS 13 OPENSTACK TORONTO | STEPHEN GORDON
  • 14. JUNO SUMMIT RE-CAP – NFV 14 OPENSTACK TORONTO | STEPHEN GORDON
  • 15. JUNO SUMMIT RE-CAP – NFV ● Aim to decouple network functions from physical infrastructure while maintaining performance. ● Increased presence from Communication Service Providers (CSPs), Network Equipment Providers (NEPs) etc. ● Formation of NFV subgroup to gather and work on requirements. ● Similar to “win the enterprise” working group launched at the Juno summit as well. 15 OPENSTACK TORONTO | STEPHEN GORDON
  • 16. JUNO RELEASE SCHEDULE ● Feature proposal freeze ● Sept 21 – Today! ● Juno-3 release and Feature Freeze ● Sept 4 ● Release candidates ● Sep 25 onwards ● Project release ● Oct 16 16 OPENSTACK TORONTO | STEPHEN GORDON
  • 17. JUNO RELEASE PROJECTS ● Integrated: ● Sahara – Formerly Savanna - Big Data service ● Incubated: ● Ironic – Baremetal Hypervisor Driver ● Zaqar – Formerly Marconi, multi-tenant cloud messaging service like Amazon SQS ● Designate – DNS-as-a-Service ● Barbican - Secure storage, provisioning and management of secrets. ● Applied: Manila – Filesystem-as-a-Service 17 OPENSTACK TORONTO | STEPHEN GORDON
  • 18. INTEGRATED: SAHARA ● OpenStack Data Processing (Sahara) ● Provisioning and management of Hadoop clusters ● Help identify and improve utilization of unused compute power from general purpose OpenStack IaaS cloud ● Pluggable system of Hadoop installation engines for different distros ● Predefined templates of Hadoop configurations with ability to modify parameters. OPENSTACK TORONTO 18 | STEPHEN GORDON
  • 19. TECHNICAL COMMITEE FOCUS AREAS ● Neutron feature parity with nova-network ● Migration strategy for moving between the two (live/cold) ● Scalability – multi-host versus distributed virtual router ● Test coverage in Tempest ● Retrospectively was integrated too early, policy changes since applied. ● Which leads to... 19 OPENSTACK TORONTO | STEPHEN GORDON
  • 20. TECHNICAL COMMITEE FOCUS AREAS ● Heat and Ceilometer gap coverage ● Updated integration requirements being applied retrospectively to integrated projects. ● Scaling issues with both projects in some scenarios. ● Not abstraction layers in the same fashion as some of the other projects (e.g. Nova and Neutron). ● Documentation coverage improving. 20 OPENSTACK TORONTO | STEPHEN GORDON
  • 21. BOARD FOCUS AREAS ● “Win the Enterprise” working group ● “Engaging hidden influencers” effort ● Both aim to determine how non-developers effectively contribute to and collaborate on OpenStack. ● DefCore – Attempt to define what is core and in turn how the OpenStack trademark can be used by vendors. 21 OPENSTACK TORONTO | STEPHEN GORDON
  • 22. ARCHITECTURE DESIGN GUIDE ● 12 writers over 5 days @ Vmware HQ in Palo Alto ● Compute, Storage, Network focused architectures among others. ● Apache License 2.0 ● On-line: ● http://docs.openstack.org/arch-design/content/ ● Print: ● http://www.lulu.com/ca/en/shop/openstack-foundation/openstack-22 OPENSTACK TORONTO | STEPHEN GORDON
  • 23. OPENSTACK JUNO (TENTATIVE) ● Ironic driver for Nova, replaces nova-baremetal. ● SR-IOV support ● Extend PCI passthrough support for SR-IOV OPENSTACK TORONTO 23 | STEPHEN GORDON
  • 24. OPENSTACK JUNO ● Scheduler NUMA awareness ● Extend compute driver to track NUMA nodes ● Aim to: ● Ensure colocation of guest CPU and RAM (CPU only initially). ● Avoid floating guest CPU and RAM across nodes . ● Enable intelligent scheduling in guest by exposing topology. OPENSTACK TORONTO 24 | STEPHEN GORDON
  • 25. OPENSTACK JUNO (TENTATIVE) ● ML2 as the standard for Neutron plugins. ● ML2 was introduced in Icehouse. ● Traditional plug-ins deprecated for removal in Juno. ● Provides more freedom for heterogeneous environments. ● Distributed virtual router (DVR). ● Further improvements to IPv6 support. OPENSTACK TORONTO 25 | STEPHEN GORDON

Editor's Notes

  1. IT operations are being challenged more than ever from various ends of an organization, each with very different types of application and workload requirements. The result…IT operations are straining to meet these new application and workload demands, using their existing traditional infrastructure. In many cases users are seeking the elasticity and dynamic growth they need, outside of their IT team, creating an uncontrolled “shadow IT” problem. Very quickly, the benefits of a private cloud are becoming apparent to IT operations, as they seek the right cloud solutions to meet their business demands.
  2. ...And these new user demands are driving new application development to be more elastic and dynamic and uniquely designed for use in the cloud. Many advantages to this cloud-enabled workload can be rapidly altered and improved, and the architecture they reside on is significantly cheaper if deployed correctly.Traditional Workloads:- often reside on a single, large, stateful VM with several vCPU, lots of vRAM, storage inside VM, etc. - have a high SLA, and cannot tolerate any downtime—if that single VM goes down the enterprise has the potential to lose real dollars. - it needs proper care and maintenance, requires enterprise virtualization features to keep VMs highly available, and must be very carefully monitored with frequent troubleshooting - Scales upward-- as app/user demand grows, the VM gets bigger Cloud workloads are very different Workload runs on many small, stateless VMs, each typically small VMs or even container where: vCPU, vRAM, storage separate) Applications tolerate failure of VMs – If one VM fails, another quickly replaces it Fault tolerance often built into workload – no longer require expensive resiliency tools provided by Virtualization Scales outward, rather than up – as app/user demand grows, add more VMs
  3. But what IS OpenStack exactly? OpenStack is actually a series of several independently developed services that comprise the sub-projects that work together to form a cloud framework. The framework is intentionally designed to be modular, which provides for massive scale-out capabilities for the entire framework. As user/application demands grow, administrators can simply add new service nodes as needed. The system is designed to scale to support thousands and tens-of-thousands VMs. Each service, comprise a set of “core” services that make up the framework, and are updated every 6 months with new projects and services.