OpenStack ATL Recap to the 11s: the danger of drama + 5 challenges & 5 successes

Posted on May 22, 2014 by Rob H

I’ve come to accept that the “Hallway Track” is my primary session at OpenStack events. I want to thank the many people in the community who make that the best track. It’s not only full of deep technical content; there are also healthy doses of intrigue, politics and “let’s fix that” in the halls.

I think honest reflection is critical to OpenStack growth (reflections from last year). My role as a Board member must not translate into pom-pom waving robot cheerleader.

What I heard that’s working:

Foundation event team did a great job on the logistics and many appreciate the user and operator focus. There’s is no doubt that OpenStack is being deployed at scale and helping transform cloud infrastructure. I think that’s a great message.
DefCore criteria were approved by the Board. The overall process and impact was talked about positively at the summit. To accelerate, we need +1s and feedback because “crickets” means we need to go slower. I’ll have to dedicate a future post to next steps and “designated sections.”
Marketplace! Great turn out by vendors of all types, but I’m not hearing about them making a lot of money from OpenStack (which is needed for them to survive). I like the diversity of the marketplace: consulting, aaServices, installers, networking, more networking, new distros, and ecosystem tools.
There’s some real growth in aaS services for openstack (database, load balancer, dns, etc). This is the ecosystem that many want OpenStack to drive because it helps displace Amazon cloud. I also heard concerns that to be sure they are pluggable so companies can complete on implementation.
Lots of process changes to adapt to growing pains. People felt that the community is adapting (yeah!) but were concerned having to re-invent tooling (meh).

There are also challenges that people brought to me:

Our #1 danger is drama. Users and operators want collaboration and friendly competition. They are turned off by vendor conflict or strong-arming in the community (e.g.: the WSJ Red Hat article and fallout). I’d encourage everyone to breathe more and react less.
Lack of product management is risking a tragedy of the commons. Helping companies work together and across projects is needed for our collaboration processes to work. I’ll be exploring this with Sean Roberts in future posts.
Making sure there’s profit being generated from shared code. We need to remember that most of the development is corporate funded so we need to make sure that companies generate revenue. The trend of everyone creating unique distros may indicate a problem.
We need to be more operator friendly. I know we’re trying but we create distance with operators when we insist on creating new tools instead of using the existing ecosystem. That also slows down dealing with upgrades, resilient architecture and other operational concerns.
Anointed projects concerns have expanded since Hong Kong. There’s a perception that Heat (orchestration), Triple0 (provisioning), Solum (platform) are considered THE only way OpenStack solves those problems and other approaches are not welcome. While that encourages collaboration, it also chills competition and discussion.
There’s a lot of whispering about the status of challenged projects: neutron (works with proprietary backends but not open, may not stay integrated) and openstack boot-strap (state of TripleO/Ironic/Heat mix). The issue here is NOT if they are challenged but finding ways to discuss concerns openly (see anointed projects concern).

I’d enjoy hearing more about success and deeper discussion around concerns. I use community feedback to influence my work in the community and on the board. If you think I’ve got it right or wrong then please let me know.

Hugs & Rants Welcome: OpenStack reaching out with “community IRC office hours”

Posted on May 22, 2014 by Rob H

This is a great move by the OpenStack community managers that I feel like is worth amplifying. Copied from community email:

Hello folks

one of the requests in Atlanta was to setup carefully listening ears for developers and users alike so they can highlight roadblocks, vent frustration and hopefully also give kudos to people, suggest solutions, etc.

I and Tom have added two 1 hour slots to the OpenStack Meetings calendar

Tuesdays at 0800 UTC on #openstack-community (hosted by Tom)

Fridays at 1800 UTC on #openstack-community (hosted by Stefano)

so if you have anything you’d like the Foundation to be aware of please hop on the channel and talk to us. If you don’t/can’t use IRC, send us an email and we’ll use something else: just talk to us.

Regards,

Stef

https://wiki.openstack.org/wiki/Meetings/Community

How DefCore is going to change your world: three advisory cases

Posted on May 20, 2014 by Rob H

The first release of the DefCore Core Capabilities Matrix (DCCM) was revealed at the Atlanta summit. At the Summit, Joshua and I had a session which examined what this means for the various members of the OpenStack community. This rather lengthy post reviews the same advisory material.

