New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
ksurap2 opened this Issue Jun 17, 2013 · 9 comments

Comments

Projects
None yet
4 participants
@ksurap2

ksurap2 commented Jun 17, 2013

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

This comment has been minimized.

Member

ypujante commented Jun 17, 2013

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

This comment has been minimized.

ksurap2 commented Jul 1, 2013

screenshot-issue-227

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

@ypujante

This comment has been minimized.

Member

ypujante commented Jul 2, 2013

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

This comment has been minimized.

itshanney commented Jul 7, 2013

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

This comment has been minimized.

Member

ypujante commented Jul 8, 2013

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

This comment has been minimized.

malonem commented Jul 10, 2013

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

This comment has been minimized.

Member

ypujante commented Jul 11, 2013

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

@ksurap2

This comment has been minimized.

ksurap2 commented Jul 12, 2013

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

This comment has been minimized.

Member

ypujante commented Jul 12, 2013

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

ypujante added a commit that referenced this issue Aug 14, 2013

@ypujante ypujante closed this Aug 14, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment