provide a CLI to assist users

[bcollard]

Some reasons why I'd like to have a glooctl portal ...CLI, after having used Gloo Portal for a few weeks:

• glooctl portal check

  • find not existing references to APIDocs in APIProducts
  • warn when the selector used for APIProducts in Environment doesn't find anything
  • report existing warnings on malformed selectors (when it complains on something like the In Operator implies a list of values, or so)
  • report errors from the (un)marshaller. Can be misindented config blocks or misconfigurations
  • apiproduct > accessLevel > products: {} is mandatory in the web UI to get a green flag
  • also leverage current glooctl check steps to verify if AuthConfig CRs are well formed and not reporting any errors
  • check for incorrect Gateway config is an APIProduct
  • report an error if the gloo-portal-controller pod is not up & running

• glooctl portal inspect apiproduct <apiproduct>

  • say which plans are available

• glooctl portal uninstall -all

  • delete the helm release and the CRDs

• glooctl portal logs level=[debug|info|warn]

  • change the log level for the controller

• glooctl portal logs --errors-only

  • show error logs from the gloo portal controller

• glooctl portal create apidoc --from-file=<path to the openapi file>

  • because it's difficult to do it manually, see here: https://gist.github.com/bcollard/98147eac7c7ab4f3e35a3f7985c9c808

• glooctl portal create css --from-file=<path to the CSS file

  • it makes things easier too

[bcollard]

Related to: https://github.com/solo-io/gloo-portal-issues/issues/153 https://github.com/solo-io/gloo-portal-issues/issues/143

[bcollard]

one more for glooctl portal check:

• report APIProduct OpenAPI stitching errors

[bcollard]

Users are struggling to find errors source. They have to inspect each and every Gloo portal resource.