profile
viewpoint

opencontainers/selinux 83

common selinux implementation

spdx/license-list-XML 54

This is the repository for the master files that comprise the SPDX License List

jbenet/depviz 49

dependency visualizer for the web

mndrix/tap-go 20

Test Anything Protocol for Go

openshift/kubernetes-drain 8

A Go library for kubectl's drain logic

adina/boot-camps 2

Software Carpentry boot camp material

LJWilliams/2014-03-17-uw 1

Software Carpentry workshop at U. Washington, March 17-18 2014

wking/angular-validation-match 1

Checks if one input matches another. Useful for confirming passwords, emails, or anything.

wking/awk-lesson 1

test run of a bower workflow for lesson distribution

pull request commentopenshift/origin

WIP: Bug 1843183: test/e2e/upgrade: Split update testing into per-hop cases

It takes 5 seconds to actually spot which upgrade is failing. Is this so you can see the summary as a test name?

Yup. I don't want more bugs with this level of initial granularity, and would much rather have bugs and success aggregation for from {source} to {target} should succeed. Even better would be having this update-scoped test just be "did the update get through or not" with the parallel disruption constraints being independently fatal and not feeding into this JUnit bucket, but I haven't figured that out yet.

wking

comment created time in 5 hours

pull request commentopenshift/openshift-controller-manager

pkg/image/controller/scheduler: Restore some logging

upgrade died on install. Previous death also install. Previous death on Service was unreachable during disruption for at least. Hopefully a run of bad luck, because I can't see how any of those would be related to this change.

wking

comment created time in 5 hours

Pull request review commentopenshift/enhancements

enhancements/update/available-update-metadata: Propose a new enhancement

+---+title: available-update-metadata+authors:+  - "@wking"+reviewers:+  - "@abhinavdahiya"+  - "@crawford"+approvers:+  - TBD+creation-date: 2019-11-19+last-updated: 2020-04-22+status: implementable+---++# Available-update Metadata++## Release Signoff Checklist++- [x] Enhancement is `implementable`+- [x] Design details are appropriately documented from clear requirements+- [x] Test plan is defined+- [x] Graduation criteria for dev preview, tech preview, GA+- [ ] User-facing documentation is created in [openshift-docs](https://github.com/openshift/openshift-docs/)++## Summary++Currently the ClusterVersion API has [a single `Update` type][api-update] used for both [the `desiredUpdate` input][api-desiredUpdate] and the [`desired`][api-desired] and [`availableUpdates`][api-availableUpdates] outputs.+But update requests like `desiredUpdate` have different schema requirements than output like `desired` and `availableUpdates`.+For example, [the `force` property][api-force] makes sense in the `desiredUpdate` context, but not in the `availableUpdates` contexts.+And release metadata like landing page URIs and available channels makes sense in the `desired` and `availableUpdates` contexts, but not in the `desiredUpdate` context.+This enhancement adds a new `Release` type to be used in `status` properties so we can distinguish between input and output schema.++## Motivation++Cincinnati provides [metadata about releases][cincinnati-metadata], including (since [here][cincinnati-channel-metadata]) the channels to which the release currently belongs.+Exposing that information to in-cluster consumers allows them to use live metadata, instead of talking to Cincinnati directly or hard-coding expected values.+For example, the console currently [hard-codes an expected set of available channels][console-channels] for a given release; with this enhancement they could look up available channels in `status.desired.metadata["io.openshift.upgrades.graph.release.channels"]`.++### Goals++* Exposing release metadata provided by upstream Cincinnati for the currently-desired and available-update releases.+* Documenting some well-known metadata keys.++### Non-Goals++* Restricting metadata keys to those documented in this enhancement.+    Cincinnati may continue to add and remove keys as they see fit as long as they provide at least the keys required by this enhancement.+* Teaching Cincinnati to support requests without `channel` query parameters.+    This might be useful for recovering from users specifying [`desiredUpdate`][api-desiredUpdate] that were not in their configured [`channel`][api-channel], but I am fine leaving recovery to the users.+    They should have received sufficient information to adjust their channel from wherever they received the target release they are supplying.++## Proposal++FIXME: In response to [Abhinav's comment](https://github.com/openshift/enhancements/pull/123#issuecomment-603370388), here are some alternative ways to do this.+Once we reach a consensus on [*a*](#a) or [*b*](#b), the alternative will move into [the *alternatives* section](#alternatives)++### A++As proposed in [this API pull request][api-pull-request], to add a new type:++```go+// Release represents an OpenShift release in the release graph.+// +k8s:deepcopy-gen=true+type Release struct {+  // version is a semantic versioning identifying the update version. When this+  // field is part of spec, version is optional if image is specified.+  Version string `json:"version"`++  // image is a container image location that contains the update. When this+  // field is part of spec, image is optional if version is specified and the+  // availableUpdates field contains a matching version.+  Image string `json:"image"`++  // metadata is additional metadata associated with the release, such+  // as associated channels (under+  // io.openshift.upgrades.graph.release.channels) or a landing page+  // (under url).+  //+  // +optional+  Metadata map[string]string `json:"metadata,omitempty"`+}+```++and to use that type instead of the current `Update` for `ClusterVersionStatus` properties.++Then, in the cluster-version operator (CVO), to port existing logic like [available-update translation][cluster-version-operator-update-translation] and [available-update lookup][cluster-version-operator-update-lookup] to preserve the Cincinnati metadata.+In some cases (when an administrator requested an update that was not in the available update set), this would require an additional Cincinnati request to retrieve metadata about the requested release.++### B++Similar to [*a*](#a), except instead of changing the `ClusterVersionStatus` fields, we'd deprecate them and make `Release` a stand-alone custom resource.+`Version` would become `ObjectMeta.Name`, and `Image` and `Metadata` would be `Status` properties.+Then we need some way to figure out which is the current release and which are the available updates, which is a bit racier now that we can no longer retrieve a single, atomic snapshot with a `GET ClusterVersion`.++### i++We'd also add some additional properties:++```go+// Source a the release version for which updates to this release can be launched.+// For example, source on a 4.1.1 release might be "4.1.0".+Source string `json:"source"`+```++In addition, the current release (being reconciled by the cluster-version operator) would have a `release.openshift.io/role` annotation with a `current` value.++### ii++We'd add new `ClusterVersionStatus` properties like:++```+// Current is the release version which is currently being reconciled by the cluster-version operator.+Current string `json:"current,omitempty"`++// AvailableUpdatesV2 holds release versions to which the current version may be updated.+AvailableUpdatesV2 []string `json:"availableUpdatesV2,omitempty`+```++### iii++Leave the current `ClusterVersionStatus` alone and just continue to fill the now-redundant `Update` properties (like `Image`) and use their `Version` properties instead of [*ii*](#ii)'s bare strings.++### Metadata properties++This enhancement declares the following to be well-known metadata properties:++* `url` (optional), a landing page for the release.+    For releases created by Red Hat, this will usually be the Errata for the release.+* `io.openshift.upgrades.graph.release.channels` (optional), the comma-delimited set of channels to which the release currently belongs.++Cincinnati implementation may, at their discretion, define, add, and remove additional properties as they see fit.++### User Stories++#### Dynamic Channel Selection++Alice's cluster is on release 4.1.23, and she wants to know if she can update to 4.2.+With interfaces like the console and `oc adm upgrade ...` exposing:++```console+$ curl -sH 'Accept:application/json' 'https://api.stage.openshift.com/api/upgrades_info/v1/graph?channel=stable-4.1&version=4.1.23' | jq -r '.nodes[] | select(.version == "4.1.23").metadata["io.openshift.upgrades.graph.release.channels"] | split(",")[]'+prerelease-4.1+stable-4.1+candidate-4.2+```++she could see that, while upgrading to 4.2 was possible, it was not yet considered stable.+And running the query again later, she could see that it had been added to `stable-4.2`.++### Implementation Details/Notes/Constraints

Ok, pushed 9e9e0f5 -> 63c027a, adding some additional language around this along with a new Available-Update Landing Pages use case.

wking

comment created time in 6 hours

push eventwking/openshift-enhancements

W. Trevor King

commit sha 63c027acf21bc489348c8db7f0c94baef218260c

enhancements/update/available-update-metadata: Propose a new enhancement With Abinav's separate-object approach as an alternative [1]. [1]: https://github.com/openshift/enhancements/pull/123#issuecomment-603370388

view details

push time in 6 hours

pull request commentopenshift/api

config/v1: New Release type for ClusterVersionStatus

Rebased onto master and updated to pull in the Release type from openshift/enhancements@9e9e0f511939f1e3 with e4687177 -> ae275214.

wking

comment created time in 6 hours

push eventwking/openshift-api

W. Trevor King

commit sha 6ffedc3bded7e4dfdc4d696c87a16942c0353cbf