DefCore sets base requirements by defining 1) capabilities, 2) code and 3) must-pass tests for all OpenStack products. This definition uses community resources and involvement to drive interoperability by creating the minimum standards for products labeled “OpenStack.”

As a refresher, there are three uses of the OpenStack mark:

Community: The non-commercial use of the word OpenStack by the OpenStack community to describe themselves and their activities. (like community tweets, meetups and blog posts)
Code: The non-commercial use of the word OpenStack to refer to components of the OpenStack framework integrated release (as in OpenStack Compute Project Nova)
Commerce: The commercial use of the word OpenStack to refer to products and services as governed by the OpenStack trademark policy. This is where DefCore is focused.

In the DefCore/Commerce use, properly licensed vendors have three basic obligations to meet: is_it_openstack_graphic

Pass the required Refstack tests for the capabilities matrix in the version of OpenStack that they use. Vendors are expected (not required) to share their results.
Run and include the “designated sections” of code for the OpenStack components that you include.
Other basic obligations in their license agreement like being a currently paid up corporate sponsor or foundation member, etc.

If they meet these conditions, vendors can use the OpenStack mark in their product names and descriptions.

Enough preamble! Let’s see the three Advisory Cases

MANDATORY DISCLAIMER: These conditions apply to fictional public, private and client use cases. Any resemblence to actual companies is a function of the need to describe real use-cases. These cases are advisory for illustration use only and are not to be considered definitive guidenance because DefCore is still evolving.

Public Cloud: Service Provider “BananaCloud”

A popular public cloud operator, BananaCloud has been offering OpenStack-based IaaS since the Diablo release. However, they don’t use the Keystone component. Since they also offer traditional colocation and managed services, they have an existing identity management system that they use. They made a similar choice for Horizon in favor of their own cloud portal.

banana

They use Nova a custom scheduler and pass all the Nova tests. This is the simplest case since they use code and pass the tests.
In the Havana DCCM, the Keystone capabilities are a must pass test; however, there are no designated sections of code for Keystone. So BananaCloud must implement a Keystone-compatible API on their IaaS environment (an effort they had underway already) that will pass Refstack, and they’re good to go.
There are no must pass tests for Horizon so they have no requirements to include those features or code. They can still be OpenStack without Horizon.
There are no must pass tests for Trove so they have no brand requirements to include those features or code so it’s not a brand issue; however, by using Trove and promoting its use, they increase the likelihood of its capabilities becoming must pass features.

BananaCloud also offers some advanced OpenStack capabilities, including Marconi and Trove. Since there are no must pass capabilities from these components in the Havana DCCM, it has no impact on their offering additional services. DefCore defines the minimum requirements and encourages vendors to share their full test results of additional capabilities because that is how OpenStack identifies new must pass candidates.

Note: The DefCore DCCM is advisory for the Havana release, so if BananaCloud is late getting their Keystone-compatibility work done there won’t be any commercial impact. But it will be a binding part of the trademark license agreement by the Juno release, which is only 6 months away.

Private Cloud: SpRocket Small-Business OpenStack Software

SpRocket is a new OpenStack software vendor, specializing in selling a Windows-powered version of OpenStack with tight integration to Sharepoint and AzurePack. In their feature set, they only need part of Nova and provide an alternative object storage to Swift that implements a version of the Swift API. They do use Heat as part of their implementation to set up applications back ended by Sharepoint and AzurePack.

For Nova, they already use the code and have already implemented all required capabilities except for the key-store. To comply with the DefCore requirement, they must enable the key-store capability.
While their implementation of Swift passes the tests, We are still working to resolve the final disposition of Swift so there are several possible outcomes:
1. If Swift is 0% designated then they are OK (that’s illustrated here)
2. If Swift is 100% designated then they cannot claim to be OpenStack.
3. If Swift is partially designated then they have to adapt their deploy to include the required code.
Their use of Heat is encouraged since it is an integrated project; however, there are no required capabilities and does not influence their ability to use the mark.
They use the trunk version of Windows HyperV drivers which are not designated and have no specific tests.

Ecosystem Client: “Mist” OpenStack-consuming Client Library

Mist is a client library for load+kt programmers working on applications using the OpenStack APIs. While it’s an open source project, there are many commercial applications that use the library for their applications. Unlike a “pure” OpenStack program, it also supports other Cloud APIs.

