Public PR

[hitankar-freshworks]

What is this PR? This is the first public pull request to enable reviewers to inspect openshift-launchpad which is a simple three-tiered application (database, server, client) designed to be run locally or deployable to the BC Government OpenShift cluster with ease. More information about Launchpad may be found in the README.md.

How to review This PR is intended to capture all of the work done so far to build the “MVP” version of OpenShift Launchpad. Since the PR (which will merge the release branch to master) has multiple commits, we recommend reviewing the application as a whole. Feel free to focus only on areas of special interest if desired - spend your time as you feel appropriate. Note: The application is intended to be light. It’s polished enough to be ready for review, but is intentionally lacking some bells and whistles to ensure clarity and ease of navigation.

Test the application locally

• Clone the ‘release’ branch to your computer.
• Follow the instructions in the README.md to get started.

Area of interest

• Evaluate server and client app.
• Evaluate OpenShift config files in the ‘deployment’ folder.
• Evaluate commands in the Makefile.
• Anything else that you’re passionate about, please let us know!

[WadeBarnes]

On Windows you should be leveraging chocolatey to install your packages at least. It would make it easy to install Git complete with GitBash, and make. That's if you are not using WSL completely. I have some scripts over here (https://github.com/WadeBarnes/dev-tools/tree/master/chocolatey) to help install chocolaty.

[jujaga]

As @patricksimonian mentioned, a PR of this size makes it difficult to catch any missed points. Anyways, here are my thoughts:

Day Zero

• Windows users should not be forgotten about. For any dependencies and requirements on any tools, there should be some quick documentation on how users on each platform (windows, unix, macos) can get these tools installed as they may not necessarily have them (or even know about them).
• As @WadeBarnes mentions, chocolatey is a fantastic package management tool for users who aren't working in WSL environment completely. Definitely a strong recommendation to have people pointed in that direction.
• make is not a tool Windows users have by default. Even if it was, I'm hesitant to say this should be "the" way to get applications locally stood up and deployed. It may be better to instead have concise readme documentation on how to do certain common tasks, and then allow the developer teams decide if they want to leverage make in their workflows or not.
• I personally have some mixed feelings about using Docker Compose because this is another orchestration-like tool. While it's good for just getting started, it can very quickly turn into a distraction from the actual deployment work (Openshift or Kubernetes).
• As a note, Minishift is not very easy/friendly to use for Windows users and assumes their machines have Hyper-V installed and working correctly. It's very easy to fall into a rabbithole trying to get minishift to work. One semi-viable alternative is to just leverage the existing openshift cli to make a mock local cluster instead (assuming you have Docker for Windows installed, and for Windows users, you NEED to use oc-cli version 3.9 as later versions simply do not work due to path bugs) and running oc cluster up instead. This makes it so that there's one less thing to have to install and manage, and would have a closer alignment to eventual day-to-day operations.

Database

• Extending on @patricksimonian 's comment, one of the ways openshift teams have been deploying HA Patroni databases is by leveraging Patroni (which uses statefulsets, and WAL history archiving to preserve transactional integrity between the different Postgres nodes in the cluster). We have some live examples of Patroni (ephemeral and persistent) being used here (look for any patroni*.yaml files here).

Code Structure

• Each of the client and server "packages" should have a README.md file or equivalent to help developers know how to get started with local development, and have a general orientation of code structure.
• There is quite a bit of PEP8 rules that appear to be disabled in server/.pylintrc - is this intentional?
• client/package.json is still under ISC licence - this should be Apache 2.0.

Openshift Deployments

• deployment folder should probably be named openshift instead as all content in there is OpenShift templates (they won't work on Kubernetes or other alternative cluster orchestration platforms).
• Wondering if there was a specific reason why these templates were all written in JSON instead of YAML, as usually most k8s/openshift templates tend to be presented as YAML templates.
• deployment/nsp.json should be cautiously considered, as the rules in place are effectively allowing any traffic between pods in the same namespace and outbound traffic to internet. While this is a good starting point, this is not something that should just be set and then forgotten about.
• Would be a good idea to have a README.md or similar residing in the deployment folder to document some of these deployment templates and their caveats on usage. I believe there should be some considerations made to assist developers who may not be as familiar with OpenShift paradigm to help ease their learning curve.

Overall, it looks like a great start. However, there needs to be a lot of testing to ensure sufficient confidence that a fresh new developer trying to use this can get things going without getting stuck on caveats and potential environment differences.

[patricksimonian]

One of the other things I'd like to press here is that if there is a way to codify best practices to continuously improve your infrastructure then that should be here. As @jujaga mentioned, this is a great starting point. I think what we need is the community to weigh in an make active contributions to projects such as these. This will build confidence and dependability. One thing i've noticed with Gatsby Documentation is that they invite community members to contribute. The maintainers of this project couldn't possibly be expected to be experts in the entire stack of a project.

[WadeBarnes]

In reply to the comment from @ashtonmeuser about obfuscation of the underlying OpenShift CLI commands. I would argue a health dose of abstraction on top of the oc cli is extremely beneficial to new and existing teams. The last thing you want to have is teams fumbling around with the raw oc cli and not using the best practice commands and switches (and tools) other teams have already figured out how and when to use the hard way. I see new teams that have taken the BCDevExchange OpenShift 10x courses struggling with this every day, and I've been pulled in to help many struggling teams get their applications deployed into OpenShift.

Provide tools that are easier to understand that perform the heavy lifting for the teams to get new teams started quickly. That provides them with the piece of mind their project is up and running quickly, and provides a reference as to how all that was accomplished if they so choose to look under the covers. Once their project is running they can learn the ins and outs of the raw cli if they need to do something more complicated or are just interested.

I manage about 80 namespaces in OpenShift. For the majority of those I use the openshift-developer-tools scripts to manage the creation and management of the build and deployment configurations. The scripts also allow a developer to extent the scripts and create application specific management scripts. Without these automation scripts I would not be able to effectively or efficiently manage the number of namespaces I do. A very simple and well documented example of how to use these scripts is here; Cullen Commission Website. A more complex example including custom ./manage scripts can be found here; orgbook-configurations

As mentioned by others the bcdk provides similar tools for creating more effective and intelligent pipelines.

[wenzowski]

@hitankar-freshworks this is now pretty stale and has a fair amount of community feedback. Do you have any specific additional asks?

[garywong-bc]

bump? @hitankar-freshworks

[garywong-bc]

This PR is stale, so closing for now. Feel free to re-open if important to you.