New in Red Hat®️ OpenStack®️ Platform 13, the fast forward upgrade feature lets you easily move between long-life releases, without the need to upgrade to each in-between release. Fast forward upgrades fully containerize Red Hat OpenStack Platform deployment to simplify and speed the upgrade process while reducing interruptions and eliminating the need for additional hardware. Today, we’ll take a look at what the fast forward upgrade process from Red Hat OpenStack Platform 10 to Red Hat OpenStack Platform 13 looks like in practice.

There are six main steps in the process:

1. Cloud backup. Back up your existing cloud.
2. Minor update. Update to the latest minor release.
3. Undercloud upgrade. Upgrade your undercloud.
4. Overcloud preparation. Prepare your overcloud.
5. Overcloud upgrade. Upgrade your overcloud.
6. Convergence. Converge your environment.

Step 1: Back up your existing cloud

First, you need to back up everything in your existing Red Hat OpenStack Platform 10 cloud, including your undercloud, overcloud, and any supporting services. It’s likely that you already have these procedures in place, but Red Hat also provides comprehensive Ansible playbooks to simply the fast forward process even more.

Manual backup procedures are likewise supported by Red Hat’s Customer Experience and Engagement (CEE) group.

A typical OpenStack backup process may involve the following steps:

1. Notify your users.
2. Purge your databases, including any unnecessary data stored by Heat or other OpenStack services. This will help to streamline the backup and upgrade process.
3. Run undercloud and overcloud backups. This will preserve an initial backup of the cloud – it may take some time if you don’t have another backup to reference to this point in time.

By performing a backup before starting the upgrade, you can speed the overall upgrade process by only requiring smaller backups later on.

Step 2: Update to the latest minor release

Next, update your Red Hat OpenStack Platform environment to the latest minor release using the standard minor update processes. This step consolidates all undercloud and overcloud node reboots required for moving to Red Hat OpenStack Platform 13. This simplifies the overall upgrade, as no reboots are needed in later steps. For example, an upgrade from Red Hat OpenStack Platform 10 to the latest, fast forward-ready minor release will update Open vSwitch (OVS) to version 2.9, Red Hat Enterprise Linux to version 7.5, and Red Hat Ceph®️ Storage to version 2.5 in your overcloud. These steps do require node reboots, so you can live-migrate workloads prior rebooting nodes to avoid downtime.

Step 3: Upgrade your undercloud

In this step, you’ll upgrade Red Hat OpenStack Platform director, known as the undercloud, to the new long-life release. This requires manual rolling updates from Red Hat OpenStack Platform 10 to 11 to 12 to 13, but does not require any reboots, as they were completed in the previous minor update. The same action pattern is repeated for each release: enable the new repository, stop main OpenStack Platform services, upgrade director’s main packages, and upgrade the undercloud. Note that Red Hat OpenStack Platform director will not be able to manage the version 10 overcloud during or after these upgrades.

Step 4: Prepare your overcloud

Red Hat OpenStack Platform 13 introduces containerized OpenStack services to the long-life release cadence. This step goes through the process to create the container registry to support the deployment of these new services during the fast forward procedure.

The first part of this step is to prepare the container images to accomplish this:

1. Upload Red Hat OpenStack Platform 13 container images to your cloud environment. These can be stored on the director node or on additional hardware. If you choose to store them on your director node, ensure that the node has enough space available for the images. Note that during this part, your undercloud will be unable to scale your overcloud.

Next, you’ll prepare your overcloud for features introduced in Red Hat OpenStack Platform 11 and 12, including composable networks and roles:

1. Include new services in any custom roles_data files.
2. Edit any custom roles_data files to add composable networks (new for Red Hat OpenStack Platform 13) to each role.
3. Remove deprecated services from any custom roles_data files and update deprecated parameters in custom environment files.

If you have a Red Hat OpenStack Platform director-managed Red Hat Ceph Storage cluster or storage backends, you’ll also need to prepare your storage nodes for new, containerized configuration methods.

1. Install the ceph-ansible package of playbooks in your undercloud and check that you are using the latest resources and configurations in your storage environment file.
2. Update custom storage backend environment files to include new parameters and resources for composable services. This applies to NetApp, Dell EMC, and Dell EqualLogic block storage backends using cinder.

Finally, if your undercloud uses SSL/TLS for its Public API, you’ll need to allow your overcloud to access your undercloud’s OpenStack Object Storage (swift) Public API during the upgrade process.

1. Add your undercloud’s certificate authority to each overcloud node using an Ansible playbook.
2. Perform one last backup. This is the final opportunity for backups before starting the overcloud upgrade.

Step 5: Upgrade your overcloud

This step is the core of the fast forward upgrade procedure. Remember that director is unable to manage your overcloud until this step is completed. During this step you’ll upgrade all overcloud roles and services from version 10 to version 13 using a fully managed series of commands. Let’s take a look at the process for each role.

Controller nodes

First, you’ll upgrade your control plane. This is performed on a single controller node, but does require your entire control plane to be down. Even so, it does not affect currently running workloads. Upgrade the chosen controller node sequentially through Red Hat OpenStack Platform releases to version 13. Once the database on the upgraded controller has been updated, containerized Red Hat OpenStack Platform 13 services can be deployed to all other controllers.

Compute nodes

Next, you’ll upgrade your compute nodes. As with your controller nodes, only OpenStack services are upgraded—not the underlying operating system. Node reboots are not required and workloads are unaffected by the process. The upgrade process is very fast, as it adds containerized services alongside RPM-based services and then simply switches over each service. During the process, however, compute users will not be able to create new instances. Some network services may also be affected.

To get familiar with the process and ensure compatibility with your environment, we recommend starting with a single, low-risk compute node.

Storage (Red Hat Ceph Storage) nodes

Finally, you’ll upgrade your Red Hat Ceph Storage nodes. While this upgrade is slightly different than the controller and compute nodes, it is not disruptive to services and your data plane remains available throughout the procedure. Director uses the ceph-ansible installer making upgrading your storage nodes simpler. It uses a rolling upgrade process to first upgrade your bare-metal services to Ceph 3.0, and then containerizes Ceph services.

Step 6: Converge your environment

At this point, you’re almost done with the fast forward process. The final step is to converge all components in your new Red Hat OpenStack Platform 13 environment. As mentioned previously, until all overcloud components are upgraded to the same version as your Red Hat OpenStack Platform director, you have only limited overcloud management capabilities. While your workloads are unaffected, you’ll definitely want to regain full control over your environment.

This step finishes the fast forward upgrade process. You’ll update your overcloud stack within your undercloud. This ensures that your undercloud has the current view of your overcloud and resets your overcloud for ongoing operation. Finally, you’ll be able to operate your Red Hat OpenStack Platform environment as normal: add nodes, upgrade components, scale services, and manage everything from director.

Conclusion

Fast forward upgrades simplify the process of moving between long-life releases of Red Hat OpenStack Platform. However, upgrading from Red Hat OpenStack Platform 10 to containerized architecture of Red Hat OpenStack Platform 13 is still a significant change. As always, Red Hat is ready to help you succeed with detailed documentation, subscription support, and consulting services.

Watch the OpenStack Upgrades Strategy: The Fast Forward Upgrade video from OpenStack Summit Vancouver 2018 to learn more about the fast forward upgrade approach.

Learn more about Red Hat OpenStack Platform:

• Red Hat OpenStack Platform product page
• Online documentation
• Free 60-day evaluation

The Open Networking Automation Platform (ONAP) is an open-source networking project hosted by the Linux Foundation. Datavision Inc. is an IT company specializing in networking solutions for software-defined networking (SDN), network functions virtualization (NFV), edge computing, 5G, data center, network security and other next-gen technologies. With a recent demo, Datavision highlighted the interoperability between ONAP and MEF 3.0, a framework for defining, delivering, and certifying agile, assured and orchestrated communication services across global automated networks.

Superuser talks to Mark Abolafia, Datavision COO, about the importance of ONAP, open source and embracing virtualization.

About the proof-of-concept between ONAP and MEF 3.0, can you break it down for us – what’s the problem you’re solving? And who would benefit?

There are really two approaches to describe in answering that, but let me try to tie it together. ONAP serves as a services design, orchestration and analytics platform used to manage and control network services. The MEF 3.0 framework is a series of interfaces and methodologies used to provide a standardized methodology to provide agile, assured, standards-based communications both within a carrier’s systems and inter-carrier communication – a lingua franca, if you will, for operating companies to exchange service parameters and commercial-related information among themselves so that users can order a service in one operating company’s world and be able to get services provisioned in another operator’s infrastructure in a completely different geography. Global provisioning. These inter- and intra- carrier provisioning (and billing) issues are the problems being solved.

Why are open source and ONAP important to Datavision and the larger industry?

Open source, and ONAP in particular, are important to Datavision because they enable us to be uncoupled from a specific vendor’s proprietary solution. From a business perspective, where engineering and integration is “what we do,” it’s important to be able to control our destiny to some extent by being able to develop, for our clients, a platform that is extensible and open, so they are not subject to vendor lock-in and are able to move forward with the industry and the open source community at that pace, versus some product manager’s pace at a single vendor.

From an industry perspective, frankly, the same criteria apply – having the open-source community develop and advance a solution helps keep things fresh and innovative, and keeps the vendors on their toes.

You wrote that “ONAP is a platform to help service providers embrace virtualization.” What have been the obstacles/concerns that have kept them from doing it until now?

The major obstacles were (are) current legacy system complexity, severe shortage of appropriate skill levels to be networking and software engineers in the same brain, literally, and, of course, the advent of systems capable of actually fulfilling the promise being presented by vendors to the industry.

What’s been the reaction of your customers to open source in general?

Very positive, actually. They recognize the advantages of not being locked into a specific vendor, but on the other side of the coin, they are going in eyes open, realizing the TCO is similar because of the inherent levels of development and ongoing support necessary to pull an open source application/platform into your operation.

What differentiates Datavision’s services from other companies?

We have the on-the-ground experience in defining and refining the requirements for these systems from an architectural level and we have significant real-world deployment experience. We’ve also been in the space since “the beginning,” having been involved with AT&T Domain 2.0 since its inception. So we’ve got a strong history, and the skills and scars to prove it!

What’s the most common request from your customers?

Help us evaluate all the vendors’ claims, help us integrate all these disparate components together and please help us integrate all THAT into our existing systems so we can enable digital transformation of our business.

Superuser wants to hear your open infrastructure story, get in touch at editorATopenstack.org

Photo // CC BY NC

The post Integrating ONAP and MEF 3.0: A proof-of-concept appeared first on Superuser.

This is placement update 18-25, a weekly update of ongoing development related to the OpenStack placement service.

This is a "contract" version, meaning that the spec and other lists do no have new additions, they are updated to remove what has been merged or abandoned. This is done to encourage people to review existing stuff before jumping on whatever the new shiny is.

With this edition I'm adding a Documentation theme as it was something that's been pointed out recently as a gap.

Most Important

Nested allocation candidates are getting very close, but remain a critical piece of functionality. After that is making sure that we are progressing on the /reshapher functionality and bringing the various virt drivers into line with all this nice new functionality (which mostly means ProviderTrees).

All that nice new functionality means bugs. Experiment. Break stuff. Find bugs. Fix them.

What's Changed

The optional placement database changes merged. This means that if [placement_database]/connection is set, that's the target database for placement data, instead of the nova_api database connection.

Support for consumer generations in allocations has merged.

The PlacementDirect non-HTTP interface to placement has merged.

Most placement unit tests no longer rely on the nova base test classs.

The spec for Reshape Provider Trees (the thing driving /reshaper) merged.

Bugs

• Placement related bugs not yet in progress: 17, one more than last week. We've got some work either starting or killing these.
• In progress placement bugs 8, -1 on last time.

Questions

In IRC yesterday we had an extensive discussion about being able to set custom resource classes on the resource provider representing a compute node, outside the virt driver. At the moment the virt driver will clobber it. Is this what we always want?

Specs

Total last week: 13. Now: 12

Spec-freeze has passed, so presumably exceptions will be required for these. For those that are just not going to happen in Rocky, I guess we can start pushing them into Stein.

• https://review.openstack.org/#/c/549067/ VMware: place instances on resource pool (using update_provider_tree)

• https://review.openstack.org/#/c/552924/ Proposes NUMA topology with RPs

• https://review.openstack.org/#/c/544683/ Account for host agg allocation ratio in placement

• https://review.openstack.org/#/c/552105/ Support default allocation ratios This one has two +2, but is pending some decision on spec-freeze.

• https://review.openstack.org/#/c/438640/ Spec on preemptible servers

• https://review.openstack.org/#/c/555081/ Standardize CPU resource tracking

• https://review.openstack.org/#/c/509042/ Propose counting quota usage from placement

• https://review.openstack.org/#/c/560174/ Add history behind nullable project_id and user_id

• https://review.openstack.org/#/c/565730/ Placement: any traits in allocation_candidate query

• https://review.openstack.org/#/c/565741/ Placement: support mixing required traits with any traits

• https://review.openstack.org/#/c/559718/ [WIP] Support Placement in Cinder

• https://review.openstack.org/#/c/569011/ Count quota based on resource class

Main Themes

Documentation

This is a section for reminding us to document all the fun stuff we are enabling. Open areas include:

• Documenting optional placement database. A bug, 1778227 has been created to track this.

• "How to deploy / model shared disk. Seems fairly straight-forward, and we could even maybe create a multi-node ceph job that does this - wouldn't that be awesome?!?!", says an enthusiastic Matt Riedemann.

• The when's and where's of re-shaping and VGPUs.

Nested providers in allocation candidates

As far as I can tell the main thing left here is to turn it on in a microversion. That code is at:

• https://review.openstack.org/#/c/565487/

There have been some tweaks to account for the behavior leakage discussed last week.

Consumer Generations

There are a couple of patches left on the consumer generation topic:

• https://review.openstack.org/#/q/topic:bp/add-consumer-generation

Is someone already working on code for making use of this in the resource tracker?

Reshape Provider Trees

This allows moving inventory and allocations that were on resource provider A to resource provider B in an atomic fashion. The blueprint topic is:

• https://review.openstack.org/#/q/topic:bp/reshape-provider-tree

There are WIPs for the HTTP parts and the resource tracker parts, on that topic.

Mirror Host Aggregates

I thought this was done but there's one thing left. A command line tool:

• https://review.openstack.org/#/c/575912/

Extraction

The optional placement database stuff has merged, and is running in the nova-next job. As mentioned above there are documentation tasks to do with this.

A while back, Jay made a first pass at an os-resource-classes, which needs some additional eyes on it. I personally thought it might be heavier than required. If you have ideas please share them.

An area we will need to prepare for is dealing with the various infra and co-gating issues that will come up once placement is extracted.

We also need to think about how to manage the fixtures currently made available by nova that we might need or want to use in placement. Some of them might be worth sharing. How should we do that?

Other

23 entries last week. 18 now. Nice merging. But we've added quite a few, we just don't see them because this is a contract week.

• https://review.openstack.org/#/c/546660/ Purge comp_node and res_prvdr records during deletion of cells/hosts

• https://review.openstack.org/#/q/topic:bp/placement-osc-plugin-rocky A huge pile of improvements to osc-placement

• https://review.openstack.org/#/c/527791/ Get resource provider by uuid or name (osc-placement)

• https://review.openstack.org/#/c/477478/ placement: Make API history doc more consistent

• https://review.openstack.org/#/c/556669/ Tighten up ReportClient use of generation

• https://review.openstack.org/#/c/537614/ Add unit test for non-placement resize

• https://review.openstack.org/#/c/493865/ cover migration cases with functional tests

• https://review.openstack.org/#/q/topic:bug/1732731 Bug fixes for sharing resource providers

• https://review.openstack.org/#/c/535517/ Move refresh time from report client to prov tree

• https://review.openstack.org/#/c/561770/ PCPU resource class

• https://review.openstack.org/#/c/566166/ rework how we pass candidate request information

• https://review.openstack.org/#/c/564876/ add root parent NULL online migration

• https://review.openstack.org/#/q/topic:bp/bandwidth-resource-provider add resource_requests field to RequestSpec

• https://review.openstack.org/#/c/560107/ normalize_name helper (in os-traits)

• https://review.openstack.org/#/c/538498/ Convert driver supported capabilities to compute node provider traits

• https://review.openstack.org/#/c/568639/ Use placement.inventory.inuse in report client

• https://review.openstack.org/#/c/517921/ ironic: Report resources as reserved when needed

• https://review.openstack.org/#/c/568713/ Test for multiple limit/group_policy qparams

End

Hi.

The Red Hat Certified Architect (RHCA) is the highest certification provided by Red Hat. To many, it can be looked at as a “holy grail” of sorts in open source software certifications. It’s not easy to get. In order to receive it, you not only need to already be a Red Hat Certified Engineer  (RHCE) for Red Hat Enterprise Linux (with the Red Hat Certified System Administrator, (RHCSA) as pre-requisite) but also pass additional exams from various technology categories.

There are roughly 20 exams to choose from that qualify towards the RHCA. Each exam is valid for 3 years, so as long as you complete 5 exams within a 3 year period, you will qualify for the RHCA. With that said, you must keep these exams up to date if you don’t want to lose your RHCA status.

An RHCA for OpenStack!

Ok, the subtitle might be misleading – there is no OpenStack specific RHCA certification! However you can select exams that will test your knowledge in technologies needed to successfully build and run OpenStack private clouds. We feel the following certifications demonstrate skills that are crucial for OpenStack:

• Red Hat Certified System Administrator in Red Hat OpenStack
• Red Hat Certified Engineer in Red Hat OpenStack
• Red Hat Certified Specialist in Hybrid Cloud Management
• Red Hat Certified Specialist in Ansible Automation
• Red Hat Certified Specialist in Virtualization
• Red Hat Certified Specialist in Configuration Management
• Red Hat Certified Specialist in OpenShift Administration

Let’s take a deeper look at each one.

The first two are strictly OpenStack-based. To become a Red Hat Certified System Administrator in Red Hat OpenStack, you need to know how to deploy and operate an OpenStack private cloud. It is also required that you have a good knowledge of Red Hat OpenStack Platform features and how to take advantage of them.

A Red Hat Certified Engineer in Red Hat OpenStack is expected to be able to deploy and work with Red Hat Storage as well as have strong troubleshooting skills, especially around networking. The EX310 exam has recently been refreshed with a strong emphasis on Network Functions Virtualization (NFV) and advanced networking – which can be considered ‘must have’ skills in many OpenStack Telco use cases in the real world.

Since Red Hat OpenStack Platform comes with Red Hat CloudForms, the knowledge of it can be as crucial as OpenStack itself. Some folks even go as far as saying CloudForms is OpenStack’s missing brother. The next certification on the list, the Red Hat Certified Specialist in Hybrid Cloud Management, focuses on managing infrastructure using Red Hat CloudForms.  Where OpenStack focuses on abstracting compute, network and storage, CloudForms takes care of the business side of the house. It manages compliance, policies, chargebacks, service catalogs, integration with public clouds, legacy virtualization, containers, and automation platforms. CloudForms really can do a lot, so you can see why it is essential for certification.

But what about … Ansible?!

For workload orchestration in OpenStack you can, of course, natively use Heat. However, if you want to become a truly advanced OpenStack user, you should consider exploring Ansible for these tasks. The biggest advantages of Ansible are its simplicity and flexibility with other platforms (not just OpenStack). It is also popular within DevOps teams for on- and off-premises workload deployments. In fact, Ansible is also a core technology behind the Red Hat OpenStack director, CloudForms, and Red Hat OpenShift Container Platform. It’s literally everywhere in the Red Hat product suites!

One of the reasons for Ansible’s popularity is the amazing functionality it provides through many reusable modules and playbooks. The Red Hat Certified Specialist in Ansible Automation deeply tests your knowledge of writing Ansible playbooks for automation of workload deployments and system operation tasks.

Virtualization of the nation

The last three certifications on this list (the Specialist certifications in Virtualization, Configuration Management, and OpenShift Administration), although not as closely related to OpenStack as the other certifications described here, extend the capability of your OpenStack skill set.

Many OpenStack deployments are complemented by standalone virtualization solutions such as Red Hat Virtualization. This is often useful for workloads not yet ready for a cloud platform. And with CloudForms, Red Hat Virtualization (RHV) and Red Hat OpenStack Platform can both be managed from one place, so having a solid understanding of Red Hat Virtualization can be very beneficial. This is why being a Red Hat Certified Specialist in Virtualization can be so crucial. Being able to run and manage both cloud native workloads and traditional virtualization is essential to your OpenStack skillset.

Puppets and Containers

To round things off, since Red Hat OpenStack Platform utilizes Puppet, we recommend earning the Red Hat Certified Specialist in Configuration Management certification for a true OpenStack-focused RHCA. Through it you demonstrate skills and knowledge in the underlying deployment mechanism allowing for a much deeper understanding and skill set.

Finally, a popular use case for OpenStack is running containerized applications on top of it. Earning the Red Hat Certified Specialist in OpenShift Administration shows you know how to install and manage Red Hat’s enterprise container platform, Red Hat OpenShift Container Platform!

Reach for the stars!

Whether you are already an OpenStack expert or looking to become one, the Red Hat Certified Architect track from Red Hat Certification offers the framework to allow you to prove those skills through an industry-recognized premier certification program. And if you follow our advice here you will not only be perfecting your OpenStack skills, but mastering other highly important supporting technologies including CloudForms, Ansible, Red Hat Virtualization, OpenShift, and Puppet on your journey to the RHCA.

So what is it like to actually GET these certifications? In the next part of our blog we share our accounts of achieving the RHCA! Check back soon and bookmark so you don’t miss it!

Ready to start your certification journey now!? Get in touch with the friendly Red Hatters at Red Hat Training in your local area today to find all the ways you can master the skills you need to accelerate your career and run your enterprise cloud!

About our authors:

Chris Janiszewski is a Red Hat OpenStack Solutions Architect. He is proud to help his clients validate their business and technical use cases on OpenStack and supporting components like storage, networking or cloud automation and management. He is the father of two little kids and enjoys the majority of his free time playing with them.  When the kids are asleep he gets to put the “geek hat” on and build OpenStack labs to hack crazy use cases!

Ken Holden is a Senior Solution Architect with Red Hat. He has spent the past 3 years on the OpenStack Tiger Team with the primary responsibility of deploying Red Hat OpenStack Platform Proof-Of-Concept IaaS Clouds for Strategic Enterprise Customers across North America.  Throughout his 20 year career in Enterprise IT, Ken has focussed on Linux, Unix, Storage, Networking, and Security with the past 5 years being primarily focused on Cloud Solutions. Ken has achieved Red Hat Certified Architect status (RHCA 110-009-776) and holds Certified OpenStack Administrator status (COA-1700-0387-0100) with the OpenStack Foundation. Outside of work, Ken spends the majority of his time with his wife and two daughters, but also aspires to be the world’s most OK Guitar Player when time permits!

Showcasing everything Open in Technology.

Open Source,
Open Networking,
Open Infrastructure,
Open Communities,
Open Beer…
Open Everything

Gathering users, vendors and solution providers, Open Infrastructure Day is an industry event to showcase the latest technologies and share real-world experiences in the next wave of IT virtualisation.

Hosted by Aptira, this conference features a range of sessions on the broader cloud and Software Defined Infrastructure ecosystem including OpenStack, Open Networking, Containers, PaaS and Automation with insights from some of the most talented members of the Open Source community.

Previously known as OpenStack Australia Day, this conference has evolved to cover more than just OpenStack. Including Compute, Storage, Networking and the myriad of associated Cloud technologies which have been pulled together under an “Open Infrastructure” banner.

Over the past 2 years, this event has ran in Sydney, Canberra and Melbourne, attracting more than 800 users from a range of public and private sector organisations. It also attracted some of the largest vendors and solution providers both locally and internationally.

Sponsorship and speaking opportunities are currently open, and early bird tickets are on sale now. Your ticket will include access to all talks and networking functions, as well as food and drinks – and yes there will be beer!

The post Open Infrastructure Day Sydney appeared first on Aptira.

At the recent Vancouver Summit OpenStack project team leads (PTLs) and core team members offered updates for the OpenStack projects they manage, what’s new for this release and what to expect for the next one, plus how you can get involved and influence the roadmap.

Superuser features summaries of the videos; you can also catch them on the OpenStack Foundation YouTube channel.

What

Nova, OpenStack’s compute service. The project aims to implement services and associated libraries to provide massively scalable, on demand, self-service access to compute resources, including bare metal, virtual machines and containers. One of the oldest OpenStack projects, Nova has 183 contributors and, according to the last User Survey, it’s deployed by 98 percent of OpenStack users.

Who two Nova core contributors Matt Riedemann of Huawei and Melanie Witt of Red Hat.

What’s new

“In Pike we had multi-cell support and in Queens we’re building on improving the performance of multi cells,” Riedemann says. “For example, in Pike,  if you’ve got multiple cells in your listing instances across the API, we’re just hitting each cell iteratively and Queens that’s all done concurrently with the results merged at the end.”

There are a ton of updates and improvements for the latest Queens release, including:

• Volume multi-attach is supported with the libvirt compute driver (microversion 2.60)
• vGPUs are supported* with the libvirt and xenapi compute drivers
• Native QEMU volume encryption (live migration, rbd encrypted volumes)
• Improved performance when filtering a list of servers by fixed IP using Neutron
• Continued versioned notification transformation
• Standardized inter-service configuration using keystoneauth adapter
• TLS encryption support for VNC consoles with the libvirt driver

