-
Notifications
You must be signed in to change notification settings - Fork 17
Cannot login to UI (helm chart) #480
Comments
The only activity seen in the nginx pod is
Whilst the most recent log from the backend UI container ends:
|
The UI itself may also need a code enhancement so that it does not continually hang if misconfigured - timeout/error ? @sarbull |
We will target this to coincide with the 3.13 release (work during Oct, release by ~ 1 Nov) |
Plan to revisit this in time for the 3.13 release since the new UI should now be ready. Likely that there are some minor changes relating to environment |
I took a look at this again now 3.13 is released. Installed with the additional config file (add
I get an nginx 'Bad gateway' error on a service pointing to the nginx pod (port 8443) the deployed configuration on nginx is:
Checking within the nginx container we see we cannot connect to the latter:
Looking at the container definition (in our charts)for egeria-ui it only declares 8080 as the exposed port. HOWEVER in it's configuration we have:
Inspecting the container image, in our staticui layer, only port 80 is exposed, and the docs in the embedded metadata refer to port 80. This is true for the base nginx image used by the UI As such it seems the //intent// is now for the staticui container to expose port 80 (not 8080) If we compare this with the older UI (version 3.2.0) used in the helm charts up until 3.2.0 we see the config file is:
confirming the 8080 port was correct then, and indeed the UI works correctly. The fix therefore is to either
(Aside: We could also get rid of the additional nginx component, but this can be a seperate issue for optimization) Since remapping is simple, the minimal change is the latter. I will do this. Any subsequent change can be done via a new issue/PR cc: @lpalashevski @sarbull |
I've added a conditional check . If version >=4 we basically use the port 80 setup. otherwise we use port 8080. Should work for old and new UI. Probably unnecessary, but it makes it easier to test the new UI in the charts. May then remove in a future release. |
Having implemented this check, we still cannot run with the container exposing port 80, since we need (want) to run our charts without root priviliges. ie the pods running on k8s will not be running under root, therefore no ports under 1024 can be bound to. This is in fact why we ran on 8080 in the first place The docker container should setup the default to run on a port not requiring root. Optional to provide the ability to configure this differently if required. If this is changed to port 8080, no change to the charts is then required. Therefore reassigning this to the egeria-ui component |
@sarbull @lpalashevski We need to change the default port for the docker container produced by egeria UI to > 1024, and ideally 8080 to keep it the same as the previous UI I am happy to make change or you can. This requires a change to Dockerfile & etc/nginx.conf. I don't think anything else. Happy to make this change and test in k8s if you like. |
Confirmed on openshift dashboard
|
In both cases our nginx related files in the helm definition create config files /etc/nginx.conf is set to fixed content from within 'egeria-uistatic.yaml'. this is done by creating a configmap, which is mounted as that file in the container filesystem:
The actual server definition is then built by creating a template in nginx. this is taken from etc/staticui.conf.template. That is placed into a volume which is mounted at /etc/nginx/templates :
This is then copied by the nginx container at startup, with variable replacement, and ends up with a correct port 8080 configuration However it seems as if whilst the old nginx image does this templating, the new version does not .... and therein lies the reason that nginx starts on the wrong port. Need to look into why templating isn't working / what's changed. Alternatively we could build explicit config files from within the helm template. |
In the old template, we left the entrypoint as it: When we look at the cmd/entrypoint definitions. Old:
New:
In the new image the entrypoint is overwritten by the Dockerfile: Since we are reusing a standard image, which already defines a good default entrypoint, we have no need to override Two other observations
For now I will not change or raise issues on the above. Note that any change to the container will need a 'release' to push |
Signed-off-by: Nigel Jones <nigel.l.jones+git@gmail.com>
Signed-off-by: Nigel Jones <nigel.l.jones+git@gmail.com>
Signed-off-by: Nigel Jones <nigel.l.jones+git@gmail.com>
👀 |
Thanks, I'm going to update the charts to a prerelease level to include the current UI |
@sarbull I'll need a new container image published for egeria-ui with those fixes before it makes sense to merge the chart update. |
ok, will do, i'll let you know |
Agreed on commmunity call 20230201 that we'd like to add into v4 cc: @lpalashevski |
Signed-off-by: Nigel Jones <nigel.l.jones+git@gmail.com>
Signed-off-by: Nigel Jones <nigel.l.jones+git@gmail.com>
Signed-off-by: Nigel Jones <nigel.l.jones+git@gmail.com>
We now have additional fixes for the ui-chassis which are being integrated into release 4 This is currently building, will be merged, and then I will rerun the release pipeline. We should then have a complete v4 build later. There is also a js commons fix made under We will need a new 'egeria-ui' container image, ideally at a release version (or make it a prerelease, we test, then repeat with final version). Can you arrange this @sarbull @lpalashevski @bogdan-sava The charts use nginx, and redirect /api to the ui-chassis container. I think we expect this to work ok with the above changes? |
@bogdan-sava is everything in pace now? if so next steps for the UI are:
If all commits are in I can take over with the versions and build the image. |
All good except for the cors. It works only with nginx or similar solution. |
@lpalashevski The release pipeline has been started at https://github.com/odpi/egeria/actions/runs/4545935086 We need an 'egeria-ui' container image (ie your 2 first bullets above ) |
I am looking for fixing the cors issues also |
If we're ok ui is good enough for now, would be good to go with the v4 builds we have as final and fix cors fully for 4.1? |
Docker image for egeria-ui v4.1.2 build running now https://github.com/odpi/egeria-ui/actions/runs/4546319965/jobs/8014803693?pr=572 |
Thanks for getting that underway :-) We'll need to do the merge to get the containers published - the PR build just verifies the build, it does not push - nor can it (permissions). The merge will actually push them to quay.io & docker.io Ok if we merge? |
I have updated the charts to include this latest image, and to facilitate wider testing. To install use:
These additional parms However, the UI is not working for me. I now get a blank screen when going to the static ui service (previously this was a login panel). Let's discuss/debug when free |
Update - incognito in chrome/safari shows different behaviour, so the blank screen was probably caching/cookies related. I can now login - so we know the uichassis is working This may be config related. Perhaps view service configuration? No warnings being seen in the ui chassis pod |
The following environment is currently set (as from old UI):
Similar properties still seem appropriate as per the application.properties for ui chassis |
Enabled debug, restarted ui pod, all ok - was able to login as erinoverview & garygeeke & retrieve assets 'Week*' |
However when in this state, a logout/login does not fix this problem.
|
The initial error is startup timing. Debug logs show:
This is due to the 'cocoMDS1' server 'built in' to the UI NOTE: Having TWO cocoMDS1 servers in the same deployment -- as is the case for coco pharma - is confusing. I think it should be named something else (but not for this release) The timing issue can probably be put in the release notes for now, though we should consider how the UI should handle that situation more elegantly -- and perhaps hint to the user to retry later. For most people experimenting, they'll likely start the UI after the cocoMDS1 has started. But, The UI should not hang without any exit route. For proper deployments of egeria (a notebook based approach is quite particular for education, developers) & as we move forward with cloud native work, we need to clearly define an appropriate health check, so that we can coordinate when pods are ready to do real work, and have requests routed to them (a much biggger topic). |
Repeated the test, but left about 7 minutes after deployment before running the UI (this was after the configure/data catalog notebooks). Was able to login to the UI first time. However also noticed 'About' does not load - again the swirling progress indicator In summary, I think the UI is now deployed ok, but there are a number of issues we should open, and document in the release notes for 4.0 - but practically, it's probably what we should go with for this release @bogdan-sava @sarbull @lpalashevski Does this make sense? Can you check what behaviour you see? |
Also
These may still be in development |
I have not raised an issue on the blank profile as I presume this is not developed yet, and at least does not cause an error, it's just there are no profile contents. Given we can now deploy the UI, closing this issue |
this should work now, there were some changes on the token implementation and cors functionality |
egeria-ui 4.0.1 was recently announced.
The currently released egeria charts uses 3.2.0 and continues to work.
However for testing I tried running with version 4.0.1 of the UI
For example:
I then ran the configure/start/building a data catalog notebooks
With the ports forwarded, and attemt to go to the nginx port (https://localhost:443) results in continually 'loading' window
I would presume we need some updates for the new UI to work correctly - configuration?
@sarbull @lpalashevski
The text was updated successfully, but these errors were encountered: