R5.0-micro-services provision - provision mx connectivity.

day1 and 2 operations are not provided by anaible deployer

Review in progress for https://review.opencontrail.org/41751
Submitter: Nitish Krishna Kaveri (<email address hidden>)

Review in progress for https://review.opencontrail.org/41752
Submitter: Nitish Krishna Kaveri (<email address hidden>)

Review in progress for https://review.opencontrail.org/41751
Submitter: Nitish Krishna Kaveri (<email address hidden>)

Review in progress for https://review.opencontrail.org/41752
Submitter: Nitish Krishna Kaveri (<email address hidden>)

Reviewed: https://review.opencontrail.org/41752
Committed: http://github.com/Juniper/contrail-ansible-deployer/commit/63ca9dba2b46cd7566d5a2ff8e4509365b922963
Submitter: Zuul v3 CI (<email address hidden>)
Branch: master

commit 63ca9dba2b46cd7566d5a2ff8e4509365b922963
Author: nitishkrishna <email address hidden>
Date: Tue Apr 10 14:45:27 2018 -0700

Closes-Bug: #1759428 - Provision External Routers (MX) from Controller

The list of routers should be specified as below:

contrail_configuration:
EXTERNAL_ROUTERS:<Router_1_name>:<Router_1_Mgmt_IP>,<Router_2_name>:<Router_2_Mgmt_IP>,...

Like:
EXTERNAL_ROUTERS:mx1:10.10.20.20,mx2:40.40.30.20

Patch 2:
Changed input format to consistent single param

Change-Id: I3ab993aea4b54d4c7b91e4c366b5d427487c0fe8

Review in progress for https://review.opencontrail.org/41751
Submitter: Nitish Krishna Kaveri (<email address hidden>)

Reviewed: https://review.opencontrail.org/41751
Committed: http://github.com/Juniper/contrail-container-builder/commit/113feca8a2d8d78b6535fe91ab3e4d74714569f0
Submitter: Zuul v3 CI (<email address hidden>)
Branch: master

commit 113feca8a2d8d78b6535fe91ab3e4d74714569f0
Author: nitishkrishna <email address hidden>
Date: Tue Apr 10 14:40:59 2018 -0700

Partial-Bug: #1759428 - Provision External Routers (MX) given list of routers

They have to be provided in the instances.yml as below:

contrail_configuration:
EXTERNAL_ROUTERS:<Router_1_name>:<Router_1_Mgmt_IP>,<Router_2_name>:<Router_2_Mgmt_IP>,...

Like:
EXTERNAL_ROUTERS:mx1:10.10.20.20,mx2:40.40.30.20

Patch 2:
Changed input format to consistent single param
Patch 3:
Missed out script name

Change-Id: I93c0f609d7de132002c7434ba716cd8e1b017a28

Manually marking fix committed as check-ins got merged in wrong order

Ritam,

Please confirm that the change works in master branch after which I will cherry-pick to 5.0

bug can't be set to incomplete for verification in another branch.

MX was configured only with ASN , the BGP peering list was not sent to the script . Because of this BGP peering did not happen btw controllers and MX. Re-opening bug.

Moving bug to suresh because provision script runs correctly but DM doesn't push config to MX as expected.

DM will be able to push configuration only if physical-router & bgp routers are created/associated.
Script is creating only Bgp Router object. This is not sufficient to trigger device config push.

Please work on the script.

Moving back to Nitish, as provision_mx creates only bgp-router object. There is another script that creates physical-router object. Probably you should use that or write your own script to create a physical router object.

Review in progress for https://review.opencontrail.org/42670
Submitter: Nitish Krishna Kaveri (<email address hidden>)

From: Nitish Krishna Kaveri Poompatnam <email address hidden>
Date: Thursday, May 3, 2018 at 2:21 PM
To: Tong Jiang <email address hidden>, Jeba Paulaiyan <email address hidden>, Madhava Jayamani <email address hidden>, Senthilnathan Murugappan <email address hidden>
Cc: Michael Henkel <email address hidden>, Abhay Joshi <email address hidden>, Ramprakash Ram Mohan <email address hidden>
Subject: Re: How to handle Provisioning of External Routers

Hi all,

After discussion with Tong and Jeba, we have decided that there is no specific external playbook required to do this provisioning of routers.
Today the Fabric DM Playbooks already does this and Tong has confirmed that he will setup an “SDN Gateway” role for the External Routers we wish to configure and peer with the contrail cluster controller nodes.
Thus we can use Fabric UI to do this provisioning.
I am moving bug to Tong to confirm and close.
For testing etc, the UTs directly call VNC API and will continue to do so.

Tong,
I have assigned bug:
https://bugs.launchpad.net/juniperopenstack/r5.0/+bug/1759428
To you

Please get the expected config from Madhava and close accordingly.

Thanks,
Nitish

Reviewed: https://review.opencontrail.org/42670
Committed: http://github.com/Juniper/contrail-controller/commit/69dc550511aadb19c95a37a72b41f3162d447bdc
Submitter: Zuul v3 CI (<email address hidden>)
Branch: master

commit 69dc550511aadb19c95a37a72b41f3162d447bdc
Author: nitishkrishna <email address hidden>
Date: Tue May 1 10:17:02 2018 -0700

Partial-Bug: #1759428 - Changing provision script to create phys device and push config to device

Change-Id: I1a1f1023d47de321068f20f89113fa4c68ca8c74

we should not a issue now, as long as we creating objects properly, looks like provisioning script does it and through UI we have tested. I dont see any issue. Please test with latest legacy overlay, if it works with legacy overlay it should work with ansibalized overlay

