search

hortonworks / streamline

StreamLine - Streaming Analytics
Apache License 2.0
164 stars 96 forks source link

Cluster security config doesn't work properly with multiple clusters having same name #693

Closed HeartSaVioR closed 7 years ago

HeartSaVioR commented 7 years ago

This is reported by @satishd while testing secure HDFS with secured HDP & HDF clusters having same name.

In point of user's view, users completely don't know about cluster id. They only know about cluster name, so they end up input cluster name. In point of backend's view, cluster name is not unique (in other words, not distinguishable), as we can import multiple Ambari clusters having same name without rearranging cluster's name.

So we should make cluster name unique (user should input cluster name while importing then), or UI should show cluster selection which also shows Ambari URL, and change cluster security config to use cluster id instead of cluster name.

HeartSaVioR commented 7 years ago

Please note that even if we show cluster name as dropdown and let users select one, only showing cluster name is not distinguishable for users too, hence we need to show another information of cluster. Maybe easier way is letting users put cluster name and not allowing duplicated cluster name.

HeartSaVioR commented 7 years ago

@shahsank3t We would be better to take same approach as source / sink hint.

  1. change cluster name input field to drop-down
  2. values of cluster name input field will be filled with available clusters in topology environment
  3. cluster name input field should show additional information like Ambari URL
  4. when user selects one and configure them, UI should pass the field with cluster ID rather than cluster name

Please let me know whether UI can handle above thing or not. If you confirm UI can handle that, I'll start doing the backend work.

Other thing to fix is, we need to put storm principal as default value instead of nimbus principal. I'll see it can be handled only with backend side.

Thanks in advance!

shahsank3t commented 7 years ago

@HeartSaVioR Yes, we can handle those points on the UI. Actually, 1 & 2 is already handled, we need to make changes for 3 & 4 points. You can start on the backend changes required for the same.

Regarding the storm principal to be a default, we actually let the user pick any principal/keytabs in the UI from the available list or create one themselves.

HeartSaVioR commented 7 years ago

@shahsank3t Unfortunately, backend side seems not be implemented properly...

Backend provides cluster lists (and their keytab/principal pairs) which has Storm as service, but it shouldn't have such limitation. Some users set their cluster without Storm, even though they're using Ambari.

An environment (namspace) should associate only one Storm service, so we can get them from that service and provide them for all cluster lists. (Yes that's redundant but make no change for UI side.)

I'll try to address it from only backend side, but will mention you if UI change is needed.

shahsank3t commented 7 years ago

@HeartSaVioR Alright. Let me know if you need any changes. Assigning this issue to you and removing UI label.

HeartSaVioR commented 7 years ago

@shahsank3t 3 and 4 are unrelated to current backend issue and should be addressed from both backend and UI side. So if you want to label UI issue please re-add label.

shahsank3t commented 7 years ago

@HeartSaVioR Have made the UI changes for 3 (commit id: https://github.com/hortonworks/streamline/commit/62bd7c50d25cf85a3a706b3a0061d0a8809f4485) Let me know when you are done with backend changes to accept clusterId instead of clusterName and I'll make the appropriate changes in UI.

HeartSaVioR commented 7 years ago

PR for backend is ready: #704