Bug 1643300
| 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: | Zihan Tang <zitang> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 3.10.0 | CC: | aos-bugs, chezhang, chuo, dcaldwel, jdesousa, jiazha, jmatthew, zitang |
| Target Milestone: | --- | ||
| Target Release: | 3.10.z | ||
| 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: | 2018-12-13 17:09:08 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, 1643301, 1643303 | ||
| Bug Blocks: | |||
|
Comment 5
Zihan Tang
2018-11-28 08:45:55 UTC
In openshift v3.10.72
network: redhat/openshift-ovs-subnet
and asb 1.2.17, I haven't reproduced it.
When provision and deprovision, it will create a new networkpolicy like:
apiVersion: v1
items:
- apiVersion: extensions/v1beta1
kind: NetworkPolicy
metadata:
creationTimestamp: 2018-11-28T09:01:56Z
generation: 1
name: apb-f633bb21-2dfb-4864-9bbc-d78c4b287365
namespace: debug
resourceVersion: "27184"
selfLink: /apis/extensions/v1beta1/namespaces/debug/networkpolicies/apb-f633bb21-2dfb-4864-9bbc-d78c4b287365
uid: 419f9c30-f2ec-11e8-bd61-fa163eb79193
spec:
ingress:
- from:
- namespaceSelector:
matchLabels:
apb-pod-name: apb-f633bb21-2dfb-4864-9bbc-d78c4b287365
podSelector: {}
policyTypes:
- Ingress
kind: List
metadata:
resourceVersion: ""
selfLink: ""
But in my env, during the networkpolicy exist, the 2 pod in the namespace can still connect to each other which checking by curl command. Steps are the same with the below verified steps.
In asb 1.2.21,
during provision and deprovision , it will not create new networkpolicy, and pods in the namespace can connect to each other, mark the issue as VERIFIED.
steps:
1. provision mediawiki-apb in project test.
2. start a test pod to check network:
# oc run debug -it --rm --image rhel7 --restart=Never --command -- bash
$ curl mediawiki-efac1a5f-f2de-11e8-876c-0a580a800005:8080 -vvv
3. provision postgresql-apb in this project
4. during provision, check networkpolicy and mediawiki pod's reponse in another shell.
# oc get networkpolicy
$ curl mediawiki-efac1a5f-f2de-11e8-876c-0a580a800005:8080 -vvv
# oc logs -f dc/asb -n openshift-ansible-service-broker
time="2018-11-28T09:39:53Z" level=info msg="No network policies found. Assuming things are open, skip network policy creation"
result:
1. no new networkpolicy created
2. mediawiki pod still response to other pods.
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-2018:3750 |