Allow to load OpenAPI spec from file or URI

[exu]

Describe the enhancement you'd like to see

Instead of using external tools for loading Open API spec file I would like to attach it as file with some ref I have already spec which is single source of truth - which I prefer not to copy to other place and keep those 2 copies in sync each time.

could be nice then to have some kind of lastAppliedFileContent variable to see what was the file content during create/update of this Custom Resource.

[Tarick]

The problem here is that your file (referenced with ref) could change and we can't detect this - routing changes only when API resource is applied. And if ref doesn't change, the Custom Resource is the same every time, so this won't be considered as update.

[dobegor]

Yes, to make this work it would require to periodically poll the resource URL. Also, it would complicate resource validation - i.e. do we pull the spec and validate it from URL during resource apply? What should we do if during one the polls spec became invalid? Unavailable?

This should be designed carefully.

[exu]

Yeah that's why I've suggested some lastApplied field to fix what was really applied during create/update resource

So the workflow would be:

• create resource passing reference to API spec
• operator will take it and tries to load spec
• if loaded create valid gateway config
• write lastApplied spec into status field of CRD

does it make sense ?

[Tarick]

It does makes sense being the convenient way to supply the configuration on the first look, but here's cons:

1. Infrastructure as a code principle will not be applicable here - you won't be able to track the changes to the gateway in a source code since the configuration is now in a ref. As a workaround you'll need to store that ref OpenAPI file with x-kusk extension embedded in a place where Manager can get it and deploy it from the source code separately - either as a ConfigMap ref type or as a configuration for HTTP endpoint ref type. This resource x-kusk settings will be different for different environments (dev, staging and production differences apply), so just deploying the application with the new OpenAPI file is not enough.
2. When applying new API CR to trigger the resource reload you won't be able to see the difference before the applying (e.g. Helm diff) since settings are now outside in a ref. You'll have the diff when applying new ref resource only and this will work with ConfigMap ref type only.

[aabedraba]

We allow kusk deploy -i link.com and I believe we also support External refs now, right @kylehodgetts ?

[kylehodgetts]

The External Refs refers to schemas stored externally, either in a relative/absolute file path or hosted at a URL. As for the kusk generate, deploy etc commands, they support parsing an API spec from a URL