profile
viewpoint
Rob Szumski robszumski Red Hat San Francisco https://robszumski.com Product Manager for OpenShift. Previously @coreos.

operator-framework/operator-lifecycle-manager 566

A management framework for extending Kubernetes with Operators

operator-framework/community-operators 228

The canonical source for Kubernetes Operators that appear on OperatorHub.io, OpenShift Container Platform and OKD.

robszumski/k8s-service-proxy 9

A Kubernetes service reverse proxy that requires no configuration

operator-framework/community 3

Community organizational documentations and process for Operator Framework

robszumski/docker-libcloud-dns 3

Update DNS records with libcloud

philips/nya 1

Archive frontend code for the etcd dashboard

robszumski/docs 1

Documentation for CoreOS in markdown

robszumski/clair 0

Vulnerability Static Analysis for Containers

robszumski/cockroachdb-operator 0

Operator build using the CockroachDB Helm chart. Uses the Operator SDK under the hood.

pull request commentopenshift/console

frontend: Update OperatorHub description text

once logged in, I can confirm that this URL is valid

rebeccaalpert

comment created time in 3 days

pull request commentopenshift/openshift-origin-design

Add Red Hat Marketplace Support

LGTM, thanks!

itsptk

comment created time in 10 days

PR opened operator-framework/operator-lifecycle-manager

Update internal objects proposal to use annotation on CSV instead of CRD

Description of the change: Updates the internal objects proposal.

Motivation for the change: Many users are not able to read the full list of CRDs on a cluster, so this proposal now stores a list of internal CRD names as an annotation on the CSV.

+10 -9

0 comment

1 changed file

pr created time in 11 days

create barnchrobszumski/operator-lifecycle-manager

branch : update-proposal

created branch time in 11 days

pull request commentoperator-framework/community-operators

Update Crunchy PostgreSQL Operator to v4.2.0

The Crunchydata has exhibited a ton of new auto-remediation and auto-healing that represent an "auto pilot" level in the capability model. I propose we include that as part of this PR.

Detailed release notes here, but this is the relevant details:

Failed primaries now automatically heal, which significantly reduces the time in which they can rejoin the cluster.

A major change to this container is that the PostgreSQL process is now managed by Patroni. This allows a PostgreSQL cluster that is deployed by the PostgreSQL Operator to manage its own uptime and availability, to elect a new leader in the event of a downtime scenario, and to automatically heal after a failover event.

In addition, Pod anti-affinity and backups with retention policies make this a really exemplary Operator.

cbandy

comment created time in 12 days

pull request commentoperator-framework/community-operators

Update Crunchy PostgreSQL Operator to v4.2.0

The Crunchydata has exhibited a ton of new auto-remediation and auto-healing that represent an "auto pilot" level in the capability model. I propose we include that as part of this PR.

Detailed release notes here, but this is the relevant details:

Failed primaries now automatically heal, which significantly reduces the time in which they can rejoin the cluster.

A major change to this container is that the PostgreSQL process is now managed by Patroni. This allows a PostgreSQL cluster that is deployed by the PostgreSQL Operator to manage its own uptime and availability, to elect a new leader in the event of a downtime scenario, and to automatically heal after a failover event.

In addition, Pod anti-affinity and backups with retention policies make this a really exemplary Operator.

cbandy

comment created time in 12 days

pull request commentoperator-framework/community

Draft Governance and Membership

@gerred Thanks for the proposal, sorry about the late respond. This got caught in the Thanksgiving email pile.

how does everyone on the Operator Framework side feel about making KUDO another subproject within the Operator Framework umbrella?

I feel good about that.

I've also suggested in a subsequent comment that we separate out kuttl for usage by the whole project, which may be worth spawning into an infrastructure / testing / certification working group.

I am super excited about a common testing framework. It's key to high quality.

How about we kick off this process in early January?

dmesser

comment created time in a month

issue commentoperator-framework/operator-sdk

Document reporting of vulnerabilities

Hey @flickerfly, thanks for pointing out this gap and the new GitHub feature. We have some automation scripts that we use to care for repos and will get this added to all of them.

In the meantime, you can find contact instructions at https://access.redhat.com/security/team/contact. As part of our donation to the CNCF, we would align with their processes as well.

flickerfly

comment created time in a month

pull request commentcncf/toc

Request to present the Operator Framework to the TOC as an incubating project

Is it an operator if it has no reconcile loop?

The Operator Framework's definition is very closely tied to "day 2" operations, executing reconfiguration and upgrading Operators and Operands, which does require a loop running.

Plans for other SDKs? lots of potential for other SDKs, python, java for example.. Totally extensible SDK model

The goal of the OF is to meet our users in their world and their skillset. If you are a traditional software engineer, Go might be your best bet. If you are more of an Ops person or need to call out to external resources, Ansible might be better. If you've invested in Helm charts, the Helm SDK is there for you.

There is no requirement to use the SDK, and we plan for other SDKs to exist over time to meet this goal. Common asks are for Java and Python, among others. For example, there are several community Java SDKs that exist out of the Operator Framework today. There is a proposal for the Kudo tool to join OF as well.

Would love to see roadmap for next 6 months

Here's a brief summary:

  • SDK (see proposals on github)
    • unified foundation with upstream kubebuilding/controller-runtime/etc
    • single command in SDK to install OLM on given cluster
    • produce new bundle format (open to using Helm here for the kube object part of it)
    • Helm SDK moves to Helm v3
    • Ansible SDK goes to 1.0
    • refactored testing tool with ability to include custom tests
  • OLM (see proposals on github)
    • simplify API surfaces
    • focus on local dev experience and registering private catalogs of Operators
    • use new bundle format
    • easier upgrades using implied semver path vs explicit mappings
  • OperatorHub (see issues on github)
    • expanding GUI editor for building your Operator metadata
    • run custom tests as part of review pipeline

Reacting to monitoring alerts is not really defined today

The capability model is intentionally vague because it really does depend on the app which parts make sense and which don't. A failure condition might actually do two things (if it made sense for the app):

  1. Trigger an alert via Prometheus or the desired tech, so a human is aware of the condition
  2. Determine if it can be auto-remediated by the Operator and do so if configured to do so

Now, you can imagine that you wouldn't want an alert every time a Deployment redeployed a Pod, but you might when your data replication is slow or not working. But it's all app dependent. The current model is to highlight a rough capability level and have the Operators that have reached that level serve as a examples, but explicitly listing this out would be an interesting exercise if you think it would be helpful.

erinaboyd

comment created time in 2 months

pull request commentcncf/toc

Request to present the Operator Framework to the TOC as an incubating project

Capturing some of the questions for longer answers from the TOC call on Dec 3:

Is it an operator if it has no reconcile loop?
Plans for other SDKs?
lots of potential for other SDKs, python, java for example..
Totally extensible SDK model
Would love to see roadmap for next 6 months
Reacting to monitoring alerts is not really defined today
erinaboyd

comment created time in 2 months

pull request commentoperator-framework/operator-lifecycle-manager

doc: add internal image proposal

@sbose78 Turning that into a blacklist seems like a good solution to me

robszumski

comment created time in 2 months

pull request commentoperator-framework/operator-lifecycle-manager

doc: add internal image proposal

@christianvogt Are you thinking it goes on to spec.customresourcedefinitions.owned? No issues on that for me other than it's now a deeper OLM spec change not an optional field to be read (or not).

robszumski

comment created time in 2 months

push eventrobszumski/falloutweb.com

Rob Szumski

commit sha 6f0a0311432c8729759da47dd47f613012360524

Update Rob

view details

push time in 2 months

push eventrobszumski/operator-lifecycle-manager

Rob Szumski

commit sha 4cc0432a95e6ca5609879af5ecaf45367b113a21

Delete file that was renamed

view details

push time in 3 months

push eventrobszumski/operator-lifecycle-manager

robszumski

commit sha 099fbc5a61e9cd9ef3ba57b91bf699e697436f1e

Swap annotation namespace

view details

push time in 3 months

pull request commentoperator-framework/operator-lifecycle-manager

doc: add internal image proposal

PTAL again, updated title, filename and added the new annotations.

robszumski

comment created time in 3 months

push eventrobszumski/operator-lifecycle-manager

robszumski

commit sha 82bd6237df65c685d0bb18b13d3fcae0563bfd8c

Use the correct title

view details

push time in 3 months

push eventrobszumski/operator-lifecycle-manager

robszumski

commit sha c48c47d95529639e599caf2a70200c13863ff6f4

Ammend proposal to include data CRDs and new annotation names.

view details

push time in 3 months

pull request commentoperator-framework/operator-lifecycle-manager

doc: add internal image proposal

Merging these two comments together would leave us with:

kind: CustomResourceDefinition
apiVersion: apiextensions.k8s.io/v1beta1
metadata:
  name: hivetables.metering.openshift.io
  annotations:
    apps.kubernetes.io/internal-object:true
    apps.kubernetes.io/data-object:true

I don't see any issues with that and can get the proposal updated. WDYT @joelanford @sbose78?

robszumski

comment created time in 3 months

PR opened operator-framework/operator-lifecycle-manager

Reviewers
doc: add internal image proposal

Description of the change: This PR adds a proposal for marking a subset of CRDs as "internal", meaning they are not for end-user consumption or manipulation.

Motivation for the change: Many Operators have internal concepts that are confusing to end-users when they show up in user interfaces or CLIs like operatorhub.io. This proposal solidifies this concept into a standard convention that others can follow to hide these CRDs and downstream user interfaces by hide them if deemed necessary for their user base.

+51 -0

0 comment

1 changed file

pr created time in 3 months

create barnchrobszumski/operator-lifecycle-manager

branch : proposal-internal-image

created branch time in 3 months

startedmatryer/bitbar

started time in 3 months

push eventrobszumski/node-docker-echo

Rob Szumski

commit sha fc3016a1f42b58a9832b984d446241adba15051a

Remove read console output

view details

push time in 3 months

push eventrobszumski/node-docker-echo

Rob Szumski

commit sha 52520f392dd50c448ae24f126c1a42e5c4e1bec3

Remove env output

view details

push time in 3 months

push eventrobszumski/node-docker-echo

Rob Szumski

commit sha cb538dcf1546ccdbf6e141f89e6bd08699428a5e

Record CPU and RAM

view details

push time in 3 months

fork robszumski/node-docker-echo

Example node.js echo environment variables in docker

fork in 3 months

issue commentoperator-framework/operator-sdk

Image use in blog post

@WtfJoke Forgot to add, can you use a caption that links it back to the original? The capabilities get updated every so often and it would be great for folks to have a way to discover the latest.

WtfJoke

comment created time in 3 months

issue commentoperator-framework/operator-sdk

Image use in blog post

@WtfJoke Feel free to use it, no issues there. Update this issue with a link to the post so we can check it out!

WtfJoke

comment created time in 3 months

pull request commentcncf/toc

Request to present the Operator Framework to the TOC as an incubating project

The link I have used in the past is below. I know that Go module handling has changed recently that throws this off.

https://github.com/search?l=Go&q=github.com%2Foperator-framework%2Foperator-sdk%2Fpkg%2Fsdk&type=Code

"Showing 2,788 available code results" but that does double or triple count some projects.

erinaboyd

comment created time in 4 months

more