Create provider discovery feature. #61
Conversation
gabrielsvinha
force-pushed
the
provider_discover
branch
from
bae774a to
973b686
Compare
|
@miq-bot add_label providers/physical-infrastructure, enhancement |
|
@gabrielsvinha Cannot apply the following label because they are not recognized: providers/physical-infrastructure |
|
@miq-bot assign @juliancheal |
gabrielsvinha
changed the title
|
This pull request is not mergeable. Please rebase and repush. |
gabrielsvinha
force-pushed
the
provider_discover
branch
from
9763347 to
a918163
Compare
| @@ -73,7 +83,15 @@ def discover_queue(username, password, zone = nil) | |||
| private | |||
|
|
|||
| def discover_from_queue(username, password) | |||
| discover(username, MiqPassword.decrypt(password)) | |||
| discover(username, '') | |||
There was a problem hiding this comment.
Something's incongruous here 😄
Passing username and '' to a method expecting ip_address and port.
Seems like the caller of discover_queue should be passing all of username, password, ip_address, and port. Then, all of that should be queued up for this method, and all of those params passed to the discover method.
There was a problem hiding this comment.
Sure thing. But I do not think neither username or password should be passed, don't you think?
There was a problem hiding this comment.
Turns out this method is never called, should I remove it?
There was a problem hiding this comment.
So, discover_queue puts discover_from_queue onto MiqQueue.
This will be called later, probably by a GenericWorker.
Currently, discovere_queue is receiving username and password, but I suspect it should also receive ip/hostname and port. In fact, it should at least receive ip/hostname and port.
Step back and think about the end user. They'll be presented with a page asking to discover an LXCA server. If they just enter username and password, the code would have to scan the entire network looking for LXCA servers, and attempting the username and password on each.
Instead, if the user is allowed to enter an ip and port, the code just has to attempt to connect to that ip and port and see if it's an LXCA server. If the user also supplies a username and password, the code can attempt to authenticate as well.
Another idea (something that's done for VMWare, I believe) is to allow the user to pass in an Subnet Mask. Then the code can search a range of IPs looking for LXCA servers. If you decide to do that, I think the username and password would not be needed. Since it's unlikely that if the code discovers two LXCA servers in that IP range, that they will both use the same credentials.
There was a problem hiding this comment.
I got your point, changes are on the way
gabrielsvinha
force-pushed
the
provider_discover
branch
from
0b01a63 to
9643024
Compare
|
Checked commits gabrielsvinha/manageiq-providers-lenovo@04dad9d~...9643024 with ruby 2.2.6, rubocop 0.47.1, and haml-lint 0.20.0 |
This Pull Request implement the discovery function for lenovo provider.
The idea is that, by receiving the ip + port, the function calls LXCA client in order to check if the params represents an appliance.
After that, it's created a new EMS instance and set all authentication with empty values. After the EMS in added, the user should update information via UI, then refreshing relationships.
Depends on: #66