/providers read/write REST API is very asymmetric

[miq-bot]

Continuing from #9743 but I want to focus on REST API, then worry about internals. http://manageiq.org/docs/reference/latest/api/reference/providers The ways to write provider endpoint & auth info is very different from the ways to read them — there is almost no overlap. Especially for multi-endpoint providers (this part BTW is not documented yet)

GET /api/providers/1?attributes=endpoints,authentications,credentials,hostname,port returns:

  ...
  "name": "63",
  "hostname": "vm-48-63.eng.lab.tlv.redhat.com",
  "port": 8443,
  "endpoints": [
    {
      "role": "default",
      "hostname": "vm-48-63.eng.lab.tlv.redhat.com",
      "port": 8443,
      ...
    },
    {
      "role": "hawkular",
      "hostname": "vm-48-63.eng.lab.tlv.redhat.com",
      "port": 443,
      ...
    }
  ],
  "authentications": [
    {
      "name": "ManageIQ::Providers::Openshift::ContainerManager 63",
      "authtype": "hawkular",
      "type": "AuthToken",
      "status": "Valid",
      ...   # excludes "auth_key", "password" for security
    },
    {
      "authtype": "bearer",
      "type": "AuthToken",
      ...
    }
  ...

POST allows several combos:

• Single endpoint as top-level hostname, port, ipaddress, single credentials:

  "hostname" : "my_vcenter_50",
  "ipaddress" : "192.168.150.1",
  "credentials" :  {
    "userid" : "vcenter_admin",
    "password" : "vcenter_password"
  }
  ...

• Single endpoint but compound credentials:

   ...
   "credentials" : [
     {
       "userid"    : "default_userid",
       "password"  : "default_password"
     },
     {
       "userid"    : "metrics_userid",
       "password"  : "metrics_password",
       "auth_type" : "metrics"
     }
  ]

• Compound endpoints paired with auths in connection_configurations:

   ...
   connection_configurations: [
     {
       endpoint: {
         role: "default",
         hostname: "sample_containers_multi_end_point.provider.com",
         port: 18443
       },
       authentication: {
         role: "bearer",
         auth_key: "good token"
       }
     },
     {
       endpoint: {
         role: "hawkular",
         hostname: "sample_containers_multi_end_point.provider.com",
         port: 443
       },
       authentication: {
         role: "hawkular",
         auth_key: "good token"
       }
     }
   ]

Spot the Differences

• You can write credentials but not read it.
  • If multiple, distinguished by auth_type.
• You can read authentications but not write it.
  • Distinguished by authtype (no undescore!)
• You can write {endpoint, authentication} pairs, but not read them.
  • You still have to supply role for each endpoint and role (not auth[_]type!) for each auth.
    • The default endpoint role sometimes expects different auth role eg. bearer above. (According to default_authentication_type method.)
  • The pairs structure you supply is I think ignored, they'll actually be matched by role.

P.S. I think only a few of the Authentication columns can be written, many are silently ignored. Most are not relevant to providers, but should either accept or give error. Anyway that's easy.

---

Where should we go from here? I'll add some proposals later, but would love to hear opinions. A central question this might hinge on: Does 1:1 endpoint:auth pairing suit all providers?

cc @abellotti @durandom @yaacov @dkorn @miq-bot add-label providers, api

---

This issue was moved to this repository from https://github.com/ManageIQ/manageiq/issues/13454, originally opened by @cben

[miq-bot]

This issue has been automatically marked as stale because it has not been updated for at least 6 months.

If you can still reproduce this issue on the current release or on master, please reply with all of the information you have about it in order to keep the issue open.

Thank you for all your contributions!

[JPrause]

@cben is this still a valid issue? If yes, please remove the stale label. If not can you close. If there's no update by next week, I'll be closing this issue.

[miq-bot]

@miq-bot Cannot apply the following labels because they are not recognized: providers, api

[miq-bot]

@miq-bot unrecognized command 'Cannot', ignoring...

Accepted commands are: add_label, add_reviewer, assign, close_issue, move_issue, remove_label, rm_label, set_milestone

[cben]

Unlikely that o be addressed, but valid. @miq-bot remove-label stale

[miq-bot]

@miq-bot unrecognized command 'unrecognized', ignoring...

Accepted commands are: add_label, add_reviewer, assign, close_issue, move_issue, remove_label, rm_label, set_milestone

[miq-bot]

This issue has been automatically marked as stale because it has not been updated for at least 6 months.

If you can still reproduce this issue on the current release or on master, please reply with all of the information you have about it in order to keep the issue open.

Thank you for all your contributions!

[mfeifer]

Related to ManageIq/manageiq#18818

[mfeifer]

cc @skateman @agrare @Hyperkid123

[miq-bot]

@miq-bot unrecognized command 'unrecognized', ignoring...

Accepted commands are: add_label, add_reviewer, assign, close_issue, move_issue, remove_label, rm_label, remove_reviewer, set_milestone

[agrare]

One issue that we've had with https://github.com/ManageIQ/manageiq/issues/18818 is managers vs providers.

This endpoint is named "providers" but it actually creates managers most of the time, and providers some of the time depending on the type.

[miq-bot]

@miq-bot unrecognized command 'unrecognized', ignoring...

Accepted commands are: add_label, add_reviewer, request_review, assign, close_issue, cross_repo_test, move_issue, remove_label, rm_label, remove_reviewer, set_milestone, unassign

[agrare]

Is @miq-bot giving itself invalid commands? :laughing:

[miq-bot]

@miq-bot unrecognized command 'unrecognized', ignoring...

Accepted commands are: add_label, add_reviewer, request_review, assign, close_issue, cross_repo_test, move_issue, remove_label, rm_label, remove_reviewer, set_milestone, unassign