text:
Better naming convention for synthetic TrafficTargets in allow-all (permissive) mode

As of this writing the name of the synthetic TrafficTargets (generated by the control plane) when in allow-all (permissive) mode look like this:
"&Service{ObjectMeta:{bookstore  default    0 0001-01-01 00:00:00 +0000 UTC <nil> <nil> map[] map[] [] []  []},Spec:ServiceSpec{Ports:[]ServicePort{ServicePort{Name:servicePort,Protocol:TCP,Port:8888,TargetPort:{1 0 backendName},NodePort:0,AppProtocol:nil,},},Selector:map[string]string{},ClusterIP:,Type:,ExternalIPs:[],SessionAffinity:,LoadBalancerIP:,LoadBalancerSourceRanges:[],ExternalName:,ExternalTrafficPolicy:,HealthCheckNodePort:0,PublishNotReadyAddresses:false,SessionAffinityConfig:nil,IPFamily:nil,TopologyKeys:[],},Status:ServiceStatus{LoadBalancer:LoadBalancerStatus{Ingress:[]LoadBalancerIngress{},},},}->&Service{ObjectMeta:{bookbuyer  default    0 0001-01-01 00:00:00 +0000 UTC <nil> <nil> map[] map[] [] []  []},Spec:ServiceSpec{Ports:[]ServicePort{ServicePort{Name:servicePort,Protocol:TCP,Port:8888,TargetPort:{1 0 backendName},NodePort:0,AppProtocol:nil,},},Selector:map[string]string{},ClusterIP:,Type:,ExternalIPs:[],SessionAffinity:,LoadBalancerIP:,LoadBalancerSourceRanges:[],ExternalName:,ExternalTrafficPolicy:,HealthCheckNodePort:0,PublishNotReadyAddresses:false,SessionAffinityConfig:nil,IPFamily:nil,TopologyKeys:[],},Status:ServiceStatus{LoadBalancer:LoadBalancerStatus{Ingress:[]LoadBalancerIngress{},},},}"
We could improve this by using the names of the services or even hashing this.
Search the source code for this Github Issue for references.

Scope (please mark with X where applicable)

New Functionality          [ ]
Install                    [ ]
SMI Traffic Access Policy  [ ]
SMI Traffic Specs Policy   [ ]
SMI Traffic Split Policy   [ ]
Permissive Traffic Policy  [ ]
Ingress                    [ ]
Egress                     [ ]
Envoy Control Plane        [ ]
CLI Tool                   [ ]
Metrics                    [ ]
Certificate Management     [ ]
Sidecar Injection          [ ]
Logging                    [ ]
Debugging                  [ ]
Tests                      [ ]
CI System                  [ ]
Project Release            [ ]

Possible use cases

@draychev , I don't understand this issue completely. Could you provide more details when you refer to using the names of the services or even hashing this? An example would help.

@draychev , I don't understand this issue completely. Could you provide more details when you refer to using the names of the services or even hashing this? An example would help.

Here is a link to the unit test where this is visible: https://github.com/openservicemesh/osm/pull/1504/files#diff-3f7cfdfe5c47b3d1cccd1d02268812e4R236-R247
Instead of having a string which represents struct -> struct - it would be nice to have default/bookbuyer -> default/bokstore
So I think this
&Service{ObjectMeta:{bookstore default 0 0001-01-01 00:00:00 +0000 UTC <nil> <nil> map[] map[] [] [] []},Spec:ServiceSpec{Ports:[]ServicePort{ServicePort{Name:servicePort,Protocol:TCP,Port:8888,TargetPort:{1 0 backendName},NodePort:0,AppProtocol:nil,},},Selector:map[string]string{},ClusterIP:,Type:,ExternalIPs:[],SessionAffinity:,LoadBalancerIP:,LoadBalancerSourceRanges:[],ExternalName:,ExternalTrafficPolicy:,HealthCheckNodePort:0,PublishNotReadyAddresses:false,SessionAffinityConfig:nil,IPFamily:nil,TopologyKeys:[],},Status:ServiceStatus{LoadBalancer:LoadBalancerStatus{Ingress:[]LoadBalancerIngress{},},},}->&Service{ObjectMeta:{bookbuyer default 0 0001-01-01 00:00:00 +0000 UTC <nil> <nil> map[] map[] [] [] []},Spec:ServiceSpec{Ports:[]ServicePort{ServicePort{Name:servicePort,Protocol:TCP,Port:8888,TargetPort:{1 0 backendName},NodePort:0,AppProtocol:nil,},},Selector:map[string]string{},ClusterIP:,Type:,ExternalIPs:[],SessionAffinity:,LoadBalancerIP:,LoadBalancerSourceRanges:[],ExternalName:,ExternalTrafficPolicy:,HealthCheckNodePort:0,PublishNotReadyAddresses:false,SessionAffinityConfig:nil,IPFamily:nil,TopologyKeys:[],},Status:ServiceStatus{LoadBalancer:LoadBalancerStatus{Ingress:[]LoadBalancerIngress{},},},}

can be
default/bookbuyer -> default/bookstore

I believe this change should be easy here: https://github.com/openservicemesh/osm/pull/1504/files#diff-8c9bb5aa4e77c52319b6903e889bd59bR350
this could be (plus namespace):
Name: fmt.Sprintf("%s->%s", source.Name, destination.Name),

Name: fmt.Sprintf("%s->%s", source.Name, destination.Name),

This is what I was looking for. This is not intended for sure :-) We should change it.

authors: draychev shashankram

repo: openservicemesh/osm


text:
Fix multi-instance Tresor certificate creation

WIP.
The createOrUpdate logic has been removed from OSM from top level,
to have better control of CA ownership for the providers themselves.

For Tresor, the first instance will create the CA when it has not
been created yet. This relies on Create atomicity on k8s API, and should
ensure only one is created, while all others can just fetch it.

For CertManager and Vault integrations, it is assumed the CA ownership
is outside OSM.

Control Plane          [X]

Please answer the following questions with yes/no.

Does this change contain code from or inspired by another project? If so, did you notify the maintainers and provide attribution?
No

Codecov Report

Merging #2539 (47f5efb) into main (1bec41f) will decrease coverage by 0.08%.
The diff coverage is 65.38%.

@@            Coverage Diff             @@
##             main    #2539      +/-   ##
==========================================
- Coverage   59.24%   59.16%   -0.09%
==========================================
  Files         155      155
  Lines        7018     7001      -17
==========================================
- Hits         4158     4142      -16
+ Misses       2844     2842       -2
- Partials       16       17       +1

Flag
Coverage Δ

