backend from OAS

[eguzki]

https://issues.redhat.com/browse/THREESCALE-7715

Use current Toolbox command for importing OAS and add an option to target a backend API (instead of a Product). The OAS itself won't be stored in 3scale but a backend-api, private base URL, mapping rules and methods will be created.

3scale import openapi -d <remote> --backend <OAS>

Dev notes:

• The 3scale import openapi has a new optional param: -o json/yaml. Since this param also affects the existing product import, I have added a report to the existing product import from OAS part that will be written to stdout only when -o is added. Otherwise, for backward compat, the product import from OAS still writes progress messages to stdout.

TODO:

• Tests
• Doc
• Validations (private host must be provided either in the OAS or from the command line)

Fixes #262

[eguzki]

ready for initial review @miguelsorianod

[abarrak]

Hi @eguzki,
Thanks for the much neeeded PR 🙏
Indeed openapi import currently is missing creating the backend, and only the service/product is created.

Also, backend_usage is missing and I think it needs to be added as well to complete integration between backend and product (service).

[eguzki]

Thanks @abarrak

Also, backend_usage is missing and I think it needs to be added as well to complete integration between backend and product (service).

backend_usage attribute belongs to the product, not the backend. So, does not apply to this new functionality (although it is related of course). The question here is, how do you bind products and backends (with the backend_usage path) from a 3scale toolbox command? We are having discussions around that. Any input would be much appreciated.

[codecov-commenter]

Codecov Report

Merging #340 (4bc32cb) into main (d560651) will increase coverage by 0.06%.
The diff coverage is 99.71%.

❗ Current head 4bc32cb differs from pull request most recent head 8643a17. Consider uploading reports for the commit 8643a17 to get more accurate results

@@            Coverage Diff             @@
##             main     #340      +/-   ##
==========================================
+ Coverage   96.43%   96.50%   +0.06%     
==========================================
  Files         290      301      +11     
  Lines       15121    15422     +301     
==========================================
+ Hits        14582    14883     +301     
  Misses        539      539              

Impacted Files	Coverage Δ
.../3scale_toolbox/commands/import_command/openapi.rb	97.59% <95.83%> (-1.01%)	⬇️
lib/3scale_toolbox/cli.rb	87.09% <100.00%> (+0.43%)	⬆️
lib/3scale_toolbox/cli/null_printer.rb	100.00% <100.00%> (ø)
...s/import_command/openapi/create_activedocs_step.rb	100.00% <100.00%> (ø)
...ommand/openapi/create_backend_mapping_rule_step.rb	100.00% <100.00%> (ø)
...port_command/openapi/create_backend_method_step.rb	100.00% <100.00%> (ø)
...ands/import_command/openapi/create_backend_step.rb	100.00% <100.00%> (ø)
...import_command/openapi/create_mapping_rule_step.rb	100.00% <100.00%> (ø)
...ands/import_command/openapi/create_service_step.rb	100.00% <100.00%> (ø)
...ands/import_command/openapi/import_backend_step.rb	100.00% <100.00%> (ø)
... and 27 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d560651...8643a17. Read the comment docs.

[abarrak]

@eguzki Aha, so this PR here is meant to support importing rules, methods, etc. under backend resource?

Anyway, for the backend_usage I'm not sure if it's possible to implement inside the import of product/backend (whichever last) or introduce a new step?

I'm writing a small plugin to toolbox, and will utilize OAS import + additional creation/update to app-plans, limits, pricing, in addition to some CMS work, and my go-to for the backend_usage will be mostly the Entities::BackendUsage in 3scale_toolbox/entities/backend_usage it seems ready to use and more convenient than underlying api-ruby-client .. what do you think?

Here's a conceptional reference on the topic:
https://www.itix.fr/blog/deploy-apis-from-your-cicd-pipeline-with-the-3scale-rest-api/#backend-usage

[eguzki]

Aha, so this PR here is meant to support importing rules, methods, etc. under backend resource?

Exactly. Create a 3scale backend out of a OAS doc.

Anyway, for the backend_usage I'm not sure if it's possible to implement inside the import of product/backend (whichever last) or introduce a new step?

The question is about which toolbox command makes sense (and what is the signature of it) to bind N backends to some product That command would need a set of N backend_usages, one for each N backends.

I'm writing a small plugin to toolbox, and will utilize OAS import + additional creation/update to app-plans, limits, pricing, in addition to some CMS work,

Cool. If you do not mind, let us have a look at it when it is finished. We can review it and add it to the core command list (maybe with some modifications) if it makes sense for somebody else.

The issue (as I see) with the pluging you are describing is that it requires a lot of inputs. 1) the oas, 2) app plans resource. The toolbox provides two commands to do that separately:

• https://github.com/3scale/3scale_toolbox/blob/main/docs/export-import-product.md
• https://github.com/3scale/3scale_toolbox/blob/main/docs/export-import-app-plan.md

and my go-to for the backend_usage will be mostly the Entities::BackendUsage in 3scale_toolbox/entities/backend_usage it seems ready to use and more convenient than underlying api-ruby-client .. what do you think?

To add backend_usageelements to a product, just use Entities::BackendUsage. The primitives to manage backend_usages are easy to use. The challenging part is expose a easy-to-use command for the users to manage them.

Here's a conceptional reference on the topic: https://www.itix.fr/blog/deploy-apis-from-your-cicd-pipeline-with-the-3scale-rest-api/#backend-usage

That is the primitive I was referring just now. That is implemented in the api-ruby-client lib.