What’s next

The team will be busy for the upcoming Rocky release as well.

“We’ve been working with CERN a lot on some cell features, like disabling a cell they’ve been really helpful in working with us to let us know what what features are missing or what things aren’t working very well so we’ve been doing a lot over there,” Witt says. CERN has already adopted Cells v2 and has a developer devoted to helping out and cleaning up deployment tools, Riedemann notes.

Cells

• Support disabling a cell
• Console proxy per cell and nova-consoleauth deprecation
• nova-manage tooling for managing cells

Scheduling and placement

• Placement request filters for improved scheduling performance
• Granular RBAC policy rules for placement API operations
• NUMA-aware live migration
• Nested resource providers

Other improvements

• Review runways
• Continued vGPU support
• nova-manage db purge
• Abort queued live migrations
• Libvirt CPU model extra flags

Get involved!
Use Ask OpenStack for general questions
For roadmap or development issues, subscribe to the OpenStack development mailing list, and use the tag [nova]
Check out the Nova wiki for more information on how to get involved – whether you’re just getting started or interested in going deeper. Participate in the weekly meetings: Thursdays alternating 14:00 UTC (#openstack-meeting) and 21:00 UTC (#openstack-meeting).

View the entire 40-minute session below and download the slides here.

The post What’s next for OpenStack compute: Nova updates appeared first on Superuser.

1. Only look at the logs relevant to the last run

/var/log/mistral/ceph-install-workflow.log will contain a concatenation of the ceph-ansible runs. The last N lines of the file will have what you're looking for, so what is N?

Determine how long the file is:

[root@undercloud mistral]# wc -l ceph-install-workflow.log 
20287 ceph-install-workflow.log
[root@undercloud mistral]#

Find the lines where previous ansible runs finshed.

[root@undercloud mistral]# grep -n failed=0 ceph-install-workflow.log 
5425:2018-06-18 23:06:58,901 p=22256 u=mistral |  172.16.0.21                : ok=118  changed=19   unreachable=0    failed=0   
5426:2018-06-18 23:06:58,901 p=22256 u=mistral |  172.16.0.23                : ok=81   changed=13   unreachable=0    failed=0   
5427:2018-06-18 23:06:58,901 p=22256 u=mistral |  172.16.0.25                : ok=113  changed=18   unreachable=0    failed=0   
5428:2018-06-18 23:06:58,901 p=22256 u=mistral |  172.16.0.27                : ok=38   changed=3    unreachable=0    failed=0   
5429:2018-06-18 23:06:58,901 p=22256 u=mistral |  172.16.0.28                : ok=77   changed=13   unreachable=0    failed=0   
5430:2018-06-18 23:06:58,901 p=22256 u=mistral |  172.16.0.29                : ok=58   changed=7    unreachable=0    failed=0   
5431:2018-06-18 23:06:58,901 p=22256 u=mistral |  172.16.0.30                : ok=83   changed=18   unreachable=0    failed=0   
5432:2018-06-18 23:06:58,902 p=22256 u=mistral |  172.16.0.31                : ok=110  changed=17   unreachable=0    failed=0   
9948:2018-06-20 12:06:38,325 p=11460 u=mistral |  172.16.0.21                : ok=107  changed=12   unreachable=0    failed=0   
9949:2018-06-20 12:06:38,326 p=11460 u=mistral |  172.16.0.23                : ok=69   changed=4    unreachable=0    failed=0   
9950:2018-06-20 12:06:38,326 p=11460 u=mistral |  172.16.0.25                : ok=102  changed=11   unreachable=0    failed=0   
9951:2018-06-20 12:06:38,326 p=11460 u=mistral |  172.16.0.27                : ok=26   changed=0    unreachable=0    failed=0   
9952:2018-06-20 12:06:38,326 p=11460 u=mistral |  172.16.0.29                : ok=46   changed=5    unreachable=0    failed=0   
9953:2018-06-20 12:06:38,326 p=11460 u=mistral |  172.16.0.30                : ok=70   changed=8    unreachable=0    failed=0   
9954:2018-06-20 12:06:38,326 p=11460 u=mistral |  172.16.0.31                : ok=99   changed=10   unreachable=0    failed=0   
14927:2018-06-20 23:14:57,881 p=7702 u=mistral |  172.16.0.23                : ok=118  changed=19   unreachable=0    failed=0   
14928:2018-06-20 23:14:57,881 p=7702 u=mistral |  172.16.0.27                : ok=110  changed=17   unreachable=0    failed=0   
14932:2018-06-20 23:14:57,881 p=7702 u=mistral |  172.16.0.34                : ok=113  changed=18   unreachable=0    failed=0   
20255:2018-06-21 09:46:40,571 p=17564 u=mistral |  172.16.0.22                : ok=118  changed=19   unreachable=0    failed=0   
20256:2018-06-21 09:46:40,571 p=17564 u=mistral |  172.16.0.26                : ok=134  changed=18   unreachable=0    failed=0   
20257:2018-06-21 09:46:40,571 p=17564 u=mistral |  172.16.0.27                : ok=102  changed=14   unreachable=0    failed=0   
20258:2018-06-21 09:46:40,571 p=17564 u=mistral |  172.16.0.28                : ok=113  changed=18   unreachable=0    failed=0   
20260:2018-06-21 09:46:40,571 p=17564 u=mistral |  172.16.0.34                : ok=110  changed=17   unreachable=0    failed=0   
[root@undercloud mistral]# 

Subtract the last run's line number from the total file lines:

[root@undercloud mistral]# echo $(( 20260 - 14932))
5328
[root@undercloud mistral]# 

Tail from that line line going forward.

2. Identify the node(s) where the playbook run failed:

I know the last 100 lines of the relevant run will have failed set to true if there was a failure. Doing a grep for that will also show me the host:

[root@undercloud mistral]# tail -5328 ceph-install-workflow.log | tail -100 | grep failed=1
2018-06-21 09:46:40,571 p=17564 u=mistral |  172.16.0.32                : ok=66   changed=14   unreachable=0    failed=1   
[root@undercloud mistral]# 

Now that I know the host I want to see on which task that host failed so I grep for 'failed:'. Just grepping for failed won't help as the log will be full of '"failed": false'.

In this case I extract out the failure:

[root@undercloud mistral]# tail -5328 ceph-install-workflow.log | grep 172.16.0.32 | grep failed:
2018-06-21 09:46:06,093 p=17564 u=mistral |  failed: [172.16.0.32 -> 172.16.0.22] (item=[{u'rule_name': u'', u'pg_num': 128, u'name': u'metrics'}, 
{'_ansible_parsed': True, 'stderr_lines': [u"Error ENOENT: unrecognized pool 'metrics'"], u'cmd': [u'docker', u'exec', u'ceph-mon-controller02', 
u'ceph', u'--cluster', u'ceph', u'osd', u'pool', u'get', u'metrics', u'size'], u'end': u'2018-06-21 13:46:01.070270', '_ansible_no_log': False, 
'_ansible_delegated_vars': {'ansible_delegated_host': u'172.16.0.22', 'ansible_host': u'172.16.0.22'}, '_ansible_item_result': True, u'changed': 
True, u'invocation': {u'module_args': {u'warn': True, u'executable': None, u'_uses_shell': False, u'_raw_params': u'docker exec ceph-mon-controller02 
ceph --cluster ceph osd pool get metrics size', u'removes': None, u'creates': None, u'chdir': None, u'stdin': None}}, u'stdout': u'', u'start': 
u'2018-06-21 13:46:00.729965', u'delta': u'0:00:00.340305', 'item': {u'rule_name': u'', u'pg_num': 128, u'name': u'metrics'}, u'rc': 2, u'msg': 
u'non-zero return code', 'stdout_lines': [], 'failed_when_result': False, u'stderr': u"Error ENOENT: unrecognized pool 'metrics'", 
'_ansible_ignore_errors': None, u'failed': False}]) => {"changed": false, "cmd": ["docker", "exec", "ceph-mon-controller02", "ceph", 
"--cluster", "ceph", "osd", "pool", "create", "metrics", "128", "128", "replicated_rule", "1"], "delta": "0:00:01.421755", "end": 
"2018-06-21 13:46:06.390381", "item": [{"name": "metrics", "pg_num": 128, "rule_name": ""}, {"_ansible_delegated_vars": 
{"ansible_delegated_host": "172.16.0.22", "ansible_host": "172.16.0.22"}, "_ansible_ignore_errors": null, "_ansible_item_result": 
true, "_ansible_no_log": false, "_ansible_parsed": true, "changed": true, "cmd": ["docker", "exec", "ceph-mon-controller02", 
"ceph", "--cluster", "ceph", "osd", "pool", "get", "metrics", "size"], "delta": "0:00:00.340305", "end": "2018-06-21 13:46:01.070270", 
"failed": false, "failed_when_result": false, "invocation": {"module_args": {"_raw_params": "docker exec ceph-mon-controller02 
ceph --cluster ceph osd pool get metrics size", "_uses_shell": false, "chdir": null, "creates": null, "executable": null, 
"removes": null, "stdin": null, "warn": true}}, "item": {"name": "metrics", "pg_num": 128, "rule_name": ""}, "msg": 
"non-zero return code", "rc": 2, "start": "2018-06-21 13:46:00.729965", "stderr": "Error ENOENT: unrecognized pool 
'metrics'", "stderr_lines": ["Error ENOENT: unrecognized pool 'metrics'"], "stdout": "", "stdout_lines": []}], 
"msg": "non-zero return code", "rc": 34, "start": "2018-06-21 13:46:04.968626", "stderr": "Error ERANGE:  
pg_num 128 size 3 would mean 768 total pgs, which exceeds max 600 (mon_max_pg_per_osd 200 * num_in_osds 3)", 
"stderr_lines": ["Error ERANGE:  pg_num 128 size 3 would mean 768 total pgs, which exceeds max 600 
(mon_max_pg_per_osd 200 * num_in_osds 3)"], "stdout": "", "stdout_lines": []}
...
[root@undercloud mistral]# 

So that's how I quickly find what went wrong in a ceph-ansible run when debugging a TripleO deployment.

3. Extra

You may be wondering what that error is.

There was a ceph-ansible issue with creating pools before the OSDs were running made the deployment fail because of the overdose protection check. This is something you can still fail if your PG numbers and OSDs are not aligned correctly (use pgcalc) but better to fail a deployment then put production data on a misconfigured cluster. You could also fail it because of this issue that ceph-ansible rc9 fixed (technically it was fixed in an earlier version but it had other bugs so I recommend rc9).

The first week of June I went to an upstream TripleO workshop in Brno. The labs we used are at https://github.com/redhat-openstack/tripleo-workshop

The third week of June I went to a downstream Red Hat OpenStack Platform event in Montreal for those deploying the upcoming version 13 in the field. I covered similar topics with respect to Ceph deployment via TripleO.

China has made massive investments with OpenStack in the last few years, including large-scale, ambitious projects from users such as China UnionPay, China Railway, State Grid Corp. and more.

To gain insight into the future of open source in China, Superuser sat down with Fei Ma, senior engineer in China Academy of Information and Communication Technology (CAICT), a scientific research institute directly under the Ministry of Industry and Information Technology (MIIT) of China.

His research focuses on cloud computing, open source and interoperability. He also currently serves as the team leader of OpenStack Interoperability for the OpenSource Cloud Alliance for industry (OSCAR).

How does your research involve OpenStack?

One of the research departments is dedicated to open source. We do research about open-source policies in China and the development of open-source technologies in the Chinese market. Many of these research reports are posted on our website and on various social media accounts to educate the public about open source and cloud-computing systems.

How are open source technologies viewed and used in China?

Based on our research, the acceptance of open-source technology is at a relatively high level in China. According to 2017 surveys that we conducted on open source in cloud computing, for Chinese businesses with private clouds, about 85.3 percent of them have used some form of open-source technology. Technical maturity and sustainability are priorities for businesses that choose open source. Security considerations are the biggest concern for those who do not use open source.

What does your research tell us about OpenStack adoption in China?

Chinese firms are very enthusiastic about OpenStack. In 2017, the 41.4 percent of Chinese businesses that have private clouds have already used OpenStack in production. From 2016 to 2017, the percentage of Chinese businesses that use OpenStack in the testing environment increased by 8.4 percent. This is fast growth. We’re expecting similar growth for 2018. In terms of the choices for OpenStack solutions, Chinese businesses are more willing to choose a commercial version of an OpenStack solution. About 48.2 percent of Chinese enterprises with private clouds have purchased commercial software. In terms of OpenStack releases, most companies are using Liberty. The most widely adopted OpenStack projects are Nova, Keystone and Horizon. For the potential improvement of OpenStack in the future, 45.2 percent of Chinese firms think that the management of multi-cloud needs to be solved urgently and many also want to have automation tools.

What about containers?

Container technology has been widely accepted and container adoption is growing. The percentage of Chinese enterprises that use container technologies has increased 6.8 percent from 2016 to 2017. There’s also been a fast growth of Chinese enterprises using container technologies in test environments as well. Why are more Chinese companies choosing container technology? Fast deployment and rapid elastic expansion are the biggest drivers. In terms of container engine technology, Docker continues to lead way and LXC is growing fast.

How does your team add to the knowledge of the larger community?

All of the research that we do is public and our reports are free to access on our website. It takes time to do the research and organize the results, but we want to educate the public about the open-source technology and it’s a great way for us to build our brand image as well. Of course we could choose to charge people to access our reports, but we don’t want to do that.

We have done a lot of research and surveys and the participants who didn’t know about OpenStack and open source got to know more by reading through the questions that we asked. It’s a great opportunity for them to educate themselves on open-source technology in general. As potential OpenStack users, they might not know what OpenStack is —  probably all they care about is what solutions are available on the market. We need to educate our users. Let the users know that OpenStack and open source is an option and choose to use them. One of our roles is to educate the users by publishing our research results. All of our research will also be presented at the OSCAR open source and cloud computing industry summit,  the next one will be held in Beijing in March 2022.

What does open source mean to you?

The definition of open source might be very different for users and partners. We have a very neutral opinion about open source. As a research institute, we do research on open source instead of profiting from it. Open source is a very good way to make cloud computing systems more accessible to people. Instead of buying a product, people can develop their own platforms using the knowledge of the open source.

Fei Ma recently spoke with Xiaodong Pan about the current landscape of OpenStack in China at the Summit Vancouver. Catch the whole 20-minute session below:

Photo // CC BY NC

The post Forecasting the future of cloud computing in China appeared first on Superuser.

Over the time that I've been observing the TC, there's been quite a lot of indecision about how and when to exercise power. The rules and regulations of OpenStack governance have it that the TC has pretty broad powers in terms of allowing and disallowing projects to be "official" and in terms of causing or preventing the merging of any code in any of those official projects.

Unfortunately, the negative aspect of these powers make them the sort of powers that no one really wants to use. Instead the TC has a history of, when it wants to pro-actively change things, using techniques of gently nudging or trying to make obvious activities that would be useful. OpenStack-wide goals and the help most-needed list are examples of this sort of thing.

Now that OpenStack is no longer sailing high on the hype seas, resources are more scarce and some tactics and strategies are no longer as useful as they once were. Some have expressed a desire for the TC to provide a more active leadership role. One that allows the community to adapt more quickly to changing times.

There's a delicate balance here that a few different conversations in the past week have highlighted. Last Thursday, a discussion about the (vast) volume of code getting review and merged in the nova project led to some discussion on how to either enforce or support a goal of decomposing nova into smaller, less-coupled pieces. It was hard to find middle ground between outright blocking code that didn't fit with that goal and believing nothing could be done. Mixed in with that were valid concerns that the TC shouldn't be parenting people who are adults and is unable to be effective. (Note: the context of those two linked statements is very important, lest you be inclined to consider them out of context.)

And then today, some discussion about keeping the help wanted list up to date led to thinking about ways to encourage reorganizing "work around objectives rather than code boundaries", despite that being a very large cultural shift that may be very difficult to make.

So what is the TC (or any vaguely powered governance group) to do? We have some recent examples of the right thing: These are written works—some completed, some in-progress—that layout a vision of how things could or should be that community members can react and refer to. As concrete documents they provide what amounts to an evolving constitution of who we are or what we intend to be that people may point to as a third-party authority that they choose to accept, reject or modify without the complexity of "so and so said…".

• Written principles for peer review and clear documentation of the same.
• Starting a Technical Vision for 2018.
• There should be more here. There will be more here.

Many of the things that get written will start off wrong but the only way they have a chance of becoming right is if they are written in the first place. Providing ideas allows people to say "that's right" or "that's wrong" or "that's right, except...". Writing provides a focal point for including many different people in the generation and refinement of ideas and an archive of long-lived meaning and shared belief. Beliefs are what we use to choose between what matters and what does not.

As the community evolves, and in some ways shrinks while demands remain high, we have to make it easier for people to find and understand, with greater alacrity, what we, as a community, choose to care about. We've done a pretty good job in the past talking about things like the four opens, but now we need to be more explicit about what we are making and how we make it.

Joining a community of 89,000 Stackers can be daunting, but when paired with a mentor, contributors are shown to stay longer and contribute more.

New data demonstrates the importance of mentoring through the lens of the Outreachy and Google Summer of Code programs. Newcomers who enter the community through a mentorship program boast a higher retention rate than other newcomers, at 13 percent versus less than 10 percent, respectively. In addition, these mentees contribute to the community for an average of 15 months, far longer than their three-month program duration. This report provides a springboard for additional research into mentorship programs, with the aim to identify and share best practices.

The latest Intel-sponsored gender diversity report from Bitergia continues to evolve and expand its research parameters in response to community and foundation feedback, incorporating several new areas of examination, including mentorship programs that serve the OpenStack community.

The report also reveals new data around representation within special interest groups and in mailing lists, as well as representation as session speakers. Women comprised 12 percent of event attendees over the last three OpenStack summits, accounting for an average 22 percent of keynote speakers and an average 12 percent of session speakers.

The ongoing OpenStack gender diversity research has been useful in raising greater awareness about the underrepresentation of females, and in turn, other minorities within the community. The results have led to many productive discussions across both the OpenStack and Linux communities, and has helped, in part, to form the basis of the CHAOSS Project’s Diversity & Inclusion Work Group.

The numbers have remained relatively consistent over time, offering a baseline against which to measure the community’s collective progress. The study also surfaces the need to pair qualitative with quantitative research to deliver further insight for meaningful action plans.

You can download the 25-page report here.

Do you have input about this study or diversity in general? Let us know at editorATopenstackdotorg.

The post Latest gender diversity report highlights the importance of mentorship programs appeared first on Superuser.

At the recent Vancouver Summit, OpenStack project team leads (PTLs) and core team members offered updates for the OpenStack projects they manage, what’s new for this release and what to expect for the next one, plus how you can get involved and influence the roadmap.

Superuser features summaries of the videos; you can also catch them on the OpenStack Foundation YouTube channel.

In this one, the Kata Containers Architecture Committee — Wei Zhang, Xu Wang, Jessie Frazelle, Jon Olson and Eric Ernst — talks about what they’re working on and the roadmap for the first release and beyond.

What

Kata Containers is an open-source project and community working to build a standard implementation of lightweight Virtual Machines (VMs) that feel and perform like containers, but provide the workload isolation and security advantages of VMs.

What’s new

Version 1.0 was released at the Summit, successfully merging Intel® Clear Containers and Hyper runV technologies to provide a single runtime for virtualized containers, delivering the speed of containers with the security of virtual machines (VMs). During the session, the Committee noted that it tackled a few easy as well as harder problems:

What’s next

Here are some potential updates for 1.0.0 or 1.01, depending on “how many people start kicking things around” says Eric Ernst of Intel.

• Enable Frakti.  Frakti lets Kubernetes run pods and containers directly inside hypervisors via runV. It’s lightweight and portable, but can provide much stronger isolation with independent kernel than linux-namespace-based container runtimes.
• Enable runv> kata-runtime migrations
• Offer “official” Kubernetes support
• Support end-to-end examples (deploying vanilla Kubernetes on bare metal, Kata under nested virtualization)

Ernst says he had a number of conversations at the Summit with people  interested in Kata — some with old kernels or new devices and others were more storage focused– and the community hopes to hear more about how to help. “I really want to focus on real people wanting to use Kata Containers to solve their problems and to really collaborate and make sure it does meet the needs you have. If it doesn’t then get to work really, really quick.”

The more variety of users and contributors, the better he added. “The success of the project from my standpoint depends on the number of people we have contributing and using, the more the better.”

How to get involved

Kata Containers is a fully open-source project––check out Kata Containers on GitHub and join the channels below to find out how you can contribute.

katacontainers.io

GitHub: https://github.com/kata-containers

Slack: link: https://katacontainers.slack.com ; invite: http://bit.ly/KataSlack

IRC: #kata-dev on Freenode

Mailing list: http://lists.katacontainers.io/cgi-bin/mailman/listinfo

You can check out the whole 40-minute session below.

The post Project update: What’s next for Kata Containers appeared first on Superuser.

In the ancient times (circa 2012), as OpenStack started to grow significantly, Ken Pepple created a diagram to represent the various OpenStack components and how information flowed between them. This diagram took a life of its own, being included in one version or another in every presentation to show in one spaghetti picture the complexity of OpenStack.

As we kept adding new (more or less optional) components to the mix, we stopped trying to represent everything in a single diagram, especially as the Technical Committee refused to special-case some components over others. That left us with a confusing list of 60+ project teams ranging from Nova to Winstackers, and no way to represent clearly "OpenStack".

This situation was identified as a key issue by the Board of Directors, the Technical Committee, the User Committee and the Foundation staff during a stategic workshop held last year in Boston. As a result, a group formed to define how to better communicate what OpenStack is, and a subgroup worked more specifically on a new map to represent OpenStack. Here is the result:

A number of things you should notice. First, the map is regularly updated. This is the latest version, from May, 2018. The map is also versioned, using a date-based number. So if someone copies it for their presentation and it gets cargo-culted into generations of presentations from there on, it should be pretty apparent that this may not be the latest available version.

Cartographers know that map design is more about what you leave out than about what you represent. This map is very opinionated in that respect. It is designed to be relevant to consumers of OpenStack technology. So it only represents first-order deliverables, things that someone may opt to install or use. That's the reason why it shows Nova, but not Oslo libraries: it does not represent second-order deliverables that first-order deliverables depend on. It also ignores plug-ins or drivers that run on a main deliverable (like Storlets running onto Swift, Dragonflow running onto Neutron, or magnum-ui running onto Horizon).

The remaining components are laid out in named "buckets", based on who the consumer is and what question they answer. There is the main OpenStack bucket, which contains components that provide a user-facing API, that you may deploy to extend the capabilities of your cloud deployment. On the right, the OpenStack-operations bucket contains add-on components that facilitate operating an OpenStack cloud. On the bottom, the OpenStack-lifecyclemanagement bucket shows the various solutions you can use to facilitate installation and lifecycle management of an OpenStack cloud. On the left, the OpenStack-user bucket contains tools that end users of OpenStack clouds can install to help interact with a running OpenStack cloud. And finally, the OpenStack-adjacentenablers bucket contains tools that help other technology stacks (Kubernetes, NFV...) make use of OpenStack services.

Inside each bucket, deliverables are approximately categorized based on what service they deliver. In addition to that, the main OpenStack bucket is organized in a semi-logical manner (base services at the bottom, higher-level services at the top). An opinionated set of "core functionality" is marked in bold to attract the attention of the casual observer to the most-consumed components.

There are lots of different ways to slice this cake, and a lot of things do not perfectly fit in the simplistic view that the map presents. The result is obviously very opinionated, so it cannot please everyone. That's why it's produced by the Foundation staff, with input from the Technical Committee, the User Committee and the Board of Directors. That doesn't mean its design cannot change, or be fixed over time to better represent the reality.

Working on this exercise really helped me visualize "OpenStack" as a product. You can see the main product (the OpenStack bucket), separate from operational add-ons, deployment tools, client tools and technology bridges. You can see things that do not fit well in the map, or stay at the edges of the map, that we could consider cutting out if they are not successful.

We hope that this map helps people to visually represent OpenStack and can replace the infamous spaghetti diagram in future slidedecks. The next step is to communicate that map more widely, and leverage it more heavily on web properties like the Project Navigator. You can always find the most recent version of the map at www.openstack.org/openstack-map.

In my previous posting on the Circumference I said that I wanted to get the eight Raspberry Pi nodes to netboot from the front end processor so I could more easily manage the nodes on which I wanted to install nova-compute. This post provides a very quick update on those explorations.

Newer Pi 3 B have firmware that can allow them to netboot without any SD card in place, but it requires a fair bit of set up. I was struggling to make headway, never seeing bootpc packets from the nodes. Turns out a newer firmware is needed. Andrew Back, from Ground Electronics the company building the Circumference, pointed to a useful cookbook blog post, Network Booting a Raspberry Pi 3 from an Ubuntu Server, that includes pointers to the new firmware.

That got me a bit further. I'm now able to see some nodes, sometimes choosing to send bootpc packets and otherwise talking to the network.

It's not perfect though. In the above video only two hosts are talking to the network. Only some hosts work some of the time. Different ones with each power cycle. More effort and exploration required.

The fun part about this, for me, was that the Circumference made it relatively painless. Like I said in the previous posting, having the hardware there in front of me works better with my brain: When I wanted to see if network activity was happening I looked at the box. When I to power cycle a node, I used the easy command line tools. Looking forward to when I get the OpenStack parts actually working.

Reminder/Disclaimer: Ground Electronics has provided me with a beta Circumference 25 for testing._

This proposal was submitted for pyconau 2018. It wasn’t accepted, but given I’d put the effort into writing up the proposal I’ll post it here in case its useful some other time. The oblique references to OpensStack are because pycon had an “anonymous” review system in 2018, and I was avoiding saying things which directly identified me as the author.

OpenStack and Kubernetes solve very similar problems. Yet they approach those problems in very different ways. What can we learn from the different approaches taken? The differences aren’t just technical though, there are some interesting social differences too.

OpenStack and Kubernetes solve very similar problems – at their most basic level they both want to place workloads on large clusters of machines, and ensure that those placement decisions are as close to optimal as possible. The two projects even have similar approaches to the fundamentals – they are both orchestration systems at their core, seeking to help existing technologies run at scale instead of inventing their own hypervisors or container run times.

Yet they have very different approaches to how to perform these tasks. OpenStack takes a heavily centralised and monolithic approach to orchestration, whilst Kubernetes has a less stateful and more laissez faire approach. Some of that is about early technical choices and the heritage of the projects, but some of it is also about hubris and a desire to tightly control. To be honest I lived the OpenStack experience so I feel I should be solidly in that camp, but the Kubernetes approach is clever and elegant. There’s a lot to like on the Kubernetes side of the fence.

Its increasingly common that at some point you’ll encounter one of these systems, as neither seems likely to go away in the next few years. Understanding some of the basics of their operation is therefore useful, as well as being interesting at a purely hypothetical level.

The post Rejected talk proposal: Design at scale: OpenStack versus Kubernetes appeared first on Made by Mikal.

This proposal was submitted for pyconau 2018. It was accepted, but hasn’t been presented yet. The oblique references to OpensStack are because pycon had an “anonymous” review system in 2018, and I was avoiding saying things which directly identified me as the author.

Since 2011, I’ve worked on a large Open Source project in python. It kind of got out of hand – 1000s of developers and millions of lines of code. Yet despite being well resourced, we made the same mistakes that those tiny scripts you whip up to solve a small problem make. Come learn from our fail.

This talk will use the privilege separation daemon that the project wrote to tell the story of decisions that were expedient at the time, and how we regretted them later. In a universe in which you can only run commands as root via sudo, dd’ing from one file on the filesystem to another seems almost reasonable. Especially if you ignore that the filenames are defined by the user. Heck, we shell out to “mv” to move files around, even when we don’t need escalated permissions to move the file in question.

While we’ll focus mainly on the security apparatus because it is the gift that keeps on giving, we’ll bump into other examples along the way as well. For example how we had pluggable drivers, but you have to turn them on by passing in python module paths. So what happens when we change the interface the driver is required to implement and you have a third party driver? The answer isn’t good. Or how we refused to use existing Open Source code from other projects through a mixture of hubris and licensing religion.

On a strictly technical front, this is a talk about how to do user space privilege separation sensibly. Although we should probably discuss why we also chose in the last six months to not do it as safely as we could.

For a softer technical take, the talk will cover how doing things right was less well documented than doing things the wrong way. Code reviewers didn’t know the anti-patterns, which were common in the code base, so made weird assumptions about what was ok or not.

On a human front, this is about herding cats. Developers with external pressures from their various employers, skipping steps because it was expedient, and how throwing automation in front of developers because having a conversation as adults is hard. Ultimately we ended up being close to stalled before we were “saved” from an unexpected direction.

In the end I think we’re in a reasonable place now, so I certainly don’t intend to give a lecture about doom and gloom. Think of us more as a light hearted object lesson.

The post Accepted talk proposal: Learning from the mistakes that even big projects make appeared first on Made by Mikal.

Back in May I traveled to Vancouver for the second time in my life. The first was in 2015 when I was there for an OpenStack Summit, and the summit brought me back this time, as I was on the program committee and giving a keynote at OpenDevCon, co-located with the summit. It’s probably my favorite venue in the world, hugging the harbor to provide spectacular views and the opportunity for nice walks along the waterfront during breaks.

The last time I was at an OpenStack Summit was in Barcelona 18 months prior, during my last week with HPE. As a high end to much of my OpenStack work, I spent that week prepping for and then delivering one of the keynotes where I demonstrated live addition of OpenStack-powered clouds to to the production Nodepool in the OpenStack project CI system. At the time, the key messaging was OpenStack as an “integration engine” that empowers organizations to embrace a wide breadth of proven technologies, from storage to compute-focused virtualization to software-defined networking. I think in these 18 months we’ve started taking those features for granted as the virtualized server side of the market becomes more commoditized and what really resonates with companies today is a desire to avoid vendor lock-in. With this change of pace, the OpenStack Summit this time around had strong messaging around “Open Infrastructure” so you’re not bound to a single cloud provider. Key to the product strategy in the container space, it’s messaging that I’m familiar with and generally resonates with my own goals in the free software movement.

As far as the OpenStack Summit itself goes, for the first time I wasn’t there to collaborate with my peers on OpenStack, so it was a very different experience than past years. As an industry observer this time, I could enjoy the keynote explorations into edge computing and the improvements in hardware involvement in virtualization, from CPUs to networks. There was the general collaboration between would-be competitors throughout the keynotes was what I’d come to expect from this amazing community (with the notable exception of Canonical…). In addition to their general “open infrastructure” messaging, there also has started to be a shift in the role of the foundation, with support of additional projects that, while complementary, aren’t strictly tied to OpenStack itself. This was highlighted with announcements around the independent projects Kata Containers and Zuul CI. Amusingly, containers and CI systems are both things that are now solidly in my wheelhouse, so it appears my own career trajectory is currently mirroring what we’re seeing there. The OpenDev conference I was there for solidly showed their commitment to CI/CD systems, but massive container tracks at the event make me now see the value in Mesosphere being a stronger part of the conversation at future summits.

OpenDev was great. I wrote about my keynote and the event in broad swaths over on the company blog in Open CI/CD Systems Gaining Traction. My keynote was about doing CI/CD for microservices in containers, where the bulk of the 14 minute talk was a demo where I showed deploying Jenkins, Github and a brand new Git repository for a website, with tests, on DC/OS in 12 minutes. It was a nerve-wracking adventure up there on the stage, but it succeeded! If you’re curious, the demo is fully open source so you can even try it yourself: video, slides and demo.

I also enjoyed finally meeting Benjamin Mako Hill (who I overlapped with a bit in Ubuntu work very early on) and seeing him speak on a topic he has written about, Free Software Needs Free Tools (video). He walked through the lessons Linux learned from their trouble with the proprietary BitKeeper software and stressed the importance of using free tools for the development of free software. It was an incredibly popular talk and message for this crowd, as much of the work we’re all doing is focused on an open source ecosystem for software development. A talk from Fatih Degirmenci and Daniel Farrell on Continuous Delivery Across Communities was also fascinating (video). Collaborating at OpenCI.io there are multiple open source projects that now do some degree of hooking their CI systems together to test specific changes against each other, it was fun to sit down with them on day two of the conference to see what the next steps are for making software development better across open source by using forward-thinking strategies that cross the boundaries between communities.

The conference had several talks spanning the open source CI/CD ecosystem today, from Spinnaker to Zuul to a Kubernetes-driven implementation of CI/CD tooling. What was most valuable to me though were the collaboration sessions, which get several practitioners in a room together, many of whom had never met, to talk through common problems and start coming up with solutions and action items. I can catch up with the talks online post-event, but it was energizing to be in a room with others who share my interest in these topics and to tackle popular operations and culture topics outside of the general DevOps umbrella, where I’m more accustom to seeing these discussions happen.

I was really happy with how this event turned out, and it was a pleasure to be invited on the program committee for it. The OpenStack Foundation succeeded in pulling of a flawless event that pulled in a lot of the right people far beyond the crowd who’d normally come to anything OpenStack related. It was really nice to see that several people had come in just for this event itself, and that made it so important voices some of us hadn’t heard before were able to add an amount of diversity to the conversations. Plus, there were cupcakes.

More photos from the OpenStack Summit and OpenDev here: https://www.flickr.com/photos/pleia2/albums/72157691445454010

On Thursday OpenDev was behind me, and I spent the afternoon in a few final sessions at the summit itself and catching up with people before taking the train to the airport. But the morning was reserved for something a lot more fun than a conference, I had booked a seaplane tour! When I visited Vancouver last time I watched longingly as the seaplanes took off and landed all week, but I decided to go to amazing Vancouver Aquarium instead on my free day. I wouldn’t miss the seaplanes this time! So I Thursday morning I dragged (ok, it didn’t take much convincing) my friend Steve along with me down to the port, which was conveniently right next to the conference venue.

We did the “Extended Panorama” (Adventure Tour) from Harbour Air, where our charming and amusing pilot took us up for about 45 minutes through the nearby mountains for much of it. The tour kicked off with a reminder from the pilot that seaplanes don’t have brakes (the water does that) and limited steering ability. Hah! Once airborne, we flew around the harbor and then into the snow-capped mountains. The tour offered gorgeous glimpses of mountain lakes and other large waterways and concluded by flying over the city of Vancouver before splashing back down into the harbor. At $200/person it’s not something I could do regularly, but I probably wouldn’t say turn down the opportunity to do it again when I’m in Vancouver again at the end of August for the Open Source Summit.

Lots more photos from the seaplane ride and some of the yummy food I enjoyed on my trip here: https://www.flickr.com/photos/pleia2/albums/72157697222323075

Traditionally, using containers in the cloud requires users to manage their own infrastructure such as a cluster of virtual servers. Users have to provision, configure and scale the clusters of virtual servers that these containers run on. They also need to perform the initial capacity planning, such as choosing the number of the servers and server types, as well as handle the dynamic reconfiguration, such as adding or removing servers from the running clusters.

Emerging clusterless container solutions, such as Amazon Web Service (AWS) Fargate and Azure Container Instances (ACI), highlight the potential for OpenStack Zun, which also takes a clusterless approach to running containers. OpenStack Zun launched in June 2016 before Fargate and ACI hit the market, which made it more difficult to understand the use case from a commercial perspective, especially compared to running platforms like Kubernetes on OpenStack or even using OpenStack Magnum to provision Kubernetes.

The clusterless approach taken by Zun, Fargate and ACI allows users to run containers without having to pre-create the set of virtual servers or manage the hosting environment.

The major benefits are:

• Reduce administration overhead: Users see their containers and the applications running in their containers, there is zero server management.
• On-demand pricing model: Users are charged by their containers which can be metered by seconds. In addition, the agility of containers allows users to quickly start and shut down their applications on-demand and users don’t need to pay if their applications aren’t running.
• Increase resource utilization: The smaller footprint of containers allows a better packing of the workloads, increasing utilization of the cloud.

In this article, we’ll go over two clusterless container technologies, AWS Fargate and OpenStack Zun and make recommendations for use cases.

AWS Fargate is a technology of Amazon Elastic Container Service (ECS). Since Fargate is embedded into ECS, all of the ECS features are immediately available. OpenStack Zun is an open-source solution. It’s integrated and released together with other OpenStack services. Both solutions are similar in term of providing a better integration between containers and their cloud infrastructure. With ECS Fargate, containers are integrated with AWS Identity and Access Management (IAM), Virtual Private Cloud (VPC), CloudWatch and many others. With OpenStack Zun, containers are integrated with OpenStack Neutron, Cinder, Keystone, Heat and Horizon.

ECS is more opinionated in the way it builds applications. You have to define your application by using their concepts such as Task and Service. In comparison, OpenStack Zun adopts a less opinionated approach, offering more flexibility to build your applications as you prefer.

OpenStack Zun

Usability

Zun primarily uses the concepts of Container and Capsule. A container is a single container backed by Docker or other container engines. The basic Docker primitives, such as create/delete container, are integrated with Zun. In addition, Zun adds several OpenStack-integrated capabilities to containers. For example, a Zun container is, by default, given Neutron IP addresses, has an option to attach Cinder volumes, the access is authenticated by Keystone and several other services. OpenStack users already familiar with the OpenStack concepts will find it fairly easy to get started with Zun containers.

In addition to the Container concept, Zun provides some slightly advanced abstractions such as Capsule. A Zun Capsule, like a Kubernetes Pod, represents a group of containers that are co-located, co-scheduled and have some shared contexts. Capsule is used to group multiple containers that need to work closely with each other to achieve a business goal.

The operational requirements of Zun are similar to other OpenStack services. They require installing a Zun API server at the controller node and a Zun compute agent at each compute node. The primary dependency of Zun is the set of OpenStack Base Services: an Oslo compatible database, message queue, Etcd and Keystone.

Feature set

At its core, Zun provides a RESTful API service for managing container resources. Zun provides basic functionalities, such as creating a container with an arbitrary amount of CPUs and memory, as well as some advanced features, such as support for single root input/output virtualization (SRIOV). Zun is integrated with OpenStack Keystone so it supports multi-tenancy and provides role-based access control (RBAC) at the level of individual containers.

In terms of networking, a Zun container typically has one or more network interfaces modeled as Neutron ports. By default, Zun creates the Neutron ports from a tenant network with default configurations. Users can customize these configurations, including choosing the Neutron network and/or the IP addresses of the ports, or even using a pre-created and pre-configured Neutron port. In addition, a Zun container can connect to more than one networks. In this case, a Neutron port will be created from each network.

Here’s an example:

openstack appcontainer run \
--net network=net1,v4-fixed-ip=10.0.0.31 \
--net network=net2 \
--net port=net3-port \
nginx:latest

Using Zun together with Neutron you can create containers within your isolated environment where your Nova instances or other OpenStack resources reside. All of the Neutron features that are available to VMs (i.e. Security Groups, QoS) are also available to Zun containers.

To containerize applications that need to persist data, the common approach is to leverage external service to provide persistent volumes for containers. Zun tackles this problem by integrating with OpenStack Cinder. When creating a container, users have the option to mount Cinder volumes into the container. The Cinder volume can be an existing volume in the tenant or a newly created volume. Each volume will be bind-mounted into a path in the container’s file system and data stored there will be persisted.

The following command offers an example:

 openstack appcontainer run \
--mount source=my_cinder_volume,destination=/path/in/container \
nginx:latest

In terms of orchestration, unlike other container platforms that provide built-in orchestration, Zun uses an external orchestration system for this purpose (Currently, Zun is integrated with OpenStack Heat. In the future, Zun will also integrate with Kubernetes). With an external orchestration tool in place, end users can define their containerized applications by using the DSL provided by the tool. With Heat, in particular, it’s also possible to define applications composed of containers and other OpenStack resources, such as Neutron load balancers, floating IPs, Nova instances, etc.

heat_template_version: 2017-09-01

resources:
db:
type: OS::Zun::Container
properties:
image: mysql
environment:
MYSQL_ROOT_PASSWORD: rootpass
MYSQL_DATABASE: wordpress
wordpress:
type: OS::Zun::Container
properties:
image: "wordpress:latest"
environment:
WORDPRESS_DB_HOST: {get_attr: [db, addresses, private, 0, addr]}
WORDPRESS_DB_USER: root
WORDPRESS_DB_PASSWORD: rootpass
floating_ip:
type: OS::Neutron::FloatingIP
properties:
floating_network: public
association:
type: OS::Neutron::FloatingIPAssociation
properties:
floatingip_id: { get_resource: floating_ip }
port_id: {get_attr: [wordpress, addresses, private, 0, port]}

outputs:
url:
value: {get_attr: [floating_ip, floating_ip_address]}
description: The web server url

Finally, SRIOV support is a unique feature found in Zun. Generally speaking, SRIOV is a hardware-based virtualization technology that can be used to enhance network performance. SRIOV is widely used for Network Function Virtualization (NFV) workloads because NFV has strict requirements for the network performance. To leverage the SRIOV capability with Zun, users need to create an SRIOV port from Neutron and pass the SRIOV port to Zun when creating a container. Under the hook, Zun will schedule the container to one of the hosts that has an SRIOV Network Interface Card (NIC) and pass-through a SRIOV NIC to the container’s network namespace. As a result, the container will have accelerated network performance.

ECS Fargate

Usability

ECS Fargate primarily uses the concepts of Task and Service. An ECS Task is similar as a Kubernetes Pod. It contains one or multiple containers that are co-located, co-scheduled and have shared context. An ECS Service is primarily for maintaining the specified number of Tasks, similar to Deployment in Kubernetes. Each Task is given an Elastic Network Interface and a private IP address within a VPC. Each Task can optionally have a data volume but the data volume is not backed by cloud storage.

In general, ECS appears to have a steep learning curve as it defines its own set of abstractions and concepts that are not used in other platforms. Users need to get familiar with them before creating their applications. In addition, the Task abstraction doesn’t expose finer control of individual containers. Users might find it impossible to perform some operations that they are used to doing in Docker, for example, start/stop/kill a container, attach to the container’s terminate, run a command in a running container, commit a container, etc. Instead, what ECS provides is a higher-level control such as specifying the number of Tasks you can run, restart the Task once it terminates, etc.

Feature set

ECS Fargate uses the concept of Task as its smallest unit of deployable resources. Each instance of Task can have one or multiple containers. Users can specify the size of the Task (i.e. how many vCPU and memory it can use), the network configuration of the Task, the data volumes available to the Task and the IAM role assigned to the Task.

A sample Task Definition follows:

{
"family": "sample-fargate",
"networkMode": "awsvpc",
"containerDefinitions": [
{
"name": "fargate-app",
"image": "nginx:latest",
"portMappings": [
{
"containerPort": 80,
"protocol": "tcp"
}
]
}
],
"requiresCompatibilities": [
"FARGATE"
],
"cpu": "256",
"memory": "512"
}

After you’ve defined a Task, there are several options to run the Task. A basic option is to run the Task manually. If the Task is manually triggered, it won’t be re-scheduled once it has finished so it might be suitable for batch workloads. Another option is to run the Task by a Service. A Service is a scheduler used to run Tasks and ensure that the specified number of Tasks are running at any point in time. The Task will be re-scheduled if it stops. In addition, users have an option to put the Service behind an AWS load balancer and the load balancer will route traffic to each instance of Task.

In terms of networking, the only network mode Fargate supports is called AWSVPC. In this mode, each instance of Task gets an Elastic Network Interface and is given a private IP address and an internal DNS hostname. Therefore, similar to OpenStack Zun, containers can be placed in the same network/VPC that other cloud resources (i.e. ECS instances) reside. Firewall features such as security groups are also available to containers. However, slightly different from Zun, the Elastic Network Interface of a Task is fully managed by ECS. That means it’s impossible to change the network configuration once the Task is created. For example, users can’t add or remove an Elastic Network Interface to a running Task.

ECS Fargate also supports the concept of Volumes in a Task. However, the support of volume is somehow limited. A volume in ECS is not backed by cloud storage. Instead, it appears to be just a data volume managed by a local Docker daemon. Moreover, it appears impossible to share a data volume between Tasks in Fargate mode. Therefore, it’s relatively hard to persist or share data within the cloud. However, in the future, this limitation might be mitigated if Fargate integrates with a cloud storage service, such as AWS Elastic Block Store (EBS) or Elastic File System (EFS).

In term of orchestration, the Service concept provides basic orchestration support. Moreover, like OpenStack Zun, ECS is integrated with their orchestration service, AWS CloudFormation, making it possible to orchestrate containers with other AWS resources.

Lastly, it’s worth mentioning that ECS Fargate is integrated with AWS CloudWatch. Basic metrics such as the CPU/memory utilization of individual Service are available at CloudWatch. These metrics can be used to set alarms, perform autoscaling of the Service, or for any other purpose.

Conclusion

We’ve gone over two clusterless container solutions: OpenStack Zun and AWS ECS Fargate. Both allow users to run containers without creating container hosts. In addition, both solutions offer seamless integration with their respective cloud platforms. The main difference between Zun and Fargate is that Fargate is a proprietary technology and Zun is open-source software. Aside from this, ECS Fargate is more opinionated than OpenStack Zun by assuming how applications are deployed. OpenStack Zun gives users finer control of individual containers while ECS Fargate offers high-level constructs for application management.

Of course, the choice between Fargate and Zun depends on your use case. If you’re already a public cloud user with AWS, ECS Fargate might be the obvious choice. If you opt for a private-cloud solution, you can use OpenStack Zun to build your clusterless container cloud. However, if you’re looking for a solution that’s independent of the underlying infrastructure, you might opt for platform-level tools such as Kubernetes. Essentially, what you need is the skill set to manage your own set of servers as well as the control plane of the orchestration platform. In the future, it might be possible to bridge Kubernetes to clusterless technologies so that you can skip the steps for provisioning a set of Kubernetes nodes and launch Kubernetes Pods on demand.

About the author

The post How to run containers without managing clusters using OpenStack Zun appeared first on Superuser.

This is placement update 18-24, a weekly update of ongoing development related to the OpenStack placement service.

It's been quite a while since the last one, mostly because of travel, but also because coming to grips with the placement universe takes some time. Catching up will mean that this update is likely to be a bit long. Bear with it. This is obviously an expand style update (where we add new stuff). Next week will be a contract.

One thing I'd like to highlight is that with the merge of change 560459 we've hit a long promised milestone with placement. Thanks to an initial hit by Eric Fried and considerable followups by Bhagyashri Shewale, we now have rudimentary support in nova for libvirt-using compute nodes that use shared disk to accurately report and claim that disk. Using it requires some currently manual set up for the resource provider associated with the disk and creating the aggregate of that disk with the compute nodes that use it. But: this is one of the earliest promises provided by the placement concept, in the works for more than two years by many different people, finally showing up. Open the bubbly or something, a light celebration is in order.

The flip side of this is that it highlights that we have a growing documentation debt with the many features provided by placement and how to make best use of them in nova (and other services that might like to use placement). Before the end of the cycle we will need to be sure that we set aside a considerable chunk of time to address this gap.

Most Important

Getting nested providers and consumer generations working are still the key pieces of work. See the links in the themes below.

A lot of complicated work is in progress or recently merged and we are getting deeper into the cycle. There are going to be bugs. The sooner we get stuff merged so it has time to interact and we have time to experiment with it the better. And there's also that documentation gap mentioned above.

Also a reminder that for blueprints that have code that is ready for wide review, put it on the runway.

What's Changed

(This is rather long because of the gap since the last report, but also because we've hit a point where lots of stuff can merge.)

Discussion revealed an issue with allocations and inventory that exists on a top-level resource provider which we'd later like to move to a nested provider. An example is VGPU inventory which, until sometime very soon, was represented as inventory on the compute node (I think). Fixing this should be an atomic operation so a spec is in progress for Handling Reshaped Provider Trees. This suggests a new /migrator URI in the placement service, and for the sake of fast-forward-upgrades, a way to reach that URI from a within-process placement service (rather than over HTTP). The PlacementDirect tool has been created to allow this and has merged. Quite a lot of work will need to be done to implement that spec, so I'm going to add it as a theme (below).

Nova now requires the 1.25 placement microversion. It will go up again soon.

The groundwork for consumer generations (including requiring some form of project and user on all allocations) has merged. What remains is exposing it all at the API layer.

The placement version discovery document was incomplete, causing trouble for certain ways of using the openstacksdk. This has been fixed.

Placement now supports granular policy (policy per URI) in-code, with customization possible via a policy file.

A potential 500 when listing usage information has been fixed.

There is now a heal allocations CLI which is designed to help people migrate away from the CachingScheduler (which doesn't use placement).

Nova host aggregates are now magically mirrored as placement aggregates and, amongst other things, this is used to honor the availability_zone hint via placement.

Bugs

• Placement related bugs not yet in progress: 16, same as last time, but a different set of bugs.
• In progress placement bugs 9, -1 on last time.

Specs

Total four weeks ago: 13. Now: 13

Spec-freeze has passed, so presumably exceptions will be required for these. There's already a notional exception for "Reshaped Provider Trees".

• https://review.openstack.org/#/c/549067/ VMware: place instances on resource pool (using update_provider_tree)

• https://review.openstack.org/#/c/552924/ Proposes NUMA topology with RPs

• https://review.openstack.org/#/c/544683/ Account for host agg allocation ratio in placement

• https://review.openstack.org/#/c/552105/ Support default allocation ratios

• https://review.openstack.org/#/c/438640/ Spec on preemptible servers

• https://review.openstack.org/#/c/555081/ Standardize CPU resource tracking

• https://review.openstack.org/#/c/509042/ Propose counting quota usage from placement

• https://review.openstack.org/#/c/560174/ Add history behind nullable project_id and user_id

• https://review.openstack.org/#/c/565730/ Placement: any traits in allocation_candidate query

• https://review.openstack.org/#/c/565741/ Placement: support mixing required traits with any traits

• https://review.openstack.org/#/c/559718/ [WIP] Support Placement in Cinder

• https://review.openstack.org/#/c/572583/ Handling Reshaped Provider Trees

• https://review.openstack.org/#/c/569011/ Count quota based on resource class

Main Themes

"Mirror nova host aggregates to placement" and "Granular" are done, so no longer listed as a theme. "Reshaped Provider Trees" is added because we're stuck if we don't do it.

Nested providers in allocation candidates

Quite a bit of the work related to nested providers in allocation candidates has merged. What remains is on this topic:

• https://review.openstack.org/#/q/topic:placement-return-all-resources

Eric noticed that in this process we've injected some changes in behavior in Rocky in the response to /allocation_candidates without guarding it by microversion changes. There's some discussion about it in IRC. First with me and then later with Jay. The gist is that it's unfortunate that happened, but it's not a disaster and the best outcome is that the diff between Queens and Rocky demonstrates the right behavior.

Consumer Generations

This allows multiple agents to "safely" update allocations for a single consumer. The code is in progress:

• https://review.openstack.org/#/q/topic:bp/add-consumer-generation

As noted above, much of this is merged. Most of what is left is exposing the functionality at the API level.

Reshaped Provider Trees

This allows moving inventory and allocations that were on resource provider A to resource provider B in an atomic fashion. Right now this is a spec on the following topic:

• https://review.openstack.org/#/q/topic:bp/reshape-provider-tree

A glance at the spec will reveal that this is a multi-faceted and multi-party effort. Nine people are listed in the Assignee section.

The placement direct part merged today.

Extraction

The placement db connection change has been previously +W but since had a few merge conflicts. It presumably will merge soon. This will allow installations to optionally use a separate database for placement data. When that merges a zuul change to use it will adjust the nova-next job. The changes required to devstack are already in place.

A stack of changes to placement unit tests to make them not rely on nova.test has merged. There are functional tests remaining which still use that. If you are looking for extraction-related work, finding ways in which nova code is imported but isn't really needed is a good way to make progress.

A while back, Jay made a first pass at an os-resource-classes, which needs some additional eyes on it. I personally thought it might be heavier than required. If you have ideas please share them.

The placement extraction forum session went well. There was pretty good consensus from the people in the room and we got some useful feedback from some operators on how things ought to work.

An area we will need to prepare for is dealing with the various infra and co-gating issues that will come up once placement is extracted.

Other

19 entries four weeks ago. 23 now.

Some of the older items in this list are not getting much attention. That's a shame. The list is ordered (oldest first) the way it is on purpose.

• https://review.openstack.org/#/c/546660/ Purge comp_node and res_prvdr records during deletion of cells/hosts

• https://review.openstack.org/#/q/topic:bp/placement-osc-plugin-rocky A huge pile of improvements to osc-placement

• https://review.openstack.org/#/c/527791/ Get resource provider by uuid or name (osc-placement)

• https://review.openstack.org/#/c/477478/ placement: Make API history doc more consistent

• https://review.openstack.org/#/c/556669/ Handle agg generation conflict in report client

• https://review.openstack.org/#/c/537614/ Add unit test for non-placement resize

• https://review.openstack.org/#/c/493865/ cover migration cases with functional tests

• https://review.openstack.org/#/q/topic:bug/1732731 Bug fixes for sharing resource providers

• https://review.openstack.org/#/c/535517/ Move refresh time from report client to prov tree

• https://review.openstack.org/#/c/561770/ PCPU resource class

• https://review.openstack.org/#/c/566166/ rework how we pass candidate request information

• https://review.openstack.org/#/c/564876/ add root parent NULL online migration

• https://review.openstack.org/#/q/topic:bp/bandwidth-resource-provider add resource_requests field to RequestSpec

• https://review.openstack.org/#/c/575127/ replace deprecated accept.best_match

• https://review.openstack.org/#/c/575222/ Don't heal allocations for deleted servers

• https://review.openstack.org/#/c/575237/ Ignore UserWarning for scope checks during test runs

• https://review.openstack.org/#/c/568965/ Enforce placement minimum in nova.cmd.status

• https://review.openstack.org/#/c/560107/ normalize_name helper (in os-traits)

• https://review.openstack.org/#/c/573475/ Fix nits in nested provider allocation candidates(2)

• https://review.openstack.org/#/c/538498/ Convert driver supported capabilities to compute node provider traits

• https://review.openstack.org/#/c/568639/ Use placement.inventory.inuse in report client

• https://review.openstack.org/#/c/517921/ ironic: Report resources as reserved when needed

• https://review.openstack.org/#/c/568713/ Test for multiple limit/group_policy qparams

End

Yow. That was long. Thanks for reading. Review some code please.

The OpenStack Foundation has begun the process of becoming an umbrella organisation for open source projects adjacent to but outside of OpenStack itself. However, there is no clear roadmap for the transformation, which has resulted in some confusion. After attending the joint leadership meeting with the Foundation Board of Directors and various Forum sessions that included some members of the board at the (2018) OpenStack Summit in Vancouver, I believe I can help shed some light on the situation. (Of course this is my subjective take on the topic, and I am not speaking for the Technical Committee.)

In November 2017, the board authorised the Foundation staff to begin incubation of several ‘Strategic Focus Areas’, including piloting projects that fit in those areas. The three focus areas are Container Infrastructure, Edge Computing Infrastructure, and CI/CD Infrastructure. To date, there have been two pilot projects accepted. Eventually, it is planned for each focus area to have its own Technical Committee (or equivalent governance body), holding equal status with the OpenStack TC—there will be no paramount technical governance body for the whole Foundation.

The first pilot project is Kata Containers, which combines container APIs and container-like performance with VM-level isolation. You will not be shocked to learn that it is part of the Container Infrastructure strategic focus.

The other pilot project, in the CI/CD strategic focus, is Zuul. Zuul will already be familiar to OpenStack developers as the CI system developed by and for the OpenStack project. Its governance is moving from the OpenStack TC to the new Strategic Focus Area, in recognition of its general usefulness as a tool that is not in any way specific to OpenStack development.

Thus far there are no pilot projects in the Edge Computing Infrastructure focus area, but nevertheless there is plenty of work going on—including to figure out what Edge Computing is.

If you attended the Summit then you would have heard about Kata, Zuul and Edge Computing, but this is probably the first time you’ve heard the terms ‘incubate’ or ‘pilot’ associated with them. Nor have the steps that come after incubation or piloting been defined. This has opened the door to confusion, not only about the status of the pilot projects but also that of unofficial projects (outside of either OpenStack-proper or any of the Strategic Focus Areas) that are hosted using on the same infrastructure provided by the Foundation for OpenStack development. It also heralds the return of what I call the October surprise—a half-baked code dump ‘open sourced’ the week before a Summit—which used to be a cottage industry around the OpenStack community until the TC was able to bed in a set of robust processes for accepting new projects.

Starting out without a lot of preconceived ideas about how things would proceed was the right way to begin, but members of the board recognise that now is the time to give the process some structure. I expect to see more work on this in the near future.

There is also a proposed initiative, dubbed Winterscale, to move governance of the foundation’s infrastructure out from under the OpenStack TC, to reflect its new status as a service provider to the OpenStack project, the other Strategic Focus Areas, and unofficial projects.

Storytelling has been vital to passing on knowledge and gaining understanding of the world since we were living in caves. These days, speaking up around diversity and inclusion is a vital way to engage others in change.

At the recent Vancouver Summit, 12 percent of attendees identified as female and there were several events throughout the week to evangelize diversity within the community, including a pre-Summit social, a screening of documentary series “Chasing Grace” and a panel to discuss ways to mentor and grow the next generation of contributors.

Nithya Ruff, senior director of the open source practice at Comcast and an active participant in cross-community diversity initiatives, moderated a panel to discuss why inclusion is so important in open source and the tech industry as a whole.

Referring to the current landscape as “World 2.0,” Ruff explained how the industry is disrupting itself. “Even for how we do the most mundane tasks like booking a taxi, the world that makes [technology] should be diverse so we can reflect the diversity around us,” Ruff said.

Ruff also explained how inclusion also facilitates the reduction of bias, developer engagement and the overall sustainability of open source.

Ruff was joined by four panelists who shared personal anecdotes and advice for improving community inclusion and diversity.

• Bryan Johnson founded Black Boys Code, a nonprofit organization based in Vancouver that introduces boys of color age 8-17 to computer science through workshops, hackathons, after school and summer programs. When it comes to being more inclusive, Johnson recommends the simple task of looking at your LinkedIn profile. “How many people of color, how many women, how many transgender or gay individuals are in your network? That will give you an idea of how far you have to go in terms of inclusion,” he said. “It’s as simple as adding two new people to your LinkedIn network.”
• Joseph Sandoval who’s been in tech for a quarter century, realized 15 years ago there just weren’t enough women and people of color. “It’s critical now that we are actionable by connecting with mentors / mentees and helping people out of bootcamps. I want people to watch what I’m doing: You can have this if you want to work towards it. With more allies coming along, I know we can make change.”
• Amy Marrich chairs of the diversity Working Group in the OpenStack community, leads the Women of OpenStack and is a member of the OpenStack User Committee. “You can come into our community and be whoever you want to be.” Activities that Marrich leads onsite include speed mentoring where XX mentors and XX mentees attended as well as a Git & Gerrit Lunch & Learn that drew 35 attendees after receiving feedback that open source tools were a challenge for people whose first language was not English. “The more we can do to include people who are located somewhere else is invaluable.”
• Jennifer Cloer has been in tech for 17 years. Her current project is an example of how storytelling can change culture. She created the “Chasing Grace Project,” a six-episode documentary series about the industry challenges women face. Her first episode, which was screened at the Summit to a standing-room only crowd, discussed the pay gap.

Opening up about the pay gap

One tangible indicator of progress, the pay gap is the focus of “Chasing Grace’s” first episode. As a preview for the testimonials in the docuseries, Cloer shared stories of women she met who were inspired by the episode to negotiate equal pay to their male counterparts. One was a 17-year old girl with her eye on a computer science degree who was currently working at a yogurt shop. As a result of watching the episode, the girl spoke up to her boss and got a raise to match the wage of her male counterpart.

Bravo @jennifercloer for your brave and important work, “Chasing Grace.” The pay gap is real. And seriously messed up! Thank you #OpenStack Summit for showcasing this! pic.twitter.com/skHjCJuMlZ

— Lisa-Marie Namphy (@SWDevAngel) May 22, 2018

“I’m encouraged because the narrative is starting to change; we are pivoting as an industry,” Cloer said. “But, it’s really early and it’s a marathon and not a sprint.”

Johnson echoed the importance of female inclusion by tapping into his own competitive spirit and desire to be number one.

“If you want to be number one, you have a whole nation where half the population is women who can rise your team to be number one,” he said. “If you really care about being the best you can be, you have this resource pool of brilliant individuals to advance your careers.”

Cloer also reminded the men in the room that all of us have a story and encouraged them to engage as a male ally, which resonated with a story that Sandoval shared around encouraging a coworker who had previously suffered in a toxic work culture.

By attending an event with his coworker and mentoring her through the following year’s event, he helped instill the confidence she needed to get internal stakeholders to pull an event sponsorship together. Now, she’s establishing herself as a leader at their organization and is well poised to reach C-suite level, says Sandoval.

Meaningful mentorship can be a 15-minute breakfast

While there are different degrees of mentorship, each of the panelists joined Sandoval in emphasizing how much difference a helping hand can make.

Marrich told the story of a man who leads the OpenStack User Group in South Africa who asked to meet for breakfast during the Barcelona Summit. He asked for advice on a local meetup he was organizing and she shared her training materials. Two months later, he followed up thanking Marrich and letting her know how well the material worked.

“It was a 15-minute conversation that changed not one life, but multiple lives of the people in attendance,” Marrich said.

Diversity takes many forms & is truly global. @CHAOSSproj is gathering multi inputs from across open source communities. @spotzz_ #OpenStackSummit pic.twitter.com/theH3cxDpI

— Nicole Huesman (@uoduckswtd) May 22, 2018

Sandoval related how his career was started by three women that helping him get into this industry. They looked at the inner person and championed, challenged him.

“In the context of open source, there is a bias,” he said. “Get the bias out of the way to get in the door to show your value. If you’re in a community, and you see someone trying to enter, try to remove the mystery behind it.”

Johnson also spoke about how Black Boys Code has created an academic environment where boys are not only learning, but excited about it. He told a story about one of the participants in the program whose mother found him still coding at 11:30 p.m.

“For me, the language is academic. It’s about getting the kids interested in coding,” he said. “Now, the school boards are contacting Black Boys Code.”

Making diversity initiatives mainstream

A member of the audience raised an important question at the end—with the increasing importance of diversity and inclusion, how we can get more people’s attention and action? Ruff put this question to the audience explaining that even at software conferences, the software and the products are only as successful as the diversity of people contributing.

“The health of a project or open source is not just measured by the maturity of the project or the number or pull requests,” she said. “It’s measured by the vibrancy and diversity of the community and how inclusive the community is.”

While there are ideas around how different events can incorporate more diversity conversations, the takeaway from this panel is to get involved and more importantly, tell your story.

To catch all the stories from the full 40-minute panel, watch the Vancouver Summit video below.
Have your own story to share? Contact editorATopenstack.org or submit it to the Berlin Summit call for presentations, deadline July 17.

The post The power of speaking up, speaking out about diversity appeared first on Superuser.

Every month, thousands of people open up the OpenStack contributor documentation to learn how to contribute to OpenStack.

Every Summit (and at OpenStack Days around the world), the OpenStack Upstream Institute (OUI) training helps new community members quickly get started being active contributors. Despite both teams working on helping contributors get started, these efforts were often done in parallel. For the Vancouver Summit, we wanted to shake up how we run OUI and help new contributors learn to navigate documentation: Enter the Contributor Guide!

The Contributor Guide, accessed through the OpenStack Contributor Portal, is a beginner-friendly tool for getting up to speed on a variety of contribution activities. There are sections on being a user, an operator and a code/documentation contributor.

With each OUI training, we learn how to make OUI more effective and engaging. First, we added more exercises to keep students attentive and interested, then we focused on moving away from a lecture-style course to a hands-on lab. Instead of using slides to deliver content (how boring!) the only slides shown pointed students to relevant sections of the Contributor Guide and to introduce exercises.

This format allows students to learn at their own pace and easily revisit topics where they need more time. The exercises kept everyone on the same page and pushed students to interact with one another and use the tools we use in our community, like IRC and Etherpad, to work collaboratively.

The feedback from both students and OUI mentors was overwhelmingly positive. Everyone loved the self-driven format and the decreased “lecture” time. Teaching from the Contributor Guide was a roaring success and we are excited to continue to build out the Guide and make it an even better resource for future students and people interested in becoming a contributor.

Get involved

We’ll be hosting more OUI trainings at OpenInfra Day Korea, OpenStack Day Brazil and OpenStack Day Nordics, as well as before the Summit in Berlin later this year. Come join us if you want to learn how to contribute upstream!

The Contributor Guide has come a long way in the last year, but there’s still a lot of work to be done. If you’re a user, especially an operator, we need your help! Those are the next sections of the Contributor Guide that need more content and expert input. Work on the Contributor Guide is being tracked in Storyboard if you want to get involved with planning the new content.

The post Learn at your own pace: How the OpenStack Upstream Institute leverages the Contributor Portal appeared first on Superuser.

Here's TC Report 24. The last one was 4 weeks ago, itself following a gap. In the intervening time new TC members (Graham Hayes, Mohammed Naser, and Zane Bitter) and a new Chair (Doug Hellman) have found their feet very well, we had a successful and moderately dramatic OpenStack Summit in Vancouver, and there have been some tweaks to how the TC reports its actions and engages with the community.

There's a refreshed commitment to using email to give regular updates to in-progress TC activity, including a somewhat more detailed official weekly status, as well as increased use of StoryBoard to track goverance changes.

The Technical Committee Tracker wiki page now includes expanded information on in-progress initiatives and there's a health tracker page listing liaisons for working groups, SIGs, and project teams and outstanding issues those groups are facing.

The thrice-weekly office hours are now logged by meetbot to make them easier to find. Here, for example, is today's.

All of these things are designed to increase the visibility and accessibility of the work being done by the TC and many other people.

This is all great. Since becoming aware of the TC, enhancing visibility and engagement has been one of my main goals so this is something like success.

But it does present a bit of a problem for what to do with these reports; there's a lot of other reporting going on.

My intention was always to provide a subjective insight into the activity of the TC and by reflection the entire OpenStack community. Over the course of the year of my first term the subjectivity ebbed and flowed as the value of simply pointing at stuff was made clear.

Things are different, lots of people are pointing to lots of things, so perhaps now is a good time to restate my assumptions.

1. An important, if not the most important, job of the TC is to represent and improve the situation of the people who elected them, the so-called "technical" contributors.

2. Representing people means listening to, observing, and engaging with people. Improving things means change.

3. In either activity, with any group of any size, the possibilities for different understandings of meaning of events, actions and terms are legion. Resolving those differences to some kind of consensual reality, a shared understanding, is what the TC must do with much of its time. It is why we (or any group) chat so much.

4. It is exceptionally easy to believe that a group has reached a shared understanding and for that not to be the case. Earlier today four TC members were struggling to agree on what "cloud" means despite working to build it for several years.

5. The differences of understanding can be incredibly nuanced, but remarkably important.

6. Resolving those differences leads to better representation and better action so highlighting them, though often contentious, can lead to better results.

With those in mind, where I imagine these reports can continue to provide some value is subjectively interpreting the meaning emerging from the various TC-related discussions (in all media) to provide a focal point (one of many, I hope) for me and anyone else to speculate on where those meanings fall short, collide or woot, nailed it. We can do a little recursive dance of feedback and refinement.

I'm not fully back in the loop, and this is long enough already, so look for something of substance next week. In the meantime, here are a few links to discussions in progress where there's been some emerging understanding:

• recent office hours logs
• review of requirements for affiliation diversity
• review principles, including "less nitpicking"
• making Castellan a base service
• ongoing updates on the status of StarlingX

Acknowledgement: Thanks to persia for helping to crystallize some of these thoughts.

BUDAPEST — More than 200 people gathered at the fifth annual OpenStack Days Budapest, organized by local community members Marton Kiss and Mark Korondi, to share their stories, recruit and build relationships. A few notable firsts: sessions about edge computing, GPUs and cryptocurrency, as well as sponsorships from Silicon valley storage firms Datera and SoftIron.

@OpenStack around the globe!! Budapest is the next stop to bring the community together, meet with users and developers, get to know what they are doing and talk about future plans and ideas! @OpenStackCEEDay pic.twitter.com/dzMEwfLeMy

— Ildiko Vancsa (@IldikoVancsa) June 6, 2018

Talking to the crowd, there were quite a few new OpenStack users ramping up their clouds and keen on getting more involved with the community. We told more than one person to “subscribe to the operator’s mailing list!” to take advantage of the global community of users who have blazed trails.

Genesis Cloud: Building the largest GPU cloud in the world

One of those new users is startup Genesis Cloud, based in Munich. The team of three spun off from Genesis Mining, which provides specialized GPU infrastructure to more than two million bitcoin miners at an efficient, low cost. (The GPUs are used for mining Ethereum, Monero, ZCash etc.) They have incorporated the sister company Genesis Cloud this year with the goal to serve a growing number of use cases for GPUs, leveraging their knowledge and expertise from the large-scale bitcoin mining operation.

While the number of use cases for GPUs is growing — including video transcoding, machine learning and of course gaming — the market price for GPUs from major public cloud providers is extremely high, even with spot pricing. Genesis Cloud wants to lower the barrier to entry by leveraging the efficiency and learnings from the bitcoin mining operation, while also using systems like OpenStack and Kubernetes for software-defined operations. As a result, they want to offer the largest, most price competitive GPU public cloud.

The team attended the Vancouver Summit in May, including Upstream Institute and is anxious to contribute and get more involved in the community. They have been participating in the relatively new Cyborg project, a management framework for hardware accelerators. The Genesis Cloud team is aggressively hiring, so check out their postings on the OpenStack jobs board.

CERN continues to go big and go boldly

Tim Bell gave an update on CERN’s OpenStack cloud, especially relevant because CERN runs several data centers in Hungary. It’s always incredible to hear the stats coming out of the Large Hadron Collider, such as the fact they take 40 million pictures per second when smashing particles, generating more than 1 petabyte of data each second.

Data is immediately filtered down so that only about 20-25GB per second is sent to the computing center via high-speed networking connections. The computing power behind the CERN cloud is more than 300,000 cores and 38,000 virtual machines running OpenStack, and CERN also runs one of the largest Kuberenetes deployments across their public and private cloud environments.

Keep calm and reboot
Wise words from @noggin143 #OpenStack #Budapest pic.twitter.com/f405hlzD29

— OpenStack CEE Day (@OpenStackCEEDay) June 6, 2018

One new update from the CERN team is their use of the OpenStack Mistral workflow service to define a repeatable workflow for burn-in and reallocation of machines. They’ve made all of the code they used publicly available in the OpenStack ops repos.

Bell also talked about how CERN operators dealt with Spectrum/Meltdown vulnerability in January, which required a reboot all of their VMs. They divided the environment into seven sections and rebooted a new section every other day over two weeks. As part of the process, they also developed automation that will allow them to deal with any similar issues in the future more easily.

Nokia zooms into the 100K core club

Nokia runs one of the largest OpenStack clouds you didn’t know about. Several team members from Nokia explained how they are using OpenStack as a product, in their products and in their research and development labs. Nokia has two OpenStack distributions, including one tailored for edge computing and they are actively using Swift to host the docker registry for their VNFs. The team actively contributes to Vitrage, root cause analysis, and Mistral, which is an interesting tie-in to the CERN use case.

Looking ahead to the Berlin Summit and Upstream Institute

The next OpenStack Summit in Berlin, November 13-15, will be the closest global event yet to the Central & Eastern European community. Prior to each Summit, community members run a program called Upstream Institute, created for new contributors who want to learn more about open source, and specifically OpenStack, tools and processes. If you want to get started contributing to OpenStack or other open source projects, save the date for this free event on November 11-12, and meet many of the community members from Hungary who keep it running! More details coming soon.

The videos from this year’s OpenStack Days CEE will be posted to the team’s YouTube channel shortly.

The post Use cases, growing scale and open infrastructure at OpenStack Days Budapest appeared first on Superuser.

Kubicorn is a magical project that helps a user manage cloud infrastructure for Kubernetes.

Creator Kris Nova says her pet project was written “out of spite and frustration,” with Kops. It was open-sourced in 2017 and took off at a gallop.  Nova, currently developer advocate at Heptio, is a Kubernetes maintainer, a maintainer of Kubernetes Kops and co-author of the book “Cloud Native Infrastructure: Patterns for Scalable Infrastructure and Applications in a Dynamic Environment.”

“I didn’t really expect it to actually be a thing and it inadvertently turned into a thing,” Nova says.  After Kubicorn made it to Hacker News, it skyrocketed to the number one Golang project on GitHub. Why name it after the legendary creature? That started out as a challenge: a friend said it would be impossible to get infrastructure engineers to talk about unicorns and yet, two years later, she has.

Meet Kubicorn

For starters, it’s a command-line tool but more than that. Think of it as remote command injection — a tool that creates infrastructure and then runs arbitrary commands on it for basic provisioning tooling. Written as library, it allows users to build out their own tools around it. For example at Heptio, it’s wrapped up as a Jenkins job to create Kubernetes clusters on the fly.

Another important characteristic: it’s API driven. “It’s basically a contract that says we will speak these data structures and if you plug them into the rest of the program you can create Kubernetes, so it’s agnostic in that way,” she says.

Last but not least, as an infrastructure engineer Nova says it also offers a magic word she really enjoys seeing around any type of infrastructure provisioning: atomic. That means you either get the infrastructure requested or you get nothing. “There’s no middle ground, there’s no intermediary stage where you get half of your infrastructure or maybe some virtual machine setup but DNS isn’t working,” she says adding that if it fails it “fails nicely,” it will undo itself, clean up all the resources and you can try again, fixing whatever the problem was.

At the recent OpenStack Summit Vancouver, she offered up a demo that gives a tour of the Kubicorn code base and creates a cluster. It’s worth a watch both because it is truly “rad” and involves a rainbow of code.

Get involved

Dive into the Kubicorn documentation or check out the code. If you have questions, send them to the public mailing list.

The team holds developer calls biweekly on Tuesdays, 1p.m. Pacific Time. Join the mailing list to get a calendar invite.

Catch her whole 45-minute session below.

The post Magical cloud native infrastructure with Kubicorn appeared first on Superuser.

Here is a scientific computing-focused summary of some discussions during the OpenStack Forum. The full list of Etherpads is available at: https://wiki.openstack.org/wiki/Forum/Vancouver2018

This post jumps into the middle of several ongoing conversations with the upstream community. In an attempt to ensure this is published while still relevant, I’ve only spent a limited amount of time setting context around each topic. Hopefully, it’s still a useful collection of ideas from the recent Forum discussions.

As you can see from the pictures the location was great, the discussions were good too…

Role-Based Access Control and Quotas

The refresh of OpenStack’s policy system is going well. RBAC in OpenStack is still suffering from a default global admin role and many services allowing access to all but global admin things when you have any role in a given project. Care to define the scope of each API action (system vs. project scope) and mapping to one of the three default roles (read-only, member, admin) should help get us to a place where we can add some more interesting defaults.

Hierarchical Quotas discussions were finally more concrete, with a clear path towards making progress. With unified limits largely implemented, agreement was needed on the shape of oslo.limits. The current plan focuses around getting what we hope is the 80% use case working, i.e. when you apply a limit, you have the option of ensuring it also includes any resources used in the tree of projects below. There was an attempt to produce a rule set that would allow for a very efficient implementation, but that has been abandoned as the rule set doesn’t appear to map to many (if any) current use cases. For Nova, it was discussed that the move to using placement to count resources could coincide with a move to oslo.limits, to avoid too many transition periods for operators that make extensive use of quotas.

Preemptible servers

To understand the context behind preemptible servers, please take a look at the video of a joint presentation I was involved with: Containers on Baremetal and Preemtable VMs at CERN and SKA.

The preemptible servers effort is moving forward, hoping to bring higher utilization to clouds that use quotas to provide a level of fair sharing of resources. The prototype being built by CERN is progressing well and Nova changes are being discussed in a spec. There was agreement around using soft shutdown to notify the running instance that its time is up.

The previous nova-spec blocker around the notifications has been resolved. The reaper only wants a subset of the notifications, while at the same time not affecting Ceilometer or other similar services. First, we agreed to consider the schedule_instances notifications for this purpose and proposed looking at the routing backend for Oslo messaging to ensure the reaper only gets a subset of the notifications.

I personally hope to revisit Blazar once preemptible servers are working. The current future reservation model in Blazar leads to much underutilization that could be helped by preemptibles. Blazar also seems too disconnected from Nova’s create server API. I do wonder if there’s a new workflow making use of the new pending instance status that would feel more cloud native. For example, when a cloud is full, rather than having a reaper to delete instances to make space, maybe you also have a promoter that helps rebuild pending instances as soon as some space becomes free, and maybe says only pick me if all the instances in the group can be built, and you will let me run for at least eight hours. More thought is required, ideally without building yet another Slurm/HTCondor like batch job scheduler.

Federation

Federation was a big topic of conversation, with the edge computing use cases being heavily discussed. Hallway track conversations covered discussions of the AARC Blueprint Architecture, eduGain Federation Architectures and relating them back to keystone. There’s a blog post brewing on the work we at StackHPC have done with STFC IRIS cloud federation project.

The AARC blueprint involving having a “proxy” that provides a single point of management for integrating with multiple external Identity Providers. It uses these IdPs purely for authentication. Firstly allowing for multiple ways of authenticating a single user, and centralizing the decisions of what that user is authorized to do, in particular it holds information on what virtual organizations (or communities) that user is associated to, and what roles they have in each organization. Ideally the task of authorizing users for a particular role is delegated to the manager of that organization, rather than the operator of the service. When considering the later part of the use case, this application becomes really interesting (thanks to Kristi Nikolla for telling me about it!): https://github.com/CCI-MOC/ksproj

Pulling these ideas together, we get something like this:

Talking through a few features of the diagram it is worth noting:

• Authentication to central Keystone is via an assertion from a trusted Identity Provider, mapped to a local user via federation mapping, such that additional roles can be assigned locally, optionally via ksproj workflows
• Authentication to leaf keystone is via assertion from the central keystone, authorization info extracted via locally-stored federation mapping
• App Creds are local to each Keystone
• There can also be a sharing of Keystone tokens, and having all those regions listed in each others service catalog.
• There is no nasty long distance sync of Keystone databases

It’s believed this should work today, but there are some things we could consider changing in keystone:

• Federation mappings of groups and projects + roles are inconsistent. One lasts for the life of the keystone token, another lasts forever. One is totally ephemeral, the other is written in the DB. One refreshes the full list of permissions on each authentication, the other can be used to slowly accrue more and more permissions as assertions change over time. For the leaf keystone deployments, a refresh on every authentication, with a time to live applied to the group membership added into the DB.
• Note that using groups in the federation maps breaks trusts and application credentials, among other things this breaks Heat and Magnum. Ideally the above federation mapping work ensures all things are written to the database in a way that ensures trusts and application credentials work (see https://bugs.launchpad.net/keystone/+bug/1589993)
• Keystone to Keystone federation is fairly non-standard (see http://www.gazlene.net/demystifying-keystone-federation.html) as it is IdP initiated, not the more “normal” SP initiated federation. We should be able to make both configurations possible as we move to SP initiated keystone to keystone federation
• No central service catalog, without allowing tokens to work across all those regions. Might be nice to have pointers to service catalogs in the central component (this could be the list of service providers used for keystone to keystone federation, but this seems to not quite fit here).

It turns out, the edge computing use cases have very similar needs. Application credentials allow scripts to have a user local to a specific keystone instance, in a way that authentication still works even when the central federation keystone isn’t available.

There’s a lot more to this story, and we hope to bring you more blog entries on the details very soon!

Ironic

Lots of usage, including from some of the largest users (looking at you Yahoo/Oath). The effort around extending traits so it gives deploy templates seems really important for lots of people. Of particular interest was the engagement of RedFish developers. In particular, interest around making better use of the TPM and better and more efficient cleaning of a system, including resetting all firmware and configuration.

Kayobe, Kolla and Kolla-Ansible

There seems to be growing usage of Kolla containers, in particular Triple-o has moved to use them (alongside kolla-ansible). There was talk of more lightweight alternatives to Kolla’s containers (as used by openstack-ansible I think), but folks expressed how they liked the current extensibility of the Kolla container workflow.

StackHPC makes use of Kayobe, which combines kolla-ansible and bifrost. We discussed how the new kolla-cli built on top of kolla-ansible and used by Oracle’s OpenStack product could be made to work well with kayobe and its configuration patterns. We also spoke a little about how Kayobe is evolving to help deal with different kolla-ansible configurations for different environments (for example production vs pre-production).

Manila

Interesting conversations about CephFS support and usage of Manila from both CERN and RedHat. There was talk about how it is believed that a large public cloud user makes extensive use of Manila, but they were not present to comment on that. Some rough edges were discussed, but the well-trodden paths seem to be working well for many users.

Glance and the Image Lifecycle

Glance caching was discussed, largely thinking about edge computing use cases, but the solution is more broadly applicable. It was a reminder about how you can deploy additional glance API servers close to the places that want to download, and it will cache images on its local disk using a simple LRU policy. While that is all available today, and I remember working on using that when I worked at Rackspace public cloud, there were some good discussions on how we could add better visibility and control, particularly around pre-seeding the cache with images.

Personally I want to see an OpenStack ecosystem wide way to select “the latest CentOS 7” image. Currently each cloud, or federation of clouds, ends up building their own way of doing things a bit like that. Having helped run a public cloud, the “hard” bit is updating images with security fixes, without breaking people.

This discussion led to the establishing of three key use cases:

Cloud operator free to update “latest” images to include all security fixes, while not breaking:

• By default, list images only shows the “latest” image for each image family
  • Users can request the “latest” image for a given family, ideally with the same REST API call across all OpenStack certified clouds
  • Users automation scripts request a specific version of an image via image uuid, allowing them to test any new images before having to use them (From a given image the user is consuming, it should be easy to find the new updated image)
• Allow cloud operators to stop users booting new servers from a given image, hiding the image from the list of images, all without breaking existing running instances

In summary, we support (and recommend) this sort of an image lifecycle:

• Cloud operator tests new image in production
• Optional, public beta for new image
• Promote image to new default/latest image for a given image family
• Eventually hide image from default image list, but users can still use and find the image if needed
• Stop users building from a given image, but keep image to not break live migrations
• Finally delete the image, once no existing instances require the image (may never happen).

Things that need doing to make these use cases possible:

• Hidden images spec: https://review.openstack.org/#/c/545397/
• CLI tooling for “image family” metadata, including server side property verification, refstack tests to adopt family usage pattern
• Allow Nova to download a deactivated image, probably using the new service token system that is used by Nova when talking to Neutron and Cinder.

OpenStack upgrades

It seems there’s agreement on how best to collaborate upstream on supporting OpenStack releases for longer, mostly due to agreeing the concept of fast forward upgrades. The backporting policy has been extended to cover these longer lived branches. By the next Forum, we will have the first release branch go into extended maintenance and could have some initial feedback on how well the new system is working.

Kubernetes

Did I put this section in to make my write-up more cool? Well no, there is real stuff happening. The OpenStack provider and the community interactions are evolving at quite a pace right now.

Using Keystone for authentication and possibly authorization, looked to be taking shape. I have yet to work out how this fits into the above federation picture, longer term.

When it comes to Nova integration, you can install Kubernetes like any other service, Magnum is simply one way you can offer that installation as a service.

Looking at Cinder there are two key scenarios to consider: First, consider Kubernetes running inside an OpenStack VM, Secondly consider running Kubernetes on (optionally OpenStack provisioned) baremetal. Given that much work has been done around Cinder, let us consider that case first. When running in a VM, you want to attach the cinder volume to the VM via Nova, but when in baremetal mode (or indeed an install outside of OpenStack all together) you can use cinder to attach the volume inside the OS that is running k8s. The plan is to support both cases, with the latter generally being called “standalone cinder,, focused on k8s deployed outside of OpenStack.

It will be interesting to see how this all interacts with the discussions around natively support multi-tenancy in k8s, including the work on kata-containers (https://blog.jessfraz.com/post/hard-multi-tenancy-in-kubernetes/).

It does seem like many of these approaches are viable, depending on your use case. For me, the current winner is using OpenStack to software define your data center, and treating the COE as an application that runs on that infrastructure. Magnum is a great attempt at providing that application as a service. Deployment on both Baremetal and VMs makes sense depending on the specific use case involved. More details on how I see some of this currently being used is available in this presentation I was involved with in Vancouver: https://www.openstack.org/videos/vancouver-2018/containers-on-baremetal-and-preemptible-vms-at-cern-and-ska

Cyborg and FPGAs

I am disappointed to not have more to report here. OpenStack now has reasonable GPU and vGPU support, but there appears to be little progress around field-programmable gate arrays. Sadly it is currently a long way down the list of things I’d like to work on.

There was discussion on how the naive PCI passthrough of the FPGA is a bad idea because an attacker would be able to damage the hardware. There does appear to be work on proprietary shells that allow a protected level of access. There was also discussion on how various physical interfaces (such as a network interface, DMA to main memory) will be integrated on the board containing the FPGAs, and how that could be properly integrate with the rest of OpenStack.

There does also appear to be some interest in delivering specific pre-build accelerators build using FPGAs, and some discussion on sharing function contexts and multi-tenancy, but there seemed to be few specifics being shared.

On reflection the ecosystem still seems very vendor specific. As various clouds offer a selection of different services based around FPGAs, it will be interesting to see what approaches gain traction. This is just one example of the possible approaches: https://github.com/aws/aws-fpga/blob/master/hdk/docs/AWS_Shell_Interface_Specification.md

Monitoring and self-healing

There are way more interesting sessions than one person can attend, and this section of the update suffers from that. I hope to read many of the other Forum summary blog posts as they start to appear.

Discussing NFV related monitoring and self-healing requirements, it became clear the use cases are very similar to those of some Scientific workloads. Fast detection of problems appeared to be key.

Personally I enjoyed the discussion around high resolution sampling and how it relates to pull (Prometheus) vs push (OpenStack Monasca) style systems. I had forgotten that you can do high resolution sampling processing in a distributed way, i.e. locally on each node (not unlike what mtail can do for logs when using Prometheus). You can then push alarms directly from the node, alongside pulling less time critical messages (i.e. being both a prometheus scrape endpoint and a client to prometheus alert manager). Although it sounds dangerously like an SNMP trap, it seems a useful blend of different approaches.

Scientific SIG

It was great to see the vibrant discussions and lightning talks during the Scientific Special Interest Group sessions. I’m even happier seeing those discussion spilling out into all the general Forum sessions thought the week, as I am attempting to document here. For example, it was great to see the overlap between the telco (edge/NFV/etc.) use cases and the scientific use cases.

I was humbled to win the lightning talk prize. If you want to find out more about the data accelerator I’m helping build, please take a look at: https://insidehpc.com/2018/04/introducing-cambridge-data-accelerator/

Overall

I feel energized after attending the Forum in Vancouver. I was in lots of Forum sessions that saw real progress made by having engagement from a broad cross section of the community. There was a great combination of new and old voices, all working towards getting real stuff done with OpenStack. I hope the only material change to the Forum, PTG and Ops summit is to have the events back to back in the same location. I’m all for being more efficient, but we must keep the great open collaboration.

This post first appeared on StackHPC.

Photo // CC BY NC

The post What’s on the horizon for high-performance computing appeared first on Superuser.

BUDAPEST — Code has been called the next universal language, but it still needs some traditional language to be understood around the world.

At the OpenStack Day CEE, Frank Kloeker, technology manager of cloud applications at Deutsche Telekom, gave an update on the OpenStack Internationalization (I18N) community team which he currently leads. Kloeker is a great example of how to contribute to an open-source community without necessarily being a programmer. When he’s not coordinating translation efforts, he’s also a core reviewer on the docs team, participates in several different working groups and SIGs and is helping prepare some big ideas for the upcoming Summit in Berlin.

The mission of the Internationalization team is to make OpenStack accessible to people of all language backgrounds. It’s a diverse and vibrant team that’s very important to the success of the project. Recent projects include translating the Edge Computing whitepaper into seven languages, in addition to the important install guides and technical documentation.

The i18n team at a glance:

• 2,719,377 words translated
• 95 project modules collaborating
• 32 languages supported (17 in the Queens release)
• 299 translators (55 active in Queens)
• 35 companies supporting the project

There’s so much potential content to translate that as team leader one of Kloeker’s biggest responsibilities is to prioritize the work. He does this based on user feedback, including the survey, developer feedback and understanding which projects are the most heavily used (for example, the most popular modules for the Horizon dashboard). He’s also constantly thinking about onboarding new translators, helping train core reviewers and helping grow future project leaders.

Communication is always a challenge, especially with a global team working across time zones. The work is organized by language teams and there are also project liaisons that provide a connection point to the various upstream projects and developers. The team stays in touch with weekly meetings alternating time zones, as well as IRC and of course mailing lists.

The team uses two primary tools: Zanata, an open-source platform that helps prioritize and coordinate the translation work and the Sphinx documentation tool. There’s also a new platform for translators to check their translations of the Horizon dashboard in context using a near real-time check site that’s easy to install locally. It was a collaborative effort between the i18n, OpenStack Ansible and Horizon teams.

Get involved

Want to get involved? Becoming a translator is a great way to give back to the community, especially if you don’t have programming skills. It’s also a great way to learn more about the projects as you read and translate documentation, which may help you get plugged into other teams or workstreams in the project.

Get in touch with the team on IRC: #openstack-i18n
Check out meetings, held alternating meetings every Thursday at 7:00 or 13:00 UTC
Dive into the documentation: docs.openstack.org/i18n
Take a look at Frank Kloeker’s presentation slides

Photo // CC BY NC

The post Cracking the code: How a volunteer team translated 2.7 million words appeared first on Superuser.

Who’s up for a rematch? Rocky Milestone 2 is here and we’re ready to rumble! Join us on June 14 & 15 (next Thursday and Friday) for an awesome time of taking down bugs and fighting errors in the most recent release. We won’t be pulling any punches.

Want to get in on the action? We’re looking for developers, users, operators, quality engineers, writers, and, yes, YOU. If you’re reading this, we think you’re a champion and we want your help!

Here’s the plan:
We’ll have packages for the following platforms:
* RHEL 7
* CentOS 7

You’ll want a fresh install with latest updates installed so that there’s no hard-to-reproduce interactions with other things.

We’ll be collecting feedback, writing up tickets, filing bugs, and answering questions.

Even if you only have a few hours to spare, we’d love your help taking this new version for a spin to work out any kinks. Not only will this help identify issues early in the development process, but you can be the one of the first to cut your teeth on the latest versions of your favorite deployment methods like TripleO, PackStack, and Kolla.

Interested? We’ll be gathering on #rdo (on Freenode IRC) for any associated questions/discussion, and working through the “Does it work?” tests.

As Rocky said, “The world ain’t all sunshine and rainbows,” but with your help, we can keep moving forward and make the RDO world better for those around us. Hope to see you on the 14th & 15th!

This three-part series was written by Mina Andrawos, author of  “Cloud Native programming with Golang,” which provides practical techniques and architectural patterns for cloud native micro-services. He’s also the author of the “Mastering Go Programming” and the “Modern Golang Programming” video courses.

This series hopes to shed some light and provide practical input on some key topics in the modern software industry, namely micro-services, cloud native applications, containers and serverless applications. It will cover both practical advantages and disadvantages of these technologies.

Micro-services

Micro-service architecture has gained a reputation as a powerful approach for building modern software applications. So what are micro-services? Micro-services separate the functionality required from a software application into multiple independent small software services. Each of these micro-services is responsible for an individual focused task. In order for micro-services to work together to form a large scalable application, they must communicate and exchange data among multiple servers, a practice known as horizontal scaling.

Each service can be deployed on a different server with dedicated resources or in separate containers (more on that below.) These services can be written in different programming languages, enabling greater flexibility and allowing separate teams to focus on each service, rendering the final application of higher quality.

Another notable advantage to using micro-services is the ease of continuous delivery, or the ability to deploy software often and at any time. Micro-services make continuous delivery easier because a new feature deployed to one micro-services is less likely to affect other micro-services.

Cloud native applications

Micro-service architectures are a natural fit for cloud native applications  — applications built from the ground up for cloud computing. An application is cloud native if designed with the expectation of deploying on a distributed and scalable infrastructure.

For example, building an application with a redundant micro-services architecture – we’ll see an example shortly – makes the application cloud native, since this architecture allows our application to be deployed in a distributed manner that allows it to be scalable and almost always available. A cloud native application doesn’t need to always be deployed to a public cloud like Amazon Web Services, it can be deployed to distributed cloud-like infrastructure as well.

In fact, what makes an application fully cloud native goes beyond just using micro-services. Your application should employ continuous delivery, the ability to continuously deliver updates to your production applications without disruptions. Your application should also make use of services like message queues and technologies like containers (covered in the next section).

Cloud native applications assume access to numerous server nodes, having access to pre-deployed software services like message queues or load balancers, ease of integration with continuous delivery services, among other things.

If you deploy your cloud native application to a commercial cloud like AWS or Azure, your application has the option to utilize cloud-only software services. For example, DynamoDB is a powerful database engine that can only be used on AWS for production applications. Another example is the DocumentDB database in Azure. There are also cloud-only message queues such as Amazon Simple Queue Service (SQS), that can be used to allow communication between micro-services in the Amazon Web Services cloud.

As mentioned earlier, cloud native micro-services should be designed to allow redundancy between services. If we take the events booking application as an example, the application will look like this:

Multiple server nodes would be allocated per micro-service, allowing a redundant micro-services architecture to be deployed. If the primary node or service fails for any reason, the secondary can take over ensuring lasting reliability and availability for cloud native applications. This availability is vital for fault intolerant applications such as e-commerce platforms, where downtime translates into lost revenue.

A notable tool worth mentioning in the world of micro-services and cloud computing is Prometheus. Prometheus is an open-source system monitoring and alerting tool that can be used to monitor complex micro-services architectures and send alerts when action needs to be taken. Originally created by SoundCloud to monitor their systems it grew to become an independent project and is now a part of the Cloud Native Computing Foundation.

Containers

A container is simply the idea of encapsulating some software inside an isolated user space or “container.” For example, a MySQL database can be isolated inside a container where the environmental variables and the configurations that it needs will live. Software outside the container will not see the environmental variables or configuration contained inside the container by default. Multiple containers can exist on the same local virtual machine, cloud virtual machine, or hardware server.

Containers provide the ability to run numerous isolated software services, with all their configurations, software dependencies, run times, tools, and accompanying files, on the same machine. In a cloud environment, this ability translates into saved costs and efforts, because the need for provisioning and buying server nodes for each micro-services will diminish since different micro-services can be deployed on the same host without disrupting each other. Containers combined with micro-services architectures are powerful tools to build modern, portable, scalable and cost-efficient software. In a production environment, more than a single server node combined with numerous containers would be needed to achieve scalability and redundancy.

Containers add more benefits to cloud native applications. With a container, you can move your micro-services, with all the configuration, dependencies and environmental variables that it needs, to fresh server nodes without the need to reconfigure the environment, achieving powerful portability.

Due to the power and popularity of the software containers technology, some new operating systems like CoreOS or Photon OS are built from the ground up to function as hosts for containers.

One of the most popular software container projects in the software industry is Docker. Major organizations such as Cisco, Google and IBM utilize Docker containers in their infrastructure as well as in their products. Another notable project in the software containers world is Kubernetes. Kubernetes is a tool that allows the automation of deployment, management, and scaling of containers. Built by Google to facilitate the management of their containers, Kubernetes provides some powerful features such as load balancing between containers, restart for failed containers, and orchestration of storage utilized by the containers.

Disadvantages of cloud native computing

It’s important to a point out the disadvantages of these technologies. One notable drawback of relying heavily on micro-services is that they can become too complicated to manage in the long run as they grow in numbers and scope. There are approaches to mitigate this by utilizing monitoring tools such as Prometheus to detect problems, container technologies such as Docker to avoid polluting the host environments and avoid over-designing the services. However, these approaches take effort and time.

For cloud native applications, if the need arises to migrate some or all of the applications, some challenges will be faced. There are multiple reasons for that, depending on where your application is deployed.

One is that if your cloud native application is deployed on a public cloud like AWS, cloud native APIs are not cross-cloud platform. For example, a DynamoDB database API utilized in an application will only work on AWS but not Azure, since DynamoDB only belongs to AWS. The API will also never work in a local environment because DynamoDB can only be utilized in AWS in production.

Another reason is that there are some assumptions made when some cloud native applications are built, such as the fact that there will be virtually unlimited number of server nodes to utilize when needed and that a new server node can be made available very quickly. These assumptions are sometimes hard to guarantee in a local data center environment, where real servers, networking hardware and wiring need to be purchased.

In the case of containers, sometimes the task of managing them can get rather complex for the same reasons as managing expanding numbers of micro-services. As containers or micro-services grow in size, there needs to be a mechanism to identify where each container or micro-services is deployed, what their purpose is and what they need in resources to keep running.

Serverless applications

Serverless architecture is a new software architectural paradigm that was popularized with the AWS Lambda service. To fully understand serverless applications, let’s start by defining function-as-a-service (FaaS.) This is the idea that a cloud provider such as Amazon or even a local piece of software such as Fission.io or funktion provides a service where a user can request a function to run remotely in order to perform a very specific task and then after the function concludes, the function results return back to the user. No services or stateful data are maintained and the function code is provided by the user to the service that runs the function.

The idea of a properly designed production applications that utilize the serverless architecture is that instead of building multiple micro-services expected to run continuously in order to carry out individual tasks, build an application that has fewer micro-services combined with FAAS for tasks that don’t need services to run continuously.

FAAS is smaller construct than a micro-service. For example, in case of the event booking application we covered earlier, there were multiple micro-services covering different tasks. If we use a serverless applications model, some of those micro-services would be replaced with a number of functions that serve their purpose. For example, here’s a diagram that showcases the application utilizing a serverless architecture:

In this diagram, the event handler acts as micro-services as well as the booking handler — micro-services were replaced with a number of functions that produce the same functionality. This eliminates the need to run and maintain the two existing micro-services.

Such a monolithic application will work well with small to medium loads. It can run on a single server, connect to a single database and will be written probably in the same programming language.

Now, what happens if business booms and hundreds of thousands or millions of users need to be handled and processed? Initially, the short-term solution is to ensure that the server on which the application runs has powerful hardware specifications to withstand higher loads with vertical scaling (the act of increasing hardware specifications like RAM and hard drive to run heavy applications). Typically, though, it’s not sustainable as the load on the application continues to grow.

Another challenge with monolithic applications is the inflexibility caused by being limited to only one or two programming languages. This inflexibility can affect the overall quality and efficiency of the application. For example, node.js is a popular JavaScript framework for building web applications, whereas R is popular for data science applications. A monolithic application will make it difficult to utilize both technologies, whereas in a micro-services application, you can simply build a data science service written in R and a web service written in Node.js.

A third notable challenge with monolithic applications is collaboration. For example, in the event booking application, a change that caused a bug in the single front-end user interface layer could affect the other pieces of the application using it like the search, events and bookings handlers.

If you were to create a micro-services version of the events application it would take the below form:

This application will be capable of horizontal scaling among multiple servers. Each service can be deployed on a different server with dedicated resources, or in separate containers.

How do micro-services work with cloud native applications?

Micro-service architectures are a natural fit for cloud native applications. A cloud native application is simply defined as an application built from the ground up to run on a cloud platform. A cloud platform has numerous advantages such as obtaining multiple server nodes at a moment’s notice without the pains of IT hardware infrastructure planning. Building your application in a microservices architecture is an important step to develop scalable cloud native applications.

Another feature of cloud native applications is utilizing cloud only software services. For example, DynamoDB is a powerful database engine that can only be used on Amazon Web Services for production applications. Another example is the DocumentDB database in Azure. There are also cloud native message queues such as Amazon Simple Queue Service (SQS), which can be used to allow communication between micro-services in the Amazon Web Services cloud.

Cloud native micro-services can also be designed to allow redundancy between services. If we take the events booking application as an example, the application would look like this:

Because obtaining new server nodes is not a hardware infrastructure challenge, multiple server nodes could be allocated per micro-service. If the primary node or service fails for any reason, the secondary can take over, ensuring lasting reliability and availability for cloud native applications. The key here is availability for fault intolerant applications such as e-commerce platforms where downtime translates into lost revenue.

Micro-services cloud native applications combine the advantages of micro-services with the benefits of cloud computing to provide great value for developers, enterprises and startups.

Another notable advantage (aside from availability and reliability) is continuous delivery. The reason why micro-services make continuous delivery easier is because a new feature deployed to one micro-service is far less likely to affect other micro-services.

Conclusion

Cloud computing has opened avenues for developing efficient, scalable and reliable software. Here, we’ve covered some significant concepts in the world of cloud computing such as microservices, cloud native applications and serverless applications.

When designing an application, architects must choose whether to build a monolithic application, a microservices cloud native application, or a serverless application. Hopefully, I’ve given you some insight on how to make that decision.

In part two of this series, we’ll dive into cloud-native applications and containers also shed some light on the disadvantages of depending on them. Part three of the series will take you through serverless applications in detail and show you how all three fit in together.

Content courtesy Packt Publishing

The post A bird’s eye view on micro-services, cloud native, containers and serverless appeared first on Superuser.

The post Kickstart your knowledge with the OpenStack Upstream Institute appeared first on Superuser.

When it came to choose a project for which to apply in Outreachy, I was looking for 3 things: mentors are in about the same timezone as me, the project is in tech stack I'm familiar with and want to expand my skills in it, and last but but not least, the project's domain is something interesting and completely new to me.

With the last point I set myself up for a lot of reading (and some videos).

At first I felt like that dog in meme 'I have no idea what I'm doing'. To wrap my head around this, I started to draw a picture with some boxes. Here is the result:

The project I'm working on is sushy and sushy-tools project.

sushy is related to, but not exactly part of, OpenStack Ironic project which deals with bare metal provisioning. Usually when talking about clouds, talk about virtual machines (VM), but there are cases where VMs do not provide necessary performance, so non-virtualized environment is necessary. Here comes Ironic project to manage bare metal servers in cloud environment - remotely. Ironic can be used independently or together with other OpenStack projects with whom it integrates. sushy is written in a way that it does not depend on Ironic and can be used by other projects. And Ironic can decide to use something else instead of sushy. But what does sushy do? Time to introduce Redfish.

Redfish is a standard API to work with bare metal servers. It lives in BMC (Baseboard Management Controller) which is a microcontroller (small computer) attached to motherboard of industrial servers. BMC allows to manage servers remotely and Redfish is one of the protocols to do it. The Redfish standard is managed by DMTF (Distributed Management Task Force).

sushy is a client library in Python for Redfish RESTful web services communicating in JSON. ironic imports sushy and uses it as one of the drivers. sushy is not the only Python library to consume Redfish API, there are alternatives named very similarly: python-redfish [5] python-redfish-library [6]

Besides sushy there is also project sushy-tools which contains emulators for testing sushy. Otherwise it is challenging for developers to test Redfish as real server with BMC and Redfish is necessary. There are 2 emulators: sushy-static which serves static JSON files provided by Redfish project. Mockups can be found at White Papers and Technical Notes section[4] looking for DSP2043. There is Redfish Mockup Creator[7] to generate mockup files from a real Redfish service. But this is little use to me as I don't have access to real Redfish service, but nice to know just in case.

Static mockup file emulator is OK for read only testing, but it does not help much when want to test actions where some changes are necessary. In this case there is sushy-emulator which uses libvirt driver connecting to virtual machine mimicking real server.

DMTF also provides similar emulators, both static mockup files[8] and dynamic[9]. I haven't tried these yet, but might try them out later. With all the alternatives available, it appears that each project takes different approach, so it is not like they are copies of each other and in the end there is choice.

Lastly, there are some acronyms that I've seen floating around in relation to Ironic that are not directly related to sushy, but I had to find out what they are and how they are related.

PXE (Preboot eXecution Environment) is way to boot up servers from network. Computers supporting PXE has NIC (network interface controller) that is up and listening to commands from network even when server itself is turned off.

IPMI (Intelligent Platform Management Interface) is a way how to manage and monitor servers remotely.

PXE and IPMI have been used together to deploy servers, but they are supposed to be replaced by newer technologies addressing some of their drawbacks - HTTP Boot and Redfish [10].

libvirt, already mentioned above, is API to manage virtualization, supporting wide range of hypervisors, including VirtualBox, VMWare, Hyper-V.

As always, in hindsight this all speaks for itself, but then again while writing this I discovered new places to go though I can avoid them now - this is just enough for sushy. It will be interesting to revisit this at the end of project and see what has changed in my point of view.

Next time I will write about first tasks I'm working on that should allow me to tell more about sushy and Redfish.

• [1] Ironic project wiki - openstack.org
• [2] Ironic User Guide - openstack.org
• [3] Sushy documentation - openstack.org
• [4] Redfish API docs - dmtf.org
• [5] python-redfish - github.com
• [6] python-redfish-library - github.com
• [7] Redfish Mockup Creator - github.com
• [8] Redfish Mockup Server - github.com
• [9] Redfish Interface Emulator - github.com
• [10] Talk from 2015 UEFI Plugfest. Firmware in the Data Center: Goodbye PXE and IPMI. Welcome HTTP Boot and Redfish! - youtube.com
• [11] In-browser Mockup file explorer - dmtf.org
• [12] Intro videos about Redfish API - dmtf.org
• [13] BMC - wikipedia.org
• [14] Microcontroller - wikipedia.org
• [15] Preboot Execution Environment - wikipedia.org
• [16] Libvirt - wikipedia.org

Containerized deployments, debugging basics

Config generation debugging overview

[root@overcloud-controller-0 docker-puppet]# jq '[.[]|select(.config_volume | contains("heat"))]' /var/lib/docker-puppet/docker-puppet.json | tee /tmp/heat_docker_puppet.json
{
  "puppet_tags": "heat_config,file,concat,file_line",
  "config_volume": "heat_api",
  "step_config": "include ::tripleo::profile::base::heat::api\n",
  "config_image": "192.168.24.1:8787/tripleomaster/centos-binary-heat-api:current-tripleo"
}
{
  "puppet_tags": "heat_config,file,concat,file_line",
  "config_volume": "heat_api_cfn",
  "step_config": "include ::tripleo::profile::base::heat::api_cfn\n",
  "config_image": "192.168.24.1:8787/tripleomaster/centos-binary-heat-api-cfn:current-tripleo"
}
{
  "puppet_tags": "heat_config,file,concat,file_line",
  "config_volume": "heat",
  "step_config": "include ::tripleo::profile::base::heat::engine\n\ninclude ::tripleo::profile::base::database::mysql::client",
  "config_image": "192.168.24.1:8787/tripleomaster/centos-binary-heat-api:current-tripleo"
}

[root@overcloud-controller-0 docker-puppet]# export NET_HOST='true'
[root@overcloud-controller-0 docker-puppet]# export DEBUG='true'
[root@overcloud-controller-0 docker-puppet]# export PROCESS_COUNT=1
[root@overcloud-controller-0 docker-puppet]# export CONFIG=/tmp/heat_docker_puppet.json
[root@overcloud-controller-0 docker-puppet]# python /var/lib/docker-puppet/docker-puppet.py2018-02-09 16:13:16,978 INFO: 102305 -- Running docker-puppet
2018-02-09 16:13:16,978 DEBUG: 102305 -- CONFIG: /tmp/heat_docker_puppet.json
2018-02-09 16:13:16,978 DEBUG: 102305 -- config_volume heat_api
2018-02-09 16:13:16,978 DEBUG: 102305 -- puppet_tags heat_config,file,concat,file_line
2018-02-09 16:13:16,978 DEBUG: 102305 -- manifest include ::tripleo::profile::base::heat::api
2018-02-09 16:13:16,978 DEBUG: 102305 -- config_image 192.168.24.1:8787/tripleomaster/centos-binary-heat-api:current-tripleo
...

Runtime debugging, paunch 101

[root@overcloud-controller-0]# cd /var/lib/tripleo-config/
[root@overcloud-controller-0 tripleo-config]# jq '{"heat_engine": .heat_engine}' hashed-docker-container-startup-config-step_4.json | tee /tmp/heat_startup_config.json
{
  "heat_engine": {
    "healthcheck": {
      "test": "/openstack/healthcheck"
    },
    "image": "192.168.24.1:8787/tripleomaster/centos-binary-heat-engine:current-tripleo",
    "environment": [
      "KOLLA_CONFIG_STRATEGY=COPY_ALWAYS",
      "TRIPLEO_CONFIG_HASH=14617e6728f5f919b16c74f1e98d0264"
    ],
    "volumes": [
      "/etc/hosts:/etc/hosts:ro",
      "/etc/localtime:/etc/localtime:ro",
      "/etc/pki/ca-trust/extracted:/etc/pki/ca-trust/extracted:ro",
      "/etc/pki/tls/certs/ca-bundle.crt:/etc/pki/tls/certs/ca-bundle.crt:ro",
      "/etc/pki/tls/certs/ca-bundle.trust.crt:/etc/pki/tls/certs/ca-bundle.trust.crt:ro",
      "/etc/pki/tls/cert.pem:/etc/pki/tls/cert.pem:ro",
      "/dev/log:/dev/log",
      "/etc/ssh/ssh_known_hosts:/etc/ssh/ssh_known_hosts:ro",
      "/etc/puppet:/etc/puppet:ro",
      "/var/log/containers/heat:/var/log/heat",
      "/var/lib/kolla/config_files/heat_engine.json:/var/lib/kolla/config_files/config.json:ro",
      "/var/lib/config-data/puppet-generated/heat/:/var/lib/kolla/config_files/src:ro"
    ],
    "net": "host",
    "privileged": false,
    "restart": "always"
  }
}
[root@overcloud-controller-0 tripleo-config]#  paunch --debug apply --file /tmp/heat_startup_config.json --config-id tripleo_step4 --managed-by tripleo-Controller
stdout: dd60546daddd06753da445fd973e52411d0a9031c8758f4bebc6e094823a8b45

stderr: 
[root@overcloud-controller-0 tripleo-config]# docker ps | grep heat
dd60546daddd        192.168.24.1:8787/tripleomaster/centos-binary-heat-engine:current-tripleo          "kolla_start"            9 seconds ago       Up 9 seconds (health: starting)                       heat_engine

Containerized services, logging

• On the host filesystem, the container logs are persisted under /var/log/containers/<service>
• docker logs <container id or name>

Debugging containers directly

[root@openstack-controller-0 ~]# docker exec -ti heat_engine /bin/bash
()[heat@openstack-controller-0 /]$ ps ax
    PID TTY      STAT   TIME COMMAND
      1 ?        Ss     0:00 /usr/local/bin/dumb-init /bin/bash /usr/local/bin/kolla_start
      5 ?        Ss     1:50 /usr/bin/python /usr/bin/heat-engine --config-file /usr/share/heat/heat-dist.conf --config-file /etc/heat/heat
     25 ?        S      3:05 /usr/bin/python /usr/bin/heat-engine --config-file /usr/share/heat/heat-dist.conf --config-file /etc/heat/heat
     26 ?        S      3:06 /usr/bin/python /usr/bin/heat-engine --config-file /usr/share/heat/heat-dist.conf --config-file /etc/heat/heat
     27 ?        S      3:06 /usr/bin/python /usr/bin/heat-engine --config-file /usr/share/heat/heat-dist.conf --config-file /etc/heat/heat
     28 ?        S      3:05 /usr/bin/python /usr/bin/heat-engine --config-file /usr/share/heat/heat-dist.conf --config-file /etc/heat/heat
   2936 ?        Ss     0:00 /bin/bash
   2946 ?        R+     0:00 ps ax

Here is a Scientific Computing focused summary of some discussions during the OpenStack Forum. The full list of etherpads is available at: https://wiki.openstack.org/wiki/Forum/Vancouver2018

This blog jumps into the middle of several ongoing conversations with the upstream community. In an attempt to ensure this blog is published while it is still relevant, I have only spent a limited amount of time setting context around each topic. Hopefully it is still a useful collection of ideas from the recent Forum discussions.

As you can see from the pictures the location was great, the discussions were good too...

Federation

Federation was a big topic of conversation, with the edge computing use cases being heavily discussed. Hallway track conversations covered discussions of the AARC Blueprint Architecture, eduGain Federation Architectures and relating them back to keystone. There is a blog post brewing on the work we at StackHPC have done with STFC IRIS cloud federation project.

The AARC blueprint involving having a “proxy” that provides a single point of management for integrating with multiple external Identity Providers. It uses these IdPs purely for authentication. Firstly allowing for multiple ways of authenticating a single user, and centralising the decisions of what that user is authorized to do, in particular it holds information on what virtual organisations (or communities) that user is associated to, and what roles they have in each organisation. Ideally the task of authorizing users for a particular role is delegated to the manager of that organisation, rather than the operator of the service. When considering the later part of the use case, this application becomes really interesting (thanks to Kristi Nikolla for telling me about it!): https://github.com/CCI-MOC/ksproj

Pulling these ideas together, we get something like this:

Talking through a few features of the diagram it is worth noting: - Authentication to central Keystone is via an assertion from a trusted Identity Provider, mapped to a local user via federation mapping, such that additional roles can be assigned locally, optionally via ksproj workflows - Authentication to leaf keystone is via assertion from the central keystone, authorization info extracted via locally-stored federation mapping - App Creds are local to each Keystone - There can also be a sharing of keystone tokens, and having all those regions listed in each others service catalog. - There is no nasty long distance sync of keystone databases

It is believed this should work today, but there are some things we could consider changing in keystone: * Federation mappings of groups and projects + roles are inconsistent. One lasts for the life of the keystone token, another lasts forever. One is totally ephemeral, the other is written in the DB. One refreshes the full list of permissions on each authentication, the other can be used to slowly accrue more and more permissions as assertions change over time. For the leaf keystone deployments, a refresh on every authentication, with a time to live applied to the group membership added into the DB. * Note that using groups in the federation maps breaks trusts and application credentials, among other things this breaks Heat and Magnum. Ideally the above federation mapping work ensures all things are written to the database in a way that ensures trusts and application credentials work (see https://bugs.launchpad.net/keystone/+bug/1589993) * Keystone to Keystone federation is fairly non-standard (see http://www.gazlene.net/demystifying-keystone-federation.html) as it is IdP initiated, not the more “normal” SP initiated federation. We should be able to make both configurations possible as we move to SP initiated keystone to keystone federation * No central service catalog, without allowing tokens to work across all those regions. Might be nice to have pointers to service catalogs in the central component (this could be the list of service providers used for keystone to keystone federation, but this seems to not quite fit here).

It turns out, the Edge Computing use cases have very similar needs. Application credentials allow scripts to have a user local to a specific keystone instance, in a way that authentication still works even when the central federation keystone isn’t available.

There is a lot more to this story, and we hope to bring you more blog entries on the details very soon!

In the mountains of Northern California, where the people are a few and far between and nary a data center is to be seen, a small institution of higher education relies on OpenStack to keep its operations running smoothly.

This is the St. Photios Orthodox Theological Seminary in Etna, California, managed largely by the monks of the nearby St. Gregory Palamas Monastery.

The Seminary, founded in 2015, opened doors for classes in 2016. A year later, research was underway to build an IT system that could meet current needs and provide for the foreseeable future. The original plan was to purchase several separate servers each running various applications on bare metal. A particular challenge in traditional, bare-metal systems is having all the different software packages coexisting peacefully.

During the formidable task of juggling the different requirements to find the best compromise between usability, security and ongoing maintenance, I discovered, quite by accident, the OpenStack project and the concept of software-defined virtualized hardware immediately captured my imagination. Although I’ve been responsible for setting up websites since 1999, I only started setting up Linux hardware a year ago and slowly moved to VPS solutions because of the flexibility they provide.

Thus began my odyssey into the world of open-source cloud computing. After wading through pages and pages of documentation and tutorials (of varying degrees of quality), and after numerous installations, hardware configurations (ultimately adding an additional compute node) and with the generous help of the OpenStack community, (having access to an international team of experts, from Europe to Korea, is absolutely incredible!) by January 2018 our OpenStack system was operational.

It was very exciting to see the system working the first time! The incredible flexibility that OpenStack provides has proved worth the effort. Now, no compromises need be made in choice of software, each service can run on its own system eliminating compatibility problems and providing unprecedented stability. Services can be rebooted, upgraded and adjusted without taking other services offline.

Ours is a micro-installation of only three nodes, one controller and two compute nodes. It typically runs five or six instances at a time with a handful of shelved instances ready to boot for testing or other needs. One of the most powerful features I find is the ability to create snapshots of running instances. I have been using this to test new features on production systems without risk of unplanned downtime. Either the changes made in the test system can then be replicated on the production server or the server can be switched out by simply reassigning the floating IP—fantastic!

The Seminary’s OpenStack system, affectionately known as the SPOTS Cyber Command Centre, is running CentOS (the base OS), Debian, Fedora and Ubuntu to support the software that make up the SPOTS Management and Academic Network.

The software services we are using to date include Koha ILS, Gibbon, iRedMail, Sandstorm and, of course, Apache httpd. The next step will be to install OpenStack Freezer to facilitate a comprehensive cloud backup system. I’d also like to expand to an HA system eventually with a complete cloud backup offsite. Right now I am just backing up essential files. If the controller goes down, I will face a system rebuild of several days.

OpenStack is not just powering the mega data centers of the world, it is nimble enough to provide amazing value in even the smallest network.

Superuser wants to hear what you’re doing with open infrastructure – get in touch at editorATsuperuser.org

All photos courtesy Father Vlasie.

The post Operator spotlight: St. Photios Orthodox Theological Seminary appeared first on Superuser.

I’m in a bit of shock that it’s already June… anyone else share that feeling? With summer around the corner for those of us in the northern hemisphere (or Juneuary as we call it in San Francisco), there’s a promise of vacations ahead. Be sure to take us along on your various adventures — sharing about your new favorite hacks, the projects you’re working on, and the conferences you’re traveling to. We love hearing what you’re up to! Speaking of which… here’s what you’ve been blogging about recently:

TripleO deep dive session #13 (Containerized Undercloud) by Carlos Camacho

This is the 13th release of the TripleO “Deep Dive” sessions. Thanks to Dan Prince & Emilien Macchi for this deep dive session about the next step of the TripleO’s Undercloud evolution. In this session, they will explain in detail the movement re-architecting the Undercloud to move towards containers in order to reuse the containerized Overcloud ecosystem.

Read more at https://www.anstack.com/blog/2018/05/31/tripleo-deep-dive-session-13.html

Tracking Quota by Adam Young

This OpenStack Summit marks the third that I have attended where we’ve discussed the algorithms to try and record quota in Keystone but not update it on each resource allocation and free.

Read more at https://adam.younglogic.com/2018/05/tracking-quota/

Don’t rewrite your driver. 80 storage drivers for containers rolled into one! by geguileo

Do you work with containers but your storage doesn’t support your Container Orchestration system? Have you or your company already developed an Openstack/Cinder storage driver and now you have to do it again for containers? Are you having trouble deciding how to balance your engineering force between storage driver development in OpenStack, Containers, Ansible, etc? Then read on, as your life may be about to get better.

Read more at https://gorka.eguileor.com/cinderlib-csi/

Ansible Storage Role: automating your storage solutions by geguileo

Were you in the middle of writing your Ansible playbooks to automate your software provisioning, configuration, and application deployment when you realized you had to manage your storage as well? And it turns out that each of your storage solutions has a completely different Ansible module. Now you have to figure out how each module works to create ad-hoc tasks for each one. What a pain! If this has happened to you, or if you are interested in automating your storage solutions, you may be interested in the new Ansible Storage Role.

Read more at https://gorka.eguileor.com/ansible-role-storage/

Cinderlib: Every storage driver on a single Python library by geguileo

Wouldn’t it be great if we could manage any storage array using a single Python library that provided the right storage management abstraction? Well, this is no longer a beautiful dream, it has become a reality! Keep reading to find out how.

Read more at https://gorka.eguileor.com/cinderlib/

“Ultimate Private Cloud” Demo, Under The Hood! by Steven Hardy, Senior Principal Software Engineer

At the recent Red Hat Summit in San Francisco, and more recently the OpenStack Summit in Vancouver, the OpenStack engineering team worked on some interesting demos for the keynote talks. I’ve been directly involved with the deployment of Red Hat OpenShift Platform on bare metal using the Red Hat OpenStack Platform director deployment/management tool, integrated with openshift-ansible. I’ll give some details of this demo, the upstream TripleO features related to this work, and insight around the potential use-cases.

Read more at https://redhatstackblog.redhat.com/2018/05/22/ultimate-private-cloud-demo-under-the-hood/

Testing Undercloud backup and restore using Ansible by Carlos Camacho

Testing the Undercloud backup and restore It is possible to test how the Undercloud backup and restore should be performed using Ansible.

Read more at https://www.anstack.com/blog/2018/05/18/testing-undercloud-backup-and-restore-using-ansible.html

Your LEGO® Order Has Been Shipped by rainsdance

In preparation for the Red Hat Summit this week and OpenStack Summit in a week, I put together a hardware demo to sit in the RDO booth.

Read more at http://groningenrain.nl/your-lego-order-has-been-shipped/

Introducing GPUs to the CERN Cloud by Konstantinos Samaras-Tsakiris

High-energy physics workloads can benefit from massive parallelism — and as a matter of fact, the domain faces an increasing adoption of deep learning solutions. Take for example the newly-announced TrackML challenge [7], already running in Kaggle! This context motivates CERN to consider GPU provisioning in our OpenStack cloud, as computation accelerators, promising access to powerful GPU computing resources to developers and batch processing alike.

Read more at https://openstack-in-production.blogspot.com/2018/05/introducing-gpus-to-cern-cloud.html

A modern hybrid cloud platform for innovation: Containers on Cloud with Openshift on OpenStack by Stephane Lefrere

Market trends show that due to long application life-cycles and the high cost of change, enterprises will be dealing with a mix of bare-metal, virtualized, and containerized applications for many years to come. This is true even as greenfield investment moves to a more container-focused approach.

Read more at https://redhatstackblog.redhat.com/2018/05/08/containers-on-cloud/

Using a TM1637 LED module with CircuitPython by Lars Kellogg-Stedman

CircuitPython is “an education friendly open source derivative of MicroPython”. MicroPython is a port of Python to microcontroller environments; it can run on boards with very few resources such as the ESP8266. I’ve recently started experimenting with CircuitPython on a Wemos D1 mini, which is a small form-factor ESP8266 board.

Read more at https://blog.oddbit.com/2018/05/03/using-a-tm-led-module-with-cir/

ARA Records Ansible 0.15 has been released by DM Simard

I was recently writing that ARA was open to limited development for the stable release in order to improve the performance for larger scale users.

Read more at https://dmsimard.com/2018/05/03/ara-records-ansible-0.15-has-been-released/

Highlights from the OpenStack Rocky Project Teams Gathering (PTG) in Dublin by Rich Bowen

Last month in Dublin, OpenStack engineers gathered from dozens of countries and companies to discuss the next release of OpenStack. This is always my favorite OpenStack event, because I get to do interviews with the various teams, to talk about what they did in the just-released version (Queens, in this case) and what they have planned for the next one (Rocky).

Read more at https://redhatstackblog.redhat.com/2018/04/26/highlights-from-the-openstack-rocky-project-teams-gathering-ptg-in-dublin/

Red Hat Summit 2018: HCI Lab by John

I will be at Red Hat Summit in SFO on May 8th jointly hosting the lab Deploy a containerized HCI IaaS with OpenStack and Ceph.

Read more at http://blog.johnlikesopenstack.com/2018/04/red-hat-summit-2018-hci-lab.html

Last week, I attended the OpenStack Summit in Vancouver, as RDO Ambassador. That was a good experience to connect with the RDO community.

What does an RDO ambassador do?

As an ambassador, your role is to engage the community by answering their questions, helping them to fix their issues, or getting started to contribute. You don’t need to know everything, but it implies, you can at least point people to the right direction.

On Sunday, we started helping with the booth setup, and for me it started with massive T-shirt folding and sorting them by size in laundry baskets. During trade shows, many people just want their swag, so efficient T-shirt distribution means more time to exchange with community members. Thanks to everyone at the booth, it was done quickly.

I also set up the RDO hardware demo. Rain Leander, RDO community liaison had prepared a shiny new demo using two NUCs and a portable gaming screen, using TripleO, this will be used in future events to demo RDO. Since we had limited time, I had to wait monday morning to reinstall everything since demo was borked during the previous event.

From monday to thursday, I had to do shifts at the booth to advocate RDO and engage with the community, welcoming people doing their shifts and helping them to get set up. The community pod was shared with Carol Chen (ManageIQ) and Leonardo Vaz (Ceph), so we were able to cover many topics.

RDO’s swag was ducks – everyone loves them, we had three colors (Red, Green, Blue!) and I can say they were a bit mischievous

Most of the questions we’ve had were related to RDO/RHOSP relations, how to contribute, TripleO, Ceph, etc. We also helped an user to debug his RDO deployment to find out a bug in CentOS cloud images breaking qemu-ev repository ($contentdir variable set to altarch instead of x86_64)

Demo and Q/A sessions

We also had people who came for demo’ing the cool stuff they made. We’ve had Michael J. Turek who demo’ed Ironic deployment on ppc64le (the shiny new arch supported by RDO!)

Also T. Nicholle Williams who presented us how to deploy OpenShift on OpenStack and as a guest star her lovely puddle.

And last but not least, David M. Simmard, creator of ARA which was the center of many questions.

RDO meetup

We had a RDO meetup jointly with the Ceph community at the Portside Pub. It was awesome to discuss around drinks and snacks. I noticed that among us, there were local stackers not attending the summit, so we reached a wider audience.

Conclusion

That was a great Summit, it was good to connect with fellow stackers (old and new friends!), and share the love around RDO. We’ve had an exceptionally good weather in Vancouver, and I must say that the scenery in British Columbia is just breathtaking. I really enjoyed my short stay there.

Thanks to Rain for sending me, my team for allowing me to go Many thanks to Leo, Carol, Jennifer, Tracy with whom I had a lot of fun

The OPNFV Verified Program is a new compliance program targeting the validation of API compliance and behavioral characteristics of a NFVI platform.

The program leverages test cases written both in OPNFV itself as well as test cases available in upstream communities. Within the OPNFV community, the Dovetail project is working on the technical realization of the program by creating a test tool, selecting test cases and engaging with the OPNFV community and upstream communities to establish new test cases.

Georg Kunz (project technical lead for Dovetail and senior systems designer at Ericsson) and Tim Irnich (technical steering chair at OPNFV, also at Ericsson) offered up an overview of the OPNFV Verified Program (OVP for short) at the OpenStack Summit Vancouver.

OVP’s goal is to verify that commercial NFVI solutions expose the same APIs but also behaviors and characteristics — validating that if you send a command to one of the APIs, it  returns the expected response and checking whether the underlying system behaves in the expected way and how well it works.  “Both vendors and operators today have to spend a lot of effort in making sure that what they have bought from a vendor actually does what the vendor promised,” says Irnich.

The pair also showed how Dovetail ties into the overall test ecosystem and leverages OPNFV and upstream test tools. They offered a live demo on the compliance portal and walk you through how to submit something for compliance verification if you want to check it out.

Get involved

Kunz and Inrich said they hoped to spark more discussions in the community about closing gaps in test coverage, test strategy and how to join forces across communities. To find out more about Dovetail, check out the user guide, documentation, Git page or jump in on a weekly meeting on IRC.

Catch the whole 40-minute talk below or take a look at slides from the presentation.

Photo // CC BY NC

The post Dovetail: a new open-source test project for NFVI compliance validation appeared first on Superuser.

Monasca provides monitoring as a service for OpenStack. It’s scalable, fault tolerant and supports multi-tenancy with Keystone integration. You can bolt it on to your existing OpenStack distribution and it will happily go about collecting logs and metrics, not just for your control plane, but for tenant workloads too.

So how do you get started? Errr... well, one of the drawbacks of Monasca’s microservice architecture is the complexity of deploying and managing the services within it. Sound familiar? On the other hand this microservice architecture is one of Monasca’s strengths. The deployment is flexible and you can horizontally scale out components as your ingest rate increases. But how do you do all of this?

Enter OpenStack Kolla. Back in 2017, Steven Dake, the founder of the Kolla project, wrote about the significant human resource costs of running an OpenStack managed cloud, and how the Kolla project offers a pathway to reduce them. By providing robust deployment and upgrade mechanisms, Kolla helps to keep OpenStack competitive with proprietary offerings, and at StackHPC we want to bring the same improvements in operational efficiency to the Monasca project. In doing so we’ve picked up the baton for deploying Monasca with Kolla and we don't expect to put it down until the job is finished. Indeed, since Kolla already provides many required services and support for deploying the APIs has just been merged, we're hoping that this isn't too long.

So what else is new in the world of Monasca? One of the key things that we believe differentiates Monasca is support for multi-tenancy. By allowing a single set of infrastructure to be used for monitoring both the control plane and tenant workloads, operational efficiency is increased. Furthermore, because the data is all in one place, it becomes easy to augment tenant data with what are typically admin only metrics. We envisage a tenant being able to log in and see something like this:

By providing a suitable medium for thought, the tenant no longer has to sift through streams of data to understand that their job was running slow because Ceph was heavily loaded, or the new intern had saturated the external gateway. Of course, exposing such data needs to be done carefully and we hope to expand more upon this in a later blog post.

So how else can we help tenants? A second area that we've been looking at is logging. Providing a decent logging service which can quickly and easily offer insight into the complex and distributed jobs that tenants run can save them a lot of time. To this effect we've been adding support for querying tenant logs via the Monasca Log API. After all tenants can POST logs in, so why not support getting them out? One particular use case that we've had is to monitor jobs orchestrated by Docker Swarm. As part of this work we knocked up a proof of concept Compose file which deploys the Monasca Agent and Fluentd as global services across the Swarm cluster. With a local instance of Fluentd running the Monasca plugin, container stdout can be streamed directly into Monasca by selecting the Fluentd Docker log driver. The tenant can then go to Grafana and see both container metrics and logs all in one place, and with proper tenant isolation. Of course, we don't see this as a replacement for Kibana, but it has its use cases.

Thirdly, a HPC blog post wouldn't be complete without mentioning Slurm. As part of our work to provide intuitive visualisations we've developed a Monasca plugin which integrates with the Discrete plugin for Grafana. By using the plugin to harvest Slurm job data we can present the overall state of the Slurm cluster to anyone with access to see it:

The coloured blocks map to Slurm jobs, and as a cluster admin I can immediately see that there’s been a fair bit of activity. So as a user running a Slurm job, can I easily get detailed information on the performance of my job? It’s a little bit clunky at the moment, but this is something we want to work on. Both on the scale of the visualisation; we’re talking thousands of nodes not 8, and in the quality of the interface. As an example of what we have today here’s the CPU usage and some Infiniband stats for 3 jobs running on nodes 0 and 1:

Finally, we'll finish up with a summary. We've talked about helping to drive forward progress in areas such as deployment, data visualisation and logging within the Monasca project. Indeed, we're far from the only people with a goal for bettering Monasca, and we're very grateful for the others that share it with us. However, we don't want you to think that we're living in a bubble. In fact, speaking of driving, we see Monasca as an old car. Not a bad one, rather a potential classic. One where you can still open the bonnet and easily swap in and out parts. It's true that there is a little rust. The forked version of Grafana with Keystone integration prevents users from getting their hands on shiny new Grafana features. The forked Kafka client means that we can't use the most recent version of Kafka, deployable out of the box with Kolla. Similar issues exist with InfluxDB. And whilst the rust is being repaired (and it is being repaired) newer, more tightly integrated cars are coming out with long life servicing. One of these is Prometheus, which compared to Monasca is exceptionally easy to deploy and manage. But with tight integration comes less flexibility. One size fits all doesn't fit everyone. Prometheus doesn't officially support multi-tenancy, yet. We look forward to exploring other monitoring and logging frameworks in future blog posts.

We had another good Summit in Vancouver and got good amount of feedback for QA which really important and helpful. I am summarizing the QA discussions during Summit.

  QA Project Updates:

I was glad to give QA project updates in Vancouver Summit. Mainly talked about what all we completed in Queens cycle and few stats about activeness of QA team. Talked about main area/features QA team is targeting for Rocky cycle and beyond. On cross project work, Zuulv3 base jobs, RBAC testing and plugin coordination are the main item we will be focusing on.

  QA feedback sessions:

Etherpad: https://etherpad.openstack.org/p/YVR18-forum-qa-ops-user-feedback

We had good number of people this time and so does more feedback.

      Key points, improvement and features requested in QA:

• AT&T Cloud QA is by AQuA API which is tooling around upstream tools like Tempest, Patrole, OpenStack Health etc.
• Tempest, Patrole are widely used tool in Cloud testing. Patrole is being used with 10 Roles in parallel testing on containers.
• There are few more support needed from Tempest which AT&T (Doug Schveninger) would like to see in upstream. Few of them are:
  •     Better support for LDAP
  •     Service available detection for plugins
  •     Configure volume_type for Cinder multiple storage types tests
  •     more tooling in Tempest like – tempest.conf generator, iproject_generator.py, advance cleanup/Leak detector, assembling tempest plugin in a docker container etc
  •     Tempest gabbi support

ACTION ITEM:  gmann to follow up on each requested features and start discussion in separate thread/IRC.

  Tagging all the Tempest plugins along with Tempest tag

Currently, we tag Tempest on release, intermediately or EOL  so that people can use that tag against particular OpenStack code base/release.  Tempest plugins are not being tagged as such.  So there are difficulty in using plugins with particular Tempest tag in compatible way. We discussed to tag all tempest plugins together whenever Tempest new tag is pushed. While writing this mail, I got to know that dmellado already doing the new tag for kuryr tempest plugin which is what we need.

ACTION ITEM: gmann to start the ML thread to get the broader agreement from each plugins and then define the process and responsible team to tag all plugins and Tempest together.

  Patrole

This is one of the important project now which is being requested/talked by many people/operator. This was one the item in keystone Default Roles forum session[1] also to start gating patrole on keystone. Below is initial plan I discussed with Felipe:

• Start gating patrole in keystone with non-voting/experimental job. This one – https://review.openstack.org/#/c/464678/ . Rocky.
• multi-policy support – Rocky
• Make  stable release of Patrole. S cycle may be. This include various things about framework stability, plugin support etc
• Start proposing the Patrole gating on other projects like nova, cinder etc – T Cycle or early if possible.

ACTION ITEM: Felipe to work on above plan and gmann will be helping him on that.

  QA onboarding sessions:

Etherpad: https://etherpad.openstack.org/p/YVR18-forum-qa-onboarding-vancouver

Around  6-7 people joined which gradually increasing since previous summits :). We started with asking people about their engagement in QA or what they are looking forward from QA.

Doug Schveninger(AT&T) talked about his team members who can helps on QA things and the new features/tooling he would like to see in Tempest, Patrole etc. They might not be permanent but it is good to have more people in contribution. QA team will help to get them on-boarded in all perspective. Thanks Doug for your support.

Other item fro this sessions was to have a centralized place (etherpad, document) for all the current feature or working items where we are looking for volunteer like CLI unit tests, schema validation etc. Where we document the enough background and helping material which will help new contributors to start working on those items.

ACTION ITEM:

• gmann to find the better place to document the working item with enough background for new contributors.
• Doug to start his team member to get involve in QA.

  Extended Maintenance Stable Branch

During discussion of Extended Maintenance sessions[2], we discussed about testing support of EM branch in QA and we all agreed on below points:

• QA will keep doing the same number of stable branches support as it is doing now. Means support till “Maintained”  phase branches. EM branch will not be in scope of guaranteed support of QA.
• As Tempest is branchless, it should work for EM phase branches also but if anything new changes break EM branch testing then we stopped testing master Tempest on EM branches.

Matt has already pushed the patch to document the above agreement [3]. Thanks for doing good documentation always :).

  Eris

Spec– https://review.openstack.org/#/c/443504/

It came up in feedback sessions also and people really want to see some progress on this. We have spec under review for that and need more volunteer to drive this forward. I will also check with SamP on this. Other than that there was not much discussion/progress on this in summit.

ACTION ITEM:  gmann to push the spec review in QA team and more follow up about progress.

[1] https://etherpad.openstack.org/p/YVR-rocky-default-roles

[2] https://etherpad.openstack.org/p/YVR-extended-maintenance

[3] https://review.openstack.org/#/c/570620/

Get involved

Check out Spinnaker’s GitHub or head to the Spinnaker community forum for a good place to initiate longer discussions with core developers or try Slack or Stack Overflow for quick questions and answers.

You can also read up with a free ebook titled “Continuous Delivery With Spinnaker,” written by a team of experts from Netflix and Google who show you how to automate deployments with Spinnaker across multiple cloud accounts.

Check out his entire 40-minute talk below.

The post Breezing through hybrid and multi-cloud deployments with Spinnaker appeared first on Superuser.

This is the 13th release of the TripleO “Deep Dive” sessions

Thanks to Dan Prince & Emilien Macchi for this deep dive session about the next step of the TripleO’s Undercloud evolution.

In this session, they will explain in detail the movement re-architecting the Undercloud to move towards containers in order to reuse the containerized Overcloud ecosystem.

You can access the presentation or the Etherpad notes.

So please, check the full session content on the TripleO YouTube channel.

Please check the sessions index to have access to all available content.

Kubernetes may rule the data center but if you have hundreds and thousands of containers running on it, it can be difficult to understand which applications they belong to, who owns them, why they were created, what’s no longer in use and the impact of changes.

Enter Aptomi, an open-source project that simplifies roll out and operation of container-based applications on Kubernetes. It introduces a service-centric abstraction, allowing dev teams to compose applications from multiple components connected together. These components can be packaged via Helm, k8s YAMLs, ksonnet, or defined in any other Kubernetes-friendly way.

Core contributor Roman Alekseenkov gave an overview of Aptomi at OpenDev. “Our idea was really simple, there seems to be a layer missing…We found for a lot of people the complexity is there, so our thought was what if we can introduce this lightweight layer built on the top of all the community abstractions, right on the top of Helm to deal with to deal with this problem, to allow you to compose services, allow you to run those services across multiple environments and multiple clusters with different settings, this layer would allow you to focus on services and the rules around those services.”

Alekseenkov gave a live demo by way of further introduction. Using the example of an application that grabs data from Twitter’s streaming API, does the processing  (calculates the top hashtags) and displays results on a webpage. It’s done with two services, an analytics pipeline service and another service,  Twitter stats which has three components — the publisher which grabs data from Twitter, a job engine that calculates hashtags using that external service and a virtualization part that displays results on the web.

Once the services are defined, he says, you can run it across multiple environments (dev, stage, production), Kubernetes clusters, as well as control its life cycle and updates. Service owners can efficiently manage multiple instances of their service, without having to deal with multiple copies of YAMLs and lower-level component configuration.

Aptomi also provides provides visibility for application owners, allowing to visualize dependencies and impact of changes. If you have hundreds and thousands of containers running on Kubernetes, it may be difficult to understand which applications they belong to, who owns them, why they were created, what is no longer in use and the impact of changes. Aptomi solves that problem with its UI for contextualized visibility.

Get involved

GitHub is a good place to get more familiar with Aptomi. To make a pull request for a bug fix or contribute a feature, see the Development Guide for how to develop, run and test your code. You can also help out by reporting bugs.

The team is always looking for feedback on how to make Aptomi better, join the Slack channel to discuss. Feature Backlog, as well as weekly project milestones, are good places to look at roadmap items.

If you have any questions, reach out to the team on Slack.

Check out his full 40-minute presentation below.

Photo // CC BY NC

The post Meet Aptomi: An application delivery engine for Kubernetes appeared first on Superuser.

VANCOUVER — Balmy spring weather and fantastic views were an invitation to stack outside, but conference goers put their heads together to talk about the future of open infrastructure in this return to Canada. These discussions were enriched by the participation of 30 open-source projects including Ansible, Ceph, Kubernetes, ONAP, Istio, Envoy, Spinnaker, OpenContrail and more.

If you didn’t attend—or if you did and want a replay—Superuser collected the announcements, user stories and Forum discussions you may have missed.

You can also catch videos for the Summit sessions on the OSF website.

Jump to roadmap & technical decisions
Jump to case studies
Jump to news from the OpenStack ecosystem
Jump to what’s next

Let’s start with the OpenStack Foundation announcements:

1) During Monday’s Summit keynotes, James Blair, founding member of the project team, gave an overview of Zuul, an open source CI/CD platform specializing in multi-system gating, its recent version 3 release. Blair announced that Zuul is now an independent project hosted at the OpenStack Foundation (OSF). Zuul is the third project to be managed by the OSF, joining OpenStack and Kata Containers.

2) After Kata Containers was announced at KubeCon last December, the team announced the 1.0 release on Tuesday morning followed by a live demo from Eric Ernst and Anne Bertucio during the container infrastructure keynotes Tuesday afternoon. Kata Containers 1.0 delivers the fully integrated code bases of the two technologies contributed to form the foundation of the project: Intel® Clear Containers from Intel Corporation and runV technology from Hyper.sh.

3) The SIG-Kubernetes, an OpenStack special interest group focused on cross-community efforts with Kubernetes, published a white paper around containers integration and recent cross-community efforts. The white paper highlights scenarios for combining OpenStack and Kubernetes and provides an overview of the open source projects, both OpenStack and otherwise, that help deliver container applications as well as production use cases from AT&T, CERN, SK Telecom and Superfluidity

4) The second annual OpenDev was co-located with the OpenStack Summit, focused on CI/CD. The event featured keynotes from Ericsson, Google, Mesosphere, Red Hat and the University of Washington as well as presentations and collaborative sessions around CI/CD technologies including Jenkins, Spinnaker, TravisCI and Zuul.

Here’s an overview of some of key community activities, technical decisions and roadmap discussions:

5) The next OpenStack release, Rocky, is scheduled for launch in late August 2018. Anne Bertucio provided an overview of the features scheduled to land, including mutable configuration across projects, fast forward upgrades, cluster upgrades and healing via Magnum and more. Check out the full list of features in the Rocky roadmap presentation.

6) As for what’s next for the S release, support for Support Python 3.5+ emerged as a top priority with other proposals include adding microversions to REST APIs, implementing API reference guide changes and adding notification schemas. Full Etherpad with discussion here.

7) Nokia’s Gergely Csatari brought forward from the Denver PTG a Forum session on gaps identified by ETSI NFV between ETSI NFV specs and OpenStack APIs; in Vancouver the group work focused on IFA005 gaps, more on the Etherpad here.

8) On the last day of the Summit, 10 community members were recognized by the Community Contributor Awards with quirky categories like the Bonsai Caretaker Award.

Now, a word from open infrastructure users in production

9) The Progressive Insurance team is leveraging the open APIs of OpenStack to provide the instrumentation to lead Progressive into the next generation of data analytics. Hear more about how they use OpenStack, Kubernetes and OpenShift to manage their big data use case.

10) Retail superstar Target came to talk about how OpenStack is rapidly becoming the foundation of their compute infrastructure. The team talked about the evolution of Target’s OpenStack architecture and deployment process over three years of production use, including CI/CD and containerization.

11) The team at Walmart Labs provided an overview of Galaxy, a multi-cloud validation tool that aims to minimize the mean time to detect issues on any number of clouds across OpenStack. A Python-based application, it’s easily pluggable to existing clouds. The idea behind this tool is to substantiate the results of the Openstack components health and perform validations of all kinds required to declare the health of the cloud.