unittests
59.16% <65.38%> (-0.09%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

cmd/osm-controller/osm-controller.go
18.80% <ø> (-11.20%)
:arrow_down:

pkg/certificate/providers/config.go
25.00% <65.38%> (+11.80%)
:arrow_up:

pkg/configurator/validating_webhook.go
70.34% <0.00%> (-9.66%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1bec41f...47f5efb. Read the comment docs.

closing, will submit a different solution

source: gharchive/pull-request

license_type: permissive

license_source: github-api


text:
Add MeshConfig upgrade when upgrading a mesh

Description:
This fixes issue #4371. Prior to this fix if there was a change to the envoy sidecar image then this would not get reflected or upgraded in the mesh config. Upon further testing we cannot just patch that in because if there are missing required keys (as indicated by the CRD) then the patch itself will fail (see the Testing done section below on the missing required key error when attempting to patch).
This PR adds the functionality for a complete upgrade of the mesh config by doing two things:

Compare CRD required fields with the current MeshConfig. If there are missing required keys then patch them in.
Compare the envoy sidecar image. If the default has been upgraded between the old and the new version and the user has not modified the default in their mesh config, then upgrade this value.

Testing done:
Integration tests and manual testing.
Prior to this change:
 $ osm version
Version: v0.9.2; Commit: 7df9badece2f251515a2bc5e5ac79438b0c58812; Date: 2021-08-19-21:02

 $ osm install
OSM installed successfully in namespace [osm-system] with mesh name [osm]

 $ git log --oneline -1
8dccabbf (HEAD -> main, upstream/main) injector: rename iptables chains for clarity (#4379)

 $ go run ./cmd/cli mesh upgrade
OSM successfully upgraded mesh [osm] in namespace [osm-system]

Even though the mesh was upgraded, the envoy sidecar image remains the old version in the mesh config:
 $ kubectl get configmap -n osm-system preset-mesh-config -o jsonpath='{.data.preset-mesh-config\.json}' | jq -r '.sidecar.envoyImage'
envoyproxy/envoy-alpine@sha256:6502a637c6c5fba4d03d0672d878d12da4bcc7a0d0fb3f1d506982dde0039abd

 $ kubectl get meshconfig -n osm-system osm-mesh-config -o jsonpath='{.spec.sidecar.envoyImage}'
envoyproxy/envoy-alpine:v1.18.3

If you try to patch that it errors because of a missing key:
 $ kubectl patch meshconfig -n osm-system osm-mesh-config --type=json --patch='[{"op":"replace","path":"/spec/sidecar/envoyImage","value":"envoyproxy/envoy-alpine@sha256:6502a637c6c5fba4d03d0672d878d12da4bcc7a0d0fb3f1d506982dde0039abd"}]'
The MeshConfig "osm-mesh-config" is invalid: spec.certificate.certKeyBitSize: Required value

With this PR:
 $ kubectl get meshconfig -n osm-system osm-mesh-config -o jsonpath='{.spec.sidecar.envoyImage}'
envoyproxy/envoy-alpine@sha256:6502a637c6c5fba4d03d0672d878d12da4bcc7a0d0fb3f1d506982dde0039abd

 $ kubectl get meshconfig -n osm-system osm-mesh-config -o jsonpath='{.spec.certificate.certKeyBitSize}'
2048

Affected area:

Functional Area

Upgrade
[X]

Please answer the following questions with yes/no.

Does this change contain code from or inspired by another project?

No.

Is this a breaking change?

No.

I know this is still WIP so I haven't taken a close look yet, but a few initial thoughts:
It seems like the simplest solution here would be to default the image name/tag in the injector and leave it empty in the MeshConfig. Then the upgraded injector would implicitly start using its updated default. This was the behavior until #4131. Of the reasons @shashankram describes there, I think the biggest problem with using a default was that the default would be used if there was some error reading the value from the MeshConfig. I'd argue we should fail the injection altogether in that case. Otherwise, I don't see any issues with using a default if no value is specified in the MeshConfig.
Going forward, adding new required fields to the CRD should result in an appropriate version bump for the API (v1alpha1 -> v1alpha2) and we should either have a conversion webhook to handle both versions or force the user to update their MeshConfigs to the new API themselves. That would handle any new required fields, so working around that here doesn't seem worth it to me unless we need this behavior for upgrading v0.9 to v0.11.

I know this is still WIP so I haven't taken a close look yet, but a few initial thoughts:
It seems like the simplest solution here would be to default the image name/tag in the injector and leave it empty in the MeshConfig. Then the upgraded injector would implicitly start using its updated default. This was the behavior until #4131. Of the reasons @shashankram describes there, I think the biggest problem with using a default was that the default would be used if there was some error reading the value from the MeshConfig. I'd argue we should fail the injection altogether in that case. Otherwise, I don't see any issues with using a default if no value is specified in the MeshConfig.
Going forward, adding new required fields to the CRD should result in an appropriate version bump for the API (v1alpha1 -> v1alpha2) and we should either have a conversion webhook to handle both versions or force the user to update their MeshConfigs to the new API themselves. That would handle any new required fields, so working around that here doesn't seem worth it to me unless we need this behavior for upgrading v0.9 to v0.11.

The reason defaults are not to be encoded in the binary is because the image digests are not known. We should avoid going back to encoding defaults in the Go code if possible, and always infer it through the MeshConfig or other means.

The reason defaults are not to be encoded in the binary is because the image digests are not known. We should avoid going back to encoding defaults in the Go code if possible, and always infer it through the MeshConfig or other means.

The default doesn't necessarily have to be a constant in Go. We could pass it on the command line or as an environment variable when the injector starts so it can still be defined once in values.yaml like it is now.

This was a complete rewrite of the original PR, so the first message in this thread is no longer completely relevant.
From the feedback, I refactored this to use environment variables if there is no setting in the MeshConfig for the following images: envoy image, envoy windows image, and the init container image.
The default was also removed from the mesh config CRD, as that would auto-populate the MeshConfig resource with the defaults.
This does not solve the problem with missing required parameters (in the original case, certKeyBitSize) but as @nojnhuh mentioned this is more of a process issue with incrementing the resource version and dealing with the changes through a conversion webhook.

Codecov Report

Merging #4386 (5da4e39) into main (8dccabb) will increase coverage by 0.05%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main    #4386      +/-   ##
==========================================
+ Coverage   69.27%   69.32%   +0.05%
==========================================
  Files         212      212
  Lines       14455    14476      +21
==========================================
+ Hits        10013    10035      +22
+ Misses       4390     4389       -1
  Partials       52       52

Flag
Coverage Δ

unittests
69.32% <100.00%> (+0.05%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

pkg/configurator/methods.go
73.38% <100.00%> (+2.85%)
:arrow_up:

cmd/cli/namespace_add.go
83.63% <0.00%> (-0.53%)
:arrow_down:

pkg/ticker/ticker.go
87.17% <0.00%> (+3.84%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8dccabb...5da4e39. Read the comment docs.

authors: codecov-commenter nojnhuh shashankram trstringer


text:
feat: Replace redis by valkey

Replace redis instance by valkey

Secret name is kept as redis-credentials for simplicity with current secret
Code package is still redis
Code variable are still REDIS_ADDR and REDIS_PASSWORD to be consistent with package

Monitoring has not been migrated because:

The current exporter image has a lot of vuln (the point of migrating is to reduce the number of vuln)
Metrics are not consumed atm anyway
The PR is probably already big enough

/lgtm
/approve

/lgtm
/approve

authors: pastequo rccrdpccl


text:
lso pkg: localvolumeset enhancements, unit test, new methods added

localvolumeset enhancements, unit test, new methods added:

WithNodeSelector
WithStorageClassName
WithVolumeMode
WithFSType
WithMaxDeviceCount
WithDeviceInclusionSpec

@trewest @kononovn @achuzhoy @cdvultur PTAL

@trewest @kononovn @achuzhoy @cdvultur PTAL

/lgtm

authors: achuzhoy elenagerman

repo: openshift-kni/eco-goinfra


text:
Adds downloading documentation

It includes documentation related to the downloading stage of the artifacts:

Downloading of OCP release artifacts
Downloading of the telco 5G RAN operators
Modifications required for disconnected environments. At this point, we can extract the operator's dependencies by using catalog sources stored in a disconnected registry. This is something that it is yet not available for OCP release container images.

cc/ @donpenney @browsell @obochan-rh

/retest

/retest

/retest

/override ci/prow/images

authors: alosadagrande donpenney

repo: openshift-kni/telco-ran-tools


text:
Add documentation about fine grained webhook token

Fixes #1037
Signed-off-by: Chmouel Boudjnah chmouel@redhat.com

Changes

Submitter Checklist

[ ] ♽  Run make test lint before submitting a PR (ie: with pre-commit, no need to waste CPU cycle on CI
[ ] 📖 If you are adding a user facing feature or make a change of the behavior, please verify that you have documented it
[ ] 🧪 100% coverage is not a target but most of the time we would rather have a unit test if you make a code change.
[ ] 🎁 If that's something that is possible to do please ensure to check if we can add a e2e test.
[ ] 🔎 If there is a flakiness in the CI tests then don't necessary ignore it, better get the flakyness fixed before merging or if that's not possible there is a good reason to bypass it. (token rate limitation may be a good reason to skip).

Codecov Report

Merging #1038 (805608c) into main (12dcb84) will decrease coverage by 0.07%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #1038      +/-   ##
==========================================
- Coverage   61.36%   61.28%   -0.08%
==========================================
  Files          99       99
  Lines        6041     6024      -17
==========================================
- Hits         3707     3692      -15
+ Misses       1986     1985       -1
+ Partials      348      347       -1

Impacted Files
Coverage Δ

pkg/resolve/resolve.go
88.54% <0.00%> (-1.28%)
:arrow_down:

pkg/adapter/tls.go
100.00% <0.00%> (+11.76%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

good to go for y'all ?

authors: chmouel codecov-commenter

repo: openshift-pipelines/pipelines-as-code


text:
Cleanup && from makefile and add missing .PHONYs

Signed-off-by: Nico Schieder nschieder@redhat.com

/lgtm

authors: erdii thetechnick

repo: openshift/addon-operator


text:
Use common generateName for storage

Use a commont generateName function to generate storage name
Wrap the swift storage creation in a loop that checks for an existing container
Swift test fixes donated by @Fedosin, thanks!

Fixes #358

/retest

/assign @adambkaplan @Fedosin @ricardomaraschini

@ricardomaraschini ptal, updated per your comments

/retest
networking flake
panic: Get https://api.ci-op-thmg1jwy-12abb.origin-ci-int-aws.dev.rhcloud.com:6443/apis/config.openshift.io/v1/clusterversions/version: dial tcp: i/o timeout

/retest
Aug  9 12:58:41.119: INFO: Couldn't delete ns: "e2e-svcaccounts-6131": namespace e2e-svcaccounts-6131 was not deleted with limit: timed out waiting for the condition, namespace is empty but is not yet removed (&errors.errorString{s:"namespace e2e-svcaccounts-6131 was not deleted with limit: timed out waiting for the condition, namespace is empty but is not yet removed"})

/test openstack-e2e

/test e2e-openstack

/test e2e-azure

/test e2e-gcp

/test e2e-gce

/approve
please have someone from @openshift/openshift-team-developer-experience lgtm

@Fedosin thanks for the review, updated per your comments

@bparees ptal

@coreydaley
https://github.com/openshift/cluster-image-registry-operator/pull/355#issuecomment-520076396

@ricardomaraschini @gabemontero Can one of you ptal and let me know if you have any questions or lgtm

/retest

/lgtm

authors: bparees coreydaley gabemontero


text:
AUTH-481: Add PSa labels to openshift-controller-manager-operator namespace

openshift-controller-manager
openshift-controller-manager-operator
openshift-route-controller-manager

/hold
blocked by https://issues.redhat.com/browse/AUTH-482

/approve

authors: liouk sayan-biswas


text:
OU-446: Support FIPS

This PR looks to add FIPS support. It updates the go version to 1.22, and uses recommended FIPS compliant images and tags. Due to some of the recommended images not being available publicly a Dockerfile.dev is added to the repo as a way to build and test images locally.

/lgtm

authors: PeterYurkovich jgbernalp


text:
Add verify command for OpenShift CI

hack/verify-deps.sh:
Add script to verify vendor/ when running on OpenShift CI.
hack/verify-gofmt.sh:
Add script to verify that all operator code is gofmt compliant.
hack/verify-generated.sh:
Add script to verify that generated manifests (e.g. the ExternalDNS CRD)
and deep copy functions are up to date.
Makefile:
Add new verify directive that calls the verify scripts in hack/.
/assign @alebedev87

/cc @lmzuccarelli

/lgtm

repo: openshift/external-dns-operator


text:
Make deployable manifests

Preparation for OLM bundle as it has to include the deployment's spec and roles. As a positive side effect we can now use the manifests to deploy the operator on a cluster.

Changed names for deployment, service account and other resources to better reflect the deliverable
Updated deployment spec (resources, probes)
Commented not used manifests (auth proxy, manager config, leader election)

/assign @sgreene570

/lgtm


text:
CFE-1022: UPSTREAM: 640: Add labels from command line option to filestore backup resource

Backport of the upstream change https://github.com/kubernetes-sigs/gcp-filestore-csi-driver/pull/640 which fixes the issue https://github.com/kubernetes-sigs/gcp-filestore-csi-driver/issues/639.
This change enables adding labels from command line option to filestore backup resource created for an OpenShift Cluster.

/lgtm

@mpatlasov Thank you for approving the changes!
Security CI job failing is during synk static code check with below errors, which was not introduced by this commit.
✗ [Medium] Use of Hardcoded Credentials
   ID: df6532bc-5b0a-43f4-a0d9-261ee145e854
   Path: pkg/csi_driver/node.go, line 44
   Info: Do not hardcode passwords in code. Found hardcoded saved in optionSmbPassword.
 ✗ [Medium] Use of Hardcoded Credentials
   ID: d6c8ce32-a664-4337-ac26-1a[39](https://prow.ci.openshift.org/view/gs/test-platform-results/pr-logs/pull/openshift_gcp-filestore-csi-driver/41/pull-ci-openshift-gcp-filestore-csi-driver-master-security/1812808764399554560#1:build-log.txt%3A39)40b5550c
   Path: pkg/csi_driver/node.go, line 127
   Info: Do not hardcode passwords in code. Found hardcoded saved in optionSmbPassword.
 ✗ [Medium] Use of Hardcoded Credentials
   ID: 2d2af722-[42](https://prow.ci.openshift.org/view/gs/test-platform-results/pr-logs/pull/openshift_gcp-filestore-csi-driver/41/pull-ci-openshift-gcp-filestore-csi-driver-master-security/1812808764399554560#1:build-log.txt%3A42)96-48ff-a7bf-50ad03555a7e
   Path: pkg/csi_driver/node.go, line [44](https://prow.ci.openshift.org/view/gs/test-platform-results/pr-logs/pull/openshift_gcp-filestore-csi-driver/41/pull-ci-openshift-gcp-filestore-csi-driver-master-security/1812808764399554560#1:build-log.txt%3A44)4
   Info: Do not hardcode passwords in code. Found hardcoded saved in optionSmbPassword.
 ✗ [Medium] Path Traversal
   ID: ff3d85f1-6d34-48d6-b624-73c8e727ae15
   Path: cmd/main.go, line 117
   Info: Unsanitized input from a CLI argument flows into os.Open, where it is used as a path. This may result in a Path Traversal vulnerability and allow an attacker to open arbitrary files.

Could you please advise on how I can proceed?

The last finding seems to be false positive, since we are not expecting a file in a predefined path, instead it's the complete path provided by the user and directory traversing does not happen. Synk can be configured to ignore the issue.
But for the hardcoded password, it's for the common windows server username/password, it would require changes to make it user configurable.
Please let me know your thoughts.

@bharath-b-rh , I'd suggest you to proceed ignoring security job failure as false-positive. That's why we tagged it as Required=false. IMHO, optionSmbPassword doesn't contain a password. It contains magic string "smbPassword" which is used as a key to get password value from a secret.

/label px-approved
/label docs-approved
no user facing changes

@mpatlasov We can't configure ignores for code scans in the local snyk policy file, we have to do it in the UI. I have requested the access for the same, but I am not sure if that will be approved.
This was observed during upstream rebase and the failure was ignored.

@bharath-b-rh , you only need qe-approved from QE team to have this PR merged. No need to configure ignores for code scans (unless you you are able and willing to do that).

/test security

/label qe-approved

authors: bharath-b-rh chao007 mpatlasov

repo: openshift/gcp-filestore-csi-driver


text:
fix(KFLUXBUGS-1342): add existing secret in the components secret form

Fixes

KFLUXBUGS-1342
Description

When onboarding a new component and adding a build time secret, the dialog cannot find an existing secret in the workspace.
Type of change

[ ] Feature
[x] Bugfix
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Documentation content changes
[ ] Other (please describe):

Browser conformance:

[ ] Chrome
[ ] Firefox
[ ] Safari
[ ] Edge

Hello @sahil143
To make the list of existing secrets available for build time I removed the filter on SecretSction.tsx and SecretForm.tsx and add a new variable to block any change of value for existing secrets. Please take a look when you have time and share your thought and concerns if this approach works.
Ps: I didn't rewrite the test yet

/retest

The current implementation looks good to me so far. I did find this weird bug though when trying to find one of my key/value secrets:
kfluxbugs-1342-select-bug.webm

The current implementation looks good to me so far. I did find this weird bug though when trying to find one of my key/value secrets:
kfluxbugs-1342-select-bug.webm

Nice catch :)
I think this was caused because I was not using states for the option values. It should have the correct behavior now

Yup that fixed it:
kfluxbugs-1342-bug-fixed.webm

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

@Katka92
Can you help to understand why ci.int.devshift.net test is failing? I did not touch anything related to getting started section.

/retest

/retest

/lgtm

/retest

/lgtm

authors: CryptoRodeo JoaoPedroPP marcin-michal

repo: openshift/hac-dev


text:
Fix GenerateName Bug in Remote Machine Set Controller, and Uninstall Missing Credentials

Fixes: https://github.com/openshift/hive/issues/123
Also fixes an uninstall error resulting from my recent rename of the aws cred secret properties.

/lgtm

Thanks all :+1:

authors: abutcher dgoodwin yaacov

repo: openshift/hive


text:
Explicit pod security

Conform to new pod security admission rules.
HIVE-2023

Note to future-me: I found violations as follows:
oc adm node-logs  $(oc get no -o name | paste -s -)  --path=kube-apiserver/audit.log|grep 'would violate PodSecurity'

/assign @akhil-rane

/retest

/test e2e-gcp
/test e2e-azure

/test e2e-pool

/retest

/retest

/hold
i give up until Monday

/test e2e-pool

/hold cancel


text:
Reset metrics on each pass of metrics controller

HIVE-2326

Seems sane to me, but I would like Suhani to have a look -- in particular to validate that this makes sense for all of these metrics.
/assign @suhanime


text:
Remove now obsolete toleration edit in remoteingress controller.

This was done to force the rollout of ingress config, which should no
longer be needed as of 4.2.0.
The code in question is now causing a problem for hive users who need to
adjust default router tolerations to land them on specific nodes, also
being done by syncsets, and now both syncsets are fighting for the
tolerations causing the pods to restart often, impacting running
services.
With this change, remoteingress will no longer work seamlessly on 4.1
OpenShift clusters, manual restarts may be required. We do not believe
this will impact many users as 4.2 and 4.3 are both available now.

With this change, remoteingress will no longer work seamlessly on 4.1
OpenShift clusters, manual restarts may be required. We do not believe
this will impact many users as 4.2 and 4.3 are both available now.

Have we checked to see if there are indeed production users that are running 4.1? Do we even have insight into that?

@mwoodson confirmed no prod users are on 4.1 anymore, they upgrade the entire fleet fairly often.

authors: dgoodwin staebler


text:
Use forked processes instead of pods to generate ignition payload

Before this commit, ignition payloads for nodepools were generated by
orchestrating MCO components using pods. This was a performance problem because
ignition server restarts (e.g. during upgrades) resulted in thundering herds of
ignition payload generation pods, limiting overall cluster capacity.
This commit refactors ignition payload generation away from pods and to a
mechanism that extracts MCO binaries (and supporting files) from release
payloads so they can be forked as subprocesses of the ignition server
controller, removing all pod scheduling overhead. This change should be
completely transparent to the end user and is a drop-in replacement for the old
implementation.
The current implementation has the following limitations:

Extracted payload contents are not cached across executions per release image.
This is possible, but not worth doing unless subsequent performance analysis
justifies it.

All payload generation executions are serial. Concurrent executions are
possible, but not worth doing unless subsequent performance analysis justifies
it.

This commit also enables metrics collection for the ignition server component and
adds the following metrics:

ign_server_token_rotation_total
ign_server_payload_cache_miss_total
ign_server_payload_generation_seconds
ign_server_payload_cache_total

What this PR does / why we need it:
Which issue(s) this PR fixes (optional, use fixes #<issue_number>(, fixes #<issue_number>, ...) format, where issue_number might be a GitHub issue, or a Jira story:
Fixes #
Checklist

[ ] Subject and description added to both, commit and PR.
[ ] Relevant issues have been referenced.
[ ] This change includes docs.
[ ] This change includes unit tests.

/lgtm

/retest

/retest

/retest

repo: openshift/hypershift


text:
create external Routes for Private clusters

Part of https://issues.redhat.com/browse/HOSTEDCP-801
We need to maintain the routes for the external KAS and OAuth names even when the cluster is Private so that traffic coming across the PrivateLink using those name are properly routed.
Strictly speaking, this isn't required for the KAS because it is the default service for the HCP router, but we should make it explicit.

/lgtm

/hold

/hold cancel

included in https://github.com/openshift/hypershift/pull/2286
/close

authors: csrwng sjenning


text:
Refactor oauth server rendering by control plane operator

Adds code to convert configv1 IdentityProviders to the identity
provider configuration used by the OAuth server.
Removes template-based rendering of the oauth server.

/test e2e-aws

/test e2e-aws

@ironcladlou comments addressed

Great stuff, thanks!
/lgtm

authors: csrwng ironcladlou


text:
fix the node pool name in the kubevirt 2e2 test

The expected node pool name in the kubevirt test was changed to include AWS zone, where there is no AWS zone in kubevirt cluster, an so the test is fails because it can't find the node pool with the wrong name.
This PR reverts the naming change in the kubevirt test.
Signed-off-by: Nahshon Unna-Tsameret nunnatsa@redhat.com

What this PR does / why we need it:
Which issue(s) this PR fixes (optional, use fixes #<issue_number>(, fixes #<issue_number>, ...) format, where issue_number might be a GitHub issue, or a Jira story:
Fixes #
Checklist

[ ] Subject and description added to both, commit and PR.
[ ] Relevant issues have been referenced.
[ ] This change includes docs.
[ ] This change includes unit tests.

r/node pull/NodePool ?

/approve

/lgtm

My bad! I feel like this is going to happen somewhat frequently without kubevirt e2e in CI.

Right. Working on it - that how I noticed this issue.

authors: enxebre nunnatsa


text:
Autodetct the container engine if not set

Search order: podman, docker
Also makes sure our command line options match what the engine(s) need:

Podman needs volumes mounted with :Z
Docker needs a socket path

Signed-off-by: Jim Ramsay jramsay@redhat.com

/lgtm
/cc @natifridman

/approve

authors: lack nocturnalastro

repo: openshift/kube-compare


text:
Synchronize with upstream

Synchronize with upstream release-1.6.
/cc @brancz

/lgtm

authors: brancz paulfantom

repo: openshift/kube-state-metrics


text:
staticpod: move revision status configmap update to prune controller

When the startup-monitor marks revision as good, the installer controller is not the right place to update the revision status configmap. It fits better into the prune controller that also consumes it.

Rebased.

repo: openshift/library-go


text:
OLS-1077: Add the YAML and Events attach options for HPAs

Add the ability to attach YAML and events to the prompt for HorizontalPodAutoscalers.
Also reorder the resource types object to match the order they appear in the console navigation menu.

Override failing test not related to this change:
/override "Red Hat Konflux / ols-enterprise-contract / lightspeed-console"

repo: openshift/lightspeed-console


text:
[TEST] fix: modify how safetensor file is fetched

Use cp instead of ln -s -> for hermetic from cachi2
Use curl instead of wget -> for non-hermetic

/lgtm

repo: openshift/lightspeed-rag-content


text:
Bug: mysql in tests/e2e is an empty database... no data, no app

Contact Details
whayutin@redhat.com
Describe bug
A bug happened when I ate cereal!  <--- TIGER?
https://github.com/openshift/oadp-operator/blob/master/tests/e2e/sample-applications/mysql-persistent/mysql-persistent-template.yaml
was meant to replace
https://github.com/openshift/oadp-operator/blob/master/tests/e2e/sample-applications/mssql-persistent/mssql-persistent-template.yaml
However... now we just deploy an empty mysql db and backup and restore that?
I think we need an app + data for the full replacement.
What happened?
Nothing.. no data.. :)
OADP Version
1.0.1 (Stable)
OpenShift Version
4.9
Velero pod logs
No response
Restic pod logs
No response
Operator pod logs
No response
New issue

[X] This issue is new

Current setup is empty..
sh-4.4$ mysql --user=root
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 12
Server version: 8.0.26 Source distribution

Copyright (c) 2000, 2021, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| MYSQL_DATABASE     |
| information_schema |
| mysql              |
| performance_schema |
| sys                |
+--------------------+
5 rows in set (0.01 sec)

mysql> use MYSQL_DATABASE;
Database changed
mysql> show tables;
Empty set (0.00 sec)

mysql>

Changing gears on this issue...  mediawiki is not a great sample app.
A more user friendly mariadb / mysql app is a better idea.
I have everything done minus one issue.  See details here:
https://github.com/weshayutin/todolist-mariadb-go/issues/1

We have added data to database in e2e.

source: gharchive/issue

authors: kaovilai weshayutin

repo: openshift/oadp-operator


text:
add ansible logging aggregator

Description of the change:
Adds a sidecar container to Ansible Operator deployments that aggregates the stdout of the ansible logs.
Motivation for the change:
Currently looking at the ansible stdout log (what people are generally accustomed to seeing with Ansible) is a huge pain (you need to exec into a pod, and look at the stdout file in a very specific directory, /tmp/ansible-operator/runner/{group}/{version}/{kind}/{namespace}/{name}/artifacts/{job id}/stdout). This PR allows you to see the aggregated stdout without interfering with the machine readability of the standard operator logs.

https://github.com/operator-framework/operator-sdk/pull/1193

ping @shawn-hurley

repo: openshift/ocp-release-operator-sdk


text:
No odo version verification is done, only information parttern is matched

/kind bug

What versions of software are you using?
Output of odo version:
master
Actual behavior
odo version test spec https://github.com/openshift/odo/blob/master/tests/integration/generic_test.go#L266 only checks the server pattern URL but does not validate the actual server URL and other information too.
Expected behavior
Server URL and other information in odo version string output should be verified with oc version output.
Any logs, error output, etc?
Born from discussion - https://github.com/openshift/odo/issues/3325#issuecomment-643594506

@amitkrout So, for #3325 , The Server URL and other information in odo version string output should be verified with oc version output and oc project output. Is it right?
$ oc version
Client Version: 4.3.18
Server Version: 4.3.22
Kubernetes Version: v1.16.2

$ oc project
Using project "myproject" on server "https://api.ocp43b.rhocp.boe:6443".

$ odo version
odo v1.2.2 (b815649d4)
Server: https://api.ocp43b.rhocp.boe:6443
Kubernetes: v1.16.2

@zhengxiaomei123 yes, I have implemented such a fix since I thought I should walk the walk… 😉

@metacosm Thanks. If so, I will close the pr #3326 .

@zhengxiaomei123 I kept the regexp check because I didn’t want to open a « competing » PR but I believe it’s probably best to remove it. What do you think?

@metacosm The PR has been merged last night, I think you can go ahead after rebasing master .

authors: amitkrout metacosm zhengxiaomei123

repo: openshift/odo


text:
Making devfile package independent of odo with the possible goal of extracting it out as a separate project

Description

Soon other projects like che would start implementing devfile related features. As a community we should reduce the duplication efforts and allow other teams to consume devfile implementation ( adapter and parser ).

User Stories ( pending approval )

Make devfile/parser independent of odo code base
Make devfile/adapters and its coupled packages (clients) independent of odo specific codebase
Extract all the packages which could be used by other project into a separate repo ( pending discussion as this might be conterproductive as well for us )

setup processes to allow faster/cross repo collaberation if we go with separate project

@kadel

Just so its clear to everyone - this is post odo v2 GA release

Thanks for sharing this. I have a couple of comments:

I think that some the controller code is currently being developed here
Why not an operator rather than a library? It would make the contract more straightforward

cc @sleshchenko @davidfestal

Why not an operator rather than a library? It would make the contract more straightforward

The operator may or may not be present in the cluster, dev console & odo would be unable to rely on it.
An operator paradigm typically deploys a "managed" workload, in this case, odo and dev console aren't looking for managed workloads.

I think that some of the controller code is currently being developed here (currently used by the devconsole and che)

Great point, Mario. We should organize and work on this with alignment to ensure:

we design and agree on the API interfaces
we avoid duplication of work :)

Let's use the devfile meeting tomorrow to get an initial working/collaboration style setup?

Why not an operator rather than a library? It would make the contract more straightforward

The operator may or may not be present in the cluster, dev console & odo would be unable to rely on it.
An operator paradigm typically deploys a "managed" workload, in this case, odo and dev console aren't looking for managed workloads - users expect to have control over them.

+1 to what everything that @sbose78  mentioned.
And I would add one more to this the library should be designed in a way that everything operating with devfiles including DevWorkspace operator can use it.

The operator may or may not be present in the cluster, dev console & odo would be unable to rely on it.

I understand your point. But dev console already depends on that operator to run the web terminal (devfile v2 based). Che will do the same. odo will consume the same dependency in a different way. Shouldn't we be consistent instead? How do we make sure that odo / che / dev console use the same version of the controller if we let run multiple instances on the same cluster (one embedded in odo and one embedded in an operator)?

An operator paradigm typically deploys a "managed" workload, in this case, odo and dev console aren't looking for managed workloads - users expect to have control over them.

We want users to have control through a devfile, users should not directly control how a devfile is transformed/reconciled into a pod.

One of the main selling points for odo is that you just download binary, and you are ready to start using it, no setup needed.

Couldn't odo deploy the operator if it's not there?

One of the main selling points for odo is that you just download binary, and you are ready to start using it, no setup needed.

Couldn't odo deploy the operator if it's not there?

No, the biggest reason is that  odo users won't have privileges to deploy operators.
Also, making operator hard requirements for odo would be a big shift in odo philosophy and architecture it would mean a full rewrite.
@gorkem What is your take on this?

No, the biggest reason is that odo users won't have privileges to deploy operators.

You are right. I don't think it's a good idea. But ideally, if the devworkspace operator is running on the cluster, I think odo should be able to leverage it.

Theoretically speaking, the operator could/should use the library this issue is discussing… :)

During our devfile F2F last week, there was a proposal to separate out the devfile package from odo into a separate go library. After a short PoC of separating devfile, we did a demo in today's call of our weekly devfile 2.0 continuation discussion, below are the updates:

About devfile-parser : this library is a golang module that projects could use to generate kubernetes objects equivalent to the guidance in a devfile.
Repo has been moved to devfile organization, which was concluded as the best place for hosting this library - https://github.com/devfile/devfile-parser
Presently the library only separates the parsing and validation code. Work is in progress on moving adapter code to complete separation. Adapter code is responsible for creating kubernetes objects from devfile.
For point 3, there are impending PRs (https://github.com/openshift/odo/pull/3596 and others coming up from @girishramnani team) - regarding refactoring of devfile commands would impact the library.
Temporary slack channel has been setup to facilitate conversations between teams which will be consuming this library. Feel free to join in #tmp-devfile-library.

Next steps are:

Define goals, refactor existing code. Continue discussion on this thread
Setup project governance in  https://github.com/devfile/devfile-parser
Agree on Common library APIs with Console, Che and odo stakeholders.
Enable odo and che workspace controller to consume this library.


text:
make clean and make goget-tools fail on ppc64le after latest changes.

Facing the following errors on ppc64le after pulling the latest changes on master:-
[root@shivani2-6b65-bastion odo]# make clean
go: finding github.com/cznic/zappy v0.0.0-20160723133515-2533cb5b45cc
go: finding github.com/hashicorp/errwrap v1.0.0
go: finding github.com/cznic/internal v0.0.0-20180608152220-f44710a21d00
go: finding github.com/cznic/sortutil v0.0.0-20150617083342-4c7342852e65
go: vbom.ml/util@v0.0.0-20160121211510-db5cfe13f5cc: unrecognized import path "vbom.ml/util" (https fetch: Get https://vbom.ml/util?go-get=1: dial tcp: lookup vbom.ml on 192.168.35.1:53: no such host)
go: vbom.ml/util@v0.0.0-20180919145318-efcd4e0f9787: unrecognized import path "vbom.ml/util" (https fetch: Get https://vbom.ml/util?go-get=1: dial tcp: lookup vbom.ml on 192.168.35.1:53: no such host)
go: finding github.com/edsrzf/mmap-go v0.0.0-20170320065105-0bce6a688712
go: missing Mercurial command. See https://golang.org/s/gogetcmd
go: bitbucket.org/ww/goautoneg@v0.0.0-20120707110453-75cd24fc2f2c: https://api.bitbucket.org/2.0/repositories/ww/goautoneg?fields=scm: 403 Forbidden
go: finding github.com/cznic/b v0.0.0-20180115125044-35e9bbe41f07
go: finding github.com/golang/snappy v0.0.0-20180518054509-2e65f85255db
go: finding github.com/cznic/strutil v0.0.0-20171016134553-529a34b1c186
go: finding github.com/cznic/golex v0.0.0-20170803123110-4ab7c5e190e4
go: finding golang.org/x/sys v0.0.0-20190102155601-82a175fd1598
go: finding golang.org/x/oauth2 v0.0.0-20181106182150-f42d05182288
go: finding google.golang.org/appengine v1.3.0
go: finding github.com/gogo/protobuf v1.2.0
go: finding github.com/gorilla/mux v1.6.2
go: finding golang.org/x/net v0.0.0-20181108082009-03003ca0c849
go: finding github.com/Nvveen/Gotty v0.0.0-20120604004816-cd527374f1e5
go: finding github.com/cznic/fileutil v0.0.0-20180108211300-6a051e75936f
go: finding github.com/cznic/mathutil v0.0.0-20180504122225-ca4c9f2c1369
go: finding github.com/cznic/lldb v1.1.0
go: error loading module requirements

[root@shivani2-6b65-bastion odo]# make goget-tools
go: vbom.ml/util@v0.0.0-20160121211510-db5cfe13f5cc: unrecognized import path "vbom.ml/util" (https fetch: Get https://vbom.ml/util?go-get=1: dial tcp: lookup vbom.ml on 192.168.35.1:53: no such host)
go: finding github.com/evanphx/json-patch v4.1.0+incompatible
go: finding github.com/gophercloud/gophercloud v0.2.0
go: finding github.com/cespare/xxhash v1.1.0
go: finding github.com/robfig/cron v0.0.0-20170526150127-736158dc09e1
go: finding github.com/oklog/ulid v1.3.1
go: finding k8s.io/kube-openapi v0.0.0-20190320154901-5e45bb682580
go: finding golang.org/x/sys v0.0.0-20190606165138-5da285871e9c
go: finding google.golang.org/api v0.3.1
go: finding google.golang.org/genproto v0.0.0-20190404172233-64821d5d2107
go: finding github.com/prometheus/common v0.0.0-20181113130724-41aa239b4cce
go: finding github.com/golang/snappy v0.0.0-20170215233205-553a64147049
go: finding github.com/openshift/origin v0.0.0-20160503220234-8f127d736703
go: finding k8s.io/utils v0.0.0-20190308190857-21c4ce38f2a7
go: finding k8s.io/autoscaler v0.0.0-20190607113959-1b4f1855cb8e
go: finding go.opencensus.io v0.20.1
go: finding github.com/hailocab/go-hostpool v0.0.0-20160125115350-e80d13ce29ed
go: finding k8s.io/klog v0.3.3
go: finding github.com/dgryski/go-sip13 v0.0.0-20181026042036-e10d5fee7954
go: finding golang.org/x/tools v0.0.0-20190606124116-d0a3d012864b
go: finding github.com/onsi/ginkgo v1.7.0
go: finding golang.org/x/crypto v0.0.0-20190605123033-f99c8df09eb5
go: finding gopkg.in/yaml.v2 v2.1.1
go: finding rsc.io/binaryregexp v0.2.0
go: error loading module requirements
# https://go-review.googlesource.com/c/go/+/198438/
GOFLAGS='' go get github.com/onsi/ginkgo/ginkgo@v1.14.0
go: finding github.com/gorilla/mux v1.7.1
go: finding github.com/go-openapi/validate v0.19.2
go: vbom.ml/util@v0.0.0-20180919145318-efcd4e0f9787: unrecognized import path "vbom.ml/util" (https fetch: Get https://vbom.ml/util?go-get=1: dial tcp: lookup vbom.ml on 192.168.35.1:53: no such host)
go: vbom.ml/util@v0.0.0-20160121211510-db5cfe13f5cc: unrecognized import path "vbom.ml/util" (https fetch: Get https://vbom.ml/util?go-get=1: dial tcp: lookup vbom.ml on 192.168.35.1:53: no such host)
go: finding github.com/go-openapi/loads v0.19.2
go: finding github.com/go-openapi/strfmt v0.19.0
go: finding github.com/go-openapi/analysis v0.19.2
go: missing Mercurial command. See https://golang.org/s/gogetcmd
go: bitbucket.org/ww/goautoneg@v0.0.0-20120707110453-75cd24fc2f2c: https://api.bitbucket.org/2.0/repositories/ww/goautoneg?fields=scm: 403 Forbidden
go: finding golang.org/x/tools v0.0.0-20180221164845-07fd8470d635
go: finding google.golang.org/protobuf v1.21.0
go: finding google.golang.org/api v0.3.2
go: finding golang.org/x/tools v0.0.0-20190311215038-5c2858a9cfe5
go: finding golang.org/x/tools v0.0.0-20190617190820-da514acc4774
go: finding golang.org/x/crypto v0.0.0-20190325154230-a5d413f7728c
go: finding golang.org/x/crypto v0.0.0-20190617133340-57b3e21c3d56
go: error loading module requirements
make: *** [Makefile:109: goget-ginkgo] Error 1

/area system-pz

[root@shivani2-6b65-bastion odo]# make goget-tools
go: finding github.com/golang/lint v0.0.0-20180702182130-06c8688daad7
go: vbom.ml/util@v0.0.0-20160121211510-db5cfe13f5cc: unrecognized import path "vbom.ml/util" (https fetch: Get https://vbom.ml/util?go-get=1: dial tcp: lookup vbom.ml on 192.168.35.1:53: no such host)
go: vbom.ml/util@v0.0.0-20180919145318-efcd4e0f9787: unrecognized import path "vbom.ml/util" (https fetch: Get https://vbom.ml/util?go-get=1: dial tcp: lookup vbom.ml on 192.168.35.1:53: no such host)
go: missing Mercurial command. See https://golang.org/s/gogetcmd
go: bitbucket.org/ww/goautoneg@v0.0.0-20120707110453-75cd24fc2f2c: https://api.bitbucket.org/2.0/repositories/ww/goautoneg?fields=scm: 403 Forbidden
go: error loading module requirements
# https://go-review.googlesource.com/c/go/+/198438/
GOFLAGS='' go get github.com/onsi/ginkgo/ginkgo@v1.14.0
go: finding github.com/OneOfOne/xxhash v1.2.2
go: finding github.com/spaolacci/murmur3 v0.0.0-20180118202830-f09979ecbc72
go: finding github.com/mattn/go-isatty v0.0.6
go: finding github.com/golang/protobuf v1.4.0-rc.4.0.20200313231945-b860323f09d0
go: finding github.com/valyala/bytebufferpool v1.0.0
go: vbom.ml/util@v0.0.0-20180919145318-efcd4e0f9787: unrecognized import path "vbom.ml/util" (https fetch: Get https://vbom.ml/util?go-get=1: dial tcp: lookup vbom.ml on 192.168.35.1:53: no such host)
go: vbom.ml/util@v0.0.0-20160121211510-db5cfe13f5cc: unrecognized import path "vbom.ml/util" (https fetch: Get https://vbom.ml/util?go-get=1: dial tcp: lookup vbom.ml on 192.168.35.1:53: no such host)
go: finding github.com/klauspost/compress v1.4.1
go: finding github.com/valyala/fasthttp v1.2.0
go: missing Mercurial command. See https://golang.org/s/gogetcmd
go: bitbucket.org/ww/goautoneg@v0.0.0-20120707110453-75cd24fc2f2c: https://api.bitbucket.org/2.0/repositories/ww/goautoneg?fields=scm: 403 Forbidden
go: finding golang.org/x/sys v0.0.0-20190310054646-10058d7d4faa
go: error loading module requirements
make: *** [Makefile:109: goget-ginkgo] Error 1

[root@shivani2-6b65-bastion odo]# make bin
go: finding github.com/go-toolsmith/astequal v1.0.0
go: finding github.com/go-toolsmith/astequal v0.0.0-20180903214952-dcb477bfacd6
go: finding github.com/go-toolsmith/astcopy v1.0.0
go: finding github.com/go-toolsmith/astp v1.0.0
go: vbom.ml/util@v0.0.0-20180919145318-efcd4e0f9787: unrecognized import path "vbom.ml/util" (https fetch: Get https://vbom.ml/util?go-get=1: dial tcp: lookup vbom.ml on 192.168.35.1:53: no such host)
go: finding github.com/go-toolsmith/astfmt v0.0.0-20180903215011-8f8ee99c3086
go: finding github.com/go-toolsmith/astfmt v1.0.0
go: finding github.com/go-toolsmith/astcast v1.0.0
go: finding github.com/logrusorgru/aurora v0.0.0-20181002194514-a7b3b318ed4e
go: missing Mercurial command. See https://golang.org/s/gogetcmd
go: bitbucket.org/ww/goautoneg@v0.0.0-20120707110453-75cd24fc2f2c: https://api.bitbucket.org/2.0/repositories/ww/goautoneg?fields=scm: 403 Forbidden
go: finding github.com/go-openapi/loads v0.17.0
go: finding golang.org/x/tools v0.0.0-20181117154741-2ddaf7f79a09
go: finding github.com/go-toolsmith/astp v0.0.0-20180903215135-0af7e3c24f30
go: vbom.ml/util@v0.0.0-20160121211510-db5cfe13f5cc: unrecognized import path "vbom.ml/util" (https fetch: Get https://vbom.ml/util?go-get=1: dial tcp: lookup vbom.ml on 192.168.35.1:53: no such host)
go: finding golang.org/x/tools v0.0.0-20190521203540-521d6ed310dd
go: finding github.com/go-toolsmith/typep v1.0.0
go: finding github.com/go-toolsmith/pkgload v0.0.0-20181119091011-e9e65178eee8
go: finding github.com/quasilyte/go-consistent v0.0.0-20190521200055-c6f3937de18c
go: finding github.com/go-toolsmith/strparse v1.0.0
go: finding github.com/mattn/goveralls v0.0.2
go: finding golang.org/x/sys v0.0.0-20190515120540-06a5c4944438
go: finding golang.org/x/crypto v0.0.0-20190621222207-cc06ce4a13d4
go: error loading module requirements
go build -mod=vendor -ldflags="-X github.com/openshift/odo/pkg/version.GITCOMMIT=ebe51e886" cmd/odo/odo.go

[root@shivani2-6b65-bastion odo]# make test
go: vbom.ml/util@v0.0.0-20180919145318-efcd4e0f9787: unrecognized import path "vbom.ml/util" (https fetch: Get https://vbom.ml/util?go-get=1: dial tcp: lookup vbom.ml on 192.168.35.1:53: no such host)
go: vbom.ml/util@v0.0.0-20160121211510-db5cfe13f5cc: unrecognized import path "vbom.ml/util" (https fetch: Get https://vbom.ml/util?go-get=1: dial tcp: lookup vbom.ml on 192.168.35.1:53: no such host)
go: missing Mercurial command. See https://golang.org/s/gogetcmd
go: bitbucket.org/ww/goautoneg@v0.0.0-20120707110453-75cd24fc2f2c: https://api.bitbucket.org/2.0/repositories/ww/goautoneg?fields=scm: 403 Forbidden
go: error loading module requirements
go test  -race
go: finding github.com/prometheus/common v0.4.0
go: finding github.com/prometheus/procfs v0.0.0-20190507164030-5867b95ac084
go: finding github.com/prometheus/tsdb v0.7.1
go: finding github.com/grpc-ecosystem/grpc-gateway v1.6.2
go: vbom.ml/util@v0.0.0-20180919145318-efcd4e0f9787: unrecognized import path "vbom.ml/util" (https fetch: Get https://vbom.ml/util?go-get=1: dial tcp: lookup vbom.ml on 192.168.35.1:53: no such host)
go: vbom.ml/util@v0.0.0-20160121211510-db5cfe13f5cc: unrecognized import path "vbom.ml/util" (https fetch: Get https://vbom.ml/util?go-get=1: dial tcp: lookup vbom.ml on 192.168.35.1:53: no such host)
go: finding git.apache.org/thrift.git v0.12.0
go: missing Mercurial command. See https://golang.org/s/gogetcmd
go: bitbucket.org/ww/goautoneg@v0.0.0-20120707110453-75cd24fc2f2c: https://api.bitbucket.org/2.0/repositories/ww/goautoneg?fields=scm: 403 Forbidden
go: finding github.com/openzipkin/zipkin-go v0.1.3
go: finding honnef.co/go/tools v0.0.0-20180920025451-e3ad64cb4ed3
go: finding google.golang.org/api v0.0.0-20181220000619-583d854617af
go: finding golang.org/x/sys v0.0.0-20181218192612-074acd46bca6
go: finding google.golang.org/genproto v0.0.0-20181219182458-5a97ab628bfb
go: finding golang.org/x/oauth2 v0.0.0-20181203162652-d668ce993890
go: finding golang.org/x/lint v0.0.0-20181217174547-8f45f776aaf1
go: finding golang.org/x/tools v0.0.0-20181219222714-6e267b5cc78e
go: error loading module requirements
make: *** [Makefile:156: test] Error 1
[root@shivani2-6b65-bastion odo]#

Tried with a clean build by cloning latest master afresh on ppc64le and go version go1.13.15 linux/ppc64le.
make goget-tools  and make bin fail as below:-
[root@shivani2-6b65-bastion odo]# make goget-tools
go: inconsistent vendoring in /usr/local/go/src/github.com/openshift/odo:
        go.mod requires github.com/openshift/odo  but vendor/modules.txt does not include it.
        run 'go mod tidy; go mod vendor' to sync
# https://go-review.googlesource.com/c/go/+/198438/
GOFLAGS='' go get github.com/onsi/ginkgo/ginkgo@v1.14.0
go: finding github.com v1.14.0
go: finding github.com/onsi/ginkgo/ginkgo v1.14.0
go: finding github.com/onsi v1.14.0
mkdir -p /root/go/bin
GOFLAGS='' go get github.com/frapposelli/wwhrd@v0.3.0
go: finding github.com v0.3.0
go: finding github.com/frapposelli/wwhrd v0.3.0
go: finding github.com/frapposelli v0.3.0
go: downloading github.com/frapposelli/wwhrd v0.3.0
go: extracting github.com/frapposelli/wwhrd v0.3.0
go: downloading github.com/jessevdk/go-flags v1.4.0
go: downloading gopkg.in/src-d/go-license-detector.v3 v3.0.2
go: downloading github.com/emicklei/dot v0.10.1
go: downloading github.com/cloudfoundry-incubator/candiedyaml v0.0.0-20170223024657-cff29b469e0f
go: extracting github.com/jessevdk/go-flags v1.4.0
go: extracting github.com/cloudfoundry-incubator/candiedyaml v0.0.0-20170223024657-cff29b469e0f
go: extracting github.com/emicklei/dot v0.10.1
go: extracting gopkg.in/src-d/go-license-detector.v3 v3.0.2
go: downloading gopkg.in/src-d/go-billy.v4 v4.3.2
go: downloading gopkg.in/src-d/go-git.v4 v4.13.1
go: downloading golang.org/x/exp v0.0.0-20190510132918-efd6b22b2522
go: downloading github.com/sergi/go-diff v1.0.0
go: extracting gopkg.in/src-d/go-billy.v4 v4.3.2
go: downloading github.com/ekzhu/minhash-lsh v0.0.0-20171225071031-5c06ee8586a1
go: extracting gopkg.in/src-d/go-git.v4 v4.13.1
go: downloading github.com/jdkato/prose v1.1.0
go: downloading github.com/hhatto/gorst v0.0.0-20171128071645-7682c8a25108
go: downloading gonum.org/v1/gonum v0.6.1
go: downloading gopkg.in/src-d/go-billy-siva.v4 v4.3.0
go: downloading github.com/russross/blackfriday/v2 v2.0.1
go: extracting github.com/sergi/go-diff v1.0.0
go: downloading github.com/src-d/gcfg v1.4.0
go: extracting golang.org/x/exp v0.0.0-20190510132918-efd6b22b2522
go: downloading github.com/jbenet/go-context v0.0.0-20150711004518-d14ea06fba99
go: extracting gopkg.in/src-d/go-billy-siva.v4 v4.3.0
go: downloading github.com/xanzy/ssh-agent v0.2.1
go: extracting github.com/ekzhu/minhash-lsh v0.0.0-20171225071031-5c06ee8586a1
go: downloading github.com/emirpasic/gods v1.12.0
go: extracting github.com/russross/blackfriday/v2 v2.0.1
go: downloading github.com/kevinburke/ssh_config v0.0.0-20190725054713-01f96b0aa0cd
go: extracting github.com/hhatto/gorst v0.0.0-20171128071645-7682c8a25108
go: downloading github.com/shurcooL/sanitized_anchor_name v0.0.0-20170918181015-86672fcb3f95
go: extracting github.com/jbenet/go-context v0.0.0-20150711004518-d14ea06fba99
go: extracting github.com/src-d/gcfg v1.4.0
go: downloading gopkg.in/warnings.v0 v0.1.2
go: extracting github.com/emirpasic/gods v1.12.0
go: downloading gopkg.in/src-d/go-siva.v1 v1.5.0
go: extracting github.com/xanzy/ssh-agent v0.2.1
go: extracting github.com/kevinburke/ssh_config v0.0.0-20190725054713-01f96b0aa0cd
go: downloading github.com/mitchellh/go-homedir v1.1.0
go: extracting github.com/shurcooL/sanitized_anchor_name v0.0.0-20170918181015-86672fcb3f95
go: downloading github.com/dgryski/go-minhash v0.0.0-20170608043002-7fe510aff544
go: extracting github.com/jdkato/prose v1.1.0
go: extracting gopkg.in/src-d/go-siva.v1 v1.5.0
go: extracting gonum.org/v1/gonum v0.6.1
go: extracting gopkg.in/warnings.v0 v0.1.2
go: extracting github.com/dgryski/go-minhash v0.0.0-20170608043002-7fe510aff544
go: downloading gopkg.in/neurosnap/sentences.v1 v1.0.6
go: downloading github.com/shogo82148/go-shuffle v0.0.0-20170808115208-59829097ff3b
go: downloading github.com/montanaflynn/stats v0.0.0-20151014174947-eeaced052adb
go: extracting github.com/mitchellh/go-homedir v1.1.0
go: extracting github.com/shogo82148/go-shuffle v0.0.0-20170808115208-59829097ff3b
go: extracting github.com/montanaflynn/stats v0.0.0-20151014174947-eeaced052adb
go: extracting gopkg.in/neurosnap/sentences.v1 v1.0.6
go: finding github.com/emicklei/dot v0.10.1
go: finding github.com/cloudfoundry-incubator/candiedyaml v0.0.0-20170223024657-cff29b469e0f
go: finding github.com/jessevdk/go-flags v1.4.0
go: finding gopkg.in/src-d/go-license-detector.v3 v3.0.2
go: finding gopkg.in/src-d/go-billy-siva.v4 v4.3.0
go: finding gopkg.in/src-d/go-billy.v4 v4.3.2
go: finding github.com/ekzhu/minhash-lsh v0.0.0-20171225071031-5c06ee8586a1
go: finding github.com/jdkato/prose v1.1.0
go: finding gopkg.in/src-d/go-siva.v1 v1.5.0
go: finding gopkg.in/src-d/go-git.v4 v4.13.1
go: finding github.com/dgryski/go-minhash v0.0.0-20170608043002-7fe510aff544
go: finding github.com/montanaflynn/stats v0.0.0-20151014174947-eeaced052adb
go: finding github.com/src-d/gcfg v1.4.0
go: finding github.com/shogo82148/go-shuffle v0.0.0-20170808115208-59829097ff3b
go: finding gopkg.in/warnings.v0 v0.1.2
go: finding gopkg.in/neurosnap/sentences.v1 v1.0.6
go: finding github.com/hhatto/gorst v0.0.0-20171128071645-7682c8a25108
go: finding github.com/emirpasic/gods v1.12.0
go: finding github.com/jbenet/go-context v0.0.0-20150711004518-d14ea06fba99
go: finding github.com/russross/blackfriday/v2 v2.0.1
go: finding gonum.org/v1/gonum v0.6.1
go: finding github.com/kevinburke/ssh_config v0.0.0-20190725054713-01f96b0aa0cd
go: finding github.com/shurcooL/sanitized_anchor_name v0.0.0-20170918181015-86672fcb3f95
go: finding github.com/xanzy/ssh-agent v0.2.1
curl -sfL https://raw.githubusercontent.com/securego/gosec/master/install.sh | sh -s -- -b /root/go/bin v2.4.0
securego/gosec crit platform linux/ppc64le is not supported.  Make sure this script is up-to-date and file request at https://github.com/securego/gosec/issues/new
make: *** [Makefile:102: goget-tools] Error 1
[root@shivani2-6b65-bastion odo]# make bin
go: inconsistent vendoring in /usr/local/go/src/github.com/openshift/odo:
        go.mod requires github.com/openshift/odo  but vendor/modules.txt does not include it.
        run 'go mod tidy; go mod vendor' to sync
go build -mod=vendor -ldflags="-X github.com/openshift/odo/pkg/version.GITCOMMIT=ebe51e886" cmd/odo/odo.go
go: inconsistent vendoring in /usr/local/go/src/github.com/openshift/odo:
        go.mod requires github.com/openshift/odo  but vendor/modules.txt does not include it.
        run 'go mod tidy; go mod vendor' to sync
make: *** [Makefile:49: bin] Error 1
[root@shivani2-6b65-bastion odo]# go version
go version go1.13.15 linux/ppc64le

This error is seen after pulling latest changes after merging PR # https://github.com/openshift/odo/pull/3866

Tried using go1.12.13 - make goget-tools still fails while make bin works on a clean master branch.
[root@shivani2-6b65-bastion /]# go version
go version go1.12.13 linux/ppc64le

[root@shivani2-6b65-bastion openshift]# git clone https://github.com/openshift/odo
Cloning into 'odo'...
remote: Enumerating objects: 61, done.
remote: Counting objects: 100% (61/61), done.
remote: Compressing objects: 100% (58/58), done.
remote: Total 97193 (delta 33), reused 3 (delta 3), pack-reused 97132
Receiving objects: 100% (97193/97193), 133.42 MiB | 11.12 MiB/s, done.
Resolving deltas: 100% (48960/48960), done.

[root@shivani2-6b65-bastion openshift]# cd odo

[root@shivani2-6b65-bastion odo]# make goget-tools
# https://go-review.googlesource.com/c/go/+/198438/
GOFLAGS='' go get github.com/onsi/ginkgo/ginkgo@v1.14.0
go: finding github.com/onsi/ginkgo/ginkgo v1.14.0
mkdir -p /root/go/bin
GOFLAGS='' go get github.com/frapposelli/wwhrd@v0.3.0
curl -sfL https://raw.githubusercontent.com/securego/gosec/master/install.sh | sh -s -- -b /root/go/bin v2.4.0
securego/gosec crit platform linux/ppc64le is not supported.  Make sure this script is up-to-date and file request at https://github.com/securego/gosec/issues/new
make: *** [Makefile:102: goget-tools] Error 1

[root@shivani2-6b65-bastion odo]# make bin
go build -mod=vendor -ldflags="-X github.com/openshift/odo/pkg/version.GITCOMMIT=fc60f6321" cmd/odo/odo.go

cc:- @kadel ^^

Tried changes in this PR https://github.com/openshift/odo/pull/3895
make goget-tools and make bin both work, make test fails as per https://github.com/openshift/odo/issues/3607
[root@shivani2-6b65-bastion odo]# make goget-tools
# https://go-review.googlesource.com/c/go/+/198438/
GOFLAGS='' go get github.com/onsi/ginkgo/ginkgo@v1.14.0
go: finding github.com/onsi/ginkgo/ginkgo v1.14.0
mkdir -p /root/go/bin
GOFLAGS='' go get github.com/frapposelli/wwhrd@v0.3.0
GOFLAGS='' go get github.com/securego/gosec/v2/cmd/gosec@v2.4.0
go: finding github.com/securego/gosec/v2/cmd/gosec v2.4.0
go: finding github.com/securego/gosec/v2/cmd v2.4.0
# It is not recomended to go get golangci-lint https://github.com/golangci/golangci-lint#go
curl -sfL https://raw.githubusercontent.com/golangci/golangci-lint/master/install.sh | sh -s -- -b /root/go/bin v1.30.0
golangci/golangci-lint info checking GitHub for tag 'v1.30.0'
golangci/golangci-lint info found version: 1.30.0 for v1.30.0/linux/ppc64le
golangci/golangci-lint info installed /root/go/bin/golangci-lint
[root@shivani2-6b65-bastion odo]# echo $?
0
[root@shivani2-6b65-bastion odo]# make bin
go build -mod=vendor -ldflags="-X github.com/openshift/odo/pkg/version.GITCOMMIT=fc60f6321" cmd/odo/odo.go
[root@shivani2-6b65-bastion odo]# go version
go version go1.12.13 linux/ppc64le

Using go version go1.13.15 linux/ppc64le, make goget-tools appears to succeed, but make bin fails
[root@shivani2-6b65-bastion odo]# go version
go version go1.13.15 linux/ppc64le
[root@shivani2-6b65-bastion odo]# make goget-tools
go: inconsistent vendoring in /usr/local/go/src/github.com/openshift/odo:
        go.mod requires github.com/openshift/odo  but vendor/modules.txt does not include it.
        run 'go mod tidy; go mod vendor' to sync
# https://go-review.googlesource.com/c/go/+/198438/
GOFLAGS='' go get github.com/onsi/ginkgo/ginkgo@v1.14.0
go: finding github.com/onsi/ginkgo/ginkgo v1.14.0
go: finding github.com/onsi v1.14.0
go: finding github.com v1.14.0
mkdir -p /root/go/bin
GOFLAGS='' go get github.com/frapposelli/wwhrd@v0.3.0
go: finding github.com v0.3.0
go: finding github.com/frapposelli v0.3.0
GOFLAGS='' go get github.com/securego/gosec/v2/cmd/gosec@v2.4.0
go: finding github.com v2.4.0
go: finding github.com/securego/gosec/v2/cmd/gosec v2.4.0
go: finding github.com/securego/gosec/v2/cmd v2.4.0
go: finding github.com/securego/gosec v2.4.0
go: finding github.com/securego v2.4.0
# It is not recomended to go get golangci-lint https://github.com/golangci/golangci-lint#go
curl -sfL https://raw.githubusercontent.com/golangci/golangci-lint/master/install.sh | sh -s -- -b /root/go/bin v1.30.0
golangci/golangci-lint info checking GitHub for tag 'v1.30.0'
golangci/golangci-lint info found version: 1.30.0 for v1.30.0/linux/ppc64le
golangci/golangci-lint info installed /root/go/bin/golangci-lint
[root@shivani2-6b65-bastion odo]# echo $?
0
[root@shivani2-6b65-bastion odo]# make bin
go: inconsistent vendoring in /usr/local/go/src/github.com/openshift/odo:
        go.mod requires github.com/openshift/odo  but vendor/modules.txt does not include it.
        run 'go mod tidy; go mod vendor' to sync
go build -mod=vendor -ldflags="-X github.com/openshift/odo/pkg/version.GITCOMMIT=fc60f6321" cmd/odo/odo.go
go: inconsistent vendoring in /usr/local/go/src/github.com/openshift/odo:
        go.mod requires github.com/openshift/odo  but vendor/modules.txt does not include it.
        run 'go mod tidy; go mod vendor' to sync
make: *** [Makefile:49: bin] Error 1
[root@shivani2-6b65-bastion odo]#

Tried the command go mod tidy; go mod vendor, no success.
As per @kadel "hmm, this is strange. it should not happen. we are not seeing this in any other systems I'm in middle of something. I'll check this later"

/reopen

Using go version go1.13.15 linux/ppc64le, with latest master, make goget-tools appears to succeed, but make bin still fails on ppc64le:
[root@shivani2-6b65-bastion odo]# make clean
go: inconsistent vendoring in /usr/local/go/src/github.com/openshift/odo:
        go.mod requires github.com/openshift/odo  but vendor/modules.txt does not include it.
        run 'go mod tidy; go mod vendor' to sync
[root@shivani2-6b65-bastion odo]# echo $?
0
[root@shivani2-6b65-bastion odo]#
[root@shivani2-6b65-bastion odo]#
[root@shivani2-6b65-bastion odo]# make goget-tools
go: inconsistent vendoring in /usr/local/go/src/github.com/openshift/odo:
        go.mod requires github.com/openshift/odo  but vendor/modules.txt does not include it.
        run 'go mod tidy; go mod vendor' to sync
# https://go-review.googlesource.com/c/go/+/198438/
GOFLAGS='' go get github.com/onsi/ginkgo/ginkgo@v1.14.0
go: finding github.com v1.14.0
go: finding github.com/onsi/ginkgo/ginkgo v1.14.0
go: finding github.com/onsi v1.14.0
mkdir -p /root/go/bin
GOFLAGS='' go get github.com/frapposelli/wwhrd@v0.3.0
GOFLAGS='' go get github.com/securego/gosec/v2/cmd/gosec@v2.4.0
go: finding github.com v2.4.0
go: finding github.com/securego/gosec/v2/cmd v2.4.0
go: finding github.com/securego/gosec/v2/cmd/gosec v2.4.0
go: finding github.com/securego v2.4.0
go: finding github.com/securego/gosec v2.4.0
# It is not recomended to go get golangci-lint https://github.com/golangci/golangci-lint#go
curl -sfL https://raw.githubusercontent.com/golangci/golangci-lint/master/install.sh | sh -s -- -b /root/go/bin v1.30.0
golangci/golangci-lint info checking GitHub for tag 'v1.30.0'
golangci/golangci-lint info found version: 1.30.0 for v1.30.0/linux/ppc64le
golangci/golangci-lint info installed /root/go/bin/golangci-lint
[root@shivani2-6b65-bastion odo]# echo $?
0
[root@shivani2-6b65-bastion odo]#
[root@shivani2-6b65-bastion odo]#
[root@shivani2-6b65-bastion odo]# make bin
go: inconsistent vendoring in /usr/local/go/src/github.com/openshift/odo:
        go.mod requires github.com/openshift/odo  but vendor/modules.txt does not include it.
        run 'go mod tidy; go mod vendor' to sync
go build -mod=vendor -ldflags="-X github.com/openshift/odo/pkg/version.GITCOMMIT=56c69f66b" cmd/odo/odo.go
go: inconsistent vendoring in /usr/local/go/src/github.com/openshift/odo:
        go.mod requires github.com/openshift/odo  but vendor/modules.txt does not include it.
        run 'go mod tidy; go mod vendor' to sync
make: *** [Makefile:49: bin] Error 1
[root@shivani2-6b65-bastion odo]# echo $?
2
[root@shivani2-6b65-bastion odo]#

@kadel please have a look.

Any updates on this one? Currently building odo on Power using go version go1.12.13 linux/ppc64le
This is blocking any further progress for ODO on PowerPC using go version go1.13.15 linux/ppc64le

Figured out both go versions - 1.12.x(previously used for odo on ppc64le) and 1.13.x(used by x86/Z including in travis jobs) have issues when used for odo on Power. After trying out a few versions, latest go version 1.15.2 works well with odo on Power and no make related issues are seen. Closing this issue for now.


text:
Fixes hardcoded directory strings with env variables

What type of PR is this?
/kind code-refactoring
What does does this PR do / why we need it:
Some of the hardcoded strings are removed from cmd_push_test.go file and replaced with env variables.
Which issue(s) this PR fixes:
Fixes #2639
How to test changes / Special notes to the reviewer:

make test-cmd-push should pass

@amitkrout done

@amitkrout done

/lgtm

/approve

authors: amitkrout girishramnani mik-dass


text:
[4.7] libct/cg/sd: reconnect and retry on dbus connection error

This is a backport of upstream PR https://github.com/opencontainers/runc/pull/2923 to release-4.7 branch, to be consumed by cri-o 1.20 in order to fix https://bugzilla.redhat.com/show_bug.cgi?id=1941456.
This also includes backports of

https://github.com/opencontainers/runc/pull/2614/commits/38447895a54daf52e9ec7670401554ae921a96b3 (PR https://github.com/opencontainers/runc/pull/2614)
https://github.com/opencontainers/runc/pull/2727/commits/eee425f5a0b4e10f58bf4058e97a6c570583869a (PR https://github.com/opencontainers/runc/pull/2727, first commit only)
mostly to make the merge simpler.

Original description follows

n case the dbus daemon is ever restarted, the connection is no longer valid and every operation
fails. This is a minor concern for short-lived runc, but much more of a issue in case there is
a long-running daemon (e.g. cri-o) is using runc's libcontainer, as the connection is never
retried and the only remedy is to restart the daemon.
The solution to the above is to check the errors returned for dbus: connection closed by user
error, and try to re-connect on that. This is what PR #2862 does.
This is a carry of #2862, implementing the idea of retry-in-place (first described
at https://github.com/opencontainers/runc/pull/2862#discussion_r600977482 and https://github.com/opencontainers/runc/pull/2862#discussion_r600975567) on top of what it does.
For more info, see commit messages as well as #2862.
Fixes:

https://github.com/kubernetes/kubernetes/issues/100328
https://bugzilla.redhat.com/show_bug.cgi?id=1941456
https://bugzilla.redhat.com/show_bug.cgi?id=1634092

/bugzilla refresh

This also needs https://github.com/opencontainers/runc/pull/2936 / https://github.com/opencontainers/runc/pull/2937 backported.

Added a backport of https://github.com/opencontainers/runc/pull/2937 (modulo test)

This also needs https://github.com/opencontainers/runc/pull/2997

repo: openshift/opencontainers-runc


text:
Added work break to fix overflowing username and project name

Added word-break class to fix overflow issue with username and project name. This would close #388

@rhamilto @spadgett

@jeff-phillips-18

Not sure why my dist/origin-web-catalogs.js is different from master? @spadgett @jeff-phillips-18

@amarie401 You probably need to rebase, hack/install-deps.sh, grunt build and push.

The file conflict has been resolved.

@dtaylor113 we should only be merging blocker bugs at this point in the sprint

@dtaylor113 we should only be merging blocker bugs at this point in the sprint

Yes, sorry :-(

repo: openshift/origin-web-catalog


text:
Use AWS_REGION instead of AWS_DEFAULT_REGION

AWS_DEFAULT_REGION is specific to cli configuration, whereas
AWS_REGION is SDK compatible and takes precedent. Given the verifier
utilizes the SDK, AWS_REGION should be used.
Ref: https://issues.redhat.com/browse/OSD-11348

/lgtm

authors: fahlmant ritmun

repo: openshift/osd-network-verifier


text:
MVP smart network-verifier

Summary of the New Goals

"Just" specify --cluster-id, no seriously, that's it. The tooling should do all the rest and return errors and guidance when it can't. This was recently enabled with https://github.com/openshift/osd-network-verifier/pull/161
Also documentation and some testing :P

A picture (or maybe just more words?) is worth a thousand words, so here's an example of a cluster with a transparent cluster-wide proxy (e.g. no additional trust bundle). I've redacted IDs, but notice how with only specifying the ID, we get a correctly selected private subnet, the master node's security group, and HttpProxy and HttpsProxy automatically populated.
❯ osdctl network verify-egress --cluster-id REDACTED
2022/12/10 22:17:34 getting AWS credentials from backplane-api
2022/12/10 22:17:37 detected BYOVPC PrivateLink cluster, using first subnet from OCM: subnet-REDACTED
2022/12/10 22:17:37 searching for security group by tags: kubernetes.io/cluster/REDACTED=owned and Name=REDACTED-master-sg
2022/12/10 22:17:38 using security-group-id: sg-REDACTED
2022/12/10 22:17:38 running with config: &{Timeout:2s Ctx:context.TODO SubnetID:subnet-REDACTED CloudImageID:ami-0af4bdc3e6f25374f InstanceType:t3.micro Proxy:{HttpProxy:http://REDACTED:8080 HttpsProxy:http://REDACTED:8080 Cacert: NoTls:false} Tags:map[Name:osd-network-verifier osd-network-verifier:owned red-hat-managed:true] AWS:{KmsKeyID: SecurityGroupId:sg-REDACTED} GCP:{Region: Zone: ProjectID: VpcName:}}
2022/12/10 22:17:40 Created instance with ID: i-0f3d75c4f874eca93
Summary:
printing out failures:
...
 -  egressURL error: Unable to reach REDACTED
...

and here's an example of a cluster-wide-proxy with an additional trust bundle, stopping SREs from mistakenly getting incorrect results:
❯ ~/git/openshift/osdctl/osdctl network verify-egress --cluster-id REDACTED
2022/12/10 22:29:12 getting AWS credentials from backplane-api
2022/12/10 22:29:13 REDACTED has an additional trust bundle configured, but no --cacert supplied

How it Works

Expects an active ocm-backplane tunnel
Uses the provided OCM internal/external cluster id or cluster name to look up the cluster in OCM, which importantly provides insight into its InfraId, region, and whether it has a cluster-wide-proxy
Retrieves AWS credentials from backplane-api and assembles then in-memory with no need for any local AWS profile or environment variables exported.
Searches AWS for the clusters private subnets and the master node's security group.
Assembles input to osd-network-verifier with all that info, failing if, for example, there's a cluster-wide proxy with a custom trust bundle, but the SRE didn't supply --cacert
???
Profit

Removals
These are options exposed generally exposed by osd-network-verifier, but in general shouldn't be used by SREs when investigating and should be reserved for osd-network-verifier directly.

--image-id
--instance-type
--cloud-tags
--timeout
--kms-key-id - The support role doesn't have permissions to BYOKMS cluster KMS keys anyway
--profile - No longer does anything, we're passing an AWS Config to osd-network-verifier now instead of a profile
--subnet-id and --security-group are no longer required flags

But does this still work if there's a backplane-api or OCM outage?

Yes and no.

Yes - the previous workflow of configuring AWS credentials locally on your own first (e.g. exporting AWS_* variables or using aws configure) still works. SREs would just need to manually specify all the flags again, --subnet-id, --security-group, --https-proxy, etc.
No - the --cluster-id flag wouldn't work.

Limitations and Future Improvement

I didn't write logic for intelligently selecting private subnets from non-PrivateLink BYOVPC clusters. It's possible and can be added in the near future (e.g. subnets with routes to an IGW == public subnet, so skip those), but for now I just return a message that says to find and specify a --subnet-id on your own. Otherwise, this tool should do the right thing.
It doesn't test all of the private subnets for multi-AZ clusters, only one.
It doesn't test egress with the worker node security group, just the master.

In general networking tends to be messed up at the VPC level and not a specific subnet or security group, but if there's enough value seen, this could easily be extended to fire off runs to test all subnets and at least one subnet with both security groups to cover all the cases.

/lgtm
Last open thread is just a non blocking thought.

/lgtm

/lgtm
This is AMAZING, well done!

A few things:

Was there an OSD card tracking this? This is quite a large change but I don't see it attached to a specific prioritized card or shift-improvement card.
This pins osdctl to not used a tagged version of the verifier code. The intention of using the tag is to make sure the cli stays in line with the official releases of the verifier. It was also intentional that cluster service and osdctl were pinned to the same version, now there's a divergence between the two and could lead to different results.
I'm not a fan of removing all the options from this command. osdctl is intended to be the SRE interface into using the osd-network-verifier in any way. Removing the configuration options for a manual run is a regression of intended feature set for this command and locks SRE into only one way to debug things.
Using "not recommended" language in the README gives a negative connotation, but running manually on a VPC is not a bad thing. It sometimes may be necessary or can just be a good exercise to understand how the verifier runs, and how a VPC can be tested.
Locking this to only the backplane credential method can be tenuous if the backplane api is down or not working. At least enabling the alternative method through public OCM endpoints that osdctl account cli/console should be added, but a subsequent PR is fine in this case.

Was there an OSD card tracking this? This is quite a large change but I don't see it attached to a specific prioritized feature card or shift-improvement card.

Yeah, sorry didn't link it in this PR. It was the same Epic for the new AWS credential interface for osd-network-verifier: OSD-14120

This pins osdctl to not used a tagged version of the verifier code. The intention of using the tag is to make sure the cli stays in line with the official releases of the verifier. It was also intentional that cluster service and osdctl were pinned to the same version, now there's a divergence between the two and could lead to different results.

Can we cut a release then? I don't agree that CS and osdctl need to be pinned to the same version. It should be the responsibility of osd-network-verifier to function correctly and for CS and osdctl to upgrade their dependencies independently. If there's a bug in osd-network-verifier then I agree both should upgrade past the bugfix...

I'm not a fan of removing all the options from this command. osdctl is intended to be the SRE interface into using the osd-network-verifier in any way. Removing the configuration options for a manual run is a regression of intended feature set for this command and locks SRE into only one way to debug things.

Depends on what "any way" means haha
osd-network-verifier CLI exists, my goal is for osdctl to do more heavy-lifting for SREs. If an SRE wants to be able to configure every option for osd-network-verifier imo that CLI is the perfect tool for the job, whereas osdctl should give SREs the correct response for production clusters as easily as possible. For example, if an SRE is running this against a BYOKMS cluster and tries to optionally specify a kms-key-arn and it fails - how do we communicate this is expected? Compared to an SRE going out of their way to do this via osd-network-verifier. Similar for choosing an incorrect instance type that doesn't support Nitro...or setting timeout...

Using "not recommended" language in the README/docs gives a negative connotation, but running manually on a VPC is not a bad thing. It sometimes may be necessary or can just be a good exercise to understand how the verifier runs, and how a VPC can be tested.

It's not a bad thing, but it is "not recommended" when running this against real clusters registered in OCM. Related to my previous response, but imo these kinds of exercises/learnings are a better fit for osd-network-verifier and not osdctl, which SREs use when responding to production alerts.

Locking this to only the backplane credential method can be tenuous if the backplane api is down or not working. At least enabling the alternative method through public OCM endpoints that osdctl account cli/console should be added, but a subsequent PR is fine in this case.

It's not locked in - it still works if you setup AWS creds beforehand and manually specify a subnet/security group ID

Thanks for the card!
We can cut a new version, just need to ask the verifier repo maintainers and have a justification. There's a process that needs to be ran for this.
The osd-network-verifier binary is mostly an example for how to integrate with the verifier library, and those cli commands will likely be removed. osdctl is meant to be the SRE interface for running verifier tests. Sorry if that wasn't clear, the work should be tracked in our epics and we can cut some new cards if its not.
I would just ask that the doc reflect that its not recommended for that specific flow. Its minor, but I think having positive language ("This is the recommended path") vs. negative ("this is not the recommended path") is better overall, but that's just my preference.
You're right, there are multiple ways, all I'm requesting is that the other flow is supported too.

Wrote up https://issues.redhat.com/browse/OSD-14257 to add back all the optional inputs for osd-network-verifier
I'll make a future PR to update the wording as I don't think I need a card for that and just reference the epic.

authors: clcollins fahlmant mjlshen typeid

repo: openshift/osdctl


text:
add cmd impl of change-advisory-status

add cmd implementation of change-advisory-status

command help

oar -r 4.12.19 change-advisory-status -h
Usage: oar change-advisory-status [OPTIONS]

  Change advisory status e.g. QE, REL_PREP

Options:
  -s, --status TEXT  Valid advisory status, default is REL_PREP
  -h, --help         Show this message and exit.

command usage

oar -r 4.12.19 change-advisory-status -s REL_PREP

/assign @kuiwang02 @wewang58 @jianzhangbjz @Xia-Zhao-rh

/retitle OCPQE-17509 add cmd impl of change-advisory-status

repo: openshift/release-tests


text:
Release v1.0.2

addons: Error when editing non-editable parameters
describe: Remove instance type
logs: Display logs when cluster is in error state
errors: Display legal terms URL
logs: Filter out misleading output
delete: Fix example command
describe: Fix command help example
aws: Add helpful error message when using STS credentials
logs: Redact KUBECONFIG line

/lgtm

repo: openshift/rosa


text:
Strip any additional ror pkgs

@bparees got rid also of the RAILS_ENV envar, which we might want to add to the rails-ex json ?

yeah that's a good idea.
thanks for cleaning this up @jhadvig, let's merge it once the dust settles on 3.0.1.

Here is the PR for the rails-ex https://github.com/openshift/rails-ex/pull/35

LGTM (@jhadvig explained me that we are doing this to keep the ruby image clean and prepare some space for ror image in future)

authors: bparees jhadvig mfojtik

repo: openshift/sti-ruby

license_source: bigquery


text:
Implement a CDM client class (cdm_cli)

Adds:

The OSD CDM client class.
The documentation covering the functionality of Core Debug Module client class
Unit tests for CDM client class.

A rough implementation layout of CDM and its client class:

A state machine (similar to one in osd_regaccess) to enable read/write register access between module and CPU core.

To provide this functionality, nothing specific is added to the API since it will be covered by osd_regaccess

Event signaling through debug packet (using debug_packetisation.sv)

General functions (similar to other module client classes) are added to support this attribute.

Please provide your feedback and suggest edits, if any.
Closes #16

@imphil Thanks a lot for the review. The latest commit incorporates most of the changes.
I haven't added the unit tests to check cpu_reg_write/read functions. The current unit test implementation supports only 16 bit wide registers. Following programs need to be changed to support register-width other than 16 bits.

mock_hostmod.c
mock_hostmod.h
mock_host_controller.c
mock_host_controller.h
check_hostctrl.c
check_hostmod.c
Should I go ahead and make those changes?

Should I go ahead and make those changes?

Do whatever changes are necessary. The list of changes sounds a bit excessive, but without seeing the code it's hard to judge.

Okay. Also, please check the current implementation of cpu_reg_read/write functions.

Please ensure a high test coverage before submitting this for review the next time. The implementation as-is cannot work and it's much faster for you to find out this by yourself by creating a test for it.

Please check this line in hostmod.c
Does that mean we need to do some changes to support registers with width other 16 bits?

Please take a look at the below implementation whenever you get some time. I am currently working at the test units.
osd_result cl_cdm_cpureg_read(struct osd_hostmod_ctx *hostmod_ctx,
                              struct osd_cdm_desc *cdm_desc,
                              void *reg_val, uint16_t reg_addr,
                              int flags)
 {

    assert(hostmod_ctx);
    assert(cdm_desc);`

    osd_result rv;

    uint16_t cdm_di_addr = cdm_desc->di_addr;

    uint16_t reg_addr_upper = reg_addr >> 15;
    uint16_t core_upper = cdm_desc->core_reg_upper;

    if (core_upper != reg_addr_upper) {

    rv = osd_hostmod_reg_write(hostmod_ctx, &reg_addr_upper, cdm_di_addr,
                              OSD_REG_CDM_CORE_REG_UPPER, 16, 0);

    if (OSD_FAILED(rv)) return rv;
    cdm_desc->core_reg_upper = reg_addr_upper;

    }

    uint16_t cdm_reg_addr = 0x8000 + (reg_addr & 0x7FFF);
    uint16_t core_dw = cdm_desc->core_data_width;
    rv = osd_hostmod_reg_read(hostmod_ctx, reg_val, cdm_di_addr,
                                    cdm_reg_addr, core_dw,
                                    flags);
    if (OSD_FAILED(rv)) return rv;

    return OSD_OK;

}

Before I take a look please run clang-lint and fix the code formatting. I've seen at least once tabs being used.

@imphil I have fixed the code formatting and also added two test cases to check cpu_reg_read/write functions. Both are working fine.
Please suggest changes, if any. Thanks!!

I have added test cases for 16 bit and 64 bit CPU cores. All the test cases are working fine.
I have also fixed almost every possible formatting error. Please take a look whenever you get sometime.

Squashed and merged through 59de556. Thanks Shivam for your work on this, it's taken a quite nice form now. Before merging I did some minor cleanups, such as renaming the STALL_BIT to follow the conventions we have for other bits.

authors: imphil shivmgg

repo: opensocdebug/osd-sw


text:
🛑 Weblate is down

In 2f4851a, Weblate (https://translate.opensourcepos.org) was down:

HTTP code: 500
Response time: 1430 ms

Resolved: Weblate is back up in abdadc8 after 12 minutes.

repo: opensourcepos/upptime

license: MIT


text:
🛑 Demo is down

In 38c3114, Demo (https://demo.opensourcepos.org) was down:

HTTP code: 500
Response time: 13511 ms

Resolved: Demo is back up in b64775f.


text:
Setup

The data load UI for OpenSpending is largely a client-side affair, at least in the first iteration.
So, we will be using the majority of the dependencies that have have in DataPackagist, as behind the scenes the requirements and data flows are the same, even if the UI is very different.
Even though it is a client-side app, we are going to host it in a small server for convenience of routing, etc., and for this we will use Express.js on top of io.js. We are using io.js instead of node.js because of support for Zombie.js, which helps with fast functional testing (Example from DataPackgist).
Tasks

[x] Setup Express and Gulp as per DataPackagist config
[x] Setup all the base dependencies
[x] Code management:

Copy current master branch to "upload-old" branch
Start new develop branch with clean slate (no history)
Make develop the default branch
Remove master branch and start again, or, clear master branch

[x] Setup a dedicated route for the landing page
[x] Setup a dedicated route for hosting the actual dataload app
[x] Write a a few small tests to show we are setup correctly

[ ] install linter, remove rule that forces to use single char vars in lambdas

Introduced new npm command which throws messages in stderr in case of js linting errors
npm run lint_js

From now on there is nothing in os-upload/dist/ dir what cannot be safely removed.

FIXED.

authors: gvidon pwalsh

repo: openspending/os-upload


text:
Push uploaded files directly to s3 rather than

As part of spike we are not doing the "s3" post route yet. We want to do this. issues will be:

We need to validate the file before upload (so need to pull some of the file in to validate it) - cf #3
We would like to show file upload progress (and perhaps support uploading multiple files at once (???)

I'm closing old issues.

authors: pwalsh rgrp


text:
Fix main content padding on various screens

Describe the feature request.
Update the implementation for the register, profile and reporting screens to use the padding requirements set out on this issue #2887
Acceptance criteria

[x] The bottom padding for the various screens should match the updated designs listed on this issue

Area path
A list of ordered steps in the app on usage of the feature to support anyone testing it e.g. Code reviewer, QA e.g.

Login to the app
Open Navigation bar
Click on Children register
Click on Child profile
Click on Edit profile from menu

Implementation plan (For Engineers)

[x] Set bottom padding for list (LazyColumn) used to render views in profile and measure report screens, as well as the row in the register footer to 80.dp if fab configuration exists in profile / register configuration otherwise default to 32.dp
[x] The UI to be updated are in MeasureReportListScreen, ProfileScreen and the RegisterFooter composable screens

Re-opening this issue to create a PR of the same pointing to 0.2.5

authors: Rkareko ageryck

repo: opensrp/fhircore


text:
BN_rand_range behavior for secure pooled BIGNUM

Is it normal that BN_rand_range(), when called for BIGNUM created from secure pool, unconditionally uses OPENSSL_malloc() (in bnrand()) to allocate short-lived temporary buf for random data?
I think it would be more logical to use OPENSSL_secure_malloc() for that case.

Marking as inactive to be closed at the end of 3.4 dev, barring further input

authors: nhorman vt-alt

repo: openssl/openssl