-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
new blog by OTel CI/CD SIG - Repost from cncf.io/blogs #5718
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A first quick review, PTAL
### Artifacts for supply chain security, aligned with the SLSA specification | ||
|
||
The [artifact attribute namespace](https://opentelemetry.io/docs/specs/semconv/attributes-registry/artifact/) had multiple attributes for its first implementation. One key set of attributes within this namespace cover [attestations](https://slsa.dev/attestation-model) that closely align with the [SLSA](https://slsa.dev/spec/v1.0/about) model. This is really the first time a direct connection is being made between Observability and Software Supply Chain Security. Consider the following [supply chain threat model](https://slsa.dev/spec/v1.0/threats) defined by SLSA: | ||
![SLSA supply chain threat model diagram](SLSA-supply-chain-model.png) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
from what I understand this image is by SLSA? We need to add a license note to that image, please review the project's license to find out what is needed for that (it seems to be custom so I can not provide guidance):
https://github.com/slsa-framework/slsa/blob/main/LICENSE.md
depending on the order of things, we might follow #5681 already
![SLSA supply chain threat model diagram](SLSA-supply-chain-model.png) | |
{{< figure class="figure" src="SLSA-supply-chain-model.png" attr="ADD LICENSE NOTICE HERE" attrlink="https://github.com/slsa-framework/slsa/blob/a2660277e5c4ec587eeae17edacb3d199395349e/LICENSE.md" >}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not a lawyer, and thus this isn't legal advice. The way I read their license is that the image needs to be attributed to SLSA at the respective version.
- Copyright.
1.1. Copyright License. Contributor grants everyone a non-sublicensable, perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as expressly stated in this License) copyright license, without any obligation for accounting, to reproduce, prepare derivative works of, publicly display, publicly perform, and distribute any materials it submits to the full extent of its copyright interest in those materials. Contributor also acknowledges that the Working Group may exercise copyright rights in the Specification, including the rights to submit the Specification to another standards organization.
1.2. Copyright Attribution. As a condition, anyone exercising this copyright license must include attribution to the Working Group in any derivative work based on materials developed by the Working Group. That attribution must include, at minimum, the material’s name, version number, and source from where the materials were retrieved. Attribution is not required for implementations of the Specification.
Source: https://github.com/slsa-framework/slsa?tab=License-1-ov-file#readme
Image was taken from https://slsa.dev/spec/v1.0/images/supply-chain-threats.svg - source code: https://github.com/slsa-framework/slsa/blob/main/docs/images/supply-chain-threats.svg
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Style suggestions and copy edits. Thanks!
|
||
However, the diverse landscape of CI/CD tools creates challenges in achieving consistent end-to-end observability. With each tool having its own means, format and semantic conventions for reporting the pipeline execution status, fragmentation within the toolchain can hinder seamless monitoring. Migrating between tools becomes painful, as it requires reimplementing existing dashboards, reports and alerts. | ||
|
||
Things become even more challenging, when needing to monitor multiple tools involved in the release pipeline in a uniform manner. This is where [open standards and specifications become critical](https://horovits.medium.com/the-rise-of-open-standards-in-observability-highlights-from-kubecon-13694e732c97). They create a common uniform language, one which is tool- and vendor-agnostic, enabling cohesive observability across different tools and allowing teams to maintain a clear and comprehensive view of their CI/CD pipeline performance. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Things become even more challenging, when needing to monitor multiple tools involved in the release pipeline in a uniform manner. This is where [open standards and specifications become critical](https://horovits.medium.com/the-rise-of-open-standards-in-observability-highlights-from-kubecon-13694e732c97). They create a common uniform language, one which is tool- and vendor-agnostic, enabling cohesive observability across different tools and allowing teams to maintain a clear and comprehensive view of their CI/CD pipeline performance. | |
Things become even more challenging when you need to monitor multiple tools involved in the release pipeline in a uniform manner. This is where [open standards and specifications become critical](https://horovits.medium.com/the-rise-of-open-standards-in-observability-highlights-from-kubecon-13694e732c97). They create a common uniform language, one which is tool- and vendor-agnostic, enabling cohesive observability across different tools and allowing teams to maintain a clear and comprehensive view of their CI/CD pipeline performance. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is a syndicated article from the CNCF.io blog, I'd rather not change wording unless meaningful, and "need vs. needing" looks more like styling IMO.
Co-authored-by: Severin Neumann <[email protected]> Co-authored-by: Tiffany Hrabusa <[email protected]>
accept suggestion Co-authored-by: Tiffany Hrabusa <[email protected]>
@horovits since you provided that feedback across multiple comments by @tiffany76, I'll address it here:
I disagree with that. We (SIG Comms) allow the re-publication of blog posts from other sources, acknowledging that there are reasons making this necessary, but we will not bend on our standards of quality, this includes that we provide rich copy editing feedback to blog authors. We are very lucky that we have experienced technical writers like @tiffany76 in our SIG who spend time and effort to ensure that. Please reciprocate with spending your time and effort to either accept the feedback or engage in a meaningful discussion. |
per @tiffany76 review: Although trace and event are defined terms in OpenTelemetry, they are common nouns and should not be capitalized. To illustrate: the OpenTelemetry Collector is capitalized because it is a proper noun referring to a specific collector. If you refer to other collectors, the term is not capitalized. Co-authored-by: Tiffany Hrabusa <[email protected]>
delete extra blank lines
@horovits please take a look at the feedback provided. Thanks |
This is a post by SIG CI/CD Observability, which was posted on cncf.io towards KubeCon NA '24.
Submitting in accordance with the approved issue 5546: #5546
Note: due to lack of support in the OTel blog in embedding social media (thanks @svrnm for the clarification), those embeds from the original CNCF blog have been omitted.
If there's a way to support those, please let me know and I'd be happy to amend.