12) The CERN team kept up its tradition of knowledge sharing with the community with a host of sessions in Vancouver, including: the evolution of networking, integrating Ironic into CERN’s private cloud, experiences with federated and multi-cloud, Ceph and HPC infrastructure and moving from CellsV1 to CellsV2.

13) Focusing on the challenges and opportunities that containerization provides in refining and modernizing CI/CD pipelines, AT&T spoke about the AT&T Integrated Cloud.

14) A demo showcased OpenLab, a community-led program to test and improve support across platforms including Kubernetes, Terraform, Cloud Foundry and more running on OpenStack. To highlight the integration testing across these technologies, Melvin Hillsman, a contributor to OpenLab, joined Mohammed Naser, CEO from VEXXHOST, to deploy an application on top of Kubernetes, leveraging the OpenStack cloud provider. Additionally, OpenLab published a case study on how Zuul is currently being used as an offering within OpenLab for projects/ applications / tools that need CI gating and/or automation around testing.

15) China Mobile shared the future of its nationwide network and the architecture, design and requirements it’s designing for edge cloud with focus on TIC (Telecom Integrated Cloud).

16) China Railway shared best practices and performance improvements for cloud storage as it keeps pace with the vast scale and nationwide boom in passenger and freight that require solid technical support.

17) At The Gap, open source is a critical component for an always-evolving infrastructure that serves one of the largest global online and offline retailers. Team members offered a look into how they are using open source tech, including OpenStack and Cloud Foundry.