On the sanity setup with latest R5.0.1 build 161 we still see the issue of bgp peering with the MX not coming up. This is the instances.yml that we use:-

***************************************************************
***************************************************************

[root@nodem14 ~]# cat contrail-ansible-deployer/config/instances.yaml
global_configuration:
   REGISTRY_PRIVATE_INSECURE: True
   CONTAINER_REGISTRY: 10.204.217.152:5000
provider_config:
  bms:
    domainsuffix: englab.juniper.net
    ntpserver: 10.204.217.158
    ssh_pwd: c0ntrail123
    ssh_user: root

instances:
  nodem10:
      ip: 10.204.216.99
      provider: bms
      roles:
          openstack_compute: null
          vrouter:
              PHYSICAL_INTERFACE: ens2f1
  nodem14:
      ip: 10.204.216.103
      provider: bms
      roles:
          analytics: null
          analytics_database: null
          config: null
          config_database: null
          control: null
          openstack: null
          webui: null
  nodem6:
      ip: 10.204.216.95
      provider: bms
      roles:
          analytics: null
          analytics_database: null
          config: null
          config_database: null
          control: null
          openstack: null
          webui: null
  nodem7:
      ip: 10.204.216.96
      provider: bms
      roles:
          analytics: null
          analytics_database: null
          config: null
          config_database: null
          control: null
          openstack: null
          webui: null
  nodem8:
      ip: 10.204.216.97
      provider: bms
      roles:
          openstack_compute: null
          vrouter:
              PHYSICAL_INTERFACE: bond0
  nodem9:
      ip: 10.204.216.98
      provider: bms
      roles:
          openstack_compute: null
          vrouter:
              PHYSICAL_INTERFACE: ens2f1

contrail_configuration:
  EXTERNAL_ROUTERS: blr-mx1:10.10.10.101
  CONTRAIL_VERSION: ocata-5.0-161
  CLOUD_ORCHESTRATOR: openstack
  METADATA_PROXY_SECRET: c0ntrail123
  OPENSTACK_NODES: 10.204.216.103,10.204.216.95,10.204.216.96
  CONTROLLER_NODES: 10.204.216.103,10.204.216.95,10.204.216.96
  AUTH_MODE: keystone
  KEYSTONE_AUTH_ADMIN_PASSWORD: c0ntrail123
  KEYSTONE_AUTH_URL_VERSION: "/v3"
  RABBITMQ_NODE_PORT: 5673
  KEYSTONE_AUTH_HOST: 10.204.216.140
  IPFABRIC_SERVICE_HOST: 10.204.216.140
  AAA_MODE: rbac
  CLOUD_ORCHESTRATOR: openstack
  CONFIG_API_VIP: 10.204.216.103
  CONTAINER_REGISTRY: 10.204.217.152:5000
  CONTRAIL_VERSION: ocata-5.0-161
  CONTROLLER_NODES: 10.204.216.103,10.204.216.95,10.204.216.96
  CONTROL_NODES: 10.10.10.14,10.10.10.6,10.10.10.7
  ENCAP_PRIORITY: VXLAN,MPLSoUDP,MPLSoGRE
  IPFABRIC_SERVICE_HOST: 10.204.216.140
  KEYSTONE_AUTH_ADMIN_PASSWORD: c0ntrail123
  KEYSTONE_AUTH_HOST: 10.204.216.140
  KEYSTONE_AUTH_URL_VERSION: /v3
  OPENSTACK_NODES: 10.204.216.103,10.204.216.95,10.204.216.96
  RABBITMQ_NODE_PORT: 5673
  REGISTRY_PRIVATE_INSECURE: true
  VROUTER_GATEWAY: 10.10.10.101
  XMPP_SSL_ENABLE: true

kolla_config:
  kolla_globals:
    kolla_internal_vip_address: 10.204.216.140
    kolla_external_vip_address: 10.204.216.140
    contrail_api_interface_address: 10.204.216.103
    keepalived_virtual_ro...

Please test with build 170 which has ansibalized DM

Tried with the instances.yml in comment 22 but still on the MX we see none of the bgp peering in established state.

[edit]
root@blr-mx1# run show bgp group testbed_regression_m14
Group Type: Internal AS: 64512 Local AS: 64512
  Name: testbed_regression_m14 Index: 28 Flags: <Export Eval>
  Options: <GracefulRestart LocalAS>
  Holdtime: 0 Local AS: 64512 Local System AS: 64510
  Total peers: 3 Established: 0
  10.10.10.14
  10.10.10.6
  10.10.10.7
  Trace options: detail packets
  Trace file: /var/log/testbed_log size 0 files 10

[edit]
root@blr-mx1#

I used build 176 with above configs and attaching the webui info on peering.

WebUI bgp peering of control nodes.

Please let me know what more information is needed before moving the bug to incomplete.

could you please the config pushed to device?

>>> could you please the config pushed to device?

Sorry didn't understand that. This does not involve any DM config. It's just that we should have a provisioning task which reads the MX router details from the instances.yml and sets up those BGP router parameters like ASN ID etc on the control node side so that BGP peering with the MX is complete. All details including configuration are provided in the bug regarding this. Please go through the earlier comments.

Why is this a bug in post 5.0? We are now in ansibalized DM. We dont provision Mx like done by scripts. I have removed 5.0 scope and we should close this for trunk as well. Keeping it open for discussion/conclusion

not required, hence closing the trunk scope also.