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" <bf1...@att.com>
Date: Friday, December 11, 2020 at 4:34 AM
To: S Thakkar
Cc: "STARK, STEVEN" <ss8...@att.com>
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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22654): https://lists.onap.org/g/onap-discuss/message/22654
Mute This Topic: https://lists.onap.org/mt/78997890/21656
Group Owner: onap-discuss+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