18) Ontario Institute for Cancer Research (OICR) won this edition of the Superuser Awards and shared operational lessons from running Openstack and Ceph. The Cancer Genome Collaboratory is an OpenStack environment designed to scale to 3,000 cores and 15 PB of object storage.

19) T-Mobile is deploying an Openstack based virtual EPC to continue to support large scale, consumer-facing data connectivity to devices and better prepare for upcoming 5G deployments. Team members shared the use-case for virtual EPC using Openstack as platform and the challenges involved.

20) To support several smart city initiatives, the University of Messina developed an OpenStack-based framework called Stack4Things (IoTronic). Stack4Things exchanges information between IoT/Edge nodes (e.g. smart cameras) and OpenStack via Horizon and Neutron. They shared an edge computing case study for Monasca AI-powered surveillance and monitoring.

21) Atmail, an Australian-based email provider, shared their journey and lessons to date (including implementation lessons with U.S. and E.U. partners); as well as their future with OpenStack projects.

22) Internet domain registrar and web hosting company GoDaddy showcased what they’re doing with Zuul in a case study and an interactive group working session on continuous integration.

23) Catalyst IT shared its lessons learned in public cloud billing– bugs, providing a solution that can handle at least 1,000 customers and 50 metrics/products — on Catalyst Cloud, a public cloud based in New Zealand.