Since the Mist library does not ship or implement the OpenStack code base, the DefCore process does not apply to their effort; however, there are several important intersections with Mist and OpenStack and Core.

First, it is very important for the DefCore process that Mist map their use of the OpenStack APIs to the capabilities matrix. They are asked to help with this process because they are the best group to answer the “works with clients” criteria.
Second, if there are APIs used by Mist that are not currently tested then the OpenStack community should work with the Mist community to close those test gaps.
Third, if Mist relies on an API that is not must-pass they are encouraged to help identify those capabilities as core candidates in the community.

DefCore Capabilities Scorecard & Core Identification Matrix [REVIEW TIME!]

Posted on May 8, 2014 by Rob H

Attribution Note: This post was collaboratively edited by members of the DefCore committee and cross posted with DefCore co-chair Joshua McKenty of Piston Cloud.

DefCore sets base requirements by defining 1) capabilities, 2) code and 3) must-pass tests for all OpenStack products. This definition uses community resources and involvement to drive interoperability by creating minimum standards minimum standards for products labeled “OpenStack.”

The OpenStack Core definition process (aka DefCore) is moving steadily along and we’re looking for feedback from community as we move into the next phase. Until now, we’ve been mostly working out principles, criteria and processes that we will use to answer “what is core” in OpenStack. Now we are applying those processes and actually picking which capabilities will be used to identify Core.

TL;DR! We are now RUNNING WITH SCISSORS because we’ve reached the point there you can review early thoughts about what’s going to be considered Core (and what’s not). We now have a tangible draft list for community review.

While you will want to jump directly to the review draft matrix (red means needs input), it is important to understand how we got here because that’s how DefCore will resolve the inevitable conflicts. The very nature of defining core means that we have to say “not in” to a lot of capabilities. Since community consensus seems to favor a “small core” in principle, that means many capabilities that people consider important are not included.

The Core Capabilities Matrix attempts to find the right balance between quantitative detail and too much information. Each row represents an “OpenStack Capability” that is reflected by one or more individual tests. We scored each capability equally on a 100 point scale using 12 different criteria. These criteria were selected to respect different viewpoints and needs of the community ranging from popularity, technical longevity and quality of documentation.

While we’ve made the process more analytical, there’s still room for judgement. Eventually, we expect to weight some criteria more heavily than others. We will also be adjusting the score cut-off. Our goal is not to create a perfect evaluation tool – it should inform the board and facilitate discussion. In practice, we’ve found this approach to bring needed objectivity to the selection process.

So, where does this take us? The first matrix is, by design, old news. We focused on getting a score for Havana to give us a stable and known quantity; however, much of that effort will translate forward. Using Havana as the base, we are hoping to score Ice House ninety days after the Juno summit and score Juno at K Summit in Paris.

These are ambitious goals and there are challenges ahead of us. Since every journey starts with small steps, we’ve put ourselves on feet the path while keeping our eyes on the horizon.

Specifically, we know there are gaps in OpenStack test coverage. Important capabilities do not have tests and will not be included. Further, starting with a small core means that OpenStack will be enforcing an interoperability target that is relatively permissive and minimal. Universally, the community has expressed that including short-term or incomplete items is undesirable. It’s vital to remember that we are looking for evolutionary progress that accelerates our developer, user, operator and ecosystem communities.

How can you get involved? We are looking for community feedback on the DefCore list on this 1st pass – we do not think we have the scores 100% right. Of course, we’re happy to hear from you however you want to engage: in intentionally named the committed “defcore” to make it easier to cross-reference and search.

We will eventually use Refstack to collect voting/feedback on capabilities directly from OpenStack community members.

DefCore Core Capabilities Selection Criteria SIMPLIFIED -> how we are picking Core

Posted on May 1, 2014 by Rob H

I’ve posted about the early DefCore core capabilities selection process before and we’ve put them into application and discussed them with the community. The feedback was simple: tl;dr. You’ve got the right direction but make it simpler!

So we pulled the 12 criteria into four primary categories:

Usage: the capability is widely used (Refstack will collect data)
Direction: the capability advances OpenStack technically
Community: the capability builds the OpenStack community experience
System: the capability integrates with other parts of OpenStack

These categories summarize critical values that we want in OpenStack and so make sense to be the primary factors used when we select core capabilities. While we strive to make the DefCore process objective and quantitive, we must recognize that these choices drive community behavior.

