Hide Forgot
The Red Hat Insights team will be creating a monitoring solution for RHEV beginning in RHEV 4.0. To monitor the entire RHEV ecosystem, we need the ability to discover all of the topological information that constitutes a RHEV deployment. This information includes, but is not limited to... - Data Centers - Clusters - Hosts (ie. hypervisors IP and hostname SPM). - Attached storage domains - Various other bits of information Currently, there are REST API is gated by a UID and PW that are typically controlled by an integrated LDAP or AD server. Hence, it is difficult for an Insights client to use the REST API without and administrator creating a UID/PW specifically for the client. We believe that this would be a blocker to adoption and we think that having the Insights client store a UID/PW is a bad idea anyway. A better approach would be to have API access granted to the local 'root' user and/or a key that a client application could use from a designated host.
This shouldn't be a blocker for adoptation in any way. In 3.6 we provide an internal extension that you can add more users to, so, the setup can be changed to ask for a password for this user, create it for you automatically, and also configure the monitor system itself. You, of course, need to sync that with the integration team. We aren't going to add another type of authentication, such as the one you suggested. I suggest you indeed sync with the integration team, and change the title, component and ovirt team of this bug accordingly.
How do we resolve this issue with CFME?
(In reply to Yaniv Dary from comment #2) > How do we resolve this issue with CFME? Please elaborate, as the question isn't clear. CFME has the username and password as well.
(In reply to Oved Ourfali from comment #3) > (In reply to Yaniv Dary from comment #2) > > How do we resolve this issue with CFME? > > Please elaborate, as the question isn't clear. > CFME has the username and password as well. Is it automatically defined? Is is the manual step in their setup?
(In reply to Yaniv Dary from comment #4) > (In reply to Oved Ourfali from comment #3) > > (In reply to Yaniv Dary from comment #2) > > > How do we resolve this issue with CFME? > > > > Please elaborate, as the question isn't clear. > > CFME has the username and password as well. > > Is it automatically defined? Is is the manual step in their setup? When you add a rhev provider, you need to provide details. Just as if you add an external provider in rhev to openstack/foreman/anything else...
Moving to the integration team for consideration, as per comment #1.
Any thoughts?
Keith, why don't you ask the admin@internal password in the access insights setup (or a password for another user)?
(In reply to Yaniv Dary from comment #8) > Keith, why don't you ask the admin@internal password in the access insights > setup (or a password for another user)? Yaniv, We ultimately decided to do this in lieu of a better option. It would still be nice to have an API key so that we don't need to save UID/PW to disk but UID/PW is the best option available, today. To be clear, this BZ is not impeding our ability to execute Insights for RHEV. Our flow, today, is as follows... 1) A RHEV Admin user creates a specific user for Insights via the RHEV-M UI. 2) When the RHEV Insights coordinator is launched there will be an option configure/save the user created in 1 to a config file. 3) When the cron job fires and launches the Insights coordinator, the Insights coordinator will read credentials saved in 2 to the gain access to the RHEV-M's REST API. NOTE: We are exploring whether or not we can create an Insights user directly from the RHEV-M's REST API _whithout_ going through the RHEV-M's UI. The flow for this, if it works, would look something like this... 1) redhat-insights-rhev --configure 2) Prompt user for a RHEV-M admin user with the ability to create other users. 3) Use the credentials from 2 to create a user for Insights via the REST API 4) Save user created in 3 to config file.
Looks like changes in engine-setup are not needed then. From my understanding this bug can be either closed wontfix or moved to insights. Moving to sub-eng team for now.
Again, API key would be nice so that we don't need to save PWs to disk but this will not be the first application to save a PW to a file. IOW, there is precedent.