When trying the Python packaged example from the docs, I got the following error:

=== Build Logs ===command=./build.sh
env=[PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin HOSTNAME=python-11726-^C2.312372,"logger":"builder","caller":"builder/builder.go:124","msg":"error building source package","error":"error starting cmd: fork/exec ./build.sh: permission denied","errorVerbose":"fork/exec ./build.sh: permission denied\nerror starting cmd\ngithub.com/fission/fission/pkg/builder.(*Builder).build\n\t/go/src/pkg/builder/builder.go:196\ngithub.com/fission/fission/pkg/builder.(*Builder).Handler\n\t/go/src/pkg/builder/builder.go:121\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:1995\nnet/http.(*ServeMux).ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2375\nnet/http.serverHandler.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2774\nnet/http.(*conn).serve\n\t/usr/local/go/src/net/http/server.go:1878\nruntime.goexit\n\t/usr/local/go/src/runtime/asm_amd64.s:1337","stacktrace":"github.com/fission/fission/pkg/builder.(*Builder).Handler\n\t/go/src/pkg/builder/builder.go:124\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:1995\nnet/http.(*ServeMux).ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2375\nnet/http.serverHandler.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2774\nnet/http.(*conn).serve\n\t/usr/local/go/src/net/http/server.go:1878"}
{"level":"info","ts":1582450652.3126423,"logger":"builder","caller":"builder/builder.go:91","msg":"build request complete","elapsed_time":0.001539051}
{"level":"info","ts":1582450652.3133094,"logger":"builder","caller":"builder/builder.go:110","msg":"builder received request","request":{"srcPkgFilename":"py-packaged-b04496d5-2e8d-4909-bc8c-905bf363f012-sknlaf","command":"./build.sh"}}
{"level":"info","ts":1582450652.3133872,"logger":"builder","caller":"builder/builder.go:112","msg":"starting build"}

Fixed it by running chmod +x build.sh before zipping the files.

Is this an expected behavior? If so I can create a PR to fix the docs.

Cheers

The Istio installation doc in Fission needs an update - most of it can point to Istio's installation doc.

We generally tell people "use minscale=1" but explicitly adding a section to that usage doc will help. Include both the CLI and the spec yaml.

There are broken links found in fission architecture section. So those links needs to be fixed

There is a typo in the HTTP requests bloc, here is the fixed asset as an attached file:

As part of fission/fission#164 we need docs/updates on how ingress will work

Copied from fission/fission#499

Documentation was revamped as part of fission/fission#496 Though there are some areas which require more detailed explanation and some areas are missing in that version. This issue will act as a placeholder for next phase of documentation.

• Creating a custom environment
• Creating a custom builder environment/image
• K8S Watch Triggers examples and concepts
• Architecture and explanation of various components (Executor, Controller, etc.)
• Examples of executors and their combinations and how behaviour changes based on various parameters
• YAML specs for functions
• Istio Integration
• Container Specs
• Change README.md at the root of the project to have only basic info and point to docs
• In the context of the package, also talk about archives

Now that this is not in the URL, we should indicate the current version somewhere on the page -- probably the footer.

The URL scheme for the docs has some disadvantages:

1. Full Version in URL means docs move often
2. Full version in URL means there are a lot of duplicates, confusing google
3. Links that people save or put into blogs/tweets/forum comments stay pointed at old versions. This is especially bad with the install page, people are still installing 0.6.0 because someone printed the link in a book.

We should follow this convention instead:

1. have only one version of every page and constantly update it.
2. the url would remain constant and would not include the version number
3. the core documentation would always up to date- there would be only one.
4. we can add a comment to the top/footer of each page that "this relates to version XX, with a link to installing it, if needed"
5. If it's necessary to have docs for old versions - we can include a page that reads "see the documentation for previous versions of fission"- it'll show a list of links- linking to the individual docsfor old versions
6. these docs "directories" have to be set to "noindex" in the metadata
7. we should redirect all the old versions of all the doc pages throughout all the old versions to the new version in item #2 to avoid breaking existing stuff

As a contributor if you deploy the helm chart form source code repo, it does not work and you get an error:

Error: found in requirements.yaml, but missing in charts/ directory: prometheus

