Form conversion: Compute/Infrastructure/Providers Discover items

[himdel]

Convert form to use DDF/React and API - parent issue #6825

Location: Compute/Infrastructure/Providers
Form: Discover items

current type: Angular
API state:
Need info

PM Input: 2 - Medium

imported status: NOT ASSIGNED

Missing components:

• ip address ranges

[skateman]

I am not entirely sure if this form is useful at all, it can only discover providers in a /24 or smaller IPv4 subnet:

@Fryguy @agrare is this something we could get rid of? Or should it be more generic and with IPv6 support?
@miq-bot add_label question

[chessbyte]

I vote to remove this feature.

[agrare]

I don't know how often this is used...but we could get rid of a bunch of port-scanning discovery code if we dropped this 👍

[chessbyte]

this is literally scanning the network for virtual infrastructure (vSphere, RHV, OpenStack, and SCVMM) endpoints. Do we really have customers that do not know where these are in their datacenter??

[Fryguy]

We did in the past...port scanning a network was a great way to find rogue vspheres. The backend code can scan any subnet range so that /24 limitation is UI-only...that is, we could open it up if we wanted and I don't know why the UI is limited in that way.

I kind of like the feature and don't think we should drop it, personally, but perhaps maybe it should be changed in some way? That is, instead of creating EMSes, perhaps it's just a report that returns the IP addresses it discovered. Maybe it just becomes a low-level tool that a power-user could use without the UI?

[skateman]

I'd be happy to ✂️ delete this from the UI

[chessbyte]

from a UX perspective, if the admin does not know about the vSpheres, they likely won't have the credentials - so adding the EMS sounds like overkill. For that reason, I do like the report idea - but not sure on level of effort for that.

[skateman]

So what's the decision here? To discover or not to discover from the UI?

[Fryguy]

Would like @agrare's opinion as well.

[agrare]

perhaps it's just a report that returns the IP addresses it discovered. Maybe it just becomes a low-level tool that a power-user could use without the UI?

I think that thing exists, it is called nmap 😆 There is even a builtin script to detect vcenters and report their version information:

$ nmap --script vmware-version -p443 10.x.y.0/24
Nmap scan report for dev-vc67.example.com (10.x.y.z)
Host is up (0.030s latency).

PORT    STATE SERVICE
443/tcp open  https
| vmware-version: 
|   Server version: VMware vCenter Server 6.7.0
|   Build: 11338799
|   Locale version: INTL 000
|   OS type: linux-x64
|_  Product Line ID: vpx
Service Info: CPE: cpe:/o:vmware:vCenter Server:6.7.0

[agrare]

Do we really have customers that do not know where these are in their datacenter??

I'm certain we have customers who do not know where these things are 😉 I don't know that this is the right way to solve that problem though.

There are other tools to solve the "discover what is on my network" that do a better job, I could even see building on e.g. nmap as a scheduled task a user could run once a week to report on what IPs are out there.

[skateman]

Okay, so what's the final decision here?

[chessbyte]

I suggest we drop this functionality. Thoughts? @Fryguy @agrare

[agrare]

👍

[Fryguy]

👍 Disagree and commit 😉 Let's remove it.

[chessbyte]

Spoke to @Fryguy and we agreed on the following:

1. For Infrastructure Discovery via port scanning, remove that code and add the nmap approach to our documentation.
2. For Cloud Provider Discovery, re-design our app so that a single provider can handle multiple regions.