onap aks integration deploy question


JIm Cunningham
 

Hi Brian / Steven,

I was going through to further my setup along after the deployment using the onap-all-ingress-nginx-vhost.yaml deployment template. Have you been able to use this and plumb services to be public facing. If so, can you share some tips on how the ingress URI mappings were done? I have the pods deployed and ingresses configured however none of the services can be identified by nginx (portal has only the LoadBalancer IP default configured by Azure during the deployment).

Also cc'ing the broader mailer

Thanks -
JC

On Friday, December 11, 2020, 08:42:44 AM PST, S Thakkar wrote:


Thanks Brian for the quick reply, nice to meet you Steven. Yes, the port manipulation in the URL was also roughly what I was doing.

 

The main challenges I noticed were the embedded frames on the portal UI which are internal redirects and some of the other services which are not plumbed through. Wanted to see if you had any experience there.

 

I’m cc’ing Jim as well he can go into more details and help get this on the discuss lists.

 

From: "FREEMAN, BRIAN D" <bf1936@...>
Date: Friday, December 11, 2020 at 4:34 AM
To: S Thakkar
Cc: "STARK, STEVEN" <SS820F@...>
Subject: RE: onap aks integration deploy question

 

Sachin,

 

portal has a lot of different http redirections going on so its not a surprise. Usually its because we aren’t updating a dns to give all the right external updates. I’ve resolved them when I cared by updating the url’s in the portal admin gui to use the Microsoft assigned fqdn but you will also still get self signed certificate.  I tend to use the nodeport to access the portal and hand edit the location url in the browser if it gets confused.

 

When I’ve deployed in azure I have always specified the region specifically so I haven’t had to run an external script.

 

Copying Steven who is our cloud.sh etc lead.

 

BTW onap-discuss is probably a better mechanism since then the question and answer would be available to others hitting the same problem.

 

brian

 

 


 

Hello Brian,

 

I was following some of the github instructions on deploying onap on aks leveraging some of the cloud.sh scripts in the integration project. I saw your name in the ONAP wiki, hope you don’t mind me sending a few questions your way

 

I was able to fully deploy Frankfurt and guilin leveraging cloud.sh but was seeing some strange port forwarding issues when I tried to access the portal. Is this expected? What’s the best way to access the portal/onap services externally with how the scripts have setup inbound networking in AKS?

 

By the way, as of last weekend, I started seeing some failures in deployment (timeouts) with the cloud.sh script. I root caused it some object replication issues in the Azure portal depending on which region you landed in. Here is what I had to run to work around in case it helps you on any of your runs (of course replace with your region of choice)..

1) az cloud register --name AzureCloudEastUS2 --endpoint-resource-manager "https://EastUS2.management.azure.com" --endpoint-active-directory "https://login.microsoftonline.com" --endpoint-active-directory-resource-id "https://management.core.windows.net/" --endpoint-active-directory-graph-resource-id "https://graph.windows.net/"

2)  az cloud set -n AzureCloudEastUS2

3)     az login

4)     Execute the script

 


 

 


Brian Freeman
 

Jim,

 

I have not setup the ingress controller so cant be much help.

 

The readthedocs page has some guidance that you would need to customize for Azure with both the ingress controller and the dns setup to avoid having to put all the /etc/hosts entried into the clients.

 

https://docs.onap.org/projects/onap-oom/en/guilin/oom_setup_ingress_controller.html?highlight=ingress#configuration-ngninx-ingress-controller

 

If you do get this working in Azure it would be great to add a wiki page or jira describing how you did it for others.

 

Perhaps someone from the oom team has additional pointers on the wiki as well.

 

brian

 

 

From: JIm Cunningham <jc3465@...>
Sent: Wednesday, December 16, 2020 1:52 AM
To: FREEMAN, BRIAN D <bf1936@...>
Cc: STARK, STEVEN <SS820F@...>; Onap-discuss <onap-discuss@...>
Subject: Re: onap aks integration deploy question

 

Hi Brian / Steven,

 

I was going through to further my setup along after the deployment using the onap-all-ingress-nginx-vhost.yaml deployment template. Have you been able to use this and plumb services to be public facing. If so, can you share some tips on how the ingress URI mappings were done? I have the pods deployed and ingresses configured however none of the services can be identified by nginx (portal has only the LoadBalancer IP default configured by Azure during the deployment).

 

Also cc'ing the broader mailer

 

Thanks -

JC

 

On Friday, December 11, 2020, 08:42:44 AM PST, S Thakkar wrote:

 

 

Thanks Brian for the quick reply, nice to meet you Steven. Yes, the port manipulation in the URL was also roughly what I was doing.

 

The main challenges I noticed were the embedded frames on the portal UI which are internal redirects and some of the other services which are not plumbed through. Wanted to see if you had any experience there.

 

I’m cc’ing Jim as well he can go into more details and help get this on the discuss lists.

 

From: "FREEMAN, BRIAN D" <bf1936@...>
Date: Friday, December 11, 2020 at 4:34 AM
To: S Thakkar
Cc: "STARK, STEVEN" <SS820F@...>
Subject: RE: onap aks integration deploy question

 

Sachin,

 

portal has a lot of different http redirections going on so its not a surprise. Usually its because we aren’t updating a dns to give all the right external updates. I’ve resolved them when I cared by updating the url’s in the portal admin gui to use the Microsoft assigned fqdn but you will also still get self signed certificate.  I tend to use the nodeport to access the portal and hand edit the location url in the browser if it gets confused.

 

