tinkerbell / .github Goto Github PK

0.0 0.0 7.0 66 KB

License: Apache License 2.0

.github's Introduction

Tinkerbell

License

Tinkerbell is licensed under the Apache License, Version 2.0. See LICENSE for the full license text. Some of the projects used by the Tinkerbell project may be governed by a different license, please refer to its specific license.

Tinkerbell is part of the CNCF Projects.

Community

The Tinkerbell community meets bi-weekly on Tuesday. The meeting details can be found here.

Community Resources:

What's Powering Tinkerbell?

The Tinkerbell stack consists of several microservices, and a gRPC API:

Tink

Tink is the short-hand name for the tink-server and tink-worker. tink-worker and tink-server communicate over gRPC, and are responsible for processing workflows. The CLI is the user-interactive piece for creating workflows and their building blocks, templates and hardware data.

Smee

Smee is Tinkerbell's DHCP server. It handles DHCP requests, hands out IPs, and serves up iPXE. It uses the Tinkerbell client to pull and push hardware data. It only responds to a predefined set of MAC addresses so it can be deployed in an existing network without interfering with existing DHCP infrastructure.

Hegel

Hegel is the metadata service used by Tinkerbell and OSIE. It collects data from both and transforms it into a JSON format to be consumed as metadata.

OSIE

OSIE is Tinkerbell's default an in-memory installation environment for bare metal. It installs operating systems and handles deprovisioning.

Hook

Hook is the newly introduced alternative to OSIE. It's the next iteration of the in-memory installation environment to handle operating system installation and deprovisioning.

PBnJ

PBnJ is an optional microservice that can communicate with baseboard management controllers (BMCs) to control power and boot settings.

Building

Use make help. The most interesting targets are make all (or just make) and make images. make all builds all the binaries for your host OS and CPU to enable running directly. make images will build all the binaries for Linux/x86_64 and build docker images with them.

Configuring OpenTelemetry

Rather than adding a bunch of command line options or a config file, OpenTelemetry is configured via environment variables. The most relevant ones are below, for others see https://github.com/equinix-labs/otel-init-go

Currently this is just for tracing, metrics needs to be discussed with the community.

Env Variable	Required	Default
`OTEL_EXPORTER_OTLP_ENDPOINT`	n	localhost
`OTEL_EXPORTER_OTLP_INSECURE`	n	false
`OTEL_LOG_LEVEL`	n	info

To work with a local opentelemetry-collector, try the following. For examples of how to set up the collector to relay to various services take a look at otel-cli

export OTEL_EXPORTER_OTLP_ENDPOINT=localhost:4317
export OTEL_EXPORTER_OTLP_INSECURE=true
./cmd/tink-server/tink-server <stuff>

Website

For complete documentation, please visit the Tinkerbell project hosted at tinkerbell.org.

.github's People

Contributors

Watchers

Forkers

displague detiber mmlb micahhausler tinkerbell-bac isabella232 chrisdoherty4

.github's Issues

The issue template is the same as the pull request template.

As demonstrated:

## Description

<!--- Please describe what this PR is going to change -->

## Why is this needed

<!--- Link to issue you have raised -->

Fixes: #

## How Has This Been Tested?
<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran to -->
<!--- see how your change affects other areas of the code, etc. -->


## How are existing users impacted? What migration steps/scripts do we need?

<!--- Fixes a bug, unblocks installation, removes a component of the stack etc -->
<!--- Requires a DB migration script, etc. -->


## Checklist:

I have:

- [ ] updated the documentation and/or roadmap (if required)
- [ ] added unit or e2e tests
- [ ] provided instructions on how to upgrade

cc @alexellis

Contributing: fixed line lengths vs one-sentence-per-line

Coming out of discussions in #4.

Going to start it with @displague's verbatim comment and then follow up, hopefully that is the most seamless option.

@displague wrote:

@mmlb

We don't have a documentation style-guide in place. I think an issue or PR on that topic would be the best place to have this discussion 😄.

That aside, I don't know which is the more popular opinion here.

I can link to posts with the opposite view point on readability and fixed-length lines. License files (markdown or others) tend to carry the 80 character column width. I encounter and use the Markdown Linter in many places, including VS Code.

In my HTML editing days, I preferred one paragraph per line, and I preferred using the IDE to soft-break text.

My preference changed when I started working with Go and Markdown, especially in Github where the review pane needs to be horizontally scrolled beyond 80 characters (Update: no longer the case? 🤔). The viewer or maintainer is not always behind an editor or IDE where width settings can be controlled.

The column width changes nothing for readers of the rendered documents. This mostly affects the people that manage and review documents.

Would it help if I adopted the citation style of markdown links? (Update: Applied).
http://www.rubycoloredglasses.com/2017/11/markdown-links-80-character-line-length/

No /COMMUNICATION.md

Many documentation links point to /COMMUNICATION.md.

Refactor team_repo_permission to make it easier to maintain

https://github.com/tinkerbell/.github/blob/master/terraform/repo_team_permission.tf

This is the file where we assign teams to the repo they maintain. I think we can do a better job using modules or for_each but I am not really good with Terraform but @displague is way better!

When this is done and we are happy with the structure I will take the job and create new teams with better ownership of repositories.

Transfer organizational documents to github.com/tinkerbell/org

Much of the documentation for Tinkerbell was moved to this repo from github.com/tinkerbell/org after tinkerbell/org#1, but as @gianarb stated out:

We can do it in .github but .github is a template as well and if I understood how a template works files and directories get moved to all the repositories created from that template. And this is not what I would like

Narrator: .github is a template repo

As it turns out, we don't want everyone opening GH org membership requests on any repo in the Tinkerbell org, so @tstromberg resurrected the org repository.

It now seems obvious to keep the issue templates, label organization in .github, but can we move the following items to org?

Code of Conduct
Communications
EMERITUS.md

This would effectively make .github a place for things that apply to every repo (labels, issue/pr templates, CODEOWNERS, etc) and org a place for organizational documents, membership applications, etc.

Current maintainers @mmlb @thebsdbox @tstromberg can you weigh in?

Shared OWNERS.md file is missing

A missing OWNERS.md in this project is referenced from other projects.

https://github.com/tinkerbell/tink/blob/main/OWNERS.md, for example.

This is similar to #43

[Organization/member]: request for micahhausler

GitHub Username

micahhausler

Role

Member

Requirements

I have reviewed the community membership guidelines
I have enabled 2FA on my GitHub account
I have subscribed to the tinkerbell-contributors e-mail list
I am actively contributing to 1 or more Tinkerbell subprojects
I have two sponsors that meet the sponsor requirements listed in the community membership guidelines
I have spoken to my sponsors ahead of this application, and they have agreed to sponsor my application
OPTIONAL: I have taken the Inclusive Open Source Community Orientation course

Sponsor 1

@detiber

Sponsor 2

@jacobweinstock

List of contributions to the Tinkerbell project

Invite 'thelinuxfoundation' + 'caniszczyk' as org owners for CNCF onboarding

cncf/toc#559