Appliance-wide custom HTTP error pages

[skateman]

There is an open BZ for having the ManageIQ logo on the HTTP error (404, 422, 500) pages. The SUI team already implemented this feature in their project and I'm thinking about making it appliance-wide.

As we can not rely on the asset pipeline when using static error, I would like to move some minimal set of files from the SUI into the public folder of the main repo. When these files are in place, we can tell Apache to take over the error handling by using ProxyErrorOverride and ErrorDocument. However, this solves the errors for the classic UI only, for the SUI we might need some extra mod_rewrite configuration or some modifications in the Angular app.

The solution for the classic UI is super simple, the question is how much changes do we need for the SUI and if this is a good idea or not?

PS: we can always fall back and use the HTTP Status Cats API 🤣

[AllenBW]

Shared 404 sounds great! SUI and OPSUI shouldn't each have their own... Lemme know what you need me to do @skateman !! 🙇‍♀️

[Fryguy]

I mentioned it in #14263, but I'll repeat here. How would we make this productizable?

[skateman]

@Fryguy we can't override but is there any problem with overwriting?

[Fryguy]

We don't overwrite in our build process for productization. Partially because the goal is to separate "productized assets" into a separate RPM, and then one can't overwrite the other, but also because we want to leave the original source as pure as possible.

[skateman]

Hm, then we have to modify the HTML files. In this public folder we don't have access to the asset pipeline at all. Until now it was fine as we weren't using icons here. Actually SUI displays the MiQ icon in production 😕

[skateman]

What about having a conditional rewrite in Apache? If there is a file called logo-product.svg under DOCUMENT_ROOT, we swap logo.svg with it. @Fryguy ?

[AllenBW]

Is that what we do for other skinnable assets? Saul it is, the change is one png, logo_transpsrent.png (pretty sure that's the name)

[skateman]

The problem is that apache can't see behind our asset pipeline, so we can't handle this single image as any other asset 😞

[AllenBW]

So there's a whole slew of assets that get skinned, here faveicon.ico also being one... or are these items not being skinned rather superseded?

brand_transparent.png is the offending image, but others including login-screen-logo.png appear to be replaced?

[skateman]

Everything that is in the app/assets folder goes through the asset pipeline...

[AllenBW]

right on! so we can affect brand_transparent.png, and it'll at least fix the miq logo showing up where it shouldn't... where would that change have to be made?

[skateman]

You are searching for productization 😉 ask @simaishi

[Fryguy]

What about having a conditional rewrite in Apache? If there is a file called logo-product.svg under DOCUMENT_ROOT, we swap logo.svg with it. @Fryguy ?

Hmmm...I mean that's possible, but then we have to maintain a list in Apache. Additionally this binds us tighter with Apache, so I'm not sure. @carbonin @bdunne Can you give your perspective with respect to the kubernetes changes?

[bdunne]

What about having a conditional rewrite in Apache? If there is a file called logo-product.svg under DOCUMENT_ROOT, we swap logo.svg with it. @Fryguy ?

Hmmm...I mean that's possible, but then we have to maintain a list in Apache. Additionally this binds us tighter with Apache, so I'm not sure. @carbonin @bdunne Can you give your perspective with respect to the kubernetes changes?

Several thoughts based on the discussions around podification...

1. We're close to having an independent httpd container as a front-end just for auth, SSL and directing to the correct openshift service (UI / API / SUI / etc.)
2. I would like to completely split off the Service UI into its own container that has no references to the existing ManageIQ application container. This container would then run a web server (I don't know if it's httpd / nginx / some node server) only serving this application. It would not have any of the ManageIQ Rails app or its dependencies on the filesystem.
3. For the rearch, a few of us have discussed removing httpd from the "classic UI" container, leaving a container that only runs rails s and also allowing rails s to serve the static assets. We still need to research whether or not this will cause any issues with excess database connections or any other problems.

[skateman]

@bdunne is there a problem in putting the error pages & logo into the httpd container?

[carbonin]

@skateman I'm not sure of the state of this discussion, but I don't think we have a productization strategy for containers (other than the miq app one). So while I think the apache container is where the static assets probably belong, I'm not sure productizing them is something we can do yet.

@Fryguy + @bdunne keep me honest if I'm missing some detail here.

[bdunne]

I've been trying to remove as much as possible from the httpd container. Soon I hope its only purpose is to handle authentication. Is there an issue with the rails server serving the error pages, or at least the images for them?

Another thing to keep in mind is not only productization, but customer skinning of the app as well. It may look foreign to users to see a ManageIQ logo on an error page if the rest of the application is skinned with their company logos.

[skateman]

I already came up with a conditional rewrite that can be used for the skinning too.

[bdunne]

Will the rails server do the rewrite?

[skateman]

@bdunne it's kinda strange to serve the assets with rails in general, but it's possible with a conditional in the config/routes.rb.

[martinpovolny]

@bdunne, @Fryguy, @carbonin : we really don't want to have Rails serve the assets. That's a step in the wrong direction for the UI.

This is a decision that has a significant impact on the UI and we need to be part of the discussion on this.

If you guys decide to have a separate httpd to do the auth, keep it slim etc. and move the assets out of that container, we would have to reintroduce Apache or some other http server in the UI container or in a seperate container just for the purpose of serving the assets.

Please, make sure that if you dig into things that have a potential of impacting the UI, you invide someone from the UI team to participate.

[Fryguy]

@bdunne @carbonin @martinpovolny @skateman In light of the rearchitecture, would this be possible now, since the assets will be in one place? I think we found some oddities with the 404, and 500 pages specifically, because they're not treated like usual assets, but I'm not sure that would come into play here.

[skateman]

@Fryguy I think yes, we just need some extra lines in the Apache configuration to catch 404 and 500 errors and forward them to the specific URL.

[miq-bot]

This issue has been automatically marked as stale because it has not been updated for at least 6 months.

If you can still reproduce this issue on the current release or on master, please reply with all of the information you have about it in order to keep the issue open.

Thank you for all your contributions!

[JPrause]

@skateman is this still a valid issue. If not can you close.
If there's no update by next week, I'll be closing this issue.

[skateman]

Well, yes it is

[JPrause]

Thanks @skateman and I'll remove the stale label to give this another lease on life.
@miq-bot remove_label stale

[chessbyte]

@skateman @martinpovolny @Fryguy @bdunne @AllenBW where did we end up with this discussion?