This just in from the OpenStack ecosystem

24) AT&T SKT, Intel Corporation and the OpenStack Foundation announced a new open infrastructure project called Airship. Building on the foundation of the OpenStack-Helm project launched in 2017, it lets cloud operators manage sites at every stage from creation through minor and major updates, including configuration changes and OpenStack upgrades.

25) Cloudify announced a newly enhanced solution to help virtualized network functions (VNF) vendors achieve cloud native capabilities for their networking services in record time, through simplified management and orchestration (MANO). This solution will enable these vendors to fully automate their VNF provisioning, configuration and management on hybrid environments, including Microsoft Azure, OpenStack, VMware, AWS, GCP, as well as add compatibility with industry standards such as ONAP & TOSCA by embedding Cloudify as their VNFM.

26) Juniper Networks announced that Fujitsu Limited has deployed Juniper’s cloud management platform AppFormix in Japan, as a key part of ensuring the operational efficiency of the new region of its widely adopted enterprise cloud platform Cloud Service K5.

27) OSF Gold Member Inspur released version 5.5 of its InCloud OpenStack cloud operating system which features unified management, multi-region support, layered security and disaster tolerance.

28) Mellanox Technologies together with Cumulus Networks announced that Vault Systems, a leading Australian government-certified cloud service provider, has chosen Mellanox end-to-end Ethernet solutions and Cumulus Linux to increase network resilience, stability and scalability. The end-to-end networking solution is fully integrated with OpenStack to provide advanced cloud features combined with ease of deployment and management.

