openslo / openslo.github.io Goto Github PK

Currently we are using a URL identifier for our OpenSLO Schemas in this format:

• https://openslo.com/schemas/<VERSION>/openslo.schema.json
• https://openslo.com/schemas/<VERSION>/parts/<PART>.schema.json

The JSONSchema tooling supports importing schemas referenced by their ID when that ID is a URL; which is why we've chosen to use this ID format. However, in order to make that possible, we need to actually serve the schema documents at that URL. I expect this could be done in one of two ways:

• dynamic proxying of the raw content from the Github Repo
• bake in the documents through the build process to be served directly

The openslo.com uses Hugo under the hood which works with Markdown files. The raw Markdown file for the specification from GitHub is available under https://raw.githubusercontent.com/OpenSLO/OpenSLO/main/README.md. Maybe there is a possibility to render it directly on the website. Using URL as a source allows having a single source of truth and avoiding manual updates

Problem to solve

The oslo CLI as validation is a great first step to automate everything. We can build a container image, and it gets used in CI/CD workflows and deployments.

Thinking of schema validation in (cloud) IDEs, such schema spec should be available online. Hosting the YML or JSON representation somewhere as single source of truth is easy. Building a plugin which locally validates the spec with live linting is a little harder.

The hardest part is to lint and validate, and build a request-response model which can be automated. The idea is to provide a REST API endpoint for OpenSLO where you'll POST the OpenSLO config file against, and get feedback from the parser/linter.

Future iterations of the spec may allow things like include or more DSL related stuff. Building a unique interface (CLI and API )

Proposal

• Extend oslo to run a webserver which accepts a POST request to /v1/spec/lint
• Build a public server which responds to requests (may need fleet scaling behind a fleet to ensure availability)
• Document how to build your own API host / proxy e.g. in a Kubernetes cluster

Inspiration

• Twitter thread: https://twitter.com/dnsmichi/status/1403286307405766657
• GitLab CI/CD config YAML validation at /ci/lint, discussed in this blog post: https://about.gitlab.com/blog/2021/04/21/devops-workflows-json-format-jq-ci-cd-lint/ and documented at https://docs.gitlab.com/ee/api/lint.html#validate-the-ci-yaml-configuration

Let's contribute and collaborate on the website and release an updated version as soon as possible https://gohugo.io/hosting-and-deployment/hosting-on-github/#build-hugo-with-github-action

If we go to blog section and zoom a bit. Description of card overflow goto buttom. We should fix that.

Problem to solve

As we try and build the community, we shouldn't require people to email me to get an invite to the slack channell

Proposal

Set up a site that allows users to sign up and get invited to the slack channel automatically. Example: https://signup.hangops.com/

Use something like this inviterbot to make a site that people can go to for self service.

Installation instructions here.

We will need to set up hosting and DNS records for this.

Attempting to connect to openslo.com in a browser with a metamask extension flags a warning that the openslo.com website has been reported as an ethereum phishing site.