openfaas
Suggestion: Offer to cache templates rather than fetching latest versions
It could be that I am using the CLI incorrectly (not using some better paradigm) but most CLI tools that I use (aws, git, and others) store at least a "rc" or other config file in my home directory for common/global configuration options. It would also make sense to stick a local copy of the template directory there, rather than scattering them all over my filesystem when I make new functions.
I think this would help me reduce repetition when I use the CLI (as I could reference a profile in the rc file) and could cache templates. Thoughts?
Derek set title: Suggestion: Offer to cache templates rather than fetching latest versions
Hey thank you for your suggestion. The OpenFaaS CLI can actually pull templates from any Git repo and there is a .openfaas folder for login credentials.
We've had this suggestion a long time ago, but the templates repo is so tiny I don't think it bothers most users.
With a cached folder I'd worry that people would get out sync and we wouldn't be able to effectively update the templates with fixes etc.
You should technically have no repetition at all, the templates are meant to be pulled for you automatically into the local scope and added to your .gitignore file.
If the community/contributors think this is something they would really benefit from, would you want to work on implementing and testing the feature?
Alex
Part of the repetition is from needing to specify the prefix for my images each time, combined with different gateways (though this is less of a concern). I just imagined managing gateway URLs (if you use more than one), image prefixes, template directories, etc., could be handled more elegantly via something like the way the AWS CLI does (using profiles in a .rc file) plus maybe a cache directory.
I'm not much of a Go developer so I'm fairly certain you would not want me contributing to the CLI. I'd be happy to test though.
If I'm the only one feeling this pain, feel free to ignore the suggestion. I'll investigate using bash aliases or the like to work around it.
Part of the repetition is from needing to specify the prefix for my images each time
This is a completely unrelated point the issue you raised. You want to store your Docker Hub / registry prefix somewhere for when you run faas-cli new?
I just imagined managing gateway URLs (if you use more than one), image prefixes, template directories, etc., could be handled more elegantly
Elegance is obviously super-subjective. How many gateway URLs do you have? What ideas do you have for managing them? Right now we store a list of URLs in ~/.openfaas/config.yaml - you can find them there, but would you like to assign them names or something like that?
If I'm the only one feeling this pain, feel free to ignore the suggestion. I'll investigate using bash aliases or the like to work around it.
There's more than one suggestion here, the one you lead with was caching the template directory, but I am not sure of the value of that proposal right now. (Maybe you can explain the value you see for that?)
This is a completely unrelated point the issue you raised.
The first sentence of my issue (emphasis added):
...most CLI tools that I use (aws, git, and others) store at least a "rc" or other config file in my home directory for common/global configuration options...
I don't recall my original title (confusing as it may have been), but the original intention with this issue was to suggest storing things used by the tool in a manageable place that I could refer to (perhaps as a "profile" as the aws CLI does) for configurable items like gateway URL, image prefix, and perhaps even a set of templates I use. Note that I'm not advocating for precisely how AWS does their profiles, just the general concept.
My use case is imagining a dev, qa, and prod set of gateways, each with a different URL, Docker registry URL (or at least pattern for naming images), and set of templates. While I can certainly accommodate such a use case now, it involves a lot of CLI flags. Imagine instead being able to describe all these as a set of named profiles that I can refer to, it would make the tool more user-friendly, at least for users that work that way. That is what I meant by "handled more elegantly".
We will likely have different people managing different aspects of how we use OpenFaaS, from building templates (which will likely have some considered "stable", and others not), writing functions, and testing/validating as things move through environments.
If the solution to that part of the issue is more like git and setting up bash aliases, then so be it. I just saw this as 1) a way to capture where the template directory ends up (in ~/.openfaas/, for instance), 2) provide caching for templates you use often, and 3) provide a way to manage different configuration options per "profile".
Sorry for rambling; I was just hoping to provide enough context that my request makes sense.