With this perspective, let’s review the selection criteria. To make it easier to cross reference, we’ve given each criteria a shortened name:

Shows Proven Usage

“Widely Deployed” Candidates are widely deployed capabilities. We favor capabilities that are supported by multiple public cloud providers and private cloud products.
“Used by Tools” Candidates are widely used capabilities:Should be included if supported by common tools (RightScale, Scalr, CloudForms, …)
“Used by Clients” Candidates are widely used capabilities: Should be included if part of common libraries (Fog, Apache jclouds, etc)

Aligns with Technical Direction

“Future Direction” Should reflect future technical direction (from the project technical teams and the TC) and help manage deprecated capabilities.
“Stable” Test is required stable for >2 releases because we don’t want core capabilities that do not have dependable APIs.
“Complete” Where the code being tested has a designated area of alternate implementation (extension framework) as per the Core Principles, there should be parity in capability tested across extension implementations. This also implies that the capability test is not configuration specific or locked to non-open technology.

Plays Well with Others

“Discoverable” Capability being tested is Service Discoverable (can be found in Keystone and via service introspection)

“Doc’d” Should be well documented, particularly the expected behavior. This can be a very subjective measure and we expect to refine this definition over time.

“Core in Last Release” A test that is a must-pass test should stay a must-pass test. This make makes core capabilities sticky release per release. Leaving Core is disruptive to the ecosystem

Takes a System View

“Foundation” Test capabilities that are required by other must-pass tests and/or depended on by many other capabilities
“Atomic” Capabilities is unique and cannot be build out of other must-pass capabilities

“Proximity” (sometimes called a Test Cluster) selects for Capabilities that are related to Core Capabilities. This helps ensure that related capabilities are managed together.

Note: The 13th “non-admin” criteria has been removed because Admin APIs cannot be used for interoperability and cannot be considered Core.

OpenCrowbar.Anvil released – hammering out a gold standard in open bare metal provisioning

Posted on April 30, 2014 by Rob H

I’m excited to be announcing OpenCrowbar’s first release, Anvil, for the community. Looking back on our original design from June 2012, we’ve accomplished all of our original objectives and more.

Now that we’ve got the foundation ready, our next release (OpenCrowbar Broom) focuses on workload development on top of the stable Anvil base. This means that we’re ready to start working on OpenStack, Ceph and Hadoop. So far, we’ve limited engagement on workloads to ensure that those developers would not also be trying to keep up with core changes. We follow emergent design so I’m certain we’ll continue to evolve the core; however, we believe the Anvil release represents a solid foundation for workload development.

There is no more comprehensive open bare metal provisioning framework than OpenCrowbar. The project’s focus on a complete operations model that comprehends hardware and network configuration with just enough orchestration delivers on a system vision that sets it apart from any other tool. Yet, Crowbar also plays nicely with others by embracing, not replacing, DevOps tools like Chef and Puppet.

Now that the core is proven, we’re porting the Crowbar v1 RAID and BIOS configuration into OpenCrowbar. By design, we’ve kept hardware support separate from the core because we’ve learned that hardware generation cycles need to be independent from the operations control infrastructure. Decoupling them eliminates release disruptions that we experienced in Crowbar v1 and makes it much easier to use to incorporate hardware from a broad range of vendors.

Here are some key components of Anvil

UI, CLI and API stable and functional
Boot and discovery process working PLUS ability to handle pre-populating and configuration
Chef and Puppet capabilities including Birk Shelf v3 support to pull in community upstream DevOps scripts
Docker, VMs and Physical Servers
Crowbar’s famous “late-bound” approach to configuration and, critically, networking setup
IPv6 native, Ruby 2, Rails 4, preliminary scale tuning
Remarkably flexible and transparent orchestration (the Annealer)
Multi-OS Deployment capability, Ubuntu, CentOS, or Different versions of the same OS

Getting the workloads ported is still a tremendous amount of work but the rewards are tremendous. With OpenCrowbar, the community has a new way to collaborate and integration this work. It’s important to understand that while our goal is to start a quarterly release cycle for OpenCrowbar, the workload release cycles (including hardware) are NOT tied to OpenCrowbar. The workloads choose which OpenCrowbar release they target. From Crowbar v1, we’ve learned that Crowbar needed to be independent of the workload releases and so we want OpenCrowbar to focus on maintaining a strong ops platform.