When I’ve deployed in azure I have always specified the region specifically so I haven’t had to run an external script.

 

Copying Steven who is our cloud.sh etc lead.

 

BTW onap-discuss is probably a better mechanism since then the question and answer would be available to others hitting the same problem.

 

brian

 

 

 

 

Hello Brian,

 

I was following some of the github instructions on deploying onap on aks leveraging some of the cloud.sh scripts in the integration project. I saw your name in the ONAP wiki, hope you don’t mind me sending a few questions your way

 

I was able to fully deploy Frankfurt and guilin leveraging cloud.sh but was seeing some strange port forwarding issues when I tried to access the portal. Is this expected? What’s the best way to access the portal/onap services externally with how the scripts have setup inbound networking in AKS?

 

By the way, as of last weekend, I started seeing some failures in deployment (timeouts) with the cloud.sh script. I root caused it some object replication issues in the Azure portal depending on which region you landed in. Here is what I had to run to work around in case it helps you on any of your runs (of course replace with your region of choice)..

1) az cloud register --name AzureCloudEastUS2 --endpoint-resource-manager "https://EastUS2.management.azure.com" --endpoint-active-directory "https://login.microsoftonline.com" --endpoint-active-directory-resource-id "https://management.core.windows.net/" --endpoint-active-directory-graph-resource-id "https://graph.windows.net/"

2)  az cloud set -n AzureCloudEastUS2

3)     az login

4)     Execute the script

 

 

 

 


JIm Cunningham
 

Thanks - okay, will do. I think I am close and will give it a try and update the wiki once I get it working

JC

On Wednesday, December 16, 2020, 03:44:37 AM PST, Brian Freeman <bf1936@...> wrote:


Jim,

 

I have not setup the ingress controller so cant be much help.

 

The readthedocs page has some guidance that you would need to customize for Azure with both the ingress controller and the dns setup to avoid having to put all the /etc/hosts entried into the clients.

 

https://docs.onap.org/projects/onap-oom/en/guilin/oom_setup_ingress_controller.html?highlight=ingress#configuration-ngninx-ingress-controller

 

If you do get this working in Azure it would be great to add a wiki page or jira describing how you did it for others.

 

Perhaps someone from the oom team has additional pointers on the wiki as well.

 

brian

 

 

From: JIm Cunningham <jc3465@...>
Sent: Wednesday, December 16, 2020 1:52 AM
To: FREEMAN, BRIAN D <bf1936@...>
Cc: STARK, STEVEN <SS820F@...>; Onap-discuss <onap-discuss@...>
Subject: Re: onap aks integration deploy question

 

Hi Brian / Steven,

 

I was going through to further my setup along after the deployment using the onap-all-ingress-nginx-vhost.yaml deployment template. Have you been able to use this and plumb services to be public facing. If so, can you share some tips on how the ingress URI mappings were done? I have the pods deployed and ingresses configured however none of the services can be identified by nginx (portal has only the LoadBalancer IP default configured by Azure during the deployment).

 

Also cc'ing the broader mailer

 

Thanks -

JC

 

On Friday, December 11, 2020, 08:42:44 AM PST, S Thakkar wrote:

 

 

Thanks Brian for the quick reply, nice to meet you Steven. Yes, the port manipulation in the URL was also roughly what I was doing.

 

The main challenges I noticed were the embedded frames on the portal UI which are internal redirects and some of the other services which are not plumbed through. Wanted to see if you had any experience there.

 

I’m cc’ing Jim as well he can go into more details and help get this on the discuss lists.

 

From: "FREEMAN, BRIAN D" <bf1936@...>
Date: Friday, December 11, 2020 at 4:34 AM
To: S Thakkar
Cc: "STARK, STEVEN" <SS820F@...>
Subject: RE: onap aks integration deploy question

 

Sachin,

 

portal has a lot of different http redirections going on so its not a surprise. Usually its because we aren’t updating a dns to give all the right external updates. I’ve resolved them when I cared by updating the url’s in the portal admin gui to use the Microsoft assigned fqdn but you will also still get self signed certificate.  I tend to use the nodeport to access the portal and hand edit the location url in the browser if it gets confused.

 

When I’ve deployed in azure I have always specified the region specifically so I haven’t had to run an external script.

 

Copying Steven who is our cloud.sh etc lead.

 

BTW onap-discuss is probably a better mechanism since then the question and answer would be available to others hitting the same problem.

 

brian

 

 

 

 

Hello Brian,

 

I was following some of the github instructions on deploying onap on aks leveraging some of the cloud.sh scripts in the integration project. I saw your name in the ONAP wiki, hope you don’t mind me sending a few questions your way

 

I was able to fully deploy Frankfurt and guilin leveraging cloud.sh but was seeing some strange port forwarding issues when I tried to access the portal. Is this expected? What’s the best way to access the portal/onap services externally with how the scripts have setup inbound networking in AKS?

 

By the way, as of last weekend, I started seeing some failures in deployment (timeouts) with the cloud.sh script. I root caused it some object replication issues in the Azure portal depending on which region you landed in. Here is what I had to run to work around in case it helps you on any of your runs (of course replace with your region of choice)..

1) az cloud register --name AzureCloudEastUS2 --endpoint-resource-manager "https://EastUS2.management.azure.com" --endpoint-active-directory "https://login.microsoftonline.com" --endpoint-active-directory-resource-id "https://management.core.windows.net/" --endpoint-active-directory-graph-resource-id "https://graph.windows.net/"

2)  az cloud set -n AzureCloudEastUS2

3)     az login

4)     Execute the script