config/v1/types_cluster_operator: Fix "Degraded indicated" -> "Degraded indicates" And drop the earlier, orphaned comment block. Both of these issues slipped through my earlier 40c55f8085 (config/v1/types_cluster_operator: ClusterOperatorStatus doc wordsmithing, 2019-10-28, #501).

view details

W. Trevor King

commit sha c6fbb2d424bfd8b1d0eba3e8998312d20a3d6578

config/v1/types_cluster_operator: Fix "spec hold the" typo The typo was originally from 898d7e3b7c (api: Move ClusterVersion/ClusterOperator into config.openshift.io, 2018-11-09, #127). The "any operator" bit explains why we don't want, for example, ingress-operator specific config in here. The later ClusterOperatorSpec comment goes into more detail on that with its 'pause' hypothetical, but a bit of extra hinting can't hurt ;).

view details

Ricardo Maraschini

commit sha f0feeb9e41d2156e71c0b14cc8ad7579febbfef1

Migrating imageregistry api definitions. Migrating image registry operator API definition.

view details

OpenShift Merge Robot

commit sha 8d715d6587469c5eb4858cbeb972f6cd34a0e786

Merge pull request #519 from ricardomaraschini/migrating-image-registry Bug 1769008: Migrating imageregistry api definitions.

view details

OpenShift Merge Robot

commit sha 722e7cb2b8bc90fe0aced27e51a7d76420ff46a5

Merge pull request #510 from wking/cluster-operator-status-condition-copy-edits config/v1/types_cluster_operator: Fix "Degraded indicated" -> "Degraded indicates"

view details

OpenShift Merge Robot

commit sha 2ea89d203c53704f1fcfeb55c13ededab14fd020

Merge pull request #499 from wking/cluster-operator-spec-hold-typo config/v1/types_cluster_operator: Fix "spec hold the" typo

view details

Michal Fojtik

commit sha a65417b2da8ba57fe4f5e502861b872b0ca5a953

operator: add description for spec and status

view details

Michal Fojtik

commit sha a15df1599300d13c57f48d037d13261d673fe711

update generated

view details

OpenShift Merge Robot

commit sha 0272a9e155e3b16a8d15bbda60a61f70f61ab687

Merge pull request #529 from mfojtik/fix-spec-status-desc Add description to spec and status fields for kube operators

view details

Clayton Coleman

commit sha d4eabe2e9a66c8cd11d486335b157d33ea22a86c

image: Improve godoc for image types End users should have a bit more info about the core image types. Describe behavior, intended use, target audience, and some details of API interactions.

view details

OpenShift Merge Robot

commit sha 9f834e33746603079c1052d1435d139742af9bf8

Merge pull request #524 from smarterclayton/improve_godoc image: Improve godoc for image types

view details

Dan Mace

commit sha 26e4884704fda329cbd98fed0073dbd3809d1f3d

operator/ingress: Add NodePort publishing strategy This commit implements the NodePort publishing strategy API described in the `ingress-nodeport-publishing` enhancement proposal[1]. Please refer to the enhancement proposal for more details. [1] https://github.com/openshift/enhancements/blob/master/enhancements/network/ingress-nodeport-publishing.md

view details

Dan Mace

commit sha 4c0185a321c132859506944e15fd89eabd476616

update NodePortService naming for consistency

view details

Dan Mace

commit sha 5f126bd17debeb179b24689ac6e460a29ae811fe

more naming updated

view details

Abu Kashem

commit sha 45d73db5bd0df6e70270bb2b7d15c859bf07a6c7

bump(*): kubernetes-1.17.0-rc.2 - bump glide.yaml to kubernetes-1.17.0-rc.2.

view details

Abu Kashem

commit sha 9eba4cde39fd4fa34db38614d1651ee38766b6c4

update generated files - update the vendor folder - update config/0000_10_config-operator_01_build.crd.yaml to match 'Description'.

view details

OpenShift Merge Robot

commit sha 377b5e2dedcb20d3c71c19236162d9e44c1ed8d4

Merge pull request #535 from tkashem/pin-kube-1.17 Bump to kubernetes-1.17.0-rc.2

view details

Ricardo Maraschini

commit sha 6bf0e230a43a8faf00df09e04e1d9acfaf5a5187

Adding missing Azure container name validation. This patch adds validation to the Azure's container name as already done by the type and crd on image registry operator.

view details

Maciej Szulik

commit sha 52ffecf235bf379c0adff33eb6011f01eb1a785d

Add missing optional tags

view details

Maciej Szulik

commit sha 9fc4efe09d2f9c417cc582015a18c48b037f4489

Generated changes

view details

push time in 6 hours

Pull request review commentopenshift/enhancements

enhancements/update/available-update-metadata: Propose a new enhancement

+---+title: available-update-metadata+authors:+  - "@wking"+reviewers:+  - "@abhinavdahiya"+  - "@crawford"+approvers:+  - TBD+creation-date: 2019-11-19+last-updated: 2020-04-22+status: implementable+---++# Available-update Metadata++## Release Signoff Checklist++- [x] Enhancement is `implementable`+- [x] Design details are appropriately documented from clear requirements+- [x] Test plan is defined+- [x] Graduation criteria for dev preview, tech preview, GA+- [ ] User-facing documentation is created in [openshift-docs](https://github.com/openshift/openshift-docs/)++## Summary++Currently the ClusterVersion API has [a single `Update` type][api-update] used for both [the `desiredUpdate` input][api-desiredUpdate] and the [`desired`][api-desired] and [`availableUpdates`][api-availableUpdates] outputs.+But update requests like `desiredUpdate` have different schema requirements than output like `desired` and `availableUpdates`.+For example, [the `force` property][api-force] makes sense in the `desiredUpdate` context, but not in the `availableUpdates` contexts.+And release metadata like landing page URIs and available channels makes sense in the `desired` and `availableUpdates` contexts, but not in the `desiredUpdate` context.+This enhancement adds a new `Release` type to be used in `status` properties so we can distinguish between input and output schema.++## Motivation++Cincinnati provides [metadata about releases][cincinnati-metadata], including (since [here][cincinnati-channel-metadata]) the channels to which the release currently belongs.+Exposing that information to in-cluster consumers allows them to use live metadata, instead of talking to Cincinnati directly or hard-coding expected values.+For example, the console currently [hard-codes an expected set of available channels][console-channels] for a given release; with this enhancement they could look up available channels in `status.desired.metadata["io.openshift.upgrades.graph.release.channels"]`.++### Goals++* Exposing release metadata provided by upstream Cincinnati for the currently-desired and available-update releases.+* Documenting some well-known metadata keys.++### Non-Goals++* Restricting metadata keys to those documented in this enhancement.+    Cincinnati may continue to add and remove keys as they see fit as long as they provide at least the keys required by this enhancement.+* Teaching Cincinnati to support requests without `channel` query parameters.+    This might be useful for recovering from users specifying [`desiredUpdate`][api-desiredUpdate] that were not in their configured [`channel`][api-channel], but I am fine leaving recovery to the users.+    They should have received sufficient information to adjust their channel from wherever they received the target release they are supplying.++## Proposal++FIXME: In response to [Abhinav's comment](https://github.com/openshift/enhancements/pull/123#issuecomment-603370388), here are some alternative ways to do this.+Once we reach a consensus on [*a*](#a) or [*b*](#b), the alternative will move into [the *alternatives* section](#alternatives)++### A++As proposed in [this API pull request][api-pull-request], to add a new type:++```go+// Release represents an OpenShift release in the release graph.+// +k8s:deepcopy-gen=true+type Release struct {+  // version is a semantic versioning identifying the update version. When this+  // field is part of spec, version is optional if image is specified.+  Version string `json:"version"`++  // image is a container image location that contains the update. When this+  // field is part of spec, image is optional if version is specified and the+  // availableUpdates field contains a matching version.+  Image string `json:"image"`++  // metadata is additional metadata associated with the release, such+  // as associated channels (under+  // io.openshift.upgrades.graph.release.channels) or a landing page+  // (under url).+  //+  // +optional+  Metadata map[string]string `json:"metadata,omitempty"`+}+```++and to use that type instead of the current `Update` for `ClusterVersionStatus` properties.++Then, in the cluster-version operator (CVO), to port existing logic like [available-update translation][cluster-version-operator-update-translation] and [available-update lookup][cluster-version-operator-update-lookup] to preserve the Cincinnati metadata.+In some cases (when an administrator requested an update that was not in the available update set), this would require an additional Cincinnati request to retrieve metadata about the requested release.++### B++Similar to [*a*](#a), except instead of changing the `ClusterVersionStatus` fields, we'd deprecate them and make `Release` a stand-alone custom resource.+`Version` would become `ObjectMeta.Name`, and `Image` and `Metadata` would be `Status` properties.+Then we need some way to figure out which is the current release and which are the available updates, which is a bit racier now that we can no longer retrieve a single, atomic snapshot with a `GET ClusterVersion`.++### i++We'd also add some additional properties:++```go+// Source a the release version for which updates to this release can be launched.+// For example, source on a 4.1.1 release might be "4.1.0".+Source string `json:"source"`+```++In addition, the current release (being reconciled by the cluster-version operator) would have a `release.openshift.io/role` annotation with a `current` value.++### ii++We'd add new `ClusterVersionStatus` properties like:++```+// Current is the release version which is currently being reconciled by the cluster-version operator.+Current string `json:"current,omitempty"`++// AvailableUpdatesV2 holds release versions to which the current version may be updated.+AvailableUpdatesV2 []string `json:"availableUpdatesV2,omitempty`+```++### iii++Leave the current `ClusterVersionStatus` alone and just continue to fill the now-redundant `Update` properties (like `Image`) and use their `Version` properties instead of [*ii*](#ii)'s bare strings.++### Metadata properties++This enhancement declares the following to be well-known metadata properties:++* `url` (optional), a landing page for the release.+    For releases created by Red Hat, this will usually be the Errata for the release.+* `io.openshift.upgrades.graph.release.channels` (optional), the comma-delimited set of channels to which the release currently belongs.++Cincinnati implementation may, at their discretion, define, add, and remove additional properties as they see fit.++### User Stories++#### Dynamic Channel Selection++Alice's cluster is on release 4.1.23, and she wants to know if she can update to 4.2.+With interfaces like the console and `oc adm upgrade ...` exposing:++```console+$ curl -sH 'Accept:application/json' 'https://api.stage.openshift.com/api/upgrades_info/v1/graph?channel=stable-4.1&version=4.1.23' | jq -r '.nodes[] | select(.version == "4.1.23").metadata["io.openshift.upgrades.graph.release.channels"] | split(",")[]'+prerelease-4.1+stable-4.1+candidate-4.2+```++she could see that, while upgrading to 4.2 was possible, it was not yet considered stable.+And running the query again later, she could see that it had been added to `stable-4.2`.++### Implementation Details/Notes/Constraints

... i don't think we should change the .status.desired

We need to change .status.desired because that's where you get "what channels is my current release on?". I'll update the PR to make this more clear after lunch.

wking

comment created time in 8 hours

Pull request review commentopenshift/enhancements

enhancements/update/available-update-metadata: Propose a new enhancement

+---+title: available-update-metadata+authors:+  - "@wking"+reviewers:+  - "@abhinavdahiya"+  - "@crawford"+approvers:+  - TBD+creation-date: 2019-11-19+last-updated: 2020-04-22+status: implementable+---++# Available-update Metadata++## Release Signoff Checklist++- [x] Enhancement is `implementable`+- [x] Design details are appropriately documented from clear requirements+- [x] Test plan is defined+- [x] Graduation criteria for dev preview, tech preview, GA+- [ ] User-facing documentation is created in [openshift-docs](https://github.com/openshift/openshift-docs/)++## Summary++Currently the ClusterVersion API has [a single `Update` type][api-update] used for both [the `desiredUpdate` input][api-desiredUpdate] and the [`desired`][api-desired] and [`availableUpdates`][api-availableUpdates] outputs.+But update requests like `desiredUpdate` have different schema requirements than output like `desired` and `availableUpdates`.+For example, [the `force` property][api-force] makes sense in the `desiredUpdate` context, but not in the `availableUpdates` contexts.+And release metadata like landing page URIs and available channels makes sense in the `desired` and `availableUpdates` contexts, but not in the `desiredUpdate` context.+This enhancement adds a new `Release` type to be used in `status` properties so we can distinguish between input and output schema.++## Motivation++Cincinnati provides [metadata about releases][cincinnati-metadata], including (since [here][cincinnati-channel-metadata]) the channels to which the release currently belongs.+Exposing that information to in-cluster consumers allows them to use live metadata, instead of talking to Cincinnati directly or hard-coding expected values.+For example, the console currently [hard-codes an expected set of available channels][console-channels] for a given release; with this enhancement they could look up available channels in `status.desired.metadata["io.openshift.upgrades.graph.release.channels"]`.++### Goals++* Exposing release metadata provided by upstream Cincinnati for the currently-desired and available-update releases.+* Documenting some well-known metadata keys.++### Non-Goals++* Restricting metadata keys to those documented in this enhancement.+    Cincinnati may continue to add and remove keys as they see fit as long as they provide at least the keys required by this enhancement.+* Teaching Cincinnati to support requests without `channel` query parameters.+    This might be useful for recovering from users specifying [`desiredUpdate`][api-desiredUpdate] that were not in their configured [`channel`][api-channel], but I am fine leaving recovery to the users.+    They should have received sufficient information to adjust their channel from wherever they received the target release they are supplying.++## Proposal++FIXME: In response to [Abhinav's comment](https://github.com/openshift/enhancements/pull/123#issuecomment-603370388), here are some alternative ways to do this.+Once we reach a consensus on [*a*](#a) or [*b*](#b), the alternative will move into [the *alternatives* section](#alternatives)++### A++As proposed in [this API pull request][api-pull-request], to add a new type:++```go+// Release represents an OpenShift release in the release graph.+// +k8s:deepcopy-gen=true+type Release struct {+  // version is a semantic versioning identifying the update version. When this+  // field is part of spec, version is optional if image is specified.+  Version string `json:"version"`++  // image is a container image location that contains the update. When this+  // field is part of spec, image is optional if version is specified and the+  // availableUpdates field contains a matching version.+  Image string `json:"image"`++  // metadata is additional metadata associated with the release, such+  // as associated channels (under+  // io.openshift.upgrades.graph.release.channels) or a landing page+  // (under url).+  //+  // +optional+  Metadata map[string]string `json:"metadata,omitempty"`+}+```++and to use that type instead of the current `Update` for `ClusterVersionStatus` properties.++Then, in the cluster-version operator (CVO), to port existing logic like [available-update translation][cluster-version-operator-update-translation] and [available-update lookup][cluster-version-operator-update-lookup] to preserve the Cincinnati metadata.+In some cases (when an administrator requested an update that was not in the available update set), this would require an additional Cincinnati request to retrieve metadata about the requested release.++### B++Similar to [*a*](#a), except instead of changing the `ClusterVersionStatus` fields, we'd deprecate them and make `Release` a stand-alone custom resource.+`Version` would become `ObjectMeta.Name`, and `Image` and `Metadata` would be `Status` properties.+Then we need some way to figure out which is the current release and which are the available updates, which is a bit racier now that we can no longer retrieve a single, atomic snapshot with a `GET ClusterVersion`.++### i++We'd also add some additional properties:++```go+// Source a the release version for which updates to this release can be launched.+// For example, source on a 4.1.1 release might be "4.1.0".+Source string `json:"source"`+```++In addition, the current release (being reconciled by the cluster-version operator) would have a `release.openshift.io/role` annotation with a `current` value.++### ii++We'd add new `ClusterVersionStatus` properties like:++```+// Current is the release version which is currently being reconciled by the cluster-version operator.+Current string `json:"current,omitempty"`++// AvailableUpdatesV2 holds release versions to which the current version may be updated.+AvailableUpdatesV2 []string `json:"availableUpdatesV2,omitempty`+```++### iii++Leave the current `ClusterVersionStatus` alone and just continue to fill the now-redundant `Update` properties (like `Image`) and use their `Version` properties instead of [*ii*](#ii)'s bare strings.++### Metadata properties++This enhancement declares the following to be well-known metadata properties:++* `url` (optional), a landing page for the release.+    For releases created by Red Hat, this will usually be the Errata for the release.+* `io.openshift.upgrades.graph.release.channels` (optional), the comma-delimited set of channels to which the release currently belongs.++Cincinnati implementation may, at their discretion, define, add, and remove additional properties as they see fit.++### User Stories++#### Dynamic Channel Selection++Alice's cluster is on release 4.1.23, and she wants to know if she can update to 4.2.+With interfaces like the console and `oc adm upgrade ...` exposing:++```console+$ curl -sH 'Accept:application/json' 'https://api.stage.openshift.com/api/upgrades_info/v1/graph?channel=stable-4.1&version=4.1.23' | jq -r '.nodes[] | select(.version == "4.1.23").metadata["io.openshift.upgrades.graph.release.channels"] | split(",")[]'+prerelease-4.1+stable-4.1+candidate-4.2+```++she could see that, while upgrading to 4.2 was possible, it was not yet considered stable.+And running the query again later, she could see that it had been added to `stable-4.2`.++### Implementation Details/Notes/Constraints

can we include a section on how the content of metadata/additionalMetadata is sourced

Collapsing this thread into this other thread.

wking

comment created time in 8 hours

Pull request review commentopenshift/enhancements

enhancements/update/available-update-metadata: Propose a new enhancement

+---+title: available-update-metadata+authors:+  - "@wking"+reviewers:+  - "@abhinavdahiya"+  - "@crawford"+approvers:+  - TBD+creation-date: 2019-11-19+last-updated: 2020-04-22+status: implementable+---++# Available-update Metadata++## Release Signoff Checklist++- [x] Enhancement is `implementable`+- [x] Design details are appropriately documented from clear requirements+- [x] Test plan is defined+- [x] Graduation criteria for dev preview, tech preview, GA+- [ ] User-facing documentation is created in [openshift-docs](https://github.com/openshift/openshift-docs/)++## Summary++Currently the ClusterVersion API has [a single `Update` type][api-update] used for both [the `desiredUpdate` input][api-desiredUpdate] and the [`desired`][api-desired] and [`availableUpdates`][api-availableUpdates] outputs.+But update requests like `desiredUpdate` have different schema requirements than output like `desired` and `availableUpdates`.+For example, [the `force` property][api-force] makes sense in the `desiredUpdate` context, but not in the `availableUpdates` contexts.+And release metadata like landing page URIs and available channels makes sense in the `desired` and `availableUpdates` contexts, but not in the `desiredUpdate` context.+This enhancement adds a new `Release` type to be used in `status` properties so we can distinguish between input and output schema.++## Motivation++Cincinnati provides [metadata about releases][cincinnati-metadata], including (since [here][cincinnati-channel-metadata]) the channels to which the release currently belongs.+Exposing that information to in-cluster consumers allows them to use live metadata, instead of talking to Cincinnati directly or hard-coding expected values.+For example, the console currently [hard-codes an expected set of available channels][console-channels] for a given release; with this enhancement they could look up available channels in `status.desired.metadata["io.openshift.upgrades.graph.release.channels"]`.++### Goals++* Exposing release metadata provided by upstream Cincinnati for the currently-desired and available-update releases.+* Documenting some well-known metadata keys.++### Non-Goals++* Restricting metadata keys to those documented in this enhancement.+    Cincinnati may continue to add and remove keys as they see fit as long as they provide at least the keys required by this enhancement.+* Teaching Cincinnati to support requests without `channel` query parameters.+    This might be useful for recovering from users specifying [`desiredUpdate`][api-desiredUpdate] that were not in their configured [`channel`][api-channel], but I am fine leaving recovery to the users.+    They should have received sufficient information to adjust their channel from wherever they received the target release they are supplying.++## Proposal++FIXME: In response to [Abhinav's comment](https://github.com/openshift/enhancements/pull/123#issuecomment-603370388), here are some alternative ways to do this.+Once we reach a consensus on [*a*](#a) or [*b*](#b), the alternative will move into [the *alternatives* section](#alternatives)

i think the current approach of updating the current CV status to use Release for availableUpdates list seems like a acceptable near term solution

I've punted "separate objects" to the Alternatives section with ca79c67 -> 9e9e0f5.

we need to make explicit call-out/decision to drop fields like force because they have never been set or used by anybody.

Isn't that covered here? Is there any wording you'd like to see added/altered there?

wking

comment created time in 8 hours

push eventwking/openshift-enhancements

W. Trevor King

commit sha 9e9e0f511939f1e3b7c45e9dea2c60d569863481

enhancements/update/available-update-metadata: Propose a new enhancement With Abinav's separate-object approach as an alternative [1]. [1]: https://github.com/openshift/enhancements/pull/123#issuecomment-603370388

view details

push time in 8 hours

Pull request review commentopenshift/enhancements

enhancements/update/available-update-metadata: Propose a new enhancement

+---+title: available-update-metadata+authors:+  - "@wking"+reviewers:+  - "@abhinavdahiya"+  - "@crawford"+approvers:+  - TBD+creation-date: 2019-11-19+last-updated: 2019-11-19+status: implementable+---++# Available-update Metadata++## Release Signoff Checklist++- [x] Enhancement is `implementable`+- [x] Design details are appropriately documented from clear requirements+- [x] Test plan is defined+- [x] Graduation criteria for dev preview, tech preview, GA+- [ ] User-facing documentation is created in [openshift-docs](https://github.com/openshift/openshift-docs/)++## Summary++Currently the ClusterVersion API has [a single `Update` type][api-update] used for both [the `desiredUpdate` input][api-desiredUpdate] and the [`desired`][api-desired] and [`availableUpdates`][api-availableUpdates] outputs.+But update requests like `desiredUpdate` have different schema requirements than output like `desired` and `availableUpdates`.+For example, [the `force` property][api-force] makes sense in the `desiredUpdate` context, but not in the `availableUpdates` contexts.+And release metadata like landing page URIs and release metadata makes sense in the `desired` and `availableUpdates` contexts, but not in the `desiredUpdate` context.+This enhancement adds a new `Release` type to be used in `status` properties so we can distinguish between input and output schema.++## Motivation++Cincinnati provides [metadata about releases][cincinnati-metadata], including (since [here][cincinnati-channel-metadata]).+Exposing that information to ClusterVersion consumers allows them to use live metadata, instead of talking to Cincinnati directly or hard-coding expected values.+For example, the console currently [hard-codes an expected set of available channels][console-channels] for a given release; with this enhancement they could look up available channels in `status.desired.metadata["io.openshift.upgrades.graph.release.channels"]`.++### Goals++* Exposing release metadata provided by upstream Cincinnati for the currently-desired and available-update releases.+* Documenting some well-known metadata keys.++### Non-Goals++* Restricting metadata keys to those documented in this enhancement.+    Cincinnati may continue to add and remove keys as they see fit as long as they provide at least the keys required by this enhancement.+* Teaching Cincinnati to support requests without `channel` query parameters.+    This might be useful for recovering from users specifying [`desiredUpdate`][api-desiredUpdate] that were not in their configured [`channel`][api-channel], but I am fine leaving recovery to the users.+    They should have received sufficient information to adjust their channel from wherever they received the target release they are supplying.++## Proposal++As proposed in [this API pull request][api-pull-request], to add a new type:+++```go+// Release represents an OpenShift release in the release graph.+// +k8s:deepcopy-gen=true+type Release struct {+  // version is a semantic versioning identifying the update version. When this+  // field is part of spec, version is optional if image is specified.+  Version string `json:"version"`++  // image is a container image location that contains the update. When this+  // field is part of spec, image is optional if version is specified and the+  // availableUpdates field contains a matching version.+  Image string `json:"image"`++  // metadata is additional metadata associated with the release, such+  // as associated channels (under+  // io.openshift.upgrades.graph.release.channels) or a landing page+  // (under url).+  //+  // +optional+  Metadata map[string]string `json:"metadata,omitempty"`

Maybe name it AdditionalMetadata ?

Having AdditionalMetadata without a Metadata seemed awkward to me, so 182442f -> ca79c67 adds both, and discusses the security trade-offs between them. That's getting into very serious ground, so I'd appreciate extra review of the new godoc comments.

wking

comment created time in 8 hours

push eventwking/openshift-enhancements

W. Trevor King

commit sha ca79c675bee2b574a8ececdc76d00f8de5532488

WIP: enhancements/update/available-update-metadata: Propose a new enhancement Rerolled to add Abinav's separate-object approach as an alternative [1]. [1]: https://github.com/openshift/enhancements/pull/123#issuecomment-603370388

view details

push time in 8 hours

push eventwking/openshift-enhancements

David Eads

commit sha d68a053f3288fc0768e2524e39e3ae78f027b293

config ClusterResourceOverrides as mutating admission webhook via OLM

view details

Lars Haugan

commit sha 6c7e6c38457eb38fd4e5c7971bc52207eabde2ff

Add proposal for Route Admission Policy A proposal for a new policy implementation to enable inter namespace route claims. Customers on OpenShift 3 using `ROUTER_DISABLE_NAMESPACE_OWNERSHIP_CHECK` are blocked from upgrading to OpenShift 4 without this RFE or disabling the default router.

view details

Dan Mace

commit sha 88bb6a3f417903f5c5dd75e212f12933694b0aff

WIP: IngressController NodePort publishing strategy Introduce a NodePort publishing strategy for IngressControllers.

view details

Maru Newby

commit sha 08a10c512c07dbced28eff47afdc551533c65337

Update service ca rotation risks with testing strategy

view details

John Hixson

commit sha 2caf11b65d6ed4242955fa8244355a98e9b3102c

Azure: customer provisioned virtual network & subnets enhancement doc https://jira.coreos.com/browse/CORS-1266

view details

John Hixson

commit sha ed93fc5f030813c2fda89ada6c9228de70b36ba4

Azure: Internal/Private clusters enhancement doc https://jira.coreos.com/browse/CORS-1269

view details

OpenShift Merge Robot

commit sha b0e06416959c31939d735739759d1f11de4c0a0f

Merge pull request #121 from jhixson74/master_azure_bring_your_own_vnet Azure: Customer provisioned virtual network & subnets enhancement doc

view details

OpenShift Merge Robot

commit sha 92341df6951382003014667e0d8b807172233f4c

Merge pull request #122 from jhixson74/master_azure_internal_private_clusters Azure: Internal/Private clusters enhancement doc

view details

Colin Walters

commit sha e5ae1c3b830b0ccc959523188af7d36f9a7a974f

Fix typo in "disk encryption" enhancement This kept bugging me.

view details

OpenShift Merge Robot

commit sha 59f181e5edff10fefa513f9e47f61eef27dc10d3

Merge pull request #125 from cgwalters/fix-typo Fix typo in "disk encryption" enhancement

view details

Dan Mace

commit sha 0f0d93ba06b4f5385f4322879e82a0a13b5735cd

Add more enhancement details

view details

Dan Mace

commit sha 1e40a1b6443e981ae57203c15831daff4b009aa9

Clarify use case and address change of defaults

view details

Dan Mace

commit sha a543e5dd620cb27d98371c5ca257bd1a8cd0ce50

Don't propose a change of default strategy

view details

Clayton Coleman

commit sha aece257a9e1b3d51967aaaeea5391fac9b4247dd

Minor whitespace improvements

view details

Dr. Stefan Schimanski

commit sha a87484a414f506dbc69158d9982b35050dac2d13

etcd-encryption: update secret names to match implementation

view details

Dr. Stefan Schimanski

commit sha c463b69ad4f01c67e99af307bd59f823ccdec318

etcd-encryption: one read key is always kept

view details

Colin Walters

commit sha 5801094784797f603c4eefc6effe812256bcbf19

diskencryption: s/CoreOS/RHCOS/ as appropriate Let's clarify this is RHCOS only - something even more important to do now that OKD exists which uses FCOS, which doesn't do any of this.

view details

Colin Walters

commit sha d316b20ce6544c19cac13587828269f3d430a753

diskencryption: Clarify even more strongly it's just the rootfs Since it's important.

view details

Colin Walters

commit sha 1e178db1285d85ba87e74b15ce6ca677ce7428af

diskencryption: Upgrades can't be encrypted The Upgrades section was kind of hopeful here; we don't have a real end-to-end story for the bootimage updates doing so would require, so remove the text and link to the bootimage issue instead.

view details

Colin Walters

commit sha 30fa771f6ac1ec22ce41c7f8dcf434c7993d686e

diskencryption: Typo fix and clarification for implementation Add the name of the unit to help people here in the future.

view details

push time in 9 hours

Pull request review commentopenshift/enhancements

enhancements/update/available-update-metadata: Propose a new enhancement

+---+title: available-update-metadata+authors:+  - "@wking"+reviewers:+  - "@abhinavdahiya"+  - "@crawford"+approvers:+  - TBD+creation-date: 2019-11-19+last-updated: 2019-11-19+status: implementable+---++# Available-update Metadata++## Release Signoff Checklist++- [x] Enhancement is `implementable`+- [x] Design details are appropriately documented from clear requirements+- [x] Test plan is defined+- [x] Graduation criteria for dev preview, tech preview, GA+- [ ] User-facing documentation is created in [openshift-docs](https://github.com/openshift/openshift-docs/)++## Summary++Currently the ClusterVersion API has [a single `Update` type][api-update] used for both [the `desiredUpdate` input][api-desiredUpdate] and the [`desired`][api-desired] and [`availableUpdates`][api-availableUpdates] outputs.+But update requests like `desiredUpdate` have different schema requirements than output like `desired` and `availableUpdates`.+For example, [the `force` property][api-force] makes sense in the `desiredUpdate` context, but not in the `availableUpdates` contexts.+And release metadata like landing page URIs and release metadata makes sense in the `desired` and `availableUpdates` contexts, but not in the `desiredUpdate` context.+This enhancement adds a new `Release` type to be used in `status` properties so we can distinguish between input and output schema.++## Motivation++Cincinnati provides [metadata about releases][cincinnati-metadata], including (since [here][cincinnati-channel-metadata]).+Exposing that information to ClusterVersion consumers allows them to use live metadata, instead of talking to Cincinnati directly or hard-coding expected values.+For example, the console currently [hard-codes an expected set of available channels][console-channels] for a given release; with this enhancement they could look up available channels in `status.desired.metadata["io.openshift.upgrades.graph.release.channels"]`.++### Goals++* Exposing release metadata provided by upstream Cincinnati for the currently-desired and available-update releases.+* Documenting some well-known metadata keys.++### Non-Goals++* Restricting metadata keys to those documented in this enhancement.+    Cincinnati may continue to add and remove keys as they see fit as long as they provide at least the keys required by this enhancement.+* Teaching Cincinnati to support requests without `channel` query parameters.+    This might be useful for recovering from users specifying [`desiredUpdate`][api-desiredUpdate] that were not in their configured [`channel`][api-channel], but I am fine leaving recovery to the users.+    They should have received sufficient information to adjust their channel from wherever they received the target release they are supplying.++## Proposal++As proposed in [this API pull request][api-pull-request], to add a new type:+++```go+// Release represents an OpenShift release in the release graph.+// +k8s:deepcopy-gen=true+type Release struct {+  // version is a semantic versioning identifying the update version. When this+  // field is part of spec, version is optional if image is specified.+  Version string `json:"version"`++  // image is a container image location that contains the update. When this+  // field is part of spec, image is optional if version is specified and the+  // availableUpdates field contains a matching version.+  Image string `json:"image"`++  // metadata is additional metadata associated with the release, such+  // as associated channels (under+  // io.openshift.upgrades.graph.release.channels) or a landing page+  // (under url).+  //+  // +optional+  Metadata map[string]string `json:"metadata,omitempty"`

Currently we are transparently passing on the label keys from cincinatti responses...

I think that's ok, but can we move that aspect of the discussion over into this thread?

wking

comment created time in 9 hours

Pull request review commentopenshift/enhancements

enhancements/update/available-update-metadata: Propose a new enhancement

+---+title: available-update-metadata+authors:+  - "@wking"+reviewers:+  - "@abhinavdahiya"+  - "@crawford"+approvers:+  - TBD+creation-date: 2019-11-19+last-updated: 2020-04-22+status: implementable+---++# Available-update Metadata++## Release Signoff Checklist++- [x] Enhancement is `implementable`+- [x] Design details are appropriately documented from clear requirements+- [x] Test plan is defined+- [x] Graduation criteria for dev preview, tech preview, GA+- [ ] User-facing documentation is created in [openshift-docs](https://github.com/openshift/openshift-docs/)++## Summary++Currently the ClusterVersion API has [a single `Update` type][api-update] used for both [the `desiredUpdate` input][api-desiredUpdate] and the [`desired`][api-desired] and [`availableUpdates`][api-availableUpdates] outputs.+But update requests like `desiredUpdate` have different schema requirements than output like `desired` and `availableUpdates`.+For example, [the `force` property][api-force] makes sense in the `desiredUpdate` context, but not in the `availableUpdates` contexts.+And release metadata like landing page URIs and available channels makes sense in the `desired` and `availableUpdates` contexts, but not in the `desiredUpdate` context.+This enhancement adds a new `Release` type to be used in `status` properties so we can distinguish between input and output schema.++## Motivation++Cincinnati provides [metadata about releases][cincinnati-metadata], including (since [here][cincinnati-channel-metadata]) the channels to which the release currently belongs.+Exposing that information to in-cluster consumers allows them to use live metadata, instead of talking to Cincinnati directly or hard-coding expected values.+For example, the console currently [hard-codes an expected set of available channels][console-channels] for a given release; with this enhancement they could look up available channels in `status.desired.metadata["io.openshift.upgrades.graph.release.channels"]`.++### Goals++* Exposing release metadata provided by upstream Cincinnati for the currently-desired and available-update releases.+* Documenting some well-known metadata keys.++### Non-Goals++* Restricting metadata keys to those documented in this enhancement.+    Cincinnati may continue to add and remove keys as they see fit as long as they provide at least the keys required by this enhancement.+* Teaching Cincinnati to support requests without `channel` query parameters.+    This might be useful for recovering from users specifying [`desiredUpdate`][api-desiredUpdate] that were not in their configured [`channel`][api-channel], but I am fine leaving recovery to the users.+    They should have received sufficient information to adjust their channel from wherever they received the target release they are supplying.++## Proposal++FIXME: In response to [Abhinav's comment](https://github.com/openshift/enhancements/pull/123#issuecomment-603370388), here are some alternative ways to do this.+Once we reach a consensus on [*a*](#a) or [*b*](#b), the alternative will move into [the *alternatives* section](#alternatives)++### A++As proposed in [this API pull request][api-pull-request], to add a new type:++```go+// Release represents an OpenShift release in the release graph.+// +k8s:deepcopy-gen=true+type Release struct {+  // version is a semantic versioning identifying the update version. When this+  // field is part of spec, version is optional if image is specified.+  Version string `json:"version"`++  // image is a container image location that contains the update. When this+  // field is part of spec, image is optional if version is specified and the+  // availableUpdates field contains a matching version.+  Image string `json:"image"`++  // metadata is additional metadata associated with the release, such+  // as associated channels (under+  // io.openshift.upgrades.graph.release.channels) or a landing page+  // (under url).+  //+  // +optional+  Metadata map[string]string `json:"metadata,omitempty"`+}+```++and to use that type instead of the current `Update` for `ClusterVersionStatus` properties.++Then, in the cluster-version operator (CVO), to port existing logic like [available-update translation][cluster-version-operator-update-translation] and [available-update lookup][cluster-version-operator-update-lookup] to preserve the Cincinnati metadata.+In some cases (when an administrator requested an update that was not in the available update set), this would require an additional Cincinnati request to retrieve metadata about the requested release.++### B++Similar to [*a*](#a), except instead of changing the `ClusterVersionStatus` fields, we'd deprecate them and make `Release` a stand-alone custom resource.+`Version` would become `ObjectMeta.Name`, and `Image` and `Metadata` would be `Status` properties.+Then we need some way to figure out which is the current release and which are the available updates, which is a bit racier now that we can no longer retrieve a single, atomic snapshot with a `GET ClusterVersion`.++### i++We'd also add some additional properties:++```go+// Source a the release version for which updates to this release can be launched.+// For example, source on a 4.1.1 release might be "4.1.0".+Source string `json:"source"`+```++In addition, the current release (being reconciled by the cluster-version operator) would have a `release.openshift.io/role` annotation with a `current` value.++### ii++We'd add new `ClusterVersionStatus` properties like:++```+// Current is the release version which is currently being reconciled by the cluster-version operator.+Current string `json:"current,omitempty"`++// AvailableUpdatesV2 holds release versions to which the current version may be updated.+AvailableUpdatesV2 []string `json:"availableUpdatesV2,omitempty`+```++### iii++Leave the current `ClusterVersionStatus` alone and just continue to fill the now-redundant `Update` properties (like `Image`) and use their `Version` properties instead of [*ii*](#ii)'s bare strings.++### Metadata properties++This enhancement declares the following to be well-known metadata properties:

I've pushed wording about tying this to apiVersion with 182442f -> 8d8a080. How does that look to you?

wking

comment created time in 9 hours

push eventwking/openshift-enhancements

W. Trevor King

commit sha 8d8a080fe8dc9c0be08d3c62aee0537784d66d0b

enhancements/update/available-update-metadata: Propose a new enhancement

view details

push time in 9 hours

pull request commentopenshift/cluster-version-operator

Bug 1844117: pkg/cvo/sync_worker: Do not treat "All errors were context errors..." as success

/lgtm

Still need to wait on QE verifying the 4.4 backport.

openshift-cherrypick-robot

comment created time in 10 hours

pull request commentopenshift/enhancements

enhancements/update/automatic-updates: Propose a new enhancement

If I am 3 releases behind in z-stream latest and enable automatic upgrades. What is the expectation? I am upgraded to latest via the shortest path?

Yup. And the CVO has had autoupdate logic to select the latest SemVer from available updates since 2018. This PR is just asking for a knob to enable that code. And if there were any stability issues with the longest recommended hop, the upstream service would remove that recommendation.

+1 for calendar configuration

I'm not against that in general, but I am against it in this PR. Ifyou feel that it's impossible to punt without getting painted into a corner, please explain why in an existing thread.

I also see a need for Y vs Z stream policy. I might be ok with z-stream auto upgrades, but not Y.

If you are running 4.6 and want to stay there, subscribe to channel stable-4.6. If you are open to moving to 4.7, subscribe to stable-4.7. So channels provide the control you seek there today, and are orthogonal to this auto-update proposal.

wking

comment created time in 13 hours

pull request commentopenshift/cluster-version-operator

Bug 1843732: pkg/cvo/sync_worker: Do not treat "All errors were context errors..." as success

/bugzilla refresh /assign @LalatenduMohanty

wking

comment created time in 13 hours

Pull request review commentopenshift/openshift-docs

[WIP] Adding documentation for updating a disconnected cluster

 [id="updating-disconnected-cluster"]-= Updating a disconnected cluster to a minor version+= Updating a disconnected cluster include::modules/common-attributes.adoc[] :context: updating-disconnected-cluster  toc::[] -You can update, or upgrade, an {product-title} cluster that you installed in a-restricted network to a minor version by using the web console.+You can update, or upgrade a disconnected or fully air gapped {product-title} cluster using `oc` commandline.  .Prerequisites +* Have access to a conatiner registry in the disconnected environment to push and pull images. The container registry should be compatible with Docker registry API v2. * Have access to the cluster as a user with `admin` privileges. See xref:../authentication/using-rbac.adoc[Using RBAC to define and apply permissions]. * Have a recent xref:../backup_and_restore/backing-up-etcd.adoc#backup-etcd[etcd backup] in case your upgrade fails and you must xref:../backup_and_restore/disaster_recovery/scenario-2-restoring-cluster-state.adoc#dr-restoring-cluster-state[restore your cluster to a previous state]. -//mirror module+[IMPORTANT]+====+If you are upgrading from earlier release than 4.5.0, you must must use the manual method of creating configmap. -include::modules/update-service-overview.adoc[leveloffset=+1]+This is because `oc` command enhancement is not available in previous releases.+==== -include::modules/understanding-upgrade-channels.adoc[leveloffset=+1]+[id="update-airgapped-env"]+== Updating an air gapped {product-title} cluster++An air gapped environment is the one in which your cluster nodes cannot access the internet. For this reason you must mirror the images to a filesystem disconnected from that environment and then bring that host or removable media across that gap. It may also be the case that there are multiple clusters within the air gapped network. In such a case it makes sense to configure a central registry in the air gapped environment from which every cluster can pull required images for upgrade.++.Procedure++. Findout if there is link:https://access.redhat.com/solutions/4583231[an update path] exists between your current version and the version you want the cluster to move.++. Mirror the version images to the internal container registry.++** Connect the removable media to a system connected to the internet.+** Mirror the images and configuration manifests to a directory on the removable media.+++----+$ oc adm release mirror "--to-dir=${REMOVABLE_MEDIA_PATH}/mirror" quay.io/openshift-release-dev/ocp-release:4.3.0-x86_64+----++++** Take the media to the disconnected environment and upload the images to the local container registry+++----+$ oc image mirror "--from-dir=${REMOVABLE_MEDIA_PATH}/mirror" file://openshift/release:4.3.0* REGISTRY/REPOSITORY

I would still rather punt on target discovery, and have this PR scoped to the mechanics of post-discovery application.

LalatenduMohanty

comment created time in a day

PR opened openshift/cluster-version-operator

Bug 1843732 pkg/cvo/sync_worker: Do not treat "All errors were context errors..." as success

Cherry-picked from #378 and edited to resolve context conflicts because release-4.4 lacks #318.

+18 -25

0 comment

1 changed file

pr created time in a day

create barnchwking/cluster-version-operator

branch : precise-context-error

created branch time in a day

push eventwking/cluster-version-operator

Eric Paris

commit sha 7ee93ce833fa6105d72c96e20eda4c389617b37a

Do not build with CGO_ENABLED=0 Back in ddeb1408 this made sense, since we were based on SCRATCH. But now we use origin:base and should not try to be fancy. Statically linking the binary and basing on SCRATCH allows us to minimize the layer size. If we're using a full base image, it no longer makes sense to statically link, since we have the libraries we need in the image. Also, when using the RHEL golang compiler fork, instead of upstream, building wth CGO_ENABLED=0 disables the ability to use nss and to get FIPS compliance. This will cause the CVO image to follow the same pattern as everything else.

view details

W. Trevor King

commit sha 19c4b148e469d06022262a925e70d2dbf0df2c05

pkg/cvo/sync_worker: Generalize CancelError to ContextError With this commit, I drop contextIsCancelled in favor of Context.Err(). From the docs [1]: If Done is not yet closed, Err returns nil. If Done is closed, Err returns a non-nil error explaining why: Canceled if the context was canceled or DeadlineExceeded if the context's deadline passed. After Err returns a non-nil error, successive calls to Err return the same error. I dunno why we'd been checking Done() instead, but contextIsCancelled dates back to 961873d66a (sync: Do config syncing in the background, 2019-01-11, #82). I've also generalized a number of *Cancel* helpers to be *Context* to remind folks that Context.Err() can be DeadlineExceeded as well as Canceled, and the CVO uses both WithCancel and WithTimeout. The new error messages will be either: update context deadline exceeded at 1 of 2 or: update context canceled at 1 of 2 Instead of always claiming: update was cancelled at 1 of 2 [1]: https://golang.org/pkg/context/#Context

view details

W. Trevor King

commit sha 64af81992572d70b129e374d7612683eddf87559

pkg/cvo/sync_worker: Promote "Sync succeeded" to v4 To match the existing v4 logs for: Running sync %s (force=%t) on generation %d in state %s at attempt %d To avoid excessive noise, also restrict it to edge transitions between states (the "Running sync ..." line exposes the level) and include the source state in the logged message. Because the * -> Reconciling transition is important, and deserves at least as much weight in the logs as "we're about to start a new sync cycle" and a log entry that comes before the next Until sleep.

view details

W. Trevor King

commit sha 21316129edee9b1ab1b5ecd00978ff0e62977dd6

pkg/cvo/sync_worker: Flatten a nested 'if changed' One less level of nesting makes for slightly easier reading. The nested 'if changed' landed when sync_worker.go was born in 961873d66a (sync: Do config syncing in the background, 2019-01-11, #82).

view details

W. Trevor King

commit sha 6a03bbc2c822d35a481f07ccb347ae553711e847

pkg/cvo/sync_worker: Drop unused 'reconciling' from SyncWorker The property landed with SyncWorker in 961873d66a (sync: Do config syncing in the background, 2019-01-11, #82), but has never been used.

view details

W. Trevor King

commit sha 1033fa4927fa050bc871c1d99fc3946aa168c3a5

pkg/cvo/sync_worker: Do not treat "All errors were context errors..." as success For [1]. Before this commit, you could have a flow like: 1. SyncWorker.Start() 2. External code calls Update(), e.g. after noticing a ClusterVersion spec.desiredUpdate change. 3. Update sets w.work to point at the desired payload. 4. Start's Until loop is triggered via w.notify. 5. Start calls calculateNext, which notices the change and sets the state to UpdatingPayload. 6. Start calculates a syncTimeout and calls syncOnce. 7. syncOnce notices the new payload and loads it. 8. For whatever reason, payload retrieval takes a while. Blackholed signature-fetch attempts in a restricted network [2] are one example of something that could be slow here. Eventually the syncTimeout kicks in and signature fetching or other verification is canceled (which counts as failed verification). 9. Force is true, so syncOnce logs "Forcing past precondition failures..." but carries on to call apply. 10. apply computes the manifest graph, runs the ClusterOperator precreation (whose handlers return ContextError() right after spawning, because the context is already expired), and runs the main RunGraph (whose handlers do the same). 11. The main RunGraph returns at a slice with a handful of context errors and nothing else. apply passes this on to consistentReporter.Errors. 12. consistentReporter.Errors calls summarizeTaskGraphErrors, which logs "All errors were context errors..." and returns nil to avoid alarming consistentReporter.Errors (we don't want to put this in our ClusterVersion status and alarm users). 13. apply returns the summarized nil to syncOnce. 14. syncOnce returns the summarized nil to Start. 15. Start logs "Sync succeeded..." and flops into ReconcilingPayload for the next round. 16. Start comes into the next round in reconciling mode despite never having attempted to apply any manifests in its Updating mode. The manifest graph gets flattened and shuffled and all kinds of terrible things could happen like the machine-config trying to roll out the newer machine-os-content and its 4.4 hyperkube binary before rolling out prerequisites like the 4.4 kube-apiserver operator. With this commit, the process is the same through 12, but ends with: 13. apply returns the first context error to syncOnce. 14. syncOnce returns that error to Start. 15. Start backs off and comes in again with a second attempt at UpdatingPayload. 16. Manifests get pushed in the intended order, and nothing explodes. The race fixed in this commit could also have come up without timing out the payload pull/verification, e.g. by having a perfectly slow ClusterOperator preconditions. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1838497#c23 [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1840343

view details

W. Trevor King

commit sha 3812e5f99114fc58758e51ce25bc774f1c281762

pkg/cvo/availableupdates: Split 'At' into LastAttempt and LastSyncOrConfigChange The previous At had been tracking the most recent attempt, regardless of success. With this commit, we rename it to the more explicit LastAttempt and add godocs explaining the intended semantics. Also grow a LastSyncOrConfigChange sibling, tracking the time since the last success (or since the configured upstream had been changed). This will make it more convenient to alert when the slice of available updates is stale, although that alert itself and the metric that feeds it will come from follow-up work [1]. Setting u.LastSyncOrConfigChange from optr.availableUpdates in the else branch preserves any existing timestamp if the new status did not trigger a reset. [1]: https://github.com/openshift/cluster-version-operator/pull/357

view details

W. Trevor King

commit sha 30bdaa8d276ed23940c13ac1dcde4ab04602be44

pkg/payload/task_graph: "on" -> "on worker" logging The old format is from cb4e0375e6 (payload: Create a task graph that can split a payload into chunks, 2019-01-17, #88), but Abhinav points out that "on %d" could use a bit more context [1]. [1]: https://github.com/openshift/cluster-version-operator/pull/264#discussion_r433554377

view details

OpenShift Merge Robot

commit sha 30412ff2320534a94886ab839e8dc0bb964b5c84

Merge pull request #377 from wking/running-on-worker-log pkg/payload/task_graph: "on" -> "on worker" logging

view details

OpenShift Merge Robot

commit sha e43c031a0060926c46106d7b8fbb2ffbd1ca38c7

Merge pull request #373 from wking/v4-sync-succeeded-log pkg/cvo/sync_worker: Promote "Sync succeeded" to v4

view details

OpenShift Merge Robot

commit sha d2cc0d08f7d0d6f5de5829299aa5d7dd2a34de34

Merge pull request #374 from wking/flatten-if-changed pkg/cvo/sync_worker: Flatten a nested 'if changed'

view details

OpenShift Merge Robot

commit sha ee6d11dacb3ab3058bef4313d498286ae6263e33

Merge pull request #368 from wking/available-updates-sync-shuffle pkg/cvo/availableupdates: Split 'At' into LastAttempt and LastSyncOrConfigChange

view details

OpenShift Merge Robot

commit sha 44b4f788cd8895fa5ef42b30927335c377b4ee89

Merge pull request #375 from wking/drop-unused-reconciling pkg/cvo/sync_worker: Drop unused 'reconciling' from SyncWorker

view details

OpenShift Merge Robot

commit sha 26de2a1acfde1c16da65d5260df658cbc689d75f

Merge pull request #372 from wking/precise-context-error Bug 1838497: pkg/cvo/sync_worker: Do not treat "All errors were context errors..." as success

view details

OpenShift Merge Robot

commit sha cb8241a33846546ab63ec8c01112f633b6980182

Merge pull request #359 from eparis/remove-cgo-0 Do not build with CGO_ENABLED=0

view details

push time in a day

delete branch wking/sippy

delete branch : suggest-job-link

delete time in a day

pull request commentopenshift/cincinnati-graph-data

Enable 4.3.23 in fast channel(s)

/retest

openshift-bot

comment created time in a day

pull request commentopenshift/cincinnati-graph-data

Enable 4.2.34 in fast channel(s)

/hold

I dunno if this has had success-review yet.

openshift-bot

comment created time in a day

push eventwking/sippy

W. Trevor King

commit sha 4e55b2eeb7d83522749885dfed59dc0df412946b

pkg/html: Fix OA -> 0A typos for percent-escaped newlines

view details

push time in a day

pull request commentbparees/sippy

pkg/html: Add job-link FIXME to "Open a bug" template

Replaced with openshift/sippy#11

wking

comment created time in a day

push eventwking/sippy

Ben Parees

commit sha e528466b9c98dff91e476bc90ca9f2b2fac2742a

aesthetic cleanup and 2 hour refresh interval

view details

Ben Parees

commit sha 368925fb286c6d6d268eed3f7aef7f8492f0e8a8

add hover text for arrows

view details

Ben Parees

commit sha 01cd2881b2dd9010bb68261c55bcaddafc8c463c

add expandable list of failing tests for each platform also beginnings of a parameterizable "detailed analysis" view page.

view details

Ben Parees

commit sha 1a0ba341a49316c2adc98fce51a23fd984834168

Merge pull request #4 from bparees/detailed add expandable list of failing tests for each platform

view details

Ben Parees

commit sha dada5cf8518afba8446fa7153a9d56ed09728789

switch to more efficient dockerfile flow

view details

Ben Parees

commit sha 6603a82230f06ea9eb4d624804c4bba626338df7

add expandable test blocks for job + platform groupings

view details

Ben Parees

commit sha 0d91b7e5d26b854a2d30b166e3da816405503843

add a parameterizable report mode

view details

Ben Parees

commit sha 9530618b1e39f02747b8a6dc5a96b09132e60107

rename parameter names for clarity

view details

Ben Parees

commit sha e2d1ef1669377f01052b540e2d32ac2997d87ec7

make detailed report use adjacent day ranges for current and previous

view details

Ben Parees

commit sha 24e4405198655bd7f045b5040013f9f2b85c7913

allow parameterizing the number of tests to show per job/jobgrouping

view details

Ben Parees

commit sha b0ffbdc200756f42af9668d3667413346509dbbb

show count of additional test failure matches and default to 15 failing tests on the main view

view details

Ben Parees

commit sha e598bfb21fb3714c5eb2720aa78dbf136c1f8fa3

open all links in a new tab

view details

Ben Parees

commit sha 028fbcc0b69fa62f671181d1b77f99d0ccb14931

clean up handling of platforms with no previous runs

view details

Ben Parees

commit sha 85c6f32ef8eb3dee74d15eebd8e5b104eadf563a

better formatting when a particular platform was NA for the previous week

view details

Ben Parees

commit sha a49c293f7397eeb2bea8d1eafbeadea1f581c484

add "upgrade" as platform type/grouping

view details

Ben Parees

commit sha 3a6865ac31975996ddb8689f2674ffeb232e34b1

add 4.4GA historical data

view details

Ben Parees

commit sha 251c8552668d829680c24fde0aa6c00a9092340a

add 4.6 to dashboard view

view details

Ben Parees

commit sha 6795065b0e604127cf3693476689cb9e128a9953

improve the readme

view details

Ben Parees

commit sha 46bf277bb9bc1ca027e8a7878f13227061803681

rename packages to openshift

view details

Ben Parees

commit sha 83f0e8559711481edf4416087bd704f073c1142a

Merge pull request #6 from bparees/rename rename packages to openshift

view details

push time in a day

pull request commentbparees/sippy

pkg/html: Add job-link FIXME to "Open a bug" template

Oops, wrong repo.

wking

comment created time in a day

PR opened bparees/sippy

pkg/html: Add job-link FIXME to "Open a bug" template
+2 -1

0 comment

1 changed file

pr created time in a day

create barnchwking/sippy

branch : suggest-job-link

created branch time in a day

pull request commentopenshift/cincinnati-graph-data

Enable 4.4.7 in candidate channel(s)

/hold

openshift-bot

comment created time in a day

pull request commentopenshift/cluster-version-operator

Bug 1843526: pkg/cvo/sync_worker: Do not treat "All errors were context errors..." as success

e2e-aws:

failed to acquire lease: resources not found

But I want this landed, so try to elbow our way back into the queue instead of waiting on the retest bot:

/test e2e-aws

openshift-cherrypick-robot

comment created time in a day

pull request commentopenshift/release

4.5 branches: accept upstream MODIFIED, ON_QA, VERIFIED

/lgtm

sdodson

comment created time in 2 days

pull request commentopenshift/cluster-version-operator

Bug 1843526: pkg/cvo/sync_worker: Do not treat "All errors were context errors..." as success

@sdodson , can you drop group-lead approval and twiddle Bugzilla? Once I get on Slack, I'll round with the test folks about 4.5 only needing MODIFIED 4.6 bugs until ART fixes the issues with building 4.6 nightlies.

openshift-cherrypick-robot

comment created time in 2 days

delete branch wking/oc

delete branch : parallel-options

delete time in 2 days

delete branch wking/openshift-installer

delete branch : drop-unused-wait-dir

delete time in 2 days

delete branch wking/cluster-version-operator

delete branch : precise-context-error

delete time in 2 days

pull request commentopenshift/origin

WIP: Bug 1843183: test/e2e/upgrade: Split update testing into per-hop cases

/bugzilla refresh

wking

comment created time in 2 days

PR opened openshift/origin

WIP: Bug 1843183: test/e2e/upgrade: Split update testing into per-hop cases

"Cluster should remain functional during upgrade" is a big bucket, and it's hard to figure out what's going on when it fails based on just the test-case. This commit pulls the setup steps out into their own case (which is unlikely to fail, but still). And it puts each hop in its own case, including the source and target version.

FIXME: break out major/minor so we can aggregate in Sippy, etc.

+31 -24

0 comment

1 changed file

pr created time in 2 days

create barnchwking/origin

branch : per-hop-update-cases

created branch time in 2 days

push eventwking/origin

Ben Parees

commit sha 84965bd24787919bec62cab984c2969fee6fd113

clarify test failure message

view details

Cesar Wong

commit sha 97f3c2f0df58cc84772785a56ccad30e4af6c6ba

Introduce IBMCloud provider, skip/fix tests

view details

Hemant Kumar

commit sha 61a14d76dcc6578a409385730742d967fd4fe606

UPSTREAM: 90147: relax zone requirement from e2e

view details

Daneyon Hansen

commit sha 38a8ef399d62fed64048d5652e9ccf82aec491ae

Enables secure metrics tests for dns

view details

gabemontero

commit sha 1f696ee62b1981daec6e5d91fb2dfc71256044a3

unskip template extended tests

view details

Miciah Masters

commit sha fbf912a454274a9055cf05ca8ad1a55ff69e4b96

test/extended/router: Disable HTTP/2 tests Disable router tests that test or rely on HTTP/2 on the frontend. We are disabling HTTP/2 on the frontend to prevent issues with connection coalescing that break the OAuth flow. This commit is required to fix bug 1825354. https://bugzilla.redhat.com/show_bug.cgi?id=1825354 * test/extended/router/grpc-interop.go: * test/extended/router/h2spec.go: Skip the tests.

view details

OpenShift Merge Robot

commit sha 980671dade33af9e71c73a38be404897dad373b0

Merge pull request #24900 from gnufied/relax-zone-requirement-e2e Bug 1823494: Storage tests should more carefully select zones for testing

view details

Francesco Romani

commit sha 16959dbbc9e1303eb500fb872bea7062e4394e31

e2e: add extended tests for topology manager The tests will skip if topology manager is not enabled on the cluster, with single-numa node policy. If it is enabled, will check the pod resources are usable and properly aligned on NUMA node. This is a superset of the e2e tests found on kubernetes. A key difference is that these tests run against a full cluster, while the e2e node tests runs in a reduced environment. Signed-off-by: Francesco Romani <fromani@redhat.com>

view details

OpenShift Merge Robot

commit sha 5d066fca8bcedefcedc8347173a2d5a623089cca

Merge pull request #24883 from bparees/errmsg clarify test failure message

view details

OpenShift Merge Robot

commit sha 55f403906e9b5e66fab9b4afb19f40b2212f74b5

Merge pull request #24817 from csrwng/ibmcloud_support_45 Bug 1827414: e2e: Add ibmcloud provider, skips and fixes

view details

OpenShift Merge Robot

commit sha 748f658f9622f55f21e00fa669bb728fb20813e3

Merge pull request #24913 from Miciah/test-slash-extended-slash-router-disable-http-2-tests Bug 1825354: test/extended/router: Disable HTTP/2 tests

view details

gabemontero

commit sha deabbe06ae33372140f9a7474cc46063f58ccd56

add templates e2e suite

view details

OpenShift Merge Robot

commit sha 83fb2e96652d79466e40978d9c98856d71031328

Merge pull request #24904 from danehans/bz_1809197 Bug 1827751: Enables secure metrics tests for dns

view details

Jack Ottofaro

commit sha 3b8cb3ca9b57e17980aa321bb8402ac9c144a17e

Add CI test to check for crit alerts post upgrade After an upgrade is successful, there should not be any critical alerts on the cluster. Post upgrade success, this change delays for alertCheckSleepMinutes and then checks if any critical alerts occurred within the last alertPeriodCheckMinutes and if so the test fails. After a successful check that confirms no critical alerts have occurred post cluster upgrade, this change will perform another Prometheus query checking for the occurrance of Watchdog alerts thereby verifying Prometheus is indeed up and running correctly. Prometheus helper package created to contain common code used to query Prometheus. The code being moved to the helper package is currently used by the upgrade Alert test and by the Prometheus extended test suite. The upgrade Alert test has been modified to use the helper package. Reworked to maintain a single framework per test

view details

Jack Ottofaro

commit sha 3a9233400053c036838bdbf7f992874b7a0805fd

Ignore KubeAPIErrorBudgetBurn alert KubeAPIErrorBudgetBurn alert is firing due to Bug 1821661. Once this bug is fixed this change will be backed out.

view details

Clayton Coleman

commit sha 5f0f7f4bbea88dea46dbb8cbaee61366d56dd5d2

test: Do not create namespaces twice The last refactor to the CLI helper resulted in namespaces being double created for origin tests, which is unnecessary.

view details

OpenShift Merge Robot

commit sha 3be2bc25e67441e67a682a790352a568e5b37144

Merge pull request #24786 from jottofar/ota-141-add-ci-alerts Bug 1828427: Add CI test to check for critical alerts post upgrade success

view details

OpenShift Merge Robot

commit sha 27ef82662cba0b9b67437c65ff1b24382f4970c4

Merge pull request #24679 from fromanirh/topomgr-e2e-tests Bug 1826807: Add tests for topology manager in single and multisocket configurations

view details

Lukasz Szaszkiewicz

commit sha b7f9cc11026358f9eb96e08aa287d44373148d7c

UPSTREAM: <drop>: this comit will be replaced by https://github.com/kubernetes/kubernetes/pull/90452

view details

Jan Chaloupka

commit sha 791b81af6b606cb07f2910bd5bf7ad21ec5ef23e

oc get --request-timeout: Timeout exceeded while reading body printed with -v=5 Expected "Timeout exceeded while reading body" error message is printed with -v=5. Without the error message, both --watch oc get commands unexpectedly fail.

view details

push time in 2 days

delete branch wking/machine-api-operator

delete branch : condition-reason

delete time in 2 days

delete branch wking/cluster-ingress-operator

delete branch : condition-reason

delete time in 2 days

delete branch wking/insights-operator

delete branch : condition-reason

delete time in 2 days

delete branch wking/cluster-version-operator

delete branch : drop-unused-reconciling

delete time in 2 days

delete branch wking/cluster-version-operator

delete branch : available-updates-sync-shuffle

delete time in 2 days

pull request commentopenshift/cluster-version-operator

Bug 1838497: pkg/cvo/sync_worker: Do not treat "All errors were context errors..." as success

upgrade job seems to have gotten lost. Kick it.

/test e2e-aws-upgrade

wking

comment created time in 2 days

delete branch wking/sippy

delete branch : index-4.6

delete time in 2 days

PR closed openshift/sippy

resources/deploymentconfig: Add 4.6

4.5 has split off from master, which now tracks 4.6 (e.g. openshift/release#9417). Have Sippy start indexing the 4.6 results to avoid:

Invalid release identifier: 4.6

+2 -0

2 comments

1 changed file

wking

pr closed time in 2 days

delete branch wking/cluster-machine-approver

delete branch : condition-reason

delete time in 2 days

delete branch wking/cluster-version-operator

delete branch : flatten-if-changed

delete time in 2 days

delete branch wking/cluster-version-operator

delete branch : v4-sync-succeeded-log

delete time in 2 days

delete branch wking/cluster-version-operator

delete branch : running-on-worker-log

delete time in 2 days

pull request commentkubernetes/test-infra

prow/spyglass/lenses/junit/template: Render <properties>

I poked at runlocal a bit, but couldn't figure it out:

$ prow/cmd/deck/runlocal
...
Extracting Bazel installation...
Starting local Bazel server and connecting to it...
ERROR: /home/wking/.cache/bazel/_bazel_wking/8b3c60e8268d88d94cd93c2ce9cc515c/external/io_bazel_rules_go/go/private/rules/sdk.bzl:72:18: Traceback (most recent call last):
	File "/home/wking/.cache/bazel/_bazel_wking/8b3c60e8268d88d94cd93c2ce9cc515c/external/io_bazel_rules_go/go/private/rules/sdk.bzl", line 37
		rule(_go_sdk_impl, attrs = {"goos": att...")}, <2 more arguments>)
	File "/home/wking/.cache/bazel/_bazel_wking/8b3c60e8268d88d94cd93c2ce9cc515c/external/io_bazel_rules_go/go/private/rules/sdk.bzl", line 72, in rule
		attr.label_list(allow_files = True, cfg = "exec", do...")
cfg must be either 'data', 'host', or 'target'.
...

Maybe my Bazel 0.24.1 is too old.

wking

comment created time in 2 days

push eventwking/ci-tools

Nikolaos Moraitis

commit sha 1efd5237651056437d09069bf96e9b39cc4f2f3c

move prowgen config to config package

view details

Nikolaos Moraitis

commit sha d97381632a7951ceac1955feee6f879a8dd7c071

update prowgen tests

view details

OpenShift Merge Robot

commit sha 11ddcc3758037d5c97795f8b4197891218f56044

Merge pull request #412 from droslean/prowgen-config Move prowgen config to config package

view details

Aniket Bhat

commit sha e7c8d85c6c33d63f7e8cd51699e57470d64d163c

Revert "Add a pre-upgrade save for iptables and must-gather"

view details

OpenShift Merge Robot

commit sha 9b6b6c4f1efa0eaf153ab6a3beef46512d44f785

Merge pull request #415 from abhat/revert-402-pre_upgrade_logging Revert "Add a pre-upgrade save for iptables and must-gather"

view details

Nikolaos Moraitis

commit sha 8af0a9f5cfc31c2ff667f3363a86bbbe0539533e

init: add ci-op-configs-mirror tool

view details

Nikolaos Moraitis

commit sha 162851fe49080be9fe646b5fa6c02fc666ba30dc

add integration tests for ci-op-configs-mirror tool

view details

Nikolaos Moraitis

commit sha c30e59a9e55f8a11a5f11b8cc8974a2ed8cb1ef4

include ci-op-configs-mirror integration to Makefile

view details

OpenShift Merge Robot

commit sha 6b5c2b047fc55730375edadd79f9301a9047ee19

Merge pull request #416 from droslean/ci-op-configs-mirror Add tool to mirror ci-operator configs to a single private repo

view details

Nikolaos Moraitis

commit sha ca516d8fa3a5a7a0f8951129c2cb613f5b3172c7

Revert "Add tool to mirror ci-operator configs to a single private repo"

view details

OpenShift Merge Robot

commit sha c5c67b5a013d08742c9bdce581c72e909e281cc2

Merge pull request #417 from droslean/revert-416-ci-op-configs-mirror Revert "Add tool to mirror ci-operator configs to a single private repo"

view details

Hongkai Liu

commit sha 3320bd98fc22923ea0219935249e0f0013a99065

Clean up build01 setup on ci-secret-mirroring repo

view details

Nikolaos Moraitis

commit sha 38492e08cc7428b9cd5273c61ad1839d2c30fda1

globalize prowgen's configuration name

view details

OpenShift Merge Robot

commit sha 1a5e3b13f7b69766930b319d0f95a9b148b2e12f

Merge pull request #420 from hongkailiu/clean_build01_on_secretmirror_repo Clean up build01 setup on ci-secret-mirroring repo

view details

OpenShift Merge Robot

commit sha 3f1b1f9278a336d13ed396934b636e687cd672c6

Merge pull request #419 from droslean/prowgen-config-global globalize prowgen's configuration name

view details

Alex Pavel

commit sha 6dc8bf361257ba6feb79c950942f1db09a7ac999

webreg: add job search page

view details

Alex Pavel

commit sha 2437ad6030dcfcd5c51295e6d3d15b1070e10cb8

webreg: don't require --prow-config flag yet

view details

OpenShift Merge Robot

commit sha 272f213d89942ff05ae30628458fa562b02952a3

Merge pull request #406 from AlexNPavel/ui-search webreg: add job search page

view details

Alex Pavel

commit sha 60ef7aba8777b8a28e42dd0ed69f25440a872e80

configresolver: make prow-config flag required

view details

OpenShift Merge Robot

commit sha f25d04fdc8878845cd232111160a34a5a55f1c03

Merge pull request #421 from AlexNPavel/prow-config-required configresolver: make prow-config flag required

view details

push time in 2 days

pull request commentkubernetes/test-infra

prow/spyglass/lenses/junit/template: Render <properties>

Bazel:

             + 	"Failed to load template file: open template.html: no such file or directory

Is there an incantation to get both Bazel and native tests loading content from the package directory?

wking

comment created time in 2 days

pull request commentkubernetes/test-infra

prow/spyglass/lenses/junit/template: Render <properties>

Rebased on master, added a unit test, and fixed the issues turned up in the unit test with 79366dd429 -> 7d92ed8640.

wking

comment created time in 2 days

push eventwking/kubernetes-test-infra

Patrick Ohly

commit sha 2e547f8abfcebfc24a7cc89a0dfb63613c88d3a5

image pushing: configure jobs for all Kubernetes-CSI repos This is part of rolling out multi-architecture image building for GCR, see https://github.com/kubernetes-csi/csi-release-tools/issues/86

view details

Jeff Grafton

commit sha 1cf4652ab68260edf5f5c5e0c1d8a9fd3b0b044b

Update go deps: k8s.io/test-infra/boskos -> sigs.k8s.io/boskos

view details

Patrick Ohly

commit sha 6af5a71b4bbc584369f0ee519493faa747d8c0fc

image pushing: more Kubernetes-CSI repos and branches, separate dashboard As discussed in https://github.com/kubernetes/test-infra/pull/17741 it's fine to enable jobs that will not succeed. A separate dashboard gets added because it's easier than trying to determine per repo where the job is meant to be shown and because it might be useful to check all of those jobs at one glance.

view details

Alvaro Aleman

commit sha c2e47b4b621abb5a50f4632b9358f217ae31a89a

PlankV2: Consider cache staleness for MaxConcurrency

view details

Antoni Zawodny

commit sha 070dcbcf7ab0ecdcd625fa5e887e470c212b6f2f

Sensitize Golang CI performance tests

view details

Laszlo Janosi

commit sha 4af85e2c99a903243842c66e3a46cfd8134a4f77

Skip the periodic SCTP related NetworkPolicy test. The environment of the periodic test execution does not support SCTP in NetworPolicy.

view details

W. Trevor King

commit sha 450c969e656758f530671a84ae7557fb6b214b61

*: Fix "jUnit" -> "JUnit" typos "JUnit" is the canonical casing [1]. Generated with: $ sed -i 's/jUnit/JUnit/g' $(git grep -l jUnit) [1]: https://junit.org/

view details

Kubernetes Prow Robot

commit sha 6e231e22b8a44e74f8c62ef4324bdd8ddf0407b3

Merge pull request #17791 from janosi/skip-sctp-np Skip the periodic SCTP related NetworkPolicy test

view details

Aaron Crickenberger

commit sha d570ef8af8adf4f71a0b8d252e46d5c9fbd985d9

prune node e2e OWNERS of known inactive reviewers

view details

Aaron Crickenberger

commit sha 5c4cfc8967b5eba59f60a238460ff5caa99779c7

add reviewers to node e2e OWNERS based on activity I've seen over the past month I would trust these folks to review node e2e changes more actively than the previous set of reviewers also ran reviewers through `sort -f`

view details

Alvaro Aleman

commit sha d22b54c3ebcef0668363afb5c00a7461510da92f

Move filteringProwJobLister into JobAgent There is no reason to ever use the JobAgent without the filtering ProwJobLister and its the only thing that uses it. This change is needed so external consumers can use the JobAgent.

view details

Kubernetes Prow Robot

commit sha aa3d9843f6fc0443dbdce78dab126687334afade

Merge pull request #17792 from wking/jUnit-casing *: Fix "jUnit" -> "JUnit" typos

view details

Alvaro Aleman

commit sha 631fff55dd7b80f860fb0dd0d6da5a69a2000780

Github: Add NewNotFound to aid in testing

view details

Kubernetes Prow Robot

commit sha 11a0110fc4450476efbdd145dbea57809204a5d6

Merge pull request #17795 from spiffxp/node-e2e-reviewers Update node e2e OWNERS

view details

Jacek Kaniuk

commit sha 04fe9b3c1a7247b894fa80a7c9060ff26e040b75

Fix wrong kubemark 100 override location

view details

Kubernetes Prow Robot

commit sha 0320c77f6131f004ff8da8e4d1ac993969bdff0d

Merge pull request #17753 from tosi3k/golang-ci-custom-thresholds Sensitize Golang CI performance tests

view details

Kubernetes Prow Robot

commit sha 33da73e144f001253a04d6b1e6b28e39043dfd48

Merge pull request #17796 from alvaroaleman/not-found Github: Add NewNotFound to aid in testing

view details

Peter Rifel

commit sha 447c3d5797f03916200372d5f34d0f6ec58017e4

Kops - add release-1.18 E2E presubmit job Also update the master E2E presubmit job to use the latest 1.19 release

view details

Kubernetes Prow Robot

commit sha 781c78a9ba7e4bc81cb316af1a9a4d31e59a2444

Merge pull request #17802 from rifelpet/kops-1.18 Kops - add release-1.18 E2E presubmit job

view details

Ben Parees

commit sha fe90664d78861d66ad0dc6e6b45c549a8f95b5de

update redhat openshift dashboards

view details

push time in 2 days

pull request commentopenshift/origin

pkg/test/ginkgo: Add 'weight' property to JUnit <testcase>

retry=failed and retry=success as properties on the ones that were retried (or some similar attribute)

I don't think we need this. Have you looked at #25053?

wking

comment created time in 2 days

pull request commentopenshift/origin

pkg/test/ginkgo: Add 'weight' property to JUnit <testcase>

You don't have enough context inside the test to say "this failed once, therefore it is informing". That is only possible to do outside of the test suite.

I am not saying that. The only informing bit in this PR is where we are explicitly creating the informing result.

wking

comment created time in 2 days

pull request commentopenshift/origin

pkg/test/ginkgo: Add 'weight' property to JUnit <testcase>

So can you articulate how you are going to use this?

kubernetes/test-infra#17798

We have to fix all three of those cases...

Agreed, but I think fixing failures is more important than zeroing informers (or we'd have made those informers fatal).

wking

comment created time in 2 days

Pull request review commentopenshift/origin

pkg/test/ginkgo: Add 'weight' property to JUnit <testcase>

 func (opt *Options) Run(args []string) error { 				FailureOutput: &FailureOutput{ 					Output: fmt.Sprintf("%d error level events were detected during this test run:\n\n%s", errorCount, errBuf.String()), 				},+				Properties: &JUnitProperties{

Is this based on any standard?

At least the "test-infra schema supports it" and "we already use it for <testsuite>" (which test-infra does not support) standards, as linked from the commit messages.

wking

comment created time in 2 days

pull request commentkubernetes/test-infra

prow/spyglass/lenses/junit/template: Render <properties>

Not verified yet. Any ideas? Would be nice to have CI coverage...

wking

comment created time in 3 days

delete branch wking/promecieus

delete branch : search-query-param

delete time in 3 days

pull request commentopenshift/origin

pkg/test/ginkgo: Include flake retries in JUnit

Nice :tada:

wking

comment created time in 3 days

PR opened kubernetes/test-infra

prow/spyglass/lenses/junit/template: Render <properties>

Our JUnit typing has supported test-case properties since ce50d4c65c (#9887). If the ingested JUnit includes them, display those properties for failing/flaky tests as a description list.

This implementation does not currently support properties for passing/skipped tests, since those don't currently have an expanding section to hold these additional details.

openshift/origin#25044 would be an example of content feeding into this display.

+27 -0

0 comment

1 changed file

pr created time in 3 days

push eventwking/kubernetes-test-infra

W. Trevor King

commit sha 79366dd429cc92bfb3ab70f56522c7530e43c8c4

prow/spyglass/lenses/junit/template: Render <properties> Our JUnit typing has supported test-case properties since ce50d4c65c (calculate code coverage and produce junit xml, 2018-10-30, #9887). If the ingested JUnit includes them, display those properties for failing/flaky tests as a description list. This implementation does not currently support properties for passing/skipped tests, since those don't currently have an expanding section to hold these additional details.

view details

push time in 3 days

delete branch wking/promecieus

delete branch : cleanup-deployments

delete time in 3 days

delete branch wking/promecieus

delete branch : resource-quota-watcher

delete time in 3 days

delete branch wking/promecieus

delete branch : fix-resource-watch

delete time in 3 days

delete branch wking/promecieus

delete branch : devel

delete time in 3 days

delete branch wking/promecieus

delete branch : drop-customize

delete time in 3 days

delete branch wking/promecieus

delete branch : client-go

delete time in 3 days

delete branch wking/promecieus

delete branch : find-tar

delete time in 3 days

delete branch wking/promecieus

delete branch : html

delete time in 3 days

delete branch wking/promecieus

delete branch : delete-button

delete time in 3 days

PR opened vrutkovs/promecieus

html/app: Add support for ?search={URI}

This allows folks to link to PromeCIeus with a particular job-detail page in mind, and folks clicking through won't have to bother pasting in the URI or clicking "Generate". For example, the job-detail page itself may want to link PromeCIeus with it's own location in the search query parameter.

Calling handleSearchInput from the new search() function means that folks typing into the form field and then clicking "Generate" will get handleSearchInput called twice, which is not a big deal. And it means that folks calling search() from other places can't forget to set the state.

The new querySearch state ensures we only trigger the auto-search logic when the query value changes.

searchParams() business is based on the MDN docs.

+25 -9

0 comment

1 changed file

pr created time in 3 days

create barnchwking/promecieus

branch : search-query-param

created branch time in 3 days

fork wking/promecieus

Create a new prometheus deployment w/ Openshift CI data

fork in 3 days

PR opened bparees/sippy

resources/deploymentconfig: Add 4.6

4.5 has split off from master, which now tracks 4.6 (e.g. openshift/release#9417). Have Sippy start indexing the 4.6 results to avoid:

Invalid release identifier: 4.6

+2 -0

0 comment

1 changed file

pr created time in 3 days

create barnchwking/sippy

branch : index-4.6

created branch time in 3 days

delete branch wking/kubernetes-test-infra

delete branch : jUnit-casing

delete time in 3 days

pull request commentopenshift/origin

pkg/test/ginkgo: Add 'weight' property to JUnit <testcase>

#25053 should also distinguish flaky vs. failing. But because it will not distinguish informers or fix the <properties> handling, I think we want both changes.

wking

comment created time in 3 days

PR opened openshift/origin

pkg/test/ginkgo: Include flake retries in JUnit

The upstream JUnit lens learned how to dedup repeated tests and distinguish flakes in kubernetes/test-infra#16992. Include our retries in the output to take advantage of that new UX.

+3 -1

0 comment

1 changed file

pr created time in 3 days

create barnchwking/origin

branch : include-flake-results

created branch time in 3 days

more