Bug 1643303
| Summary: | Provisioning two APB services temporarily broke networking in the namespace | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Jesus M. Rodriguez <jesusr> |
| Component: | Service Broker | Assignee: | Jesus M. Rodriguez <jesusr> |
| Status: | CLOSED ERRATA | QA Contact: | Zhang Cheng <chezhang> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 3.9.0 | CC: | aos-bugs, chezhang, chuo, dcaldwel, jdesousa, jiazha, jmatthew, shurley, trankin |
| Target Milestone: | --- | ||
| Target Release: | 4.2.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: |
Cause: The Automation Broker always created a network policy to give the transient namespace access to the target namespace.
Consequence: Adding a network policy to a namespace that does not have any other network policies in place causes the namespace to be locked down to the newly created policy. Before the network policy, everything was open and namespaces could communicate with each other.
Fix: The Automation Broker looks to see if there are any network policies in place for the target namespace. If there are none, the broker will not create a new network policy. The broker will assume that things are open enough to allow the transient namespace we create to communicate with the target namespace.
The broker will still create a network policy giving the transient namespace access to the target namespace, if there are other network policies in place for the target namespace.
Result: The fix allows the broker to perform the APB actions without affecting existing services running on the target namespace.
|
Story Points: | --- |
| Clone Of: | 1613280 | Environment: | |
| Last Closed: | 2019-10-16 06:27:40 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1613280 | ||
| Bug Blocks: | 1643300, 1643301 | ||
|
Comment 2
Zihan Tang
2018-12-04 09:15:47 UTC
Fixed by PR https://github.com/openshift/ansible-service-broker/pull/1177 for OpenShift 3.9 (Broker 1.1.19+) * OpenShift 4.0 (Broker 1.4.x) Fixed by broker PR https://github.com/openshift/ansible-service-broker/pull/1180 and by bundle-lib PR https://github.com/automationbroker/bundle-lib/pull/178 * OpenShift 3.11 (Broker 1.3.x) Fixed by broker PR https://github.com/openshift/ansible-service-broker/pull/1181 and by bundle-lib PR https://github.com/automationbroker/bundle-lib/pull/178 * OpenShift 3.10 (Broker 1.2.x) Fixed by broker PR https://github.com/openshift/ansible-service-broker/pull/1185 and by bundle-lib PR https://github.com/automationbroker/bundle-lib/pull/180 PR is merged in v1.4.5. the lastest image in downstream is still 1.4.4. Move to Modified. docker run --entrypoint=asbd reg-aws..../ose-ansible-service-broker:v4.0 --version 1.4.4 According to #comment 10, Move back to modified. The target release is 4.2, but there's not ose-ansible-service-broker v4.2 image in brew registry.
when using: oc image info ..../openshift/ose-ansible-service-broker:v4.1 --insecure=true,
no commit info for asb
do we still using `asbd --version` to trace code change in asb image?
asb operator image code change can be traced by `oc image info` like:
$ oc image info .../openshift/ose-ansible-service-broker-operator:v4.1 --insecure=true | grep commit
io.openshift.build.commit.id=156c29309ae3951ed11d60e13616de49537ee5b8
io.openshift.build.commit.url=https://github.com/openshift/ansible-service-broker/commit/156c29309ae3951ed11d60e13616de49537ee5b8
I believe this is the build that you are looking for: https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=917197 Verified: ose-ansible-service-broker:v4.2.0-201906240232 asb version:1.4.5 when provision and deprovision, no new networkpolicy created, and no errors when no networkpolicy to delete. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:2922 |