Contrail Networking :: 16.04 29 ocata :: Need to move contrail component/plugin provisioning to ansible tasks instead of kolla ansible doing it.

[Ritam Gangopadhyay]

Hi Ritam,

One of the important things if you are using contrail networking is that we bring up the contrail roles (controller, analytics, analyticsDB etc). The openstack portion is provisioned separately by customer. Now to work with contrail, it would mean taking care of installing our contrail plugin in openstack containers too. Earlier in package based installations, we took care of that as part of our provisioning, but that was done mostly as convenience in our testing. It is not meant to be something that is provided to customer as a solution. In container based openstack deployment, it is even harder to automate this as part of contrail provisioning step. We have to resort to providing manual steps to plug our neutron plugin to neutron container.

Hope this helps,

Abhay

From: Ritam Gangopadhyay <email address hidden>
Date: Thursday, September 7, 2017 at 11:21 PM
To: Abhay Joshi <email address hidden>, Sudheendra Rao <email address hidden>, Jeba Paulaiyan <email address hidden>
Cc: Nagendra Maynattamai <email address hidden>, Ramprakash Ram Mohan <email address hidden>, Nitish Krishna Kaveri Poompatnam <email address hidden>, Sivakumar Gurumurthy <email address hidden>
Subject: RE: Contrail Networking support for Ocata.

For Ocata as well contrail networking is not actually supported. As I had mentioned in my prior mail:

        Right now, we have a parameter under kolla_globals, contrail_api_interface_address. As part of openstack provisioning we update the contrail plugin parameters in the conf files of openstack services like neutron and heat based on this IP. These things should not be taken up by openstack provisioning. We should move back to the parameter external_openstack_ip under contrail provisioning (as in mitaka and newton), so that ansible provisioning can populate these things in the external openstack node.

        Openstack provisioning is expected to do a pure openstack installation and contrail provisioning is expected to update these contrail plugin related info into the openstack service conf files, otherwise we can’t claim to support contrail-networking as such.

          So, we will only be able to support networking package if the openstack was provisioned using our openstack package. So people have to use our openstack containers if they want to use our networking package with openstack on a separate cluster, which does not make sense as per contrail networking use case.

Regards,
Ritam.

From: Abhay Joshi
Sent: Friday, September 08, 2017 10:45 AM
To: Ritam Gangopadhyay <email address hidden>; Sudheendra Rao <email address hidden>; Jeba Paulaiyan <email address hidden>
Cc: Nagendra Maynattamai <email address hidden>; Ramprakash Ram Mohan <email address hidden>; Nitish Krishna Kaveri Poompatnam <email address hidden>; Sivakumar Gurumurthy <email address hidden>
Subject: Re: Contrail Networking support for Ocata.

Yes you should test. Only thing that DOES NOT need to be done is testing with Kilo. We will not have Kilo support in 4.0.1 – for contrail cloud and contrail networking.

From: Ritam Gangopadhyay <email address hidden>
Date: Thursday, September 7, 2017 at 9:48 PM
To: Abhay Joshi <email address hidden>, Sudheendra Rao <email address hidden>, Jeba Paulaiyan <email address hidden>
Cc: Nagendra Maynattamai <email address hidden>, Ramprakash Ram Mohan <email address hidden>, Nitish Krishna Kaveri Poompatnam <email address hidden>, Sivakumar Gurumurthy <email address hidden>
Subject: RE: Contrail Networking support for Ocata.

Please let us know if we need to test contrail networking any further or we claim not to support it for Ocata.

Regards,
Ritam.

From: Abhay Joshi
Sent: Thursday, September 07, 2017 8:46 PM
To: Ritam Gangopadhyay <email address hidden>; Sudheendra Rao <email address hidden>; Jeba Paulaiyan <email address hidden>
Cc: Nagendra Maynattamai <email address hidden>; Ramprakash Ram Mohan <email address hidden>; Nitish Krishna Kaveri Poompatnam <email address hidden>; Sivakumar Gurumurthy <email address hidden>
Subject: Re: Contrail Networking support for Ocata.

Thanks for the update, Ritam.

From: Ritam Gangopadhyay <email address hidden>
Date: Wednesday, September 6, 2017 at 11:26 PM
To: Abhay Joshi <email address hidden>, Sudheendra Rao <email address hidden>, Jeba Paulaiyan <email address hidden>
Cc: Nagendra Maynattamai <email address hidden>, Ramprakash Ram Mohan <email address hidden>, Nitish Krishna Kaveri Poompatnam <email address hidden>, Sivakumar Gurumurthy <email address hidden>
Subject: RE: Contrail Networking support for Ocata.

Hi,

        Contrail-networking provisioning completed and services on openstack and contrail side were up on my setup with patch applied by Ram (https://review.opencontrail.org/#/c/35317/) and packages made available in the contrail repo by Nagendra (https://review.opencontrail.org/#/c/35319/).

        Right now, we have a parameter under kolla_globals, contrail_api_interface_address. As part of openstack provisioning we update the contrail plugin parameters in the conf files of openstack services like neutron and heat based on this IP. These things should not be taken up by openstack provisioning. We should move back to the parameter external_openstack_ip under contrail provisioning (as in mitaka and newton), so that ansible provisioning can populate these things in the external openstack node.

        Openstack provisioning is expected to do a pure openstack installation and contrail provisioning is expected to update these contrail plugin related info into the openstack service conf files, otherwise we can’t claim to support contrail-networking as such.

        It may not be a trivial change but Ram is already looking into it and will try the code changes tomorrow.

Regards,
Ritam.

[Ramprakash R (ramprakash)]

In the case of Mitaka and Newton, the open stack nodes are bare metal and it was possible to install our neutron plugin through ansible tasks. In the case of Ocala, the open stack services are all docker containers and it is not possible to install packages after the containers have been launched. Packages if any need to be installed while building the containers itself and in the case of an externally provisioned container-based openstack, we do not have control over it at all.

So the only way out is for them to use our containers to bring up open stack. We cannot fix this using the same/similar tasks as what we used in Mitaka or Newton.