Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Execute Export template from API #3665

Closed
itmicus opened this issue Nov 3, 2019 · 7 comments
Closed

Execute Export template from API #3665

itmicus opened this issue Nov 3, 2019 · 7 comments
Assignees
Labels
status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application
Milestone

Comments

@itmicus
Copy link

itmicus commented Nov 3, 2019

Environment

  • Python version: 3.7.3
  • NetBox version: 2.6.6

Proposed Functionality

Execute Export templates from Netbox API

Use Case

Now, I can execute Export templates from UI, but I need get export template from API by my script.
Netbox using authentification for access to UI

Database Changes

None

External Dependencies

None.

@jeremystretch
Copy link
Member

jeremystretch commented Nov 4, 2019

I don't think that returning rendered export templates via the REST API is feasible given that all API responses must be structured JSON, and export templates by nature produce arbitrary output. We could encapsulate their output within a JSON field, but that 1) introduces the risk that we won't be able to properly serialize rendered content, and 2) greatly reduces the utility of the feature.

It sounds like what you really need is just a mechanism for reliably authenticating to the current mechanism for rendering export templates, is that correct?

@jeremystretch jeremystretch added the status: under review Further discussion is needed to determine this issue's scope and/or implementation label Nov 4, 2019
@sdktr
Copy link
Contributor

sdktr commented Nov 4, 2019

Maybe these exports should be made async based on the RQ worker? API could then be used to schedule the export, publishing a link to a file that contains the output once ready.

@itmicus
Copy link
Author

itmicus commented Nov 5, 2019

I don't think that returning rendered export templates via the REST API is feasible given that all API responses must be structured JSON, and export templates by nature produce arbitrary output. We could encapsulate their output within a JSON field, but that 1) introduces the risk that we won't be able to properly serialize rendered content, and 2) greatly reduces the utility of the feature.

sure, I think so, it is not good idea, responcing rendered tempalte in JSON field.

For example,
GET /api/export-template/{ID}/
Content-Type: {MIME type from export-template}

It sounds like what you really need is just a mechanism for reliably authenticating to the current mechanism for rendering export templates, is that correct?

It is correct, but I think using the API is more logical

@jeremystretch
Copy link
Member

Maybe these exports should be made async based on the RQ worker? API could then be used to schedule the export, publishing a link to a file that contains the output once ready.

There is no need for that. Export templates are rendered on-demand, in the same manner as a list of objects fetched via the REST API. The only additional overhead is whatever rendering logic is imposed in a template.

@darcynz
Copy link

darcynz commented Feb 11, 2020

We've approached this feature request as we build our Automation Pipeline using Netbox as the source of truth for configuration.

Whilst we can get the data via API calls to the objects, using export templates would help present the data organised for models that we want to deploy. This would need to be via API to be be part of our CICD pipeline.

Could one option be to create an API first export template that would conform for serialization purposes?

@jeremystretch jeremystretch added API change status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application and removed status: under review Further discussion is needed to determine this issue's scope and/or implementation labels Mar 30, 2020
@jeremystretch jeremystretch self-assigned this Apr 8, 2020
@jeremystretch
Copy link
Member

I've done some digging into this, and while I have gotten it to work, I'm concerned about the performance implications. Using a custom renderer, we can't use the response data directly because it's already been serialized, and an ExportTemplate expects to work with a raw queryset (or at least a list of instances). While we can access the original queryset from the view and perform the same filtering, this is done only after the serialized response is generated, so we incur the overhead of both serialization and template rendering for a single request.

Ideally, we want to be able to bypass model serialization entirely. I'm not sure that's feasible given that it's obviously a central component of the API framework. We may have to come up with an alternative approach.

@jeremystretch jeremystretch added needs milestone Awaiting prioritization for inclusion with a future NetBox release and removed status: accepted This issue has been accepted for implementation labels Jul 24, 2020
@jeremystretch jeremystretch removed their assignment Jul 24, 2020
@jeremystretch jeremystretch added this to the v2.12 milestone May 10, 2021
@jeremystretch jeremystretch added status: accepted This issue has been accepted for implementation and removed needs milestone Awaiting prioritization for inclusion with a future NetBox release labels May 10, 2021
@jeremystretch
Copy link
Member

Going to take another stab at this for v2.12

@jeremystretch jeremystretch self-assigned this May 11, 2021
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 10, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application
Projects
None yet
Development

No branches or pull requests

4 participants