29) Mirantis announced a new VNF certification program that centers around providing communication service providers (CSPs) with validated solutions on Mirantis Cloud Platform that can be more readily deployed by CSPs for production services.

30) The second version of FlexPod SolidFire was released with Red Hat OpenStack Platform 10 – Cisco Validated Design (CVD) solution. Paired with its partner Design Guide, this CVD enables an enterprise-grade OpenStack deployment, in an accelerated fashion, with little risk.

31) One of Monasca’s top contributors, Op5, were on hand in the Marketplace and gave a talk on best practices for monitoring OpenStack with Monasca.

32) Red Hat introduced Red Hat Hyperconverged Infrastructure for Cloud, an integrated solution for customers seeking to co-locate compute and storage functions in OpenStack environments. The new offering combines Red Hat OpenStack Platform 13 and Red Hat Ceph Storage 3 in a single user experience, supported by a common lifecycle for greater operational and organizational efficiency.

33) Red Hat announced that Tata Communications chose Red Hat Cloud Suite, Red Hat’s broadest hybrid cloud offering, to help enhance its IZO Private Cloud service.

34) Red Hat OpenStack Platform 13, the latest version of Red Hat’s massively scalable and agile cloud Infrastructure-as-a-Service solution based on the OpenStack Queens release was announced.

