Contiv on Openshift

[Mikey032]

Description

It isn't possible at the moment to deploy Contiv on Openshift 3.11. Currently someone readded Contiv on the 3.11 branch but it doesn't seem to work out very well. (openshift/openshift-ansible#10788)

Expected Behavior

Contiv installation completes successful on Openshift 3.11.

Observed Behavior

We are using the contiv bridge mode with vlan encapsulation and ovs. The ovs is installed from an Openstack repo where the installation of ovs itself fails with dependency and permission errors. By using the official Centos ovs package, the ovs service starts successfully. The next problem is the etcd proxy that receives TLS errors when using the use_contiv_etcd=False option. When not using the option the Contiv etcd server is in a crashloop.

Something else that is weird is by specifying contiv_private_ext_subnet it only wants a /16 subnet. What is the reason for this?

Steps to Reproduce (for bugs)

1. Install Ansible and clone the repo https://github.com/amon-ra/openshift-ansible/tree/oondeo-3.11
2. edit the hosts file with adding: openshift_additional_repos=[{'id': 'centos-okd-ci', 'name': 'centos-okd-ci', 'baseurl' :'http://buildlogs.centos.org/centos/7/paas/x86_64/openshift-origin311/', 'gpgcheck' :'0', 'enabled' :'1'}]
3. edit the Contiv role so the ovs package is installed from the official Centos repo
4. run the playbook

Your Environment

• netctl version 1.2.0 (-> 1.2.1 doesn't come with netctl cli)
• Orchestrator version (e.g. kubernetes, mesos, swarm): Openshift 3.11
• Operating System and version: Centos 7.6

[srampal]

FYI Contiv support with Openshift has not been actively maintained since about Openshift 3.7 so it’s likely not working for recent releases. For the etcd error, your quickest route may be to pursue the use_contiv_etcd=false option and triage the TLS errors. On Dec 12, 2018, at 4:16 AM, MikeySmet <notifications@github.com<mailto:notifications@github.com>> wrote: Description It isn't possible at the moment to deploy Contiv on Openshift 3.11. Currently someone readded Contiv on the 3.11 branch but it doesn't seem to work out very well. (openshift/openshift-ansible#10788<openshift/openshift-ansible#10788>) Expected Behavior Contiv installation completes successful on Openshift 3.11. Observed Behavior We are using the contiv bridge mode with vlan encapsulation and ovs. The ovs is installed from an Openstack repo where the installation of ovs itself fails with dependency and permission errors. By using the official Centos ovs package, the ovs service starts successfully. The next problem is the etcd proxy that receives TLS errors when using the use_contiv_etcd=False option. When not using the option the Contiv etcd server is in a crashloop. Something else that is weird is by specifying contiv_private_ext_subnet it only wants a /16 subnet. What is the reason for this? Steps to Reproduce (for bugs) 1. Install Ansible and clone the repo https://github.com/amon-ra/openshift-ansible/tree/oondeo-3.11 2. edit the hosts file with adding: openshift_additional_repos=[{'id': 'centos-okd-ci', 'name': 'centos-okd-ci', 'baseurl' :'http://buildlogs.centos.org/centos/7/paas/x86_64/openshift-origin311/', 'gpgcheck' :'0', 'enabled' :'1<http://buildlogs.centos.org/centos/7/paas/x86_64/openshift-origin311/',%20'gpgcheck'%20:'0',%20'enabled'%20:'1>'}] 3. edit the Contiv role so the ovs package is installed from the official Centos repo 4. run the playbook Your Environment * netctl version 1.2.0 (-> 1.2.1 doesn't come with netctl cli) * Orchestrator version (e.g. kubernetes, mesos, swarm): Openshift 3.11 * Operating System and version: Centos 7.6 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#1161>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AIL80LRGJqd1FBLn0iNey4DNOSVbUe-Iks5u4PONgaJpZM4ZPUtG>.

[Mikey032]

Solved the TLS errors and contiv netmaster en netplugins are working correctly except that it isn't possible to use services. A request, that goes from a containers to a service with service cidr 172.30.0.0/16, is routed to the default gateway which it denies. Doesn't the request need to stay in the "internal network"?

[Mikey032]

After some changes it is now possible to use services from within pods using contiv but not from pods running in the host network. This traffic is routed to the default gateway.
Is it possible to troubleshoot?
EDIT: I have 2 nics on my virtual machines, a management nic and a data nic.