This release marks four years of hard-earned Crowbar v1 deployment experience and two years of v2 design, redesign and implementation. I’ve talked with DevOps teams from all over the world and listened to their pains and needs. We have a long way to go before we’re deploying 1000 node OpenStack and Hadoop clusters, OpenCrowbar Anvil significantly moves the needle in that direction.

Thanks to the Crowbar community (Dell and SUSE especially) for nurturing the project, and congratulations to the OpenCrowbar team getting us this to this amazing place.

Can’t Contain(erize) the Hype – is Docker real or a bubble?

Posted on April 18, 2014 by Rob H

Editorial Note: This was written in April 2014. Check out how we are using Docker in our latest architectures.

The new application portability darling, Docker, was so popular at this week’s Red Hat Summit that I was expecting Miley Cyrus’ flock of paparazzi to abandon in her favor of Ben Golub.

Personally, I find Docker to be a useful tool and we’ve been embedding it into our dev and test processes in useful ways for DefCore TCUP (at Conference), OpenCrowbar Admin and Dev Nodes. To me, these are concrete and clear use cases.

There are clearly a lot more great use-cases for Docker, but I can’t help but feel like it’s being thrown into architectural layer cakes and markitectures as a substitute for the non-words “cloud”, “amazing” and “revolutionary.”

How do I distinguish hot from hype? I look for places where Docker is solving just one problem set instead being a magic wand solution to a raft of systemic issues.

Places where I think Docker is potent and disruptive

Creating a portable and consistent environment for dev, test and delivery
Helping Linux distros keep updating the kernel without breaking user space (RHEL 7 anyone?)
Reducing the virtualization overhead of tenant isolation (containers are lighter)
Reducing the virtualization overhead for DevOps developers testing multi-node deployments

But I’m concerned that we’re expecting too many silver bullets

Packaging is still tricky: Creating a locked box helps solve part of downstream problem (you know what you have) but not the upstream problem (you don’t know what you depend on).
Container sprawl: Breaking deployments into more functional discrete parts is smart, but that means we have MORE PARTS to manage. There’s an inflection point between separation of concerns and sprawl.
PaaS Adoption: Docker helps with PaaS but it does not solve neither the “you have to model your apps for a PaaS” nor the “PaaS needs scalable data services” problems

Speaking of Miley Cyrus, it’s not the container that matters, but what’s on the inside. Docker can take a lesson from Miley: attention is great but you’ve still got to be able to sing. I’m not sure about Miley, but I am digging the tracks that Docker is laying down. Docker is worth putting on your play list.

Running with scissors > DefCore “must-pass” Road Show Starts [VIDEOS]

Posted on April 11, 2014 by Rob H

The OpenStack DefCore committee has been very active during this cycle turning the core definition principles into an actual list of “must-pass” capabilities (working page). This in turn gives the community something tangible enough to review and evaluate.

TL;DR! We appreciate those in the community who have been patient enough to help define and learn the process we’re using the make selections; however, we also recognize that most people want to jump to the results.

This week, we started a “DefCore roadshow” with the goal of learning how to make this huge body of capabilities, process and impact easier to digest (draft write-up for review & Troy Toman’s notes). So far we’ve had two great sessions on this topic. We took notes and recorded at both meetups (San Francisco & Austin).

My takeaways of these initial meetups are:

Jump to the Capabilities right away, the process history is not needed up front
You need more graphics – specifically, one for the selection criteria (what do you think of my 1st attempt?)
Work from some examples of scored capabilities
Include some specific use-cases with a user, 2 types of private cloud and a public cloud to help show the impact

Overall, people like what they are hearing. It makes sense and decisions are justified.

We need more feedback! Please help us figure out how to explain this for the broader community.

OpenCrowbar reaches critical milestone – boot, discover and forge on!

Posted on March 17, 2014 by Rob H

We started the Crowbar project because we needed to make OpenStack deployments to be fast, repeatable and sharable. We wanted a tool that looked at deployments as a system and integrated with our customers’ operations environment. Crowbar was born as an MVP and quickly grew into a more dynamic tool that could deploy OpenStack, Hadoop, Ceph and other applications, but most critically we recognized that our knowledge gaps where substantial and we wanted to collaborate with others on the learning. The result of that learning was a rearchitecture effort that we started at OSCON in 2012.

After nearly two years, I’m proud to show off the framework that we’ve built: OpenCrowbar addresses the limitations of Crowbar 1.x and adds critical new capabilities.

So what’s in OpenCrowbar? Pretty much what we targeted at the launch and we’ve added some wonderful surprises too:

Heterogeneous Operating Systems – chose which operating system you want to install on the target servers.
CMDB Flexibility – don’t be locked in to a devops toolset. Attribute injection allows clean abstraction boundaries so you can use multiple tools (Chef and Puppet, playing together).
Ops Annealer –the orchestration at Crowbar’s heart combines the best of directed graphs with late binding and parallel execution. We believe annealing is the key ingredient for repeatable and OpenOps shared code upgrades
Upstream Friendly – infrastructure as code works best as a community practice and Crowbar use upstream code without injecting “crowbarisms” that were previously required. So you can share your learning with the broader DevOps community even if they don’t use Crowbar.
Node Discovery (or not) – Crowbar maintains the same proven discovery image based approach that we used before, but we’ve streamlined and expanded it. You can use Crowbar’s API outside of the PXE discovery system to accommodate Docker containers, existing systems and VMs.
Hardware Configuration – Crowbar maintains the same optional hardware neutral approach to RAID and BIOS configuration. Configuring hardware with repeatability is difficult and requires much iterative testing. While our approach is open and generic, my team at Dell works hard to validate a on specific set of gear: it’s impossible to make statements beyond that test matrix.
Network Abstraction – Crowbar dramatically extended our DevOps network abstraction. We’ve learned that a networking is the key to success for deployment and upgrade so we’ve made Crowbar networking flexible and concise. Crowbar networking works with attribute injection so that you can avoid hardwiring networking into DevOps scripts.
Out of band control – when the Annealer hands off work, Crowbar gives the worker implementation flexibility to do it on the node (using SSH) or remotely (using an API). Making agents optional means allows operators and developers make the best choices for the actions that they need to take.
Technical Debt Paydown – We’ve also updated the Crowbar infrastructure to use the latest libraries like Ruby 2, Rails 4, Chef 11. Even more importantly, we’re dramatically simplified the code structure including in repo documentation and a Docker based developer environment that makes building a working Crowbar environment fast and repeatable.

Why change to OpenCrowbar? This new generation of Crowbar is structurally different from Crowbar 1 and we’ve investing substantially in refactoring the tooling, paying down technical debt and cleanup up documentation. Since Crowbar 1 is still being actively developed, splitting the repositories allow both versions to progress with less confusion. The majority of the principles and deployment code is very similar, I think of Crowbar as a single community.

Interested? Our new Docker Admin node is quick to setup and can boot and manage both virtual and physical nodes.

Anyone else find picking OpenStack summit sessions overwhelming?!

Posted on March 3, 2014 by Rob H

The scope and diversity of sessions for the upcoming OpenStack conference in Atlanta are simply overwhelming. As a board member, that’s a positive sign of our success as a community; however, it’s also a challenge as we attempt to pick topics. That’s why we turn to you, the OpenStack community, to help sift and select the content.

Even if you are not attending, we need your help in selection! Content from the summits is archived and has a much larger outside of the two conference days. You’re voice matters for the community.

While it’s a simple matter to ask you to vote for my DefCore presentation and some excellent ones from my peers at Dell, I’d also like share some of my thoughts about general trends I saw illustrated by the offerings:

Swift has a strong following as a solution outside of other products
Ceph seems to emerging as a critical component with Cinder
Neutron has breath but not depth in practice
HA and Upgrades remain challenges
We are starting to see specializations emerge (like NFV)
OpenStack case studies! There are many – some of uncertain utility as references
Some community members and companies are super prolific in submitting sessions. Perhaps these sessions are all great but on first pass it seems out of balance.
Vendor pitch or conference session? You often get both in the same session. We’re still not certain how to balance this.

The number and diversity of sessions is staggering – we need your help on voting.

We also need you to be part of the dialog about the conference and summits to make sure they are meeting the community needs. My review of the sessions indicates that we are trying to serve many different audiences in a very limited time window. I’m interested in hearing yours! Review some sessions and let me know.

Rob Hirschfeld

On Computing, Containers, Cloud & Tech Culture

Category Archives: Events