Twitter github

Become a Founding Kubernetes Certified Service Provider

In early September, CNCF will be announcing the founding class of Kubernetes Certified Service Providers (KCSPs). If your company provides professional services to support Kubernetes deployments, please consider signing up to become part of the founding class.

The main benefits of becoming a KCSP are:

  • Placement in a new section at the top of https://kubernetes.io/partners/
  • Monthly meetings with cloud native project leaders, TOC members,
    and representatives from the CNCF Governing Board
  • Access to leads from end users looking for support

Requirements are:

  • Three or more engineers who pass the Certified Kubernetes Administrator (CKA) exam
  • Demonstrable activity in the Kubernetes community including active contribution
  • A business model to support enterprise end users, including putting engineers at a customer site

The CKA exam is about to enter early release beta testing prior to the public release in September. It is an online, proctored, performance-based test that requires solving multiple issues from a command line. It takes 3 to 4 hours to complete, and costs $300, though a discount is available for beta testers to $100.

If your company is interested in becoming a KCSP, please do the following 4 things:

  1. Ensure that your company is listed at https://kubernetes.io/partners/
    and if not (or if the listing should be updated), please do so via the link
    at the top of that page.
  2. Have 3 or more of your Kubernetes experts sign up for the beta test at:
    https://docs.google.com/forms/d/e/1FAIpQLSd9-6nL5L3SzWIddCSPoKeuX_Pdq_KHI8C4mQzcUryP-gu0dQ/viewform
    .Please have them use their company email so we can properly associate
    them. Within a week, we will send beta test dates, a discount coupon code, and instructions to register and schedule.
  3. Register your interest in becoming a KCSP at this form: https://docs.google.com/forms/d/e/1FAIpQLSfai-zlNuvP-q0fz3jw89v3v4m_wYaF7tOBmNY0WoKsZgeQUQ/viewform
  4. If you are not already on it, and want to track progress of the certification program over time, please subscribe to the Kubernetes Certification Working Group list: https://lists.cncf.io/mailman/listinfo/cncf-kubernetescertwg.

Questions or issues? Please email cncf-kcsp-support at lists.cncf.io

Thanks!

2018 Eclipse Simultaneous Release Name: Photon

Hey Eclipse friends, as part of my duties on the Eclipse Planning Council, we have worked with the Eclipse Foundation EMO and wider community to finalize the Oxygen+1 simultaneous release name (see bug 510201 for details): Photon

Thanks to everyone who voted in the community!

Open Container Initiative in 2017

Last year I had the opportunity to help build out/run the Open Container Initiative (OCI) and I wanted to take some time to reflect back on what the OCI community accomplished in 2016 and how far we’ve come in a short time since we were founded a little over a year ago.

The community has been busy! The project saw 3000+ commits from 128 different authors across 36 different organizations. With the addition of the Image Format specification project, we expanded our initial scope from just the runtime specification. Our membership grew to nearly 50 members and we also added new developer tools projects —runtime-tools and image-tools— which serve as repositories for conformance testing tools and have been instrumental in gearing up for the upcoming v1.0 release.

We’ve also recently created a new project within OCI called go-digest (which was donated and migrated from docker/go-digest). This provides a strong hash-identity implementation in Go and services as a common digest package to be used across the container ecosystem.

In terms of early adoption, we have seen Docker support the OCI technology in its container runtime (libcontainer) and contribute it to the OCI project (as runc). Additionally, Docker has committed to adopting OCI technology in its latest containerd announcement. The Cloud Foundry community has been an early consumer of OCI by embedding runc via Garden as the cornerstone of its container runtime technology. The Kubernetes project is incubating a new Container Runtime Interface (CRI) that adopts OCI components via implementations like CRI-O and rklet. The rkt community is adopting OCI technology already and is planning to leverage the reference OCI container runtime runc in 2017. The Apache Mesos community is currently building out support for the OCI image specification.

Speaking of the v1.0 release, we are getting close to launch! The milestone release of the OCI Runtime and Image Format Specifications version 1.0 will hopefully be available this first quarter of 2017 or shortly the following quarter, drawing the industry that much closer to standardization and true portability. To that end, we’ll be launching an official OCI Certification program once the v1.0 release is out. With OCI certification, folks can be confident that their OCI-certified solutions meet a high set of criteria that deliver agile, interoperable solutions.

We’ll be looking into the possibility of adding more projects in the coming year, and we hope to showcase even more demonstrations of the specs in action under different scenarios. We’ll be onsite at several industry events, so please be on the lookout and check out events page for details.

There is still much work to be done!  The success of our community depends on a wide array of contributions from all across the industry; the door is always open, so please come join us in shaping the future of container technology! In particular, if you’re interested in contributing to the technology, we recommend joining the OCI developer community which is open to everyone. If you’re building products on OCI technology, we recommend joining as a member and participating in the upcoming certification program.

Note: This was cross-posted to the OCI community blog.

Improved GitHub Code Review Tools

The default GitHub code review experience has always been lacking for me, especially when it comes to code review enforcement. I definitely admit to my bias of being a Gerrit code review fan but at least GitHub is moving in the right direction with recent code review improvements earlier this year.

On the bright side, GitHub has a fairly open API and there’s been a great ecosystem of tools that have popped up that help deal with some of the shortcomings in my opinion. Even more so after GitHub opened up the commit status API, it’s definitely enabled some interesting workflows.

PullApprove

One interesting code review workflow involves enforcing that changes must be reviewed by certain team members (which is a fairly common code review practice). In my opinion, the best tool that I’ve come across that handle this scenario is PullApprove. All you need is a simple metadata file that formalizes your requirements, and you’re good to go, here’s an example of what we use in the OCI project:

approve_by_comment: true
approve_regex: '^(Approved|lgtm|LGTM|:shipit:|:star:|:\+1:|:ship:)'
reject_regex: ^Rejected
reset_on_push: true
signed_off_by:
required: true
reviewers:
teams:
- image-spec-maintainers
name: default
required: 2

The important pieces here are the approve/reject regexes which dictate what terms will be used to approve and reject changes:

As a bonus, the “signed_off_by” setting can be used to enforce DCO which is to make sure your commits are properly signed off for DCO purposes.

LGTM

I also want to give an honorable mention to LGTM which is a simple pull request approval system that is open source but not as configurable as PullApprove IMHO.

Reviewable.io

For any large scale and high velocity projects on GitHub, managing what you need to review can be a daunting task. I’ve personally found Reviewable.io as an interesting tool that helps address the problem of managing the context of what you looked last and what’s on your queue.

Anyways, hope this helps and happy code reviewing! If you’re interested in more integrated GitHub code review tools, I highly recommend checking out the GitHub integration directory.

Open Container Initiative at 12 Months

Today at DockerCon 2016 I had fun speaking with colleagues on where we are with the Open Container Initiative (OCI) after about a year:

The industry needs standards around the container format/runtime to enable portability, if you’re interested in joining this effort you can find more information here: https://www.opencontainers.org/join

Cloud Native Computing Foundation and Kubernetes

Over the past few months I’ve been helping form an infrastructure focused open source foundation (from scratch) and acting as its interim Executive Director. I’m thrilled to announce that the Cloud Native Computing Foundation (CNCF) has accepted its first project, Kubernetes:

There’s a ton of work to do still around developing and evolving development processes, but I’m happy to have our first project which will collaborate with us to establish and evolve these processes (along with the other projects that get accepted).

In the end, it’s really been an adventure in setting up this new open source foundation and I definitely need to write a blog post on some of the lessons learned so far about the experience. I’m really looking forward to see the CNCF become a cloud native commons home for many projects, move the cloud native computing paradigm forward and define what it means to be an open source foundation in the modern GitHub era.

CFP: MesosCon 2016

MesosCon is happening again and I’m happy to be involved with the Program Committee. MesosCon 2016 will be in Denver on June 1st-2nd:

The CFP is open until March 9th and the schedule will be announced on April 4th!

 

@EclipseFdn Neon+1 Name: Oxygen

Oxygen (a pretty important element for life) is now the name of the Eclipse Foundation Neon+1 release:

oxygen

See bug 485861 for more details.

Git Ketch multi master replication in JGit

Google is contributing a new a new multi-master implementation to JGit called Git Ketch (based on the Raft consesnus algorithm).

More information is on the JGit mailing list and on Gerrit if you’re interested in this important feature.

@EclipseFdn Neon+1 Name

The vote for the Eclipse Foundation’s Neon+1 name is over (see bug 485861):

  1. Oxygen (Condorcet winner: wins contests with all other choices)
  2. Odyssey loses to Oxygen by 121–112
  3. Osiris loses to Oxygen by 141–94, loses to Odyssey by 131–97
  4. Opal loses to Oxygen by 136–95, loses to Osiris by 112–109
  5. Oberon loses to Oxygen by 143–98, loses to Opal by 115–110
  6. Orpheus loses to Oxygen by 142–90, loses to Oberon by 121–99
  7. Ozone loses to Oxygen by 152–61, loses to Orpheus by 111–103
  8. Ohm loses to Oxygen by 152–69, loses to Ozone by 103–99
  9. Oceana loses to Oxygen by 161–54, loses to Ohm by 103–94
  10. Oort loses to Oxygen by 158–63, loses to Oceana by 116–78

Screen Shot 2016-01-14 at 9.37.03 AM Pending legal approval, Eclipse Oxygen will be the name for Neon+1