35) SevOne had a busy week in the Marketplace with live demonstrations of its NFV Service Assurance Monitoring Solution, optimized for Red Hat technologies. It provides businesses with automation of assurance, performance and insight into virtual network services to reduce downtime and boost customer loyalty.

36) Scale Computing came to Vancouver to demo its NVMe optimized edge solution featuring a Cinder plugin. Lab tests on the solution have achieved mean IO latencies as low as 20 microseconds delivered to a guest virtual machine.

37) SolarWinds announced a wave of updates network management product portfolio, which can support networks up to four times larger than the previous version.

38) StarlingX was announced as an initiative to open source components from the Wind River Titanium Cloud portfolio. Through the StarlingX project, Intel and Wind River are opening many of these enhancements with the hope others find this a good reference platform upon which to innovate. They invite the community to contribute code and looks forward to working together to define the infrastructure stack for edge computing and accelerating integration across many existing open source projects including cloud native technologies.

39) Storage Made Easy announced that it had released to the community an open source compliance rules repository that can be used for GDPR and other compliance regimes.

40) Supermicro brought two new cloud-scale enterprise systems to the Summit Marketplace. The multi-node BigTwin and SuperBlade were showcased along with a 1U Cloud Storage system, all three have already been deployed across data center environments including cloud service providers (CSPs), media streaming, e-commerce, social, telecommunications, semiconductor, OpenStack, artificial intelligence (AI), content delivery networks (CDN), and hyper-converged infrastructure (HCI).

41) Trilio and Canonical announced a partnership agreement to deliver TrilioVault backup and recovery solutions as part of BootStack, Canonical’s fully managed OpenStack private cloud solution. TrilioVault will also be made available as an option to Ubuntu Advantage support customers. As a result, users taking advantage of the Ubuntu platform for their OpenStack deployment now have seamless access to the only OpenStack-native data protection solution on the market.

42) VMware launched its latest distribution, OpenStack 5, based on the Queens release. It counts as one of the first commercial OpenStack distributions to comply with the OSF’s 2018.02 interoperability guidelines.

What’s next

That’s a strong finish for the Vancouver Summit, but we’re already thinking about our next run. We’re taking the Summit to across the pond to Berlin, November 13 – 15, 2018.
See you there!

The post OpenStack Vancouver Summit recap: 40 things you need to know appeared first on Superuser.

This OpenStack summit marks the third that I have attended where we’ve discussed the algorithms to try and record quota in Keystone but not update it on each resource allocation and free.

We were stumped, again. The process we had planned on using was game-able and thus broken. I was kinda bummed.

Fortunately, I had a long car ride from Vancouver to Seattle and talked it over with Morgan Fainberg.

We also discussed the Pig War. Great piece of history from the region.

