Glu Console Fabric menu is too large for users' screen resolution

[ksurap2]

We've had reports of developers resorting to the browser zoom function to make the console usable when the number of fabrics in fabric menu is large. When menu is too large for the window, an auto add scroll to the browser window is needed.

[ypujante]

Can you please post a screenshot showing the problem? I am not too sure I understand what the issue is. Also note that you can inject your custom css in the console which may help you tweak the display a bit.

[ksurap2]

Attached is the screenshot. There are 16 other fabric names on the menu not being shown on the screen or scrollable.

[ypujante]

thanks for the screenshot. I can now see what you are talking about. I am not trying to escape from fixing the problem, but I am very curious why you have so many fabrics? This is certainly not the "traditional" use case for glu and maybe you are not using it properly or there is another way to achieve what you are trying to do...

[itshanney]

I will comment on this because we have the same issue, or will have it soon. The issue is the fact that we use Glu to deploy our software to our customer's servers. We also host our customer's environments for them, if needed.

In this manner, if we have 30 or 100 or 500 customers, we have that many fabrics due to the fact that each customer installation is indeed a new fabric that should be logically isolated, network-wise, from each and every other fabric. The only caveat is there are holes in the firewalls to allow Glu to work.

This setup is definitely different than a traditional Dev and Prod fabric, like most companies have because we have to treat each Prod fabric as its own.

We would be happy to try a different approach if you could define a best practice that solves this use case. As I'm also sure the OP would be happy to hear too.

[ypujante]

Hmm interesting use case. I guess the question to ask yourself, to know if it is the right level, is whether you need to do something across all of them: the fabric is the "biggest" level of orchestration you can have in glu.

Within a fabric you can use tags (or metadata), to filter out the view (in the tutorial for example, there is this notion of product that also appears as a "first class citizen" in the navigation bar... you can configure your console to be the same and have "customer" as your primary filtering level).

Using this technique, you always see a "view" of your system centered around a customer. But if you need to do an operation across customers, you can still do it by selecting 'no filter'. If a customer is represented by a fabric then you have to select each and every fabric and do the same operation.

The advantage though with 1 fabric per customer is that you have 1 (system) model per customer => less change of messing up the other customers: it is more isolated.

Yan

[malonem]

We see this issue in our development environment, where all the fabrics are isolated by team, so there is no need to orchestrate between them. All our other environments function in the way you've described. We didn't have a problem before, but now with some personnel shuffling we have a lot more fabrics in Dev.

[ypujante]

Yes I understand now. I will address it in an upcoming release.

[ksurap2]

We were able to solve this issue using customCss and changing position: fixed to position: absolute for

.navbar-fixed-top{ top: 0; position: absolute; }

Thanks, Keerthi

[ypujante]

Awesome. I will add this fix to an upcoming release. Thanks for posting it!