This is because you need to update prometheus dependency before you can install. We either need to document this or find a good way to download automatically:

$ cd charts/fission-all/
$ helm dependency update
Hang tight while we grab the latest from your chart repositories...
...Unable to get an update from the "local" chart repository (http://127.0.0.1:8879/charts):
	Get http://127.0.0.1:8879/charts/index.yaml: dial tcp 127.0.0.1:8879: getsockopt: connection refused
...Successfully got an update from the "fission-charts" chart repository
Update Complete. ⎈Happy Helming!⎈
Saving 1 charts
Downloading prometheus from repo https://kubernetes-charts.storage.googleapis.com
Deleting outdated charts

A document for custom environment creation by either extending existing once or writing your own

Link to install instructions for Prometheus (nothing fission fission specific here).

Document our metrics and what they mean; show some sample queries.

Based on fission/fission#1107 instructions need to be added for manual provisioning of volumes (Related: #20) to setup documentation

Copied over from: fission/fission#531

Each trigger type should have its own page, examples, and explanation of behaviour/error cases etc.

1. Draw some architecture/diagram graphs to explain how fission works
2. Advanced session/tutorial, like how to set up the environment variable .e.g
3. Check and revise existing documents to make sure its easy to understand for the newcomer.

I want to learn fission by reading through docs, and why not translate them at the same time? so I fork and create a branch translation-zh-hans and PR? or how do you want i18n managed?

I think after the migration to new documentation theme, we have broken some links that we get from search box.
For example if we try searching for kafka and click on the first link we 404. Same is happening for some other links as well.

Workflows version in the install instructions is still 0.2.0. This probably leads to lots of people still using 0.2.0.

User guide on manual volume provisioning for Fission in case there is no dynamic volume provisioner available.

Currently, most of the examples we have are a simple source file for a function. In the real world - things are more than a file. We need a few examples of main languages like Go, Python where we show a non-trivial example working as a function.

Document the persistence.* helm chart options (existing claim, storage class etc)

Write some instructions on manually provisioning storage.

Autoscaling usage doc issues:

1. Small mincpu used. Even though it's used for forcing autoscaling in a demo, people may take it as a recommendation. Suggest simply removing mincpu/maxcpu settings and leaving them as the defaults.
2. k used as an alias for kubectl
3. It should mention somewhere that the HPA takes > 1 minute to start autoscaling and N minutes to scale down (what is N? also 1?)

Our listing should be in the order

• Installation
• Using Fission
• Concepts
• Triggers
• Environments
• Examples
• Troubleshooting
• FAQs
• Contributing
• Release highlights

We need to compress the existing listing and also need to ensure it is in order for simplicity of browsing or seems natural to the new user.

We could use PodSpec how to expose secret/configmap as ENV
fission/fission#1122 (comment)

Hey there, how are u doing?

I'm using K8S from Docker from Desktop and, after creating a route for a function, the command curl localhost:<port>/<url> just works!

In the docs it says it had a bug and instructs the user to do a port-forward, which maybe is not necessary anymore?

Here's my Docker for Desktop version:

If confirmed, I can work on a PR to remove or adapt the content of the doc 💃

Cheers!

An on-premise installation may not have a load balancer for example. We need to document the details of the installation for an on-premise use case

Currently if you go to website and navigate to any page, the URL has current version's number in the URL:

https://docs.fission.io/0.7.0/usage/executor/

Instead of this, it will be better to have latest in the URL so the if user bookmarks and visits later user will be redirected to latest version's page of the documentation.

https://docs.fission.io/latest/usage/executor/

Not sure if this is possible, but nice to have.

Examples of executors and their combinations and how behaviour changes based on various parameters

Timer trigger retries a function when it fails. Today it retries up to 10 times with an exponential delay starting at a half a second.

We should document this behaviour, including how to tune it (see fission/fission#660)

We should also encourage people to test their functions with fission fn test before setting up a timer. Digging through timer logs is inherently more difficult than having an error happen while you're still setting things up.

Create an example with a route with multiple parameters.
What is the syntax?

This (https://docs.fission.io/usage/kafka-trigger-tutorial/) needs update based on fission/fission#1025

See fission/fission#1133

Document Istio integration and examples from user's POV

Document Container Specs with use case and examples