By the time we got to the airport the next day, I think we had it solved. Morgan came to the solution first, and I followed, slowly.  Here’s what we think will work.

First, lets get a 3 Level deep project setup to use for out discussion.

The rule is simple:  even if a quota is subdivided, you still need to check the overall quota of the project  and all the parent projects.

In the example structure above,  lets assume that project A gets a quota of 100 units of some resource: VMs, GB memory, network ports, hot-dogs, very small rocks, whatever.  I’ll use VMs in this example.

There are a couple ways this could be further managed.  The simplest is that, any resource allocated anywhere else in this tree is counted against this quota.  There are 9 total projects in the tree.  If each allocate 11 VMs, there will be 99 created and counted against the quota.  The next VM created uses up the quota.  The request after that will fail due to lack of available quota.

Lets say, however, that the users in project C33 are greedy, and allocate all 100 VMs.  The people in C11 Are filled with righteous indignation.  They need VMs too.

The Admins wipe everything out and we start all over.  They set up a system to fragment the quota by allowing A project to split its quota assignment up and allocate some of it to subordinate projects.

Project A says “I’m going to keep 50 VMs for myself, and allocate 25 to B1 and B2.”

Project B1 Says I am going to keep 10 for Me and I’m going to allocate 5 to each C11, C12, C13.  And the B1 Tree is happy.

B2 is a manipulative schemer and decides to play around.  B2 Allocates his entire quota of 25 to C21.  C21 Creates 25 VMs.

B2 now withdraws his quota from C21.  There is no communication with Nova.  The VMs keep running.  He then allocates his entire quota of 25 VMs to C22, and C22 creates 25 VMs.

Nova says “What project is this?  C22?   What is its quota?  25?  All good.”

But in reality, B2 has doubled his quota.  His subordinates have allocated 50 VMs total.  He does this again with project C33, gets up to 75 VMs, and contemplates creating yet another project C34 just to keep up the pattern.  This would allocate more VMs than project A was originally allocated.

The admins notice this and get mad, wipe everything out, and start over again.  This time they’ve made a change.  Whenever the check quota on a project, they also will go and check quota on the parent project, counting all VMs underneath that parent.  Essentially, they will record that a VM created in project C11 is also reducing the original quota on B1  and on A.  In essence, they record a table.  If the user creates a VM in Project C11, the following will be recorded and check for quota.

When a User then creates a VM in C21 the table will extend to this:

In addition, when creating the VM2, Nova will check quota and see that, after creation:

• C21 now has 1 out of 25 allocated
• B2 now has 1 out of 25 allocated
• A now has 2 out of 100 allocated

(quota is allocated prior to the creation of the resource to prevent a race condition)

Note that the quota is checked against the original amount, and not the amount reduced by sub allocating the quota.  If project C21 allocates 24 more VMs, to quota check will show:

• C21 now has 25 out of 25 allocated
• B2 now has 25 out of 25 allocated
• A now has 26 out of 100 allocated

If B2 tried to play games, and removes the quota from C21 and gives it to C22, project C21 will be over quota, but Nova will have no way to trap this.  However, the only people this affects is other people within projects B2, C21, C22, and C23.  If C22 attempts to allocate a virtual machine, the quota check will show that B2 has allocated its full quota and cannot create any more.  The quota check will fail.

You might have noticed that the higher level projects can rob quota from the child projects in this scheme.  For example.  If Project A allocates 74 more VMs now, project B1 and children will still have allocated quota, but their quota check will fail because A is at full.  This could be mitigated by having 2 checks for project A: total quota (max 100), and directly allocated quota (max 50).

This scheme removes the quota violation by gaming the system.  I promised to write it up so we could continue to try and poke holes in it.

EDIT:  Quota would also have to be allocated per endpoint, or the endpoints will have to communicate with each other to evaluate usage.

VANCOUVER — At the previous Summit in Sydney, the OpenStack Foundation announced a new integration strategy to support open infrastructure. This strategy resulted in the definition of several focus areas and the Foundation launching its first non-OpenStack project, Kata Containers.

Speaking at the Vancouver Summit, the OSF’s VP of engineering Thierry Carrez took a deep dive into these changes and what they mean for the future. Here’s a summary of his 40-minute talk, you can catch the video here.

First, a bit of background. Back in 2017 a number of discussions in the community all pointed to a similar need for a change. OpenStack started as very project focused, “we equated the community that was producing software with the software being produced,” Carrez says. This was reinforced by the structural project reform in 2015, dubbed the big tent.

“It helped us grow to the massive size that we are today but it was pretty clear that we were hitting some of the limits of that model being project-centric,” he says. Those limitations include isolation from adjacent communities, adoption of other technologies and confusion about about the very definition of OpenStack. In addition, the success of OpenStack lead to requests from outfits like NASA seeking more open collaboration or companies interested in edge or container infrastructure but these projects didn’t fit into the big tent structure.

“What really struck a chord with me and signaled a need for change was realizing our users were mixing and matching open infrastructure technologies to solve their needs and how difficult that integration was,” he says.

So when the board of directors, the Technical Committee, the User Committee and the OpenStack foundation staff met in March 2017 to define strategic issues to work on, better communication about what is OpenStack emerged as key. The result of that work is the OpenStack map.

The map shows what the community produces but focuses on a user perspective, highlighting the pieces of software that you might be interested in deploying to solve a specific problem, says Carrez.

The central piece is the OpenStack cloud infrastructure framework which has multiple components but all of them provide a service that will be consumed by cloud end users through APIs. On the right side are add-on tools to facilitate operations — monitoring, billing etc.— and on the left are  bridges — like SDKs and libraries — that facilitate work with adjacent communities. “That lets us really target the various components that we produce to people who might be interested in deploying them,” he adds.

Shining a light on continuous integration

“One thing we did really well in OpenStack is building continuous integration in from day zero,” Carrez says. “The sad part is that this incredible system was invisible to other communities or other people on open-source projects because it was seen as OpenStack project infrastructure.” The fact that it’s extremely reusable got completely lost in a strategy that tended to promote the entire stack, he says. That’s where the launch of Zuul comes in as the second discrete project.

The approach gets back to the roots of OpenStack, a strong belief that in order to create really successful open-source technology, open source is not enough. It requires open collaboration, where any individual, any organization can contribute as an equal on a level playing field without anyone holding the keys to the kingdom.

Other core concepts include placing equal importance on upstream and downstream development and last, but not least, having fun. “We’re embarking on an ambitious journey and if we don’t have fun along the way we don’t create a community that’s really nice to be in.”

Community

OpenStack has always been more than the sum of its software: from the beginning it was a coalition of like-minded organizations, coming together around the concept of openly developing an open infrastructure solution. These companies might be competitors to public-cloud giants, retailers, telecoms who aren’t interested in “funding their own long-term extinction by financing Amazon AWS,” Carrez says, or research outfits like CERN with massive compute needs.
And while the OSF is expanding to house new initiatives, it’s a focused effort. “We are not interested in grabbing every interesting project out there,” says Carrez. “It’s not a land grab where anything goes. All projects need to be about open infrastructure and they need to play well together.”

Governance

Answering a question from the audience about the what the governance structure will be going forward, Carrez explains that there will continue to be single board of directors for the OSF. The other projects will potentially have their own technical bodies, but it depends on the focus area. Some are more synergistic with other projects and others are more standalone.

There will also always be some version of the User Committee, to make sure those voices are heard, but again how that mechanism works depends on the project. “For Zuul, we need to structure things in a way so the consumers of the project infrastructure can they can feed back into into the development team, but the I’m not sure we would call it a user committee.”
Catch his entire 40-minute talk below.

The post Beyond data center cloud: The future of the OpenStack Foundation appeared first on Superuser.

The post OpenStack Summit 2018: collaboration is everything appeared first on Stackmasters.

VANCOUVER — On the last day of the Vancouver Summit, the Community Contributor Awards gave a special tip of the hat to those who might not be aware that they are valued.

These awards are a little informal and quirky but still recognize the extremely valuable work that everyone does to make OpenStack excel. These behind-the-scenes heroes were nominated by other community members.

There were three main categories: those who might not be aware that they are valued, those who are the active glue that binds the community together and those who share their knowledge with others.

OSF’s upstream developer advocate Kendall Nelson runs the program and handed out the honors at the Summit feedback session.

Jay Pipes – Key to Stack City

Jens Harbott – Bonsai Caretaker
Harbott managed to tackle not just one, but TWO help-most-wanted items. He stepped up to help maintaining our project infrastructure, becoming a new infra-core in a previously under-served region (Europe). He also stepped up to help the Designate project and is now Designate core reviewer!

Stacy Veronneau – ‘Does Anyone Actually Use This’ Trophy
He helped to reboot and fuel the Canadian OpenStack community. He is our first ambassador and also a mentor with the OSF mentor program. He deserves recognition because he has put a lot of effort and time into our community and still does.

Clay Gerrard- ‘When Do You Sleep’ Award
He has worked tirelessly for years on the Swift project. He’s one of the hardest working devs and one of the key components to the great culture we have inside the Swift team. Time and time again I’ve seen him spend hours answering mailing list questions, responding to bugs and mentoring new contributors through code reviews and in channel. He still manages to spend hours giving detailed and thorough reviews from his years of dev and OP experience on this project. He’s definitely a huge contributing factor to the quality of the project. He does all this, yet is still working on developing some highly complex Swift improvements…
To top it all off, he’s very humble. He’s one of the backbones of our community, a key factor to the great team culture and cohesion of our team and continues to work tirelessly behind the scenes.

Adam Spiers – Bonsai Caretaker
He helps everywhere — beyond his direct involvement as the Self-Healing SIG lead, he has been fixing things here and there, getting involved in the PTGbot, StoryBoard… He somehow still finds the time to pursue a major musical career as a talented cellist. I suspect he has a twin also called Adam.

Mark Voelker – Open Infra Structure Shield
He has really helped the Interop working group grow and thrive through out multiple years. He is always working on patches, whether he is flying to his next meeting or staying up late into the night. Without him, the Interop WG would not survive. Thanks!

Marcos Sungaila – Mentor of Mentors
He’s one of the top OpenStack professionals in Brazil. In addition to the excellent work he performs, he never refuses to share his knowledge and always offers great insight into OpenStack. He contributes a lot in terms of spreading the word and teaching Openstack in Brazil.

Matt Riedemann – Smiling in the Face of Adversity Cup
He has been involved in OpenStack for years. A long-time PTL for OpenStack Nova, he’s an extremely resourceful person who’s always willing to go the extra mile to help people out. He takes pride and ownership of the OpenStack Nova project and takes a personal responsibility in the OpenStack ecosystem and he’s an extremely valuable member of our community.

Father Vlasie – The Don’t Stop Believin’ Cup
For implementing the micro-installation of three nodes, one controller and two compute nodes that powers the St. Photios Orthodox Theological Seminary in Etna, California. Stay tuned for an upcoming Superuser feature on his OpenStack journey.

Croke Park Hotel – The Giving Tree
As many might know at this point, the fallout of the winter storm Emma during the Dublin PTG was that the original venue had to close due to a Red safety warning being issued by the Irish government. They did everything with a smile, while sleeping on cots in the hotel. I didn’t hear a single negative comment from any attendees. They joked with us, they engaged us on social media. They became part of our family and we must recognize this, for our family, our community is not just developers… but developers, operators, users and those who interact with all of us.

Stay tuned for news on when the next nominations open!

The post OpenStack Community Contributor Awards: Vancouver Summit edition appeared first on Superuser.

InfiniBand networks are commonplace in the High Performance Computing (HPC) sector, but less so in cloud. As the two sectors converge, InfiniBand support becomes important for OpenStack. This article covers our recent work integrating InfiniBand networks with OpenStack and bare metal compute.

InfiniBand

InfiniBand (IB) is a standardised network interconnect technology frequently used in High Performance Computing (HPC), due to its high throughput and low latency, and intrinsic support for Remote Direct Memory Access (RDMA) based communication.

After initial competition in the IB market, only one vendor remains - Mellanox. Despite this, IB remains a popular choice for HPC and storage clusters.

This slightly old roadmap from the InfiniBand Trade Association shows the data rates of historical and future InfiniBand standards.

Mellanox IB and Virtualised Compute

Before we look at IB for bare metal compute, let's look at the (relatively) well trodden path - virtualised compute. Mellanox provides a Neutron plugin with two ML2 mechanism drivers that allow Mellanox ConnectX-[3-5] NICs to be plugged into VMs via SR-IOV. IB partitions are treated as VLANs as far as Neutron is concerned.

The first driver, mlnx_infiniband, binds to IB ports. The companion agent, neutron-mlnx-agent, runs on the compute nodes and manages their NICs, their SR-IOV Virtual Functions (VFs), and ensures they are members of the correct IB partitions.

The second driver, mlnx_sdn_assist, programs the InfiniBand subnet manager to ensure that compute nodes are members of the required partitions. This may sound simple, but actually involves a chain of services. Mellanox NEO is an SDN controller, Mellanox UFM is an InfiniBand fabric manager, and OpenSM is an open source InfiniBand subnet manager. This driver is optional since neutron-mlnx-agent manages partition membership on the compute nodes, but does add an extra layer of security.

Connectivity to IB partitions from the Open vSwitch bridges on the Neutron network host is made possible via Mellanox's eIPoIB kernel module, provided with OFED, which allows Ethernet to be tunnelled over an InfiniBand network. This allows Neutron to provide DHCP and L3 routing services.

eIPoIB ContraBand?

As of the 4.0 release, Mellanox OFED no longer provides the eIPoIB kernel module that is required for Neutron DHCP and L3 routing. No official solution to this problem is provided, nor is it mentioned in the documentation on the wiki. The OFED software is fairly tightly coupled to a particular kernel, so using an older release of OFED is typically not an option when using a recent OS.

VANCOUVER — The European Organization for Nuclear Research, known as CERN, is on a mission to unravel the mysteries of the universe.

Driven by the demand to support research at the world’s largest particle collider, the CERN IT department decided in 2012 to build an agile infrastructure centered around an OpenStack- based private cloud. CERN provides several facilities and resources to scientists all around the world, including compute and storage resources, for their fundamental research.

Internally, CERN’s data center provides roughly 20 to 25 percent of these resources, says Arne Wiebalck, computing engineer. The analysis is done in a worldwide distributed grid with 170 data centers on about 800,000 cores  and a total 900 petabytes of data on disk on tape. Some 90 percent of the CERN resources are delivered on top of OpenStack.

Running OpenStack in production has also lead to some mysteries, challenges setbacks and achievements, much like those faced by its researchers Wiebalck says.

One of these head-scratchers was the baffling case of innocent instances being killed randomly, VMs “just disappearing.” The culprit was a random independent service that was supposed to remember which PIDs to kill — but instead just killed randomly here and there. “It took us quite a while to identify the murderer,” he adds.

Then there were hosts shutting down right after boot, deletions grinding Cinder to a halt and the bare metal database losing entries.

Challenges included scaling a booming service — more than 300,000 cores over 9,000 hypervisors spanning over 4,000 projects — continuous upgrades, staff turnover and bridging the physical-to-virtual performance gap.

Fortunately the CERN team can count a vast number of achievements, too. In addition to the numbers cited above, they include deployment across two data centers, migration of thousands of VMS due, two million requests handled by a Magnum Kubernetes cluster and many contributions upstream.

Catch his entire talk below or on the OSF’s YouTube channel.

The post OpenStack in production at CERN: Mysteries, challenges, setbacks and achievements appeared first on Superuser.

At the recent Red Hat Summit in San Francisco, and more recently the OpenStack Summit in Vancouver, the OpenStack engineering team worked on some interesting demos for the keynote talks.

I’ve been directly involved with the deployment of Red Hat OpenShift Platform on bare metal using the Red Hat OpenStack Platform director deployment/management tool, integrated with openshift-ansible. I’ll give some details of this demo, the upstream TripleO features related to this work, and insight around the potential use-cases.

TripleO & Ansible, a Powerful Combination!

For anyone that’s used Red Hat OpenStack Platform director (or the upstream TripleO project, upon which it is based), you’re familiar with the model of deploying a management node (“undercloud” in TripleO terminology), then deploying and managing your OpenStack nodes on bare metal.  However, TripleO also provides a very flexible and powerful combination of planning, deployment, and day-2 operations features. For instance, director allows us to manage and provision bare metal nodes, then deploy virtually any application onto those nodes via Ansible!

The “undercloud” management node makes use of several existing OpenStack services, including Ironic for discovery/introspection and provisioning of bare metal nodes, Heat, a declarative orchestration tool, and Mistral, a workflow engine.  It also provides a convenient UI, showcased in the demo, along with flexible CLI interfaces and standard OpenStack ReST APIs for automation.

As described in the demo, director has many useful features for managing your hardware inventory – you can either register or auto-discover your nodes, then do introspection (with optional benchmarking tests) to discover the hardware characteristics via the OpenStack ironic-inspector service.  Nodes can then be matched to a particular profile either manually or via rules implemented through the OpenStack Mistral workflow API. You are then ready to deploy an Operating System image onto the nodes using the OpenStack Ironic “bare metal-as-a-service” API.

When deciding what will be deployed onto your nodes, director has the concept of a “deployment plan,” which combines specifying which nodes/profiles will be used and which configuration will be applied, known as “roles” in TripleO terminology.

This is a pretty flexible system enabling a high degree of operator customization and extension through custom roles where needed, as well as supporting network isolation and custom networks (isolated networks for different types of traffic), declarative configuration of  network interfaces, and much more!

Deploying Red Hat OpenShift Container Platform on bare metal

What was new in the Summit demo was deploying OpenShift alongside OpenStack, both on bare metal, and both managed by Red Hat OpenStack Platform  director. Over the last few releases we’ve made good progress on ansible integration in TripleO, including enabling integration with “external” installers.  We’ve made use of that capability here to deploy OpenShift via TripleO, combining the powerful bare-metal management capabilities of TripleO with existing openshift-ansible management of configuration.

Integration between Red Hat OpenStack Platform and Red Hat OpenShift Container Platform

Something we didn’t have time to get into in great detail during the demo was the potential for integration between OpenStack and OpenShift – if you have an existing Red Hat OpenStack Platform deployment you can choose to deploy OpenShift with persistent volumes backed by Cinder (the OpenStack block storage service). And for networking integration, the Kuryr project, combined with OVN from OpenvSwitch, enables the sharing of a common overlay network between both platforms, without the overhead of double encapsulation.

This makes it easy to add OpenShift managed containers to your infrastructure, while almost seamlessly integrating them with VM workloads running on OpenStack. You can also take advantage of existing OpenStack capacity and vendor support while using the container management capabilities of OpenShift.

Container-native virtualization

After we deployed OpenShift we saw some exciting demos focussed on workloads running on OpenShift, including a preview of the new container native virtualization (CNV) feature. CNV uses the upstream KubeVirt project to run Virtual Machine (VM) workloads directly on OpenShift.

Unlike the OpenShift and OpenStack combination described above, here OpenShift manages the VM workloads, providing an easier way to  transition your VM workloads where no existing virtualization solution is in place. The bare-metal deployment capabilities outlined earlier are particularly relevant here, as you may want to run OpenShift worker nodes that host VMs on bare metal for improved performance. As the demo has shown,  the combination of director and openshift-ansible makes deploying, managing, and running OpenShift and OpenStack easier to achieve!

Today the Kata Containers project launched the 1.0 release, successfully merging Intel® Clear Containers and Hyper runV technologies to provide a single runtime for virtualized containers, delivering the speed of containers with the security of virtual machines (VMs).

Get started with Kata Containers on Kata’s GitHub.

Kata Containers addresses the security drawbacks of traditional containers

Kata Containers bridges the gap between traditional VM security and the lightweight benefits of traditional Linux* containers. Traditional containers share the same underlying Linux kernel. There are known exploits that allow a malicious user to “escape” a container and gain access to the kernel and the shared containers. In a multi-tenant environment where workloads are running with unknown levels of trust, significant efforts are required to ensure a secure system.

Traditional containers use Linux control groups, referred to as cgroups, for managing and allocating resources and namespaces to provide container isolation. Further security isolation is provided by dropping Linux capabilities, using read-only mount points, mandatory access controls (MAC) security measures like those in SELinux and AppArmor*, dropping syscalls using SECCOMP, etc. It’s difficult, if not impossible, to effectively apply these security policies to complex applications.

As a result, most often containers end up being provisioned in their own full VM, negating the performance promises of containers. Protecting against security breaches in these environments is one of the drivers behind the Kata Containers project.

Kata Containers provides container isolation by using hardware virtualization. In the case of Docker*, kata-runtime provides VM isolation at the container level. For Kubernetes, VM isolation is provided at the pod level. (In the rest of this post, the term container/pod refers to for container for Docker and pod for Kubernetes.)

For Kata Containers, each container/pod is booted as a lightweight VM with its own unique kernel instance. Since each container/pod is now running with its own VM, they no longer gain access to the host kernel and get the full security benefits of a VM. This simplifies the security policies you need to put in place to protect the host kernel against container exploits.

Kata Containers also makes it possible for container-as-a-service (CaaS) providers to offer containers running on bare metal. Kata Containers allows mutually untrusting tenants to use the same cluster thanks to the hardware isolation between containers. This assumes there are also network security policies in place to provide network isolation between tenants within the cluster.

How Kata Containers fits into the container ecosystem

A container runtime is the component that handles the life cycle of a container, implementing basic concepts such as creating, starting, stopping and removing a container workload. The Open Container Initiative (OCI) created a runtime specification that details the API for an OCI-compatible runtime. runC is the canonical OCI runtime solution, which is described as a “CLI tool for spawning and running containers according to the OCI specification.” runC uses Linux cgroups and namespaces to provide isolation.

Kata Containers is a member of OCI and the Kata Containers runtime — known as kata-runtime — will be OCI-compatible.

Another place the term runtime is used is in the Container Runtime Interface (CRI) provided in Kubernetes. CRI runtimes are at a higher level of abstraction and should not be confused with an OCI-compatible runtime.

Interacting with Docker Engine

For Docker, kata-runtime is just one more OCI-compatible runtime option that can be used.

In a default configuration, if you install and run Docker, the Docker engine will:

1. Create a container configuration.
2. Pass this configuration to runC.
3. runC will create a container based on the configuration and workload provided from the Docker engine.

If you install Kata Container’s runtime, kata-runtime, you can configure Docker to be aware of both container runtimes, giving users the choice of which to use on a per-container granularity. kata-runtime complements runC and enhances the solution provided by Docker. (See Docker’s runtime documentation for more details.) When using kata-runtime, each Docker container will run within its own lightweight VM.

Kata Containers and Kubernetes

Kubernetes 1.5 introduced the CRI (Container Runtime Interface), which enables a variety of container runtimes to be plugged in easily. Prior to this, Kubernetes only made use of the default Docker image repository and its default OCI-compatible runtime, runC. Since “runtime” continues to be an overloaded term, in this discussion we’ll call the CRI runtime a CRI shim and use “runtime” to describe an OCI-compatible runtime.

Since the introduction of CRI, a number of CRI shims have been introduced, including cri-containerd, CRI-o, dockershim, and frakti. Some of these call into an OCI-based runtime, while others are a monolithic solution. A high-level overview of how these implement a solution via CRI is shown below. Note that dockershim currently only supports runC, not kata-runtime.

Kata Containers provides two interfaces for CRI shims to manage hardware virtualization based Kubernetes pods:

1. An OCI-compatible runtime, kata-runtime. This is currently usable with the CRI solutions, cri-containerd and CRI-O.
2. A hardware virtualization runtime library API for CRI shims to consume and provide a more CRI-native implementation. Frakti is an example CRI shim here.

While the work of defining the concept of a secure sandbox continues at the Kubernetes level, some of the CRI implementations already support the concept of multiple runtimes running on a single node. For example, CRI-O supports the concept of a trusted and an untrusted sandbox. Based on pod annotations and default CRI-O configuration, you can run a mix of VM and namespace-based pods. This article goes into depth on how this currently works with CRI-O.

VM isolation is provided at the pod level for kata-runtime. Containers running inside a Kata Containers pod are isolated and managed via namespaces and cgroups, similar to what is done by runC.

How to try out and get involved with Kata Containers

Kata Containers 1.0 is now ready! Kata Containers is a fully open-source project––check out Kata Containers on GitHub and join the channels below to find out how you can contribute.

katacontainers.io

GitHub: https://github.com/kata-containers

Slack: link: https://katacontainers.slack.com ; invite: http://bit.ly/KataSlack

IRC: #kata-dev on Freenode

Mailing list: http://lists.katacontainers.io/cgi-bin/mailman/listinfo

The post Say hello to Kata Containers 1.0 appeared first on Superuser.

Our project with the Square Kilometre Array includes a requirement for high-performance containerised runtime environments. We have been building a system with bare metal infrastructure, multiple physical networks, high-performance data services and optimal integrations between OpenStack and container orchestration engines (such as Kubernetes and Docker Swarm).

We have previously documented our upgrade of OpenStack deployment from Ocata to Pike. This upgrade impacted Docker Swarm and Kubernetes: provisioning of both COEs in a bare metal environment failed after the upgrade. We resolved the issues with Docker Swarm but left Kubernetes for patching over a major release upgrade.

A fix was announced with Queens release, along with swarm-mode support for Docker. This strengthened the case to upgrade Magnum to Queens on an underlying Openstack Pike. The design ethos of Kolla-Ansible and Kayobe, using containerisation to avoid the nightmares of dependency interlock, made the targeted upgrade of Magnum a relatively smooth ride.