Synopsys and Red Hat OpenShift 4: One smooth Operator!

May 06, 2019 / 4 min read

Table of Contents

What is the Synopsys Operator?
Operator resources
Operator publishing lessons learned
Final advice

Synopsys and Red Hat have produced a smooth Operator that I think would even impress Sade herself! Synopsys is introducing a new version of our Synopsys Operator, version 2019.4.0, which helps our customers easily deploy our application security testing tools in container orchestration environments. We also just completed Red Hat certification for this version of the Synopsys Operator, and we’re tremendously impressed by how it’s rendered and integrated into OpenShift 4.

In this blog post, I’ll share some resources and lessons we learned through the process of producing what you see in the following screenshot. Even though it’s not the smooth operator Sade was singing about, it’s pretty darn sexy!

What is the Synopsys Operator?

Synopsys Operator is a cloud-native administration utility for Synopsys software. Synopsys Operator assists in the deployment and management of Synopsys software like Black Duck, OpsSight Connector, and Black Duck Alert in a Kubernetes and Red Hat OpenShift environment.

In addition to the OperatorHub, the Synopsys Operator deployment can be managed by a utility called synopsysctl. The synopsysctl utility makes it easy to deploy Synopsys Operator, and it eliminates the need to edit YML/JSON configuration files when deploying and managing software with Synopsys Operator. Synopsysctl provides a rich set of command-line parameters to allow for fast, highly configurable deployments of Black Duck, OpsSight Connector, and Black Duck Alert. Synopsysctl’s interface mimics that of kubectl and oc, making it immediately familiar to anyone with Kubernetes or Red Hat OpenShift experience.

Operator resources

You definitely need a rock star engineering team, like we have at Black Duck, to develop a smooth Operator. Stating the obvious here. But then, as you begin the Operator publishing process, here are some key resources to keep in mind:

Community Operators GitHub: Give the readme a full read to start with. Lots of good information to guide you through the entire process.
OperatorHub > Contribute: Another great initial read to help guide the process.
Red Hat Certified Operator Build Guide: Some great steps and tips to get your Operator ready for OpenShift.
Building your CSV: Very good detail about specific fields and blocks within your CSV yaml.
OperatorHub > Preview: After countless hours of pressing your spacebar and delete keys to align your yaml, this utility gives you a much-needed endorphin rush when you see all your hard work.
Some excellent, smart, and patient Operator folk who help you through the process, like @SamiSousa, @jdob, @jsm84, and Paul Christensen.

Operator publishing lessons learned

As a result of all my mishaps, I’ve got some tips to help you while you publish your Operator. You’ll notice a common theme in all these points: If I had just RTFM!

Contribute where? Know where to contribute your Operator. OK, I didn’t take my own advice and instead failed to read the entire community Operators guide. So I first put the Synopsys Operator in the wrong folder.

Test, test, test. There’s a reason why testing your Operator is the first thing mentioned in the instructions before you submit a pull request for your Operator. Here’s how I recommend testing each change to your metadata files:
1. Test your CSV in Operator Preview.
2. Run operator-courier verify twice, the second time with the --ui_validate_io parameter.
3. Test your Operator in a Kubernetes or OpenShift environment manually! I tell my kids, “Do as I say, not as I do!” Same thing applies to this very important step. I procrastinated on this point, and it cost me some precious time and many, many embarrassing failed builds.

OpenShift 4 deployment. Test with OpenShift by using the OpenShift Developer Preview. In the past, I always dreaded building an OpenShift cluster. Now, you can do it in three easy steps:
1. ./openshift-install create cluster.
2. Go get a mocha.
3. Return to your workstation. (OK, Steps 2 and 3 are optional, but everything has three steps, right?)

-certified. When you test with OpenShift, your packageName requires a “-certified” suffix.

Quay authentication. When using operator-courier to push your application to Quay, don’t stop reading before you get to the Authentication section.

OperatorSource. When linking your Quay application repository, check out this OperatorSource yaml, which is what finally worked for me:


apiVersion: operators.coreos.com/v1
kind: OperatorSource
metadata:
name: synopsys-certified
namespace: openshift-marketplace
spec:
type: appregistry
endpoint: https://quay.io/cnr
registryNamespace: davemeurer
displayName: "Synopsys Operators"
publisher: "Synopsys"

Spec descriptors. Don’t fret with spec descriptors! If your Operator CRDs have a ton of fields, you aren’t required to specify each one in the CSV. You only need the important ones that are either required or involve user interaction.

Scorecard score. Your scorecard score won’t be on your permanent record! If you get a 44%, it’s OK. You still have a chance to get into college. And most importantly, the score doesn’t affect whether your build fails or not.

Failed builds. If you are lucky enough to experience OLM errors that say it’s failing to pick up the subscription, there could be something wrong with your CSV yaml. We also saw these errors in our manual OpenShift 4 testing, where the subscription status was unknown and the installed and installing counts were always 0. In our case, we had quotes in env blocks in places where they shouldn’t have been. Whoopsies! The only way we found this was to rewrite and strip down our Operator CSV based on a working example, test it manually, and add blocks in, one at a time, to pinpoint the bad yaml. It seems painstaking, but who wouldn’t want to press space and delete for another hour?

Final advice

Well, I hope this blog is somewhat helpful as you contribute your Operators to Kubernetes and OpenShift. At the very least, the best advice I can give you as you’re working on the required metadata files is to throw on some early ’80s music in hopes that you’re building a smooth Operator. Feel free to ping me if you have any questions, or stop by our booths at Red Hat Summit and KubeCon this year!