METRON-2179: Make navigation in both UIs consistent #1464
Conversation
mmiklavc
left a comment
mmiklavc
left a comment
There was a problem hiding this comment.
@sardell Nice work man. I spun this one up in full dev and I like how it works. Everything looks pretty good, except for one potential issue - it appears to me that you're hardcoding port numbers in the menu links. How is that going to work for:
- Customized UI ports in Ambari
- Knox
| subLinks: [ | ||
| { | ||
| linkName: 'Sensors', | ||
| routerLink: ':4200/sensors', |
There was a problem hiding this comment.
Is this the right place to hardcode a port number?
| }, | ||
| { | ||
| linkName: 'General Settings', | ||
| routerLink: ':4200/general-settings', |
There was a problem hiding this comment.
Is this the right place to hardcode a port number?
| subLinks: [ | ||
| { | ||
| linkName: 'Overview', | ||
| routerLink: ':4201/alerts-list', |
There was a problem hiding this comment.
Is this the right place to hardcode a port number?
| }, | ||
| { | ||
| linkName: 'PCAP', | ||
| routerLink: ':4201/pcap', |
There was a problem hiding this comment.
Is this the right place to hardcode a port number?
|
@mmiklavc Good point. Let me take a look and update this weekend. |
|
@mmiklavc After taking a moment to look at Swagger, I do not see a REST endpoint where I can access the dynamic port values for both UIs. I figured this might be the case since we don't need those in the current UI implementations. So, now my question is if I cannot obtain these values currently, how much work is required to make this happen? Including @merrimanr probably has some insight on this as well. |
|
@mmiklavc is there a way to get the port numbers from Ambari? |
|
@tiborm Yes, you can. See the Ansible scripts for an example. |
|
Did a bit of sleuthing here @tiborm and @sardell. Here's the chain of variable resolutions that should be able to provide this in some way:
That management_ui.yml should provide you access to the port in the same way it provides access to the REST API host and port. |
|
@mmiklavc I think I'm having trouble following what you're proposing above. How would I be able to handle links between interfaces with the values in that configuration? For example, links to the Management UI from the Alerts UI and vice versa. |
|
@sardell - we're writing out the host:port info in those config files via Ambari. Probably the easiest thing to do here is expose the additional properties in the respective UI configs. So each UI config would have 1..n config details for connections to the other service(s). If you want to tag-team that, maybe @merrimanr or I can walk you through it. Should be pretty easy to test, also - it's either going to work, or it's not, ha. This UI menu approach looks like it has the potential to start moving us towards a more pluggable UI architecture where we have more than just 2 UI services. There has been some loosely guided discussion in the past about microservices as well as containerizing certain components/services. I spoke a bit offline with @merrimanr about this. I'll let him talk about this in more detail, but one option for moving in this direction is to use a gateway to manage the endpoints. Of course, there are other options as well, e.g. web containers have had application isolation for ages now. I don't think any of that's required for this PR, but it seems like a good time to start some community discussion around it. |
CONFLICTS: metron-interface/metron-alerts/src/app/app.module.ts
Removed hardcoded ports
|
Alright, @mmiklavc. I think we are now covered for customized ports thanks to @merrimanr's contribution. Thank you both for helping me out with that task! |
|
Nice work guys! I'm +1 pending a successful Travis build. |
|
Looks like the build timed out. I noticed this same issue in the PR I submitted against this. Could it be specific to this PR? @sardell you might want to try closing and reopening. |
|
@merrimanr I closed and reopened, but it looks like we the build is still timing out. It's odd because it looks to me like the build is successful in the Travis logs. |
|
According to traviscistatus.com, there were some network issues last week that could've caused the mvn download error in the latest Travis build. I'm going to close and rebuild since it looks like they've resolved the issue. |
|
Well, it looks everything builds fine now. However, upon one last inspection, I noticed that the menu is still rendering sometimes when a user is logged out (it's hard to catch as it's mostly invisible). See the screenshot below.
Obviously, this needs to be fixed before merging. So far, I can only make this happen when I toggle between UIs on full dev. I haven't been able to reproduce this when serving the UIs manually from a terminal window. Keeping my fingers crossed that I can figure this out through some debugging in dev tools. |
|
@sardell good catch. Thank you for the attention to detail on this. |
|
@mmiklavc After clearing my browser's cache and testing again for quite a while, I'm unable to reproduce the bug mentioned previously. If you're still a +1, I'll merge this in. |
|
Yes, I'm still +1. Good work @sardell |
5 participants
Contributor Comments
Link to original JIRA ticket here: https://issues.apache.org/jira/browse/METRON-2179
A PR was already opened for this a couple of days ago, but after some discussion it was decided that I should split out the Angular upgrade work from the central navigation implementation. To catch up on the discussion, you can check it out here: #1460
Currently, both UIs approach navigation in two different ways. This makes the interfaces seem inconsistent and can be confusing for new users. Both ways are also not collapsible. We also cannot navigate between both UIs (this was intentional in the original implementation, but feedback from users over time seems to indicate separating the personas is not necessarily beneficial).
This is how the navigations currently look on master:
In this PR, I added a collapsible sidebar navigation and removed the previous implemented navigations.
In order to do this, I utilized the Angular-version of Ant Design's component library. I did this because bootstrap does not contain a collapsible side navigation like this, and Ant Design allowed me to quickly implement this feature.
Testing
Open either the Alerts or Management UI. A navigation should exist on the left-hand side of the screen (see above screenshots), and you should be able to minimize it by clicking on the arrow at the bottom of the menu. Besides navigating within the app, you should be able to navigate between both UIs.
Pull Request Checklist
Thank you for submitting a contribution to Apache Metron.
Please refer to our Development Guidelines for the complete guide to follow for contributions.
Please refer also to our Build Verification Guidelines for complete smoke testing guides.
In order to streamline the review of the contribution we ask you follow these guidelines and ask you to double check the following:
For all changes:
For code changes:
Have you included steps to reproduce the behavior or problem that is being changed or addressed?
Have you included steps or a guide to how the change may be verified and tested manually?
Have you ensured that the full suite of tests and checks have been executed in the root metron folder via:
Have you written or updated unit tests and or integration tests to verify your changes?
If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
Have you verified the basic functionality of the build by building and running locally with Vagrant full-dev environment or the equivalent?
For documentation related changes:
N/A
Have you ensured that format looks appropriate for the output in which it is rendered by building and verifying the site-book? If not then run the following commands and the verify changes viasite-book/target/site/index.html:N/A
Have you ensured that any documentation diagrams have been updated, along with their source files, using draw.io? See Metron Development Guidelines for instructions.Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.
It is also recommended that travis-ci is set up for your personal repository such that your branches are built there before submitting a pull request.