* skeleton for envtest fission
* Refactor code and add CLI test
* hack
* Update server test
* remove skip-ci for lint tests
* Pass client go storagesvc
* Add clientGen interface across code
* Fix storagesvc test
* Fix cmd client
* add retry in server test
* Fix concurrenct access to pool deployment
* Remove old executor test
* get rid of ginkgo/gomega
* disable flaky test
* flaky test
* revert ci change
* handle err from ParseBool
---------
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Co-authored-by: Pranoy Kundu <pranoy1998k@gmail.com>
- Update kubernets version 1.23+
- Update post chart install notes with namespace info
- Update upgrade notes in chart
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
- added retainPods flag to take in the number of specialized pods to retain
- add retainPods in both the create function and update function command
- modify crd keys to be typed instead of string
- keep track of function generation in case of update function operation
- add delete handler function to make sure specialized pods are deleted in case function is deleted
---------
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Signed-off-by: Pranoy Kundu <pranoy1998k@gmail.com>
Co-authored-by: Pranoy Kundu <pranoy1998k@gmail.com>
the FISSION_..._NAMESPACE environment variables are used by all services during init
to check if the CRDs are loaded.
Move them to the 'fission-resource-namespace' macro to ensure all services know the relavant namespaces.
Signed-off-by: Anthony King <anthony@datapane.com>
* Add fixes for failure in specialization
* reduce specialization in progress and remove expired requests from queue when specialization is timed out
* rename markSpecializationFailure and remove logger from the queue
* refactor clean up code in api.go and add test case for queue
Details:
- Cleanup svc waiting for the counter in the pool manager if specialization fails
- Cleanup active requests counter in pool manager if client exists the demand for function service while we have allocated function service
- Consider specialization timeout if pod ready timeout > specialization timeout in waiting for ready pod. We also consider if the request to choosePod is cancelled.
- We ensure if we have requests waiting for service requests but if there is no pod in the specialization we clean up those.
---------
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Co-authored-by: Pranoy Kundu <pranoy1998k@gmail.com>
* add functionality to wait for specialization by keeping track of incoming requests
* format executor package
* fix required capacity to specialise new pod condition
* move handling concurrency logic into pool cache from executor
* remove unused methods and structs
* implement queue in to store the svc wait
* create a queue struct and its methods to handle concurrent inputs
* use newly created queue to store waiting for svc requests
* add waiting requests in queue and use them when a svc is ready
* set function to request in queue if the context is still alive
* remove concurrency approach to set svc for waiting requests
* update the active requests whenever requests from pool are assigned a svc
* add doc to define why the conditions exist
* remove unwanted params in strcut and clean up code
* set error while getting svc value if sum of specialization in progress and specialized is only more than concurrency limit
* remove duplicate functions and unnecessary values in struct
* close svc channel on set value and create constants for default concurrency and rpp
* get next value in queue in case context is timed out for fetched value
* remove specializationInProgress counter from pool cache
* return in case the queue is empty wihle setting func to svc
* test getSvcVaue and setSvcValue in poolcache
* add unit tests for GetConcurrent and GetRequestsPerPod methods
* reorder imports
* add fuzzy testing for getSVCValue and setSVCValue in poolcache
* restructure go mod file and update pool cache test cases
* Add tests and bug fixes
* refactor code and add test cases
* add svcWaiting check while setting svc value
---------
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Co-authored-by: Sanket Sudake <sanketsudake@gmail.com>
* use flag FnExecutionTimeout instead of FnTestTimeout
* use flag FnExecutionTimeout instead of FnTestTimeout
* keep FnTestTimeout and FunctionTimeout both
* code review changes
Signed-off-by: Shubham Bansal <shubhambansaliimtgn@gmail.com>
---------
Signed-off-by: Shubham Bansal <shubhambansaliimtgn@gmail.com>
* changes to push images in github container registry
* reverting changes for helm chart to pass CI test
* use gitURL instead of whole URL
* use gitURL instead of whole URL
* added release process for docker.io
* removed trailing spaces
* added support for multi arch images in GHCR
* set authorization header for fission version and check command
* display warning if response status is unauthorize or forbidden
* passing context to http request
* create roles for custom resource in function and builder namespace
* Create roles for CR for builder in function and builder namespace
* convert warn to info to remove error stack trace
Merged pool cache package into fscache to avoid import cycle.
Also changed all types in pool cache from interface to specific
types.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Fix issue with updating time trigger without --cron flag
* Add check with ResourceVersion
* Change in UpdateFunc
Signed-off-by: Shubham Nazare <shubham4443@gmail.com>
Signed-off-by: Shubham Nazare <shubham4443@gmail.com>
* service account changes for fission-builder
* moved code into executor
* changed default timing to 30 min
* code refactor and add new roles for executor
* create role if serviceAccountCheck is enabled
* Use informerfactory across executor
* Run function informer for poolpodcontroller if istio enabled
* Use same namespace for secret as keda mqtriggers
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Remove cluster role references
* Convert secret/package getter cluster roles to role
* Remove all cluster role binding permissions
* Remove unwanted permission
* Try removing all RBAC-related code
* Remove additional constants
* Add functionality for service account checks
* Restrict permission across services
* Remove package informer factory from the executor
* Revert service account check code for now
* Skip adding roles in place of cluster roles
* Remove additional permission from the router
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* trigger test job to ensure backward compatibility
* update builder and function namespace in the CI test
* resolve namespace to show logs for fission-CLI
* export function-namespace variable
* Use a common script for an old and new test run
* Revert empty namespace values in the chart
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Co-authored-by: Sanket Sudake <sanketsudake@gmail.com>
* Replace all cluster roles with autogenerated namespaced roles
* Use cluster role only for preupgrade api extension permissions
* Correct role definition typos
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Co-authored-by: shaunak_deshmukh <shaunak@infracloud.io>
Co-authored-by: Sanket Sudake <sanketsudake@gmail.com>
Consider specific namespaces mentioned by the user in building informers in the executor
- Confimaps
- Secrets
- Deployments
- Services
- Pods
- Replicasets
We enable security context by default now, so that the fission pod do not have root access to the system.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* handle error condition in fission fn log command
* use the single stream for log exclude fetcher logs
* add all pods in the fn logs command
* update the previous stable version
* remove proxy to the controller for influxdb call
* stop running controller if influxdb flag turned true
* port-forward for influx DB
* remove controller dependency from test case
* port forward to influx DB if URL not provided by the user
* archive pruner test
* Backup Prometheus data from CI run
* use `kube-prometheus-stack` instead of `prometheus`
* Add dump-analyzer script
* Fix monitor helm chart values
* Update readme for dump-analyzer
* Disable grafana and alertmanager
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* handle error condition in fission fn log command
* use single stream for log exclude fetcher logs
* add all-pods in fn logs command
* update previous stable version
* add controller enablement flag
* throw an error if service not found
* add logs from Kubernetes in function log command
* pass context in function param
* add pod-namespace in function log command
* pass context in function param
* search for the pod in fn ns in the test
Currently, we create Fission resources in the default namespace, function-related resources are created in the fission-function namespace, whereas builder resources are created in the fission-builder namespace. This causes confusion for a lot of users.
In this fix, we allow the user to set the function and builder namespace empty so that function and builder resources are created in the same namespace as the function resource always.
If the user desires older behaviour they can functionNamespace and builderNamespace the same previous before the upgrade.
* use default namespace for fission function and builder
* support for existing fission namespaces
* Replace builder and function namespace with template
* Fix namespace creation template
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Convert ClusterRoles to Roles for all components for multiple namespaces
* Added templates for rules and role generator to dynamically generate roles for each component
* Fix role-generator component templating
* Enable namespaces variable for preupgradechecks
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Co-authored-by: shaunak_deshmukh <shaunak@infracloud.io>
Co-authored-by: Sanket Sudake <sanketsudake@gmail.com>
* Add variables for function/builder namespace in the test
* Allow different namespaces in integration tests
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Co-authored-by: Sanket Sudake <sanketsudake@gmail.com>
Use the Kubernetes and Fission Client from CLI instead of Controller API.
This removes port-forwarding for the controller across Fission CLI mostly.
* Use configurable client in CLI
* Move resource namespace under cmd client
* use server to get fission version
* get archive with URL
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Co-authored-by: Sanket Sudake <sanketsudake@gmail.com>
We allow functions to refer to configmap/secrets. We are monitoring all namespaces for config maps and secrets and also allow cross-namespace references.
This fix monitors configmaps/secret updates in specific namespaces. Also, we ignore cross-namespace references for configmap/secret updates.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* added unit test for setup role binding method
* changes to throw an error in case of mismatch in cluster role name
* changes to add a check for role kind
* Role and RoleBinding for fission-fetcher and fission-builder can be created in additional namespaces
* Added template file for fetcher and builder role and rolebinding
This PR moves fission CLI as closer as possible to kubectl command behaviour. We have improved namespace handling behaviour across CLI.
* add namespace param for fn and env
* use common fn for ns check
* update validation
* default namespace for httpTrigger, env and package, config and triggers
* use default ns
* add namespace filter to spec
* add forceNamespace flag
* set current namespace
* add default namespace in config
* add namespace specific destroy
* add all namespace in the list of resources
* add namespace as global tag
* use %s instead of %v
* add test cases for namespace
* use ns in get all functions
* Separate service accounts for each component
* Permission changes per component
* Fixed fluentbit permissions
* added hooks to pre-upgrade service account and role
* Adjusted hook weights for pre-upgrade hook
* Replaced * with explicit permissions
Added properties to configure object reaper interval, global and specific to exec type.
OBJECT_REAPER_INTERVAL - global
NEWDEPLOY_OBJECT_REAPER_INTERVAL - for new deploy type
CONTAINER_OBJECT_REAPER_INTERVAL - for container type
POOLMGR_OBJECT_REAPER_INTERVAL - for poolmgr
These changes have specifically been made for Kafka connector. This will expose a new metric named `fission_mqt_message_lag`, which will show a number of messages lag per topic and partition.
We can use this metric in the auto-scaling of the pod for the new deploy type executor function. While creating a new deploy function we need to add hpa metrics of external type inside the function definition.
* allow two HTTP triggers with no URL and different prefix
* update dependency
* Fix controller existing tests
* Ensure namespace cleanup in API test
* update test cases
* handle error conditions in test
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Co-authored-by: Sanket Sudake <sanketsudake@gmail.com>
* Add grafana dashboards and configmap creation
* Fix Data source, job and template rules
* Add units to all panels
* fix units and fix linting issues
* Enable verbose linting for dashboards
Co-authored-by: shaunak_deshmukh <shaunak@infracloud.io>
Configmap inside pods for newdeploy and pool manager executor type were not being updated if the user update the configmap.
This fix will help to update the pods for both executor type with new configmap. As per the changes if there is any configmap update then pods will get restarted for both executor type and then it will refer new configmap.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Co-authored-by: Sanket Sudake <sanketsudake@gmail.com>
* Updated all Go language dependencies to latest version available
* Formatted all files as per gofmt
* Update Golangci-lint version to 1.48.0
* Updated action version wherer application in Github workflows
* Updated Kubernetes version to latest available
* Remove "io/ioutil" references and replace with "io"/"os"
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
1. Use websocket support introduced in Openetelemetry Librarries
2. Use propagators settings introduced in Opentelemetry Go SDK
3. Use samplers settings introduced in Openetelemetry Go SDK
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
The users can now set the pod spec for builder and fn pods via helm chart.
Currently we have set some default securitycontext for the pods. Before there were no permissions set and the user would by default enter root when kubectl exec into pod. Now the permissions have been set and the user will not be able to access root directory in poolmgr and newdeploy pods.
* Add API for listing storage service archives
If id is mentioned we allow user to download specific
archive. If id is not mentioned we list all archives
present with storage service.
This will allow us to build CLI with storage service
and help users to debug storage service.
* Added commands for storagesvc cli and functionalities
* Reusing code and added geturl and download.
* Fixed geturl for localstorage.
* Fixed description of fission archive command
* Added unit tests for function getstorageurl
* Added integration test for archive cli
Co-authored-by: Sanket Sudake <sanketsudake@gmail.com>
* allow buildcmd command to process arguments
* Add unit tests for builder with different scenarios
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Co-authored-by: Sanket Sudake <sanketsudake@gmail.com>
* Add pre-check flag to root cmd
* Make precheck flag optional
* Remove pre from global optional flag
Signed-off-by: Shubham Nazare <shubham4443@gmail.com>
Following component has been updated with securityContext -
1. buildermgr
2. controller
3. executor
4. kubewatcher
5. router
6. timer
7. storagesvc
* Removed the security context from fetcher as per the offline discussion
* Add support for custom metrics for HPA
* Cleanup TargetCPUPercent references from possible places
* HPA v2beta has 80% default cpu limit if not set
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Migrate HPA v1 to v2beta2
HPA v2beta2 is defined and supported from 1.19+ onwards.
Also HPA v2 is stable from 1.23 onwards. As we support 1.19+
onwards using HPA v2beta2.
This change is base for custom metrics support we want to add
later by modifying Function spec.
* Add unit tests for hpa operations
* Use constants instead of strings
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Use latest goreleaser with GOAMD64 support
* Update Go version to 1.18.1
* Hardcode GOAMD64 in cli install
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Created separate file for authmiddleware fn
* Optimize auth login and middleware
* Added unittests for authmiddleware
* Fixed authURL
* Removed featureConfig as global variable
* Fix integration test according to examples repo changes
* Fix integration test path for go module-example
Co-authored-by: Sanket Sudake <sanketsudake@gmail.com>
Using interface makes it easy to create a fake client and unit test
a specific portion of the code. We should be able to more write unit
test and increase coverage of code with this change.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
In pool pod controller we were using pool namespace
rather than pod namespace in cleanup which was causing
issue in few scenarios. Using pod namespace now instead.
Also add unit test for scenario which was failing.
Using kubernetes client interface now across instead of
kubernetes ClientSet for testing.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Defining httpserver package to capture httpserver shutdown and
introduces uniform running of http server across codebase.
* Add unit tests for httpserver
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
- Enabled metrics in storagesvc, buildermgr and controller.
- Added a middleware in storagesvc, router, executor and controller to monitor total number of http requests, each request's duration and number of requests that are currently being served. These requests can be filtered on their path, method or statuscode.
- Removed functionCallDuration and functionCallResponseSize metrics from router.
- Removed funcAliveSummary, funcIsAlive, funcReapTime and idleTime metrics.
- Replaced function calls for collecting metrics to direct metric calls.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Co-authored-by: Sanket Sudake <sanketsudake@gmail.com>
Currently we dial on localport and wait until, port forwarding
is done. Using channel instead from forwarder to wait explicitly.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
We are removing Fission deprecated Azure Storage Queue connector and
planning to adopt Keda going forward to have better
delegated functionality and more rich support.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
We are removing Fission deprecated Nats connector and
planning to adopt Keda going forward to have better
delegated functionality and more rich support.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
We should avoid tap service call to executor if service URL retrieved from executor is empty.
Added sanity checks to ensure that.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
- Use mqtrigger watch instead of polling mqtrigger every 5 seconds
- Added metrics to monitor no of subscriptions, and no of messages per subscription
- Add standard go metrics exported by prometheus
- Enable prometheus discovery for mqtrigger pod
- Optimized mqtrigger manager cache
- Add unit tests for mqtrigger cache
Co-authored-by: Sanket Sudake <sanketsudake@gmail.com>
* Update Go version to 1.17 and dependencies
* Changes in ProbeHandler and LifeCycleHandler
* Update CRD definitions
* Update Go version to 1.17 in Github Actions
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Removing Prometheus dependency from fission chart
* User should install their own Prometheus installation
* Install Prometheus chart in Github CI workflow
* Change Prometheus query logging to debug
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
This change mainly fixes few things around router and executor
exposed metrices.
1. We are trying to follow standard in metric names.
2. Lables such as namespace are colliding with kube-prometheus standards
so they are getting relabled to exported_namespace. Added function prefix
to resolve this.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* fix helm templating on resources of router deployment
* add resources attribute to other fission deployments
Co-authored-by: crmendes <carlos.mendes@kelvininc.com>
* Change RBAC resource names work for multiple Fission release
* Fetch secret configmap and package cluster role based on the release name
* Remove default namespace hardcoding from helm chart
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* If a bucket already exists with the same name, allow the user to use that one
* Abstracted create or get a storage container
* Check err when the con is empty and return container name with error
- Currently, fission components don't handle shutdown signals.
So we don't get any to do the required cleanup before the fission process
exits. Adding signal capture process with cancelling context so
that all dependent processes stop working when the process gets term
signal.
- Set log level to error in otel shutdown function
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Currently when any of fission component exists, we fail to sync
log as logger.Sync is not called before exiting.
Restructured code so that we can logger.Sync before existing from
the fission bundle component execution.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Reactored ready pod controller code to user lister and cache sync checks,
so that we avoid querying lister if cache is not synced in choodPod function.
Also, as noticied in #2258 we were initializing workqueue in goroutine
which was causing nil pointer reference. We have moved it out of goroutine
and kept specific parts in goroutine.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Currently default pod termination logs go to /dev/termination-log.
With CI we need to change customize path somewhere to /var/log for
exporting logs with the kind export logs command.
Setting FallbackToLogsOnError as termination policy for skaffold.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
In Fission CI as well in a couple of scenarios, noticed Fission pods
getting preempted when Function pods are getting created. As both
Fission components and function pods have the same priority class
fission component pods might get preempted. It to be recommended to
set higher priority class for components such as Fission router, executor,
controller so that Fission functioning doesn't get disrupted.
Most of the Fission components work fine with restart except the executor. So
user should set priorityClass for Fission executor.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
- New flag `--specignore` has been added for command fission spec [list | validate | apply | destroy]
- This flag is optional.
- The default spec ignore file name is `.specignore`, if the flag is not used
- The spec ignore file existence will be checked in the `--specdir` path
- If spec ignore file is passed to the flag, with a name other than .specignore and if it does not exist in the `--specdir` path then an error will be returned.
- `--specdir` will be the root path against which the patterns will be evaluated
- The behaviour of the spec ignore file will be similar to .gitignore (only for yml and yaml files). For reference: http://git-scm.com/docs/gitignore
We would like to deprecate Fission Nats Integration and recommend
user to use Fission Keda Nats connector to handle Keda events.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
The io/ioutil package has been deprecated as of Go 1.16, see
https://golang.org/doc/go1.16#ioutil. This commit replaces the existing
io/ioutil functions with their new definitions in io and os packages.
Signed-off-by: Eng Zer Jun <engzerjun@gmail.com>
Added options to allow disabling of pre-upgrade checks,
also providing options to mention image and image tag
for pre-upgrade.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Sync a few files from fission-all to fission-core chart
* Change values in fission-all chart
We keep the following components by default disabled now, which were enabled by default earlier.
1. nats - Fission Nats integration
2. influxdb - Influxdb and logger component
3. prometheus - Prometheus disabled by default
4. canaryDeployment - Disabled by default
This change reduces the need for a fission-core chart and we can configure
values of fission-all so that it can provide the behaviour of fission-all
as well as fission-core.
* Remove fission-core chart
* Add README in the fission-all chart
* Rename clusterrolebinding fission-crd to fission-cr-admin
* Add icon and sources in helm chart
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* security: Update go-uuid to recommended version
* security: Update mholt/archiver dep to recommended version
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Samplers: Check PR/helm values for supported types
* Propagators: Check PR/helm values for supported types
* Added tracing support via fission CLI
* Use parentbased_traceidratio as default sampler with 0.1 ratio
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Capture important open telemetry events with span in fission
* Add context to missing HTTP calls
* Add Trace ID in logs
* capture trace id in the proxy handler function
* Always registry tracer to get traceID
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
When fetch request is received by fetcher, it fetches
package information. Checking if package resource version mentioned
in fetch req matches with one received. Adding warning for now,
in future we need to ensure we give error if resource version
are not matching.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
In upgrade tests, sometimes in race condition pool manager podlister
takes time to sync in which case, poolpodcontrolller get nil reference
for gpm.podLister. Passing podInformer to poolpodcontroller so that
we wait for podInformer cache to sync.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
With addition of prefix based routes in 1.13.1, we have turned
all internal routes prefix based. This is causing wrong responses
in functions names with common prefixes such as `hello-world` and
`hello-world-consumer`. This patch fixes it where we add a fix route
for function name and prefix path for function name with `/`.
We improve overall prefix path handing with fix and prevent breakage
for existing flow.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Using controller-runtime zap integration which is aware of Kubernetesobjects and logs only name+namespace of the object when complete runtime.Object compatible type is given to logger.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Signed-off-by: Sanket Sudake sanketsudake@gmail.com
- Use informers and listers in executors
- Passing context properly in pool manager executor
- Environment updates in the pool manager would not cause updates in the deployment
- Environment update minimizing downtime
- Use replicaset controller and environment delete triggers to cleanup specialized pods
Generally using typed informers is more standard practise
than using SharedIndexInformer(SII) implicity. SII also lack
listers provided by informer factory and few other high level
abstractions.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Currently most of informers used in Fission are using resync
period of 30sec which is quite low and causes lot of disturbances
in overall system. Since informers already have watchers which would
be delivering events to the handlers. If any handlers require lower
sync period they should register handler with `AddEventHandlersWithResyncPeriod`
instead of we generaling informer.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* add opentracing section and otelCollectorEndpoint
* initialize OTLP exporter
* pkg/controller: changes for context propagation
* pkg/executor: changes for context propagation
* pkg/fetcher: changes for context propagation
* pkg/router: changes for context propagation
* pkg/storagesvc: changes for context propagation
* set no default value for otel collector endpoint
* update readme and add notes to charts
* move common code to pkg/utils/otel
* adding fn and env as attributes
* don't use otelhttp transport for websocket
* URL ignore with common filter UrlsToIgnore
Note: The web socket example does not work when using OTEL HTTP. Here is an issue related to that on open-telemetry/opentelemetry-js-contrib.
Signed-off-by: Gaurav Gahlot <gauravgahlot0107@gmail.com>
Co-authored-by: Sanket Sudake <sanketsudake@gmail.com>
The patch adds few improvements in pool manager and adds better
function composability by reorganizing code.
1. Added created status in get pool call
2. Improved logging in certain areas and having logger per component
3. Separated deployment-specific code in diff file for extensibility
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Currently when we update env, even if we dont have newdeploy related
functions env is getting is getting triggered. Added filter in finding
related functions to avoid this behaviour.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Change Ingress version from v1beta1 to v1 for K8s 1.22+ compatibility
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Minor fix
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
PR adds a new executortype which supports running containers as functions. New CLI under functions is added to create container as functions.
Co-authored-by: Harsh Thakur <harshthakur9030@gmail.com>
Co-authored-by: Sanket Sudake <sanketsudake@gmail.com>
1. Support for adding labels and annotations to functions & environment via fission CLI through create & update command.
2. Change ensures labels and annotations assigned to the environment would reflect on pods created via executor type pool manager and new deploy.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Retrieve pod metrics only if metrics server is running
Currently we query pod metrics every 30 sec which floods executor logs,
added check which confirms if metrics server is running then only we start
querying pod metrics for identifying CPU utilization.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Fixed couple of typos and misspells with Go CI
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Remove unnecessary conversions with Go CI
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* add multi env and multi k8s support on integraation tests
* test workflow
* test workflow
* test workflow
* remove test branch name
* correct kind action with image and version
* use same kind version as per kind images
* use OS as ubuntu-latest
* fetch upstream
* add .github/workflows to paths
* resolve conflicts
* make kindimage appear first on workflow
Co-authored-by: Sanket Sudake <sanketsudake@gmail.com>
* Correct release name in release script for non helm install
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Increase test timeout to 20 minutes
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Enable codeql for master only
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Added GCP PubSub Image, enabled Keda by default and updated versions of all Keda connector images
Signed-off-by: Vishal Biyani <vrbiyani@gmail.com>
* Fixed the hyphens, it's been long since I have written Helm templates :)
Signed-off-by: Vishal Biyani <vrbiyani@gmail.com>
* Fixed the hyphens, it's been long since I have written Helm templates :)
Signed-off-by: Vishal Biyani <vrbiyani@gmail.com>
* Update charts/fission-all/values.yaml
Co-authored-by: Harsh Thakur <harshthakur9030@gmail.com>
* Update charts/fission-core/values.yaml
Co-authored-by: Harsh Thakur <harshthakur9030@gmail.com>
Co-authored-by: Sanket Sudake <sanketsudake@gmail.com>
Co-authored-by: Harsh Thakur <harshthakur9030@gmail.com>
* Add a SharedIndexInformer for services and deployments to NewDeploy executor.
This brings the NewDeploy executor behaviour into sync with GenericPoolManager behaviour
by caching Kubernetes services and deployments used in per-request function validation.
* Create informers in executer by executor label
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Co-authored-by: James Sinclair <irgeek@btc.com.au>
* Enable prefix based routing
Signed-off-by: Harsh Thakur <harshthakur9030@gmail.com>
* Optimize checking condition
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Disable few tests
* disable router modification for now
* run code generator
* Collect fission dump in CI
* Enable all tests back
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Remove unwanted code
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Add prefix support at more places and couple of todo's
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Few more changes
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Improve function trim support
* Support for prefix based urls in fission function test
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* multi route for fission function test
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Improve validations in trigger creations
* Adjust leading / in url from fission
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Change suburl to subpath for function test
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Co-authored-by: Sanket Sudake <sanketsudake@gmail.com>
* Add a warning if spec is applied on a dirty worktree
* Update go dependencies after rebase
* Use the console package for showing the warning
* Fix merge conflicts
* Handle errors and use better messages
Co-authored-by: Sanket Sudake <sanketsudake@gmail.com>
Since we recently migrated all fission examples to fission/examples repository, we need to change
respective references.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
We are facing issue in CI for multiple PRs due to mlock. It depends on kernel version or ulimit. Trying to switch to latest go version from 1.14 and see if it helps!
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Series are sorted internal by "order by", but the set of all series returned is not. Tried some ways to sort completely on database, found no way .. client side sort works at least
Co-authored-by: Vishal <vishal-biyani@users.noreply.github.com>
Adding once only execution pattern to pool manager based functions. This is for use cases where you don't want to share the samne pod for another execution instance!
In test_mqtrigger.sh and test_mqtrigger_error.sh tests, we timeout program
if not received right output. Ensuring we capture timeout signal and do program
cleanup accordingly. Also printing due to which signal program failed.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Moved out environments and examples out of main Fission repo to their own repo. This is to allow changes to environment releases to be independent of main Fission releases.
Websocket event support for cleaning up pods only after WS connection is terminated. The support for websocket is right now in the environment itself and router simply acts as a proxy for WS communication!
Increase the default concurrency to 500 from 5 set in the function. Usually, it is good to error on the higher side and if needed, users can always fine-tune it to their needs.
This feature enables routing more than one request to a pod at the same time. This is the first draft of the work and might involve more optimizations later.
Passing information of function from router to executor is more efficient than calling the K8S API. This change does that instead of passing only metadata and then executor calling the K8S API again.
A ready pod which can be specialized was fetched for every function earlier, this has been changed to a queue and cache implementation in client-go to improve performance.
Poolmanager when tested at high load had some issues and this PR fixes one set of them which were found so far.
Co-authored-by: Vishal <vishal-biyani@users.noreply.github.com>
Concurrency in the pool manager allows specializing pods concurrently based on a specified limit.
Co-authored-by: Vishal <vishal-biyani@users.noreply.github.com>
Attribute enableServiceLinks can be now configured in PodSpec so that environment variables are not injected in function pods and DNS is used for discovery
This PR let the controller returns the detail error message
of kubernetes error which makes users understand what's
happening instead of meanless error msg.
This PR changes the behavior of controller API which
wrongly exposes sensitive data to the client. Now, the
API only returns success if secret/configmap exists;
otherwise, an error will be returned.
In some cases, creating a package and querying the package info
immediately the Kubernetes API server will return "not found"
error. So retry the query again after some time.
In some cases (#1384), users may want to access the file in the directory of deploy archive, however, we use the function UID name as the directory name and make it difficult for users to use as they don't know the real path of the directory.
This PR uses the fix name "deployarchive" to make things easier.
If the user applies package YAML file has no status field,
the package won't be able to be compiled or deployed due
to lack of status. This PR aims to add a check at buildermgr
to set initial package status to those packages.
Executor wrongly deletes role bindings if the user
creates an environment in the reserved namespaces. This
PR is a quick fix to solve the problem by checking if
an environment is under reserved namespaces.
This PR adds a fake controller client for local CLI operations like
offline spec generation or for unit test purposes. The fake client
now only implements the "Version()" function and more functions
will be implemented once we figure out how to achieve the goals
mentioned above.
The root cause of the problem is that eagerPoolCreator
tries to create the deployment when the poolmanager
is trying to delete it. To avoid this, start eager pool
creator after executor starts serving requests.
Adding fission spec list functionality. It lists Functions, Environment, Packages, HTTPTrigger, MessageQueueTriggers, Canary Config, TimeTrigger, KubeWatch created by an application specification.
The 3rd party package version used by the go server
may be different from the one in the user's source code
and will cause plugin version mismatched. Hence, we
should never import any external packages except the
Fission or built-in packages.
This PR replaces all 3rd-party packages with built-in packages.
This PR adds an interface for controller API client, it allows us to
implement mock API client for unit testing with ease and we are
able to generate spec file without accessing the real Fission server.
The pod template is embedded inside the deployment. So if
the pod annotation contains instance-id, the deployment
will get updated and thus triggers a rolling update whenever
a new executor starts which is unwanted.
After this PR, poolmanager will patches instance-id when a
pod is chosen for a function.
For newdeploy, unlike poolmanager manages the lifecycle
of function pod directly, newdeploy is only responsible
to create the deployment so we append instance-id to top-
level controller (deployment) only.
We used to update timestamp in the deployment environment field
in order to trigger a rolling update when the function referenced
resources get updated. However, use timestamp means we are not
able to avoid triggering a rolling update when executor tries to adopt
orphaned deployment due to timestamp changed which is unwanted.
In order to let executor adopt deployment without triggering a rolling
update, we need an identical way to get a value that can reflect res-
ources changed without affecting by time.
To achieve this goal, the sum of the resource version of all referenced
resources is a good fit for our scenario since the sum of the resource
version is always the same as long as no resources changed.
When a new executor starts up, it adopts the orphan kubernetes resources created
by the old executor instance. However, the adopted resource won't reflect the changes
come with the new executor, for example, the fetcher image inside won't be changed.
To solve this, executor updates the resource spec (HPA/Deployment/Service) with the
latest resources spec. By doing this, we can prevent the inconsistency between resources
created by different executor instance, also minimizes the impact on users.
Previously, once the executor is deleted for reasons (like upgrade or cluster scale-in),
the new executor deletes all existing resources created by the old executor and creates
new one. This mechanism becomes a problem when there are requests connecting to the
existing pods. Also in the worst case, the cluster may not have enough resources to create
new pods and cause service downtime.
This PR let each executor type adopts existing resources before starting the executor
API services, and so the alive connections won't experience failure. However, the requests
send to the function that doesn't have alive function pods will still fail due to the
executor is in bootstrapping.
The pool manager keeps terminating function pod periodically even there are
traffic to the function. The root cause is that executor, poolmgr, newdeploy
manage their own functionServiceCache separately. And when router taps a
function, executor updates the access time of the function service entry in its
own cache without notifying executor types to do the update as well. Hence,
the access time of function service entry in poolmanager cache never gets updated.
Due to the access time never gets updated, the idle pod reaper in poolmanager
then thinks the function pod is in idle state and recycle it.
This PR removes the cache in executor itself, and when router tries to tap a function,
executor will call executor type to tap the function and update access time.
The router taps function service one by one which is inefficient and
increases the burden of executor. This PR aggregates all requests into
one to solve the problem mentioned above.
When a function is created before the creation of the environment it's used, the newdeploy will not be able to create kube objs. Hence no function service record is inserted into the cache.
When getFuncSvc is called, the newdeploy tries to find the record in service cache in order to create kube objs with the same name used in previous kubeobjs creation. However, due to no record in the cache, a NotFound error is returned directly and causes the problem. To solve this, we use fn meta UID to ensure we always get the same obj name instead of getting it from the cache.
If the context of request is closed before ReverseProxy finishing writing
a huge response body to the response writer, the client will only receive
a truncated response body.
To solve this, move the context cancel after ReverseProxy finished.
To keep archive creation implementation simple and prevent any
confusion, we decided to remove `--keepurl` flag and embed URL
directly without downloading the file from it . In this way, we can
ensure consistent behavior in either package creation or spec file
creation. Also, it increases the portability of spec file.
1. The records are stored in redis which is not migratable to another cluster for the testing purposes.
2. Some of the requests fields are not recorded.
3. People should consider using https://github.com/buger/goreplay which is an existing mature and well-tested solution for testing purposes.
The function implementations of controller client package are
inconsistent. This PR lets functions reuse the functions
that already implemented and able to set additional headers to
request.
When `fn test` failed to retrieve logs from the function
pod, it turns to query logs from the log database. However,
the logdb type flag is not set to `fn test`, hence the logdb
type is empty (even without default value) and cause `fn logs`
returns an error due to unable to find the corresponding log
database type.
This PR adds logdb type flag to `fn test` to resolve the problem.
Jaeger preserves the trace data of router healthz endpoints
which is not so helpful for monitoring function metrics and
consumes storage to store such trace data.
This PR uses `GetStartOptions` to examine the request's path and
check if it's a request to healthz endpoint. If yes, skip and not
to trace it.
To follow 12-factor app rules, make jaeger collector endpoint
as an environment variable instead of CLI args. It's easier to
replace the value in different deployments. Also, we can utilize
valueFrom to get value from the configmap.
The helm pre-upgrade check failed due to the program tries to
check whether a multierr is a nil pointer instead of errors it contains.
This PR changes the way the program checks multierr in order not to block the upgrade.
Helm treats the single line "extraCoreComponentPodConfig" in
values.yaml as a key value pair config.
```
extraCoreComponentPodConfig:
```
And when a user tries to install helm with providing config
like following, it failed.
```
extraCoreComponentPodConfig:
nodeSelector:
serverless: fission
```
The root cause is that helm treats config in default values.yaml
and providing config as two different types of config, which is
key-value vs. value table. And so it's unable for helm to merge these
two configs even with the same key name.
This PR comments out the single line config in default values.yaml
to prevent the issue.
Before this PR, CLI functions fatal out when encountering error
instead of returning it. Such behavior makes it hard to reuse
the functions nor writing unit tests. This PR aims to make functions
return errors instead of error out.
Istio sidecar proxy blocks all requests sent through the reverse proxy
to the target service if the request.Host is not properly set to the
internal target service host. This PR sets the target service hosts
before establishing the proxy for the client in order to pass the
Istio sidecar proxy check.
Tensorflow Serving supports three kinds of API: predict, classify, regress. In order to fully support possible API types, this PR adds code to split the entry point with separator ":" to get model name and the API type separately. And append the API type to proxy URL when receiving the requests.
$ fission fn create --name t1 --pkg <pkg name> \
--env tensorflow --entrypoint "half_plus_two:regress"
The utility function GetMetadata uses wrong flag text to get the resource namespace and could cause the wrong results returned from the API server. This PR changes the function signature that allows users to pass in the flag text in order to get the correct value.
In the case of large files, it takes a long time for the user to download
the source from the URL and upload it to StorgeSvc through CLI.
This PR allows a user to use URL as the function source when creating a function
and provides a new flag "--keeparchiveurl" to let the user to decided
whether the CLI should download the file first or store the file URL in the
archive directly. If "--keeparchiveurl" is true, then no checksum will be
generated, it's the user's responsibility to ensure the file won't be changed.
When a function with executor type newdeploy got created, Newdeploy
is expected to create deployment/HPA/service for it and insert serviceEntry
to the cache for later use. Once clients call the function, newdeploy returns
the serviceEntry to the router.
However, the log shows that the newdeploy was unable to find the entry and
prints "Resource not found - key 'xxx' not found". The root cause is that the
informer controller instead of processing items in parallel, it dispatches XXFunc
to process items one by one. So if there is any problem during the creation of the
kubernetes resource, it takes a longer time to process the next item and hence
the serviceEntry was not inserted before clients call the function.
This PR lets the newdeploy to process items in extra goroutines instead of blocking
the process loop. It's a workaround to solve the problem above, we should consider
using workqueue to solve it in the future.
Encoded path means the URL path contains encoded string like "/foo%2Fbar".
Gorilla/Mux by default doesn't enable encoded path support, you need to enable
it when initializing the router.
This PR adds a new environment variable USE_ENCODED_PATH to the router
deployment to enable encoded path support.
If a user deploys fission in the namespace which is different from the one in the single YAML file generated by helm, fission components won't be able to talk to each other due to the wrong namespace appends after the service address.
This PR adds --namespace when generating the YAML file to prevent the mismatch problem.
ReplicaSet generated by Deployment distributes pods to nodes based
on nodes resource usage, which means in some cases the newly created
pods may be assigned to only a few nodes. The requests will go to the
same node if there multiple pods on it and may increase the node
resource usage and overall request latency.
To solve the problem mentioned above, this PR allows users to deploy
the router as DaemonSet so that we can distribute requests across all
nodes for better workload distribution and lower latency.
The merge function executor used wasn't merge container correctly, and it
didn't merge all fields in spec except volumeMount & Env which confused people.
To apply the user-configured container correctly, this PR changes the way of merge
and follows rules:
1. Slices are merged and return an error if the elements in the slice have name conflicts.
2. Maps are merged, the value of map of dst container are overridden if the key is the same.
3. The rest of the fields of dst container are overridden directly.
In 1.9, kubernetes prompted Deployment to apps/v1 and finally deprecated
extensions/v1beta1 support in 1.16. Users will see the following error message
in log when fission components try to submit Deployment to the k8s API server
and specify extensions/v1beta1 as API group.
error: unable to recognize "deployment": no matches for kind "Deployment" in version "extensions/v1beta1"
This PR updates call to k8s API server and apiKind in chart files to avoid fission failure in 1.16.
Router readiness probe failed due to kubelet cannot find router healthz endpoint.
This is caused that the healthz endpoint is added only when there is any update request
send to the updateRouterRequestChannel, and makes router failed.
This PR sends an update request right before the router is started to avoid the problem.
The router prints error no matter what error type it is.
It's useful for troubleshooting, however, it also prints
the context canceled error, which means that users abort
request before reply and its really normal nowadays. Also,
the router returns 502 if error is not nil and may confused
client if it's a timeout error.
To solve these problems, this PR adds an error handler to
reverse proxy to examine the return error and change the
status code when needed.
Previously, the spec doesn't update the package status if nothing
in the spec file changed. Due to this, the failed package will
always stay in the failed state.
This PR adds a check to see whether a package is in the failed state.
If yes, then changes the state to pending for builder manager to rebuild it.
Previously, a user has to delete HTTP triggers point to
the same function one by one. This PR adds new flag --function
to list & delete commands. So that user can delete or list all
triggers with the same function. However, this feature is not
working for triggers with canary deployment setup.
For each ingress controller, the format of ingress host,
path and annotations are different. To support different
kinds of controller, this PR adds new ingress config field
to http trigger spec. A user can set annotations, host and
path based on the type of underlying ingress controller
with CLI.
Command example:
fission route create --name foo \
--url /foo/{bar} --function foofn --createingress \
--ingressannotation "nginx.ingress.kubernetes.io/ssl-redirect=false" \
--ingressannotation "nginx.ingress.kubernetes.io/use-regex=true" \
--ingressrule "*=/foo/*"
* Add specializationtimeout flag to function create/update
* Set specialization timeout of 120 seconds if not present
* Add default newdeploy timeout for rest of the test cases
* Comment out specialization timeout in validations for compatibility
* Add warning if specializationtimeout is lower than default value
This fix allows the empty repository tag in values.yaml file. The changes are done in the templates of deployment and fluentbit where repository tag will be added in the docker image name only when specified with some value in case of empty repository tag image name contain the name of image and tag only.
* Config and secret change to invoke function update
* Added recycle function for pool manager as well - where it recycles the specialized pods
* Switched to rolling update of pods and env variable based change instead of deleting pods in new deploy executor
This PR removes not so useful logs and changes most of Info level
log to Debug/Error level in hot path while preserving some of them
that is helpful for troubleshooting.
Currently, only one CI build can be started at the same time due to we only have only one testing cluster. This PR aims to enable multiple concurrent builds can be triggered to reduce the waiting time for CI builds. The major changes listed below:
1. Each build generate unique images for testing and debugging
2. Check whether the testing cluster is being used by another build.
3. Cache docker image & go mod after build finished
4. Improve dockerfiles for reusing docker build cache
## Web UI (tracked separately in the fission-ui repo)
## Performance and Scalability ([area-perf](https://github.com/fission/fission/labels/area-perf))
- Autoscaling
- Cold-start optimization -- optimistically choose from pool, save about ~20msec
- Cold-start optimization -- preload funcs in fetcher
- Cold-start optimization -- preload libraries in envs (v2) -- mem vs. speed tradeoff
## Function extensibility ([area-ext](https://github.com/fission/fission/labels/area-ext))
- Env v2: easy addition of dependencies etc.
- Integration with Service Broker
## Multi-area stuff
- Execution strategies: cold-start pool vs create-pod-on-cold-start -- one size doesn't fit all, at least with current tech; abstract over execution strategies according to requirements
Multi-tenancy in Fission allows users to create Fission objects, i.e functions, packages, environments and triggers in different namespaces.
It mandates that a function reference secrets, configmaps and its package (if explicity referenced during function creation/updation) to be present in the same namespace as the function.
This allows user separation and prevents in-advertent access to sensitive data of other users sharing the same cluster.
However, users are allowed and encouraged to share environments to ensure optimal utilization of cluster resources. To achieve this, users can create all the necessary environments in a ns, say ns1 and then go on to create functions in different namespaces and refer to env in ns1.
Users that prefer complete isolation can create their env, functions in the same ns.
## Roles and privileges
1. Cluster-Admin Role : Fission's services need cluster-admin privileges to monitor, create, update and delete resources across namespaces.
2. Package-getter Role : This role has privileges to do a get, watch and list on fission package objects.
3. Secret-Configmap-getter Role : This role has privileges to do a get, watch and list on secrets and configmaps.
## Service Accounts
1. fission-fetcher
This SA is created in every namespace that a user creates runtime environments in.
Also created in function namespaces where a user creates functions that use NewDeploy executor backend.
2. fission-builder
This SA is created in every namespace that a user creates builder environments in.
## Role-bindings
1. Package-getter-binding
Every time a user creates a package explicity in a namespace, this rolebinding is created in package's namespace (which is also function's namespace). This grants package-getter role to fission-fetcher SA present in the referenced environment's namespace.
If the package is a source package, then, fission-builder SA present in the environment namespace is also added to this rolebinding.
Next when the user creates a function in the same namespace, if the function's executor type is newdeploy, then, the fission-fetcher SA present in function namespace is also added to the same rolebinding.
Note : For functions that have executor type poolmgr, the env pods are created in the namespace that env object is created. Whereas, for those functions that have executor type New deploy mgr, the function pods are created in the namespace that function object is created in.
This is because, poolmgr allows env sharing and optimal resource utilization. so generic env pools are created in a different namespace and all functions that prefer sharing this env pool can reference these pools.
If users require strict isolation, they can either create functions with new deploy backend, or, create env's in different namespaces and not share them across functions.
2. Secret-Configmap-getter-binding
Every time a user creates a function in a namespace, Secret-Configmap-getter-binding is created in the same namespace, granting secret-configmap-getter role to fission-fetcher SA present in the referenced environment's namespace in case the executor type is poolmgr.
If the executor type is newdeploymgr, then the same rolebinding is created in the same namespace as the function, granting the same secret-configmap-getter role to fission-fetcher SA present in the function namespace.
## Examples
1. create a generic python runtime env in ns 1 and function with poolmgr executor type in ns 2 that references it.
2. create a builder and runtime environment in ns3, a source pkg in ns3 and a function referring to this src pkg also in ns3. (for complete isolation, all objs are in ns3)
1. To maintain backward compatibility, fission objects that are created without the ns flags are created in default namespace. Also, the run time env pods in such a case will continue to live in fission-function ns and builder env pods in fission-builder ns
2. Since all envs in a namespace have the same fission-fetcher SA mounted in them, even though multiple envs are created in a namespace and referenced by functions in different namespaces, the SA will have previleges to view those function's secrets if any.
3. Similarly, if there are multiple functions in different namespaces but all sharing an env in one namespace, the fission-fetcher SA in that namespace will have previleges to see all of their secrets.
Annotations are used by the core Kubernetes system and to even larger extent by projects such as Istio Ingress Controllers and Prometheus and such.
Users want to add annotations to some objects such as ingress (https://github.com/fission/fission/issues/989).
To enable the users to use annotations, here are some thoughts and ideas:
## Defining annotations
Annotations can be defined fairly easily in the spec file for any object as part of metadata.
``` yaml
apiVersion: fission.io/v1
kind: HTTPTrigger
metadata:
creationTimestamp: null
name: spectest
namespace: default
annotations:
test-anno: some-test-value
spec:
createingress: true
```
These annotations can be merged to target object using a merging mechanism - so that additional annotations put by Fission can also be preserved.
## Considerations
- More often than not the annotations are needed by a Kubernetes objects created by one of the function CRDs/controllers. For example ingress created by route needs the annotation and not the route object itself.
### Implementation 1
- Most annotations use a convention which we can use to determine if an annotation is meant for an ingress object or to be applied on a pod.
For example. look at annotations:
|Annotation name| Description|
|:-------------|:-------------|
|`prometheus.io/scrape`| Prometheus - applied to pod|
|`sidecar.istio.io/inject`|Istio - applied to pod|
|`helm.sh/hook`| Used by helm to apply to pods/jobs|
|`traefik.ingress.kubernetes.io/app-root`|Used by Trafeik ingress controller, applied to ingress|
|`nginx.ingress.kubernetes.io/add-base-url`|Used by Nginx ingress controller, applied to ingress|
So we can write a simple logic - to check if a annotation is applicable for an ingress and based on that apply or not apply annotations to ingress.
### Implementation 2
- One of side effects of this is that the annotations will still stay on the source CRD object - for example annotation will stay on the httptrigger as well as the ingress object. This can cause problems in certain cases where something like Prometheus uses annotations to scrape objects. So instead we wrap the annotations needed by an object into another annotation name. This also solves problem of having to guess which annotations to apply to which object.
This is specifically important because for example newdeploy function will create a deployment, service and HPA and all three might have different set of annotations.
Based on discussion in the team there is a additional option of adding a explicit field in the spec to hold the annotations. For now this assumes that we are only considering HTTPTriggers for annotations and not other objects such as Functions.
- The implementation idea 2 & 3 look better than 1. The third option involves HTTPTrigger Spec change.
- For both (2) & (3) - if in future we have to implement annotations for Functions etc. we will have to consider the fact that a function will in turn create 3 objects (Service, Pod & HPA) and annotations for all three would need to be accommodated.
# Continuous Integration and Delivery of Fission functions
This document outlines a simple CI/CD process for Fission functions which can be extended to any CI/CD tool. Before we start, some level setting for terminology used as the terms are used rather broadly in industry.
## Continuous Integration
CI is made up of a series of broad areas:
- The first step is to compile the source code and convert into artifact which is pushed to artifact repository. Traditionally this has been building a Py or wheel package (Python) or Jar file (Java) but as containers became mainstream the container image became the package. The traditional artifact repositories were replaced by the Docker registries.
- Execution and reporting of unit testing has been a crucial part of the CI cycle and is done after the source code can be compiled successfully.
- Running a static/dynamic code analyzer is the next step in continuous integration. The static code analysis is usually used to measure and report quality metrics and dynamic code scanning/analysis for security.
In the draft version of this proposal we will only consider the source to artifact conversion part and will not dive into unit testing or code scanning/analysis cycles of the CI.
## Continuous Delivery
CD is also composed of a few broad areas focusing on different aspects:
- After CI cycle completes successfully - deploying the artifact to a Dev/Staging environment so that it can be tested by developers and QA teams.
- Once the tests & teams have verified that a function works, the same function should be promoted from Dev/Stage to higher/production environment. The number of environment that a organization maintains varies but the idea of promotion from one environment to higher environment does exist. There are very few organizations who deploy the newer versions of functions directly in production with a A/B setup but that is as of this writing is an exception and not the norm.
- Another aspect of promoting from one environment to higher environment is the configuration for both environments will be different. For ex. the DB connection string will be different for each environment. Or the "maxscale" property for production environment could be higher than that for Dev. The ability to store all these environment specific configurations in some sort of system (Github for normal values and some sort of KMS for sensitive data) and being able to combine the logic and configurations for each environment when deploying is important.
Beyond these points there are integration/automation points such as being able to call a test suite after deployment is done etc. but we will skip for now for brevity.
## 1 Fission specs in a container
Let's start with a simple Fission function which uses specs. A typical directory structure looks like below:
```
.
├── multifile
│ ├── README.md
│ ├── __init__.py
│ ├── main.py
│ ├── message.txt
│ └── readfile.py
└── specs
├── README
├── env-python.yaml
├── fission-deployment-config.yaml
└── function-pyz.yaml
```
Irrespective of if source code that needs to be built or not, there is a simple command to fire to update the function, which will build (if applicable) and deploy the function:
```
$ fission spec apply
```
If we look at this from CI/CD perspective this process requires:
1. Source code & specs
2. A github push event when any one of the two change
3. Fission CLI
4. Kubernetes Config so that the apply command can be run
So if we build a container - which has the above requirements met as installed software (Ex. Fission & Kubectl CLI) or available as environment variable (Github pull token or Kubeconfig), the container can be used as part of CI workflow in any tool such as - Jenkins, Argo, Github Actions, Gitlab etc.
The idea is to build a generic container with Fission CLI, Kubernetes CLI and a way to read Github token and Kubeconfig from env variable/mounted files and being able to run `fission spec apply` command.
### 1.1
Instead of building a container in previous section - the same can be achieved by a function. The Github webhook can call a function endpoint which in turn can execute the process similar to inside the container.
## 2 Environment Configurations
There are use cases and reasons to have environment configuration different for each environment such as Dev/Staging etc. Let's assume that we want to vary the `maxscale` in functions and `DB_CONNECTION` in environment
```
spec:
InvokeStrategy:
ExecutionStrategy:
ExecutorType: newdeploy
MaxScale: 2 // <-- Varies based on environment deployed in
MinScale: 1
```
```
container:
env:
- name: DB_CONNECTION
value: "http://database.url" // <-- Varies based on environment deployed in
```
Without changing anything in Fission spec it is possible to change these things from environment to environment and some of strategies used by people are:
1. Generate and maintain specs for each environment. This is not a best practice as it leads to drift in code and configuration between environment over time.
2. Use placeholder variables (i.e. $DB_CONNECTION_VALUE) and replace them for each environment before deploying. This is better in the sense that you are combining changes specific to each environment with spec code but is still a work around sort of.
For environment specific configurations, it is possible to use some sort of templating or overlay mechanism. One of interesting projects using overlays is [Kustomize](https://github.com/kubernetes-sigs/kustomize). In any case as of today the fission spec command does not have a way to use template or modify values using overlay and it is worth exploring this approach for fission spec.
## 3 Promotion from one environment to another
This necessarily does not fall in the area of Fission per se but it would be fairly easy to build a pipeline in the the tool used for CI/CD if we have container mentioned in (1) and even work around mentioned in (2).
## Action Items
As a first step it would be good to build a simple container mentioned in (1) and use it in various tools to understand the value it adds and any unknowns. The next steps would be to build a full end to end pipeline from source to production.
timetrigger, tt, timer Manage Time triggers (timers)for functions
mqtrigger, mqt, messagequeue Manage message queue triggers for functions
environment, env Manage environments
watch, w Manage watches
package, pkg Manage packages
spec, specs Manage a declarative app specification
upgrade Upgrade tool from fission v0.1
tpr2crd Migrate tool for TPR to CRD
help, h Shows a list of commands or helpfor one command
PLUGINS:
workflows, wf Inspect and manage workflow executions
ui Start the user interface
GLOBAL OPTIONS:
--server value Fission server URL (default: "http://127.0.0.1:65356")
--help, -h show help
--version, -v print the version
```
Of course Fission needs to be able to find all plugins for this. There are several ways in which we can provide discoverability. The simplest one is for Fission to look in the path for all binaries starting with the `fission-*` prefix. Optionally, fission could invoke a specific command on the subcommand to get info about the plugin (such as version, help text, aliases...)
With Fission Workflows this info would look something like this:
```bash
$ fission-workflows --plugin
name: workflows
version: 0.4.0
help: Inspect and manage workflow executions
```
The idea is that this plugin info is all completely optional.
If it is not available, we simply degrade the results to user.
This way users/we can easily prototype or add plugins without having to worry about adhering to some interface.
**List version**
```bash
$ fission --version
client:
fission: 0.8.0
fission-workflows: 0.4.0
server:
fission: 0.8.1
fission-workflows: 0.3.0
```
Again, versioning info for fission-workflows is taken from the plugin info of the commands.
Note: a related issue is to have some more formalized plugin support/discoverability on the server-side,
but that is out of the scope of this issue.
### Other (optional) extensions and notes
- Like git we could setup a preferred binary path, where fission looks first when searching for the subcommand.
This could optionally be defined with a `FISSION_EXEC_PATH`.
- With the current approach we cannot have aliases for commands---fission will not be able to find fission-workflows
when the user calls `fission wf`. This might be UX issue, with these long path names. One option is let the user fix
it themselves by symlinking `fission-wf` to `fission-workflows`; using the plugin info Fission can recognize and
merge aliases together.
- To help detect versioning conflicts (old version of fission, too new version of fission workflows). We could add
a `requires` field to the fission-workflows plugin info. Then we could throw a warning or error, when two out of sync
versions are being used.
- To avoid unhelpful errors to the user when they have not installed a plugin, we could add a heuristic to check
`https://github.com/fission/SUBCOMMAND` to see if the subcommand might be an uninstalled plugin.
OR, we could lookup a simple text file that contains common plugins `https://github.com/fission/fission/plugins.txt`
and list them as suggestions to the user. OR we could of course just default to a bit help text that says something
like `unknown subcommand 'foo'. If this is a plugin, ensure that it is present on your PATH`.
---
### Motivation
The proposed approach is to use the git-based plugin system for now. Reasons for this approach over a sophisticated,
integrated plugin-based approach:
- It is low effort to implement.
- It is easy to extend with minimal to no required interface.
- The binaries remain standalone, allowing users to separate them if needed and make independent development on the
binaries easy.
Limitations of the proposed approach:
- The user still has to do some work, adding binaries to the PATH; ensuring that permissions are correct; ensuring
that the binary is executable; how to deal with duplicate binaries on the PATH. All this makes this approach assume
basic/intermediate knowledge of the OS from the user.
- I have to admit: I am not entirely sure if this approach requires any changes for Windows. Probably not.
- Upgrading fission with many plugins could be cumbersome, as you would need to upgrade each binary one by one.
Improving this is probably best left to future work.
The more heavyweight solution solves some of these limitations to an extent, but these do not way up to the increased
development and maintainance cost IMO. If needed we could explore this option (or some hybrid option) in the future.
Fission's currently uses a pool of running "environments" and specialized them for execution of a function. This design served the cold start use cases well but this is not the only strategy for creation and execution of functions. For example requirements for a new execution backend have been discussed in https://github.com/fission/fission/issues/193. This document aims to discuss the currently under development "newdeploy" backend and related thoughts
# Executor
A new layer - executor now sits between the router and actual backends are responsible for all of heavy lifting for execution of functions. Executor layer is responsible for accepting requests from router and checking with cache before calling on a backend for execution of a function.
# Backend
A backend is responsible for execution of a function - which can involve provisioning appropriate objects in Kubernetes. So with the new design Pool manager becomes one of backends. As of this writing there are two backends which are described as:
### Pool Manager Backend
Pool manager backend uses a pool of environment pods and specialized them when a function is invoked. The specialized pods are cleaned up if not in use after a few minutes. More details on Pool manager can be found here: https://github.com/fission/fission/blob/5c470735185b980c1f7987921db360e91c65573b/Documentation/Architecture.md
### New Deploy Backend
New Deploy backend create a Kubernetes deployment, a Kubernetes Service for a given function. It additionally creates a HorizontalPodAutoscaler if scale parameters are provided. The creation of deployment and service can be eager or lazy based on input.
### Execution Strategy
While this is still a WIP, parameters that affect execution behaviour of function are based on `InvokeStrategy`. A invoke strategy defines the `strategyType` and actual strategy parameters encapsulated in the strategy object.
```
InvokeStrategy struct {
ExecutionStrategy ExecutionStrategy
StrategyType StrategyType
}
```
For example in above case the strategy type is `ExecutionStrategy` and the corresponding parameters are listed below.
```
ExecutionStrategy struct {
Backend BackendType
MinScale int
MaxScale int
EagerCreation bool
}
```
In future there could be more strategies for different use cases.
## Dispatch to backend
As of now one of the backends is chosen based on a simple flag in `ExecutionStrategy`. In future there might be a intelligent/hybrid ways of choosing a backend. For example initial requests of a function could be served from a pool manager while later scaling could be served by a NewDeploy backend
This document documents the design and thoughts that lead to design of Java environment. Before we dive deeper, some important points:
- When we say Java, we really mean JVM. That does not mean that all languages will work seamlessly, so support will be added gradually based on validation. Some of popular languages as of today are:
- Scala
- Groovy
- Kotlin (Server side with Spring)
- In Java there are a few prominent frameworks which have a ecosystem of their own (See list below). How these framework fit in the environment will be detailed later, but it is important to understand their place in ecosystem and design for it.
- A large percentage of entertprise developers use [Spring framework](https://spring.io/) as has been shown by multiple surveys
- Reactive has taken up recently with data intensive operations [Reactive extensions for JVM](https://github.com/ReactiveX/RxJava)
- [Spark](http://sparkjava.com/) is a micro web framework
A draft implementation of the Java environment design is in the branch [java_env_alpha](https://github.com/fission/fission/tree/java_env_alpha). Also a earlier implementation based on Vort.x framework [can be found here](https://github.com/tobias/fission-java-env/)
## Function interface
The goal is here is to minimize the lock in for the user into any framework as much as possible. Java 8 introduced an interface called ```Function``` which could be a great fit here. The user has to implement the ```Function<T, R>``` class and to meet the contract implement the apply method:
```
public class HelloWorld implements Function<T, R> {
public R apply(T str) {
```
Now - the T & R could be different things and we discuss some options below:
### Body in request and response
From the early implementation in the branch mentioned above, the environment extracts the body and send it as a JSON string. The JSON then can be transformed into the appropriate object by the function.
This works well, but has one major limitation: the function does not get access to other things like headers etc. The same thing applies to the reponse: function can send the body but looses control over status code etc.
### HttpServletRequest and HttpServletResponse
It is possible to send the [HttpServeletRequest](https://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletRequest.html) request object as it is to the function class but then the interface becomes a bit too low level. For example the function user has to retrieve the body of request using ```getInputStream``` which gives raw input stream and needs additional work.
Also most enterprise applications today use a framework of some sort for web applications instead of dealing with the raw HttpServlet
### Custom/Context Object
A custom object which encapsulates all needed fields etc. can be used to pass the data from environment to the function. But this means the user has to import a Fission object/library for this object in the application code.
This approach has been taken in the implementation done earlier for a Java environment in Fission and [object interface can be found here](https://github.com/tobias/fission-java-env/blob/master/src/main/java/io/fission/api/Context.java). Related discussion is in the [issue](https://github.com/fission/fission/issues/91)
AWS Lambda also uses a context object, but the purpose is very different, [details of context object here](https://docs.aws.amazon.com/lambda/latest/dg/java-context-object.html).
### Spring's HttpEntity
If we have to depend on a class/library, it is probably better to depend on a class which is part of ecosystem. So instead of using the low level interface of Servlet, we can use [HttpEntity's subclasses RequestEntity and ResponseEntity](https://docs.spring.io/spring/docs/5.0.5.RELEASE/javadoc-api/org/springframework/http/HttpEntity.html). This ensures that the function user is not locked in the Fission object contract, but also gets the full access to request/response object.
The Spring cloud function project also discusses the issue of not having access to other things in request and [related issues are here](https://github.com/spring-cloud/spring-cloud-function/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+header)
### Thoughts
- If we only intend to pass request/response object to function - then using HttpEntity might be a good choice
- If there is a need for additional exchange of information between the environment and function execution in future, then a custom/context object is a better option. We can wrap the HttpEntity's fields and additional fields in the custom context object
## Environment Design
JVM environment design is based on Spring boot and Spring MVC frameworks. The details can be found in branch, but here are some key points:
- All classes in the function and dependent classes are loaded into JVM. Which means the user should supply the uber/fat jar for execution.
- The entrypoint class is specified by the user as ```entrypoint``` flag on the class. The method is by convention (```apply``` as per the Function interface contract)
Fission now has rich functionality supported by multiple services, however, it brings the complexity of troubleshooting.
This proposal tends to give a picture of fission support tool that can help both user and developer to locate the problem in short time.
To achieve this, the support tool will dump related kubernetes objects, fission resources and pod logs from the given cluster.
# Functionality
## Environment Information Collection
Before troubleshooting, some of the basic information is needed to give others an overview of kubernetes/fission user test with so that we can locate the problem in short time.
* Fission version
* Client/Server version
* Kubernetes cluster version
* Cluster version (i.e v1.9.7-gke.0)
* Running environment (i.e GKE, AKS and minikube)
* Nodes version and other information
## Service Logs Collection
The component logs and the logs of interaction between components are important for people to understand what really happened in cluster. Following are components need to collect logs from.
* All fission component pods
* Function pods
* Builder pods
* Environment pods
## Object dumping
Fission is deeply coupled with Kubernetes, most of the objects are created and maintained by it. There is two major type of objects need to be dumped from kubernetes:
* K8S objects
* CRD resources
All objects should be dumped into a readable file format. It will be great if people can reproduce similar environment with these files.
## Information upload
Upload dump files to the specific backend server for support channel to analysis
# CLI Interface
```
$ fission support collect
NAME:
fission support collect - Collect pod logs, fission resources and related kubernetes objects for troubleshooting
USAGE:
fission support collect [command options] [arguments...]
OPTIONS:
--dumpdir value Directory to save dump kubernetes objects and fission resources (default: "fission-dump")
--fissionns value Namespace of fission installation (default: "fission")
--builderns value Namespace of fission package builder (default: "fission-builder")
--funcns value Namespace of fission function pod (default: "fission-function")
```
# Thoughts?
1. What to do with sensitive objects like secrets and configmap? Ignore the dump for such objects?
2. The functionality is necessary but not listed above?
This proposal was initially started as a upgrade testing proposal but soon problems that were posed resulted in a bigger proposal.
### Kinds of testing
Most of current integration tests are CLI driven. Fission CLI is used to test execute various test cases. In future we would have to also focus on API level testing as a UI is built for Fission.
## Needs & patterns
This section only explains the problems/best practices without going into tooling and language used for implementation.
### Separating the test & data
Seperating the tests from test data has two aspects - one is separation of concerns and second is scaling the tests without touching the test logic. The test data is a simple data structure which holds all information and test can take data and execute the logic.
As an example today we test "Hello world" for nodejs environment with a simple hello.js like this:
fission route create --function $fn --url /$fn --method GET
response=$(curl http://$FISSION_ROUTER/$fn)
```
The variables here are environment image, function code & route URL.
If tomorrow if we had to scale this test for all environments, we will have to repeat ourselves. (Violate DRY principle). Instead of that if we encapsulate the test setup & test in a simple function:
```
test_hello_env(envImage, codePath, routeURL){
}
```
And feed it with a dictionary which has all possible combination of tests:
- Separate the test execution logic from the data it needs clearly.
- For adding new kind of environments, you just need to add one more entry into data structure.
Testing all environments may not be most apt example for this, but there can be potential use cases like this.
### Separating the test & setup/teardown
When we run a test there are typically three distinct phases:
- Setup (Create env, fn, route)
- Test (Curl the function)
- Cleanup (Delete fn, route & env)
It should be possible to separate the before test and after test parts from actual tests at two levels:
- Each test
- A whole test suite
The ability to have clean and separate before and after blocks, apart from separation of concerns, enables:
- Running a suite of tests for same setup (See tagging for suite of tests)
### Tagging tests & running a selection
Over a period of time as tests grow, there will be unit, smkoe, integration, performance, soak tests and so on. Ability to run a perticular test suite only or a combination of them makes it easy to run for specific purpose.
### Measuring test times
[Good to have, not a must] Measuring time for tests and reporting somewhere helps over time to monitor trends. Although this job is better done by performance/benchmark tests so it is not a strict requirement
### Cleaner Logging
It would be good to have cleaner/relevant logging as part of build & test. For example something that Ginkgo framework does is it shows error logs only for failed tests.
### Tests in Parallel
It would be good to be able to run tests in parallel.
## Evalutaing the tools/alternatives
### BATS
Bash Automated Testing System is like a enhanced version of bash with support for @test tags and before and after steps & ability to skip tests etc. While it enhances the bash to certain extent, the overall improvement is only marginal.
The testing package of Go also is quite feature rich for most of the use cases we need. Go 1.7 onwards there is support for setup & teardown parts and parallelism etc.
#### Go - Testing package
- Support for setup and teardown based on https://golang.org/pkg/testing/#hdr-Main
- Go testing already supports and has examples of table driven tests (Separating test & data), measuring test times and parallel tests
#### Shell execution: Go's Exec Library
GO provides a built in Exec library for working with CLI commands. The package seems good enough for us to work, though a few working examples will help decide better
https://golang.org/pkg/os/exec
### Using CLI package
Currently we build a CLI and then execute the tests. The tests basically call one of functions from CLI package. If we decide to use a go lang based framework, then we can import the CLI package and then call those functions by providing them context. This is as good as calling the Fission from CLI, with added benefit of programmibility of Go langugage.
```
func TestSomething(t *testing.T) {
// Build the Cli context with flags etc.
ctx := cli.Context{}
// Pass the ctx to create function
fnCreate(ctx)
}
```
Some of benefits of using above pattern are:
- We can build a small framework around above core where we can pass various flag combinations etc. and exercise all flags in great detail
- We can use rest of Go testing library and other libraries to build matchers, looping, parallelism etc.
- It allows us to exercise the logic in CLI as well as validate the API at the same time.
### Ginkgo & Gomega
Ginkgo is a BDD framework which works with Gomega matcher library. I will state relevant portions of these two frameworks which can be utilized:
From Ginkgo:
- Global `BeforeSuite` and after `AfterSuite` can be used to have global setup and tear down phases
- For tests `BeforeEach` and `AfterEach` and more such varients to do before and after test tasks.
From Gomega:
Gomega is a matcher library but the `gexec` library makes it really easy to interact with OS execution environment. Some working examples:
- Build and cleanup the Fission CLI before & after the tests
- Gomega provides quite a few built in matchers - so you don't have to code those small usual checks, for example:
```
Ω(ACTUAL).Should(BeTrue()) // The output should be true
Ω(ACTUAL).Should(BeAnExistingFile()) // The file should already exist
```
There are many more matchers which cane be found here: http://onsi.github.io/gomega/#provided-matchers
- We can build custom mathers in Go language for reusable logic.
#### Links
Ginkgo: http://onsi.github.io/ginkgo/
Gomega: http://onsi.github.io/gomega/
## Thoughts & Next actions
Based on the discussion with team, here are current thoughts and next action items:
### Thoughts
- As far as possible we should stick to Go's built in testing package
- Ginkgo's cleaner logging feature (Onlu log if there are errors) - is very useful. We can decide to incorporate this in future.
- Gomega's (gexec)[http://onsi.github.io/gomega/#gexec-testing-external-processes] is really neat and some matchers can be used if necessary
### Action items
- How will upgrade test for Fission fit in the framework?
- How will migration of tests happen over time:
- Aim is to keep existing tests around so that enough validation is in place
- May be migrate one test at a time
- How much of current setup etc. will move into framework? For example it is clear that helm commands should be part of test framework as part of setup/teardown. But other sections may or may not be. A RCA needs to be done to analyze and come up with clear demarkation.
| Binary (for executables or scripts) | `fission/binary-env` |
| Go | `fission/go-env` |
| JVM | `fission/jvm-env` |
| .NET | `fission/dotnet-env` |
| .NET 2.0 | `fission/dotnet20-env` |
| NodeJS (Alpine) | `fission/node-env` |
| NodeJS (Debian) | `fission/node-env-debian` |
| Perl | `fission/perl-env` |
| PHP 7 | `fission/php-env` |
| Python 3 | `fission/python-env` |
| Ruby | `fission/ruby-env` |
You can also extend environments or create entirely new
ones if you want. (An environment is essentially just a container
with a webserver and dynamic loader.)
A _trigger_ is something that maps an event to a function; Fission
as of today supports [HTTP request](https://docs.fission.io/usage/trigger/#create-a-http-trigger), [timed](https://docs.fission.io/usage/trigger/#create-a-time-trigger), and [message queue](https://docs.fission.io/usage/trigger/#create-a-message-queue-trigger) triggers.
Usage
-----
## Getting Started
```bash
# Add the stock NodeJS env to your Fission deployment
Fission is a project by [Platform9 Systems](https://platform9.com/fission/)
and [many contributors](https://github.com/fission/fission/graphs/contributors).
The following companies, organizations, and individuals support Fission's ongoing maintenance and development. If you are using/contributing to Fission, we would be happy to list you here, please raise a Pull request.
| `fission-core` | FaaS essentials, and triggers for HTTP, Timers and Kubernetes Watches |
| `fission-all` | Log aggregation with fluentd and InfluxDB; NATS for message queue triggers; Fission-UI |
## Installing the chart
To install the chart with the release name `my-release`,
```bash
$ helm install --name my-release fission-all
```
## Uninstalling the chart
To uninstall/delete chart,
```bash
$ helm delete my-release
```
## Configuration
The following table lists the configurable parameters of the Fission chart and their default values.
Parameter | Description | Default
--------- | ----------- | -------
`serviceType` | Type of Fission Controller service to use. For minikube, set this to NodePort, elsewhere use LoadBalancer or ClusterIP. | `ClusterIP`
`routerServiceType` | Type of Fission Router service to use. For minikube, set this to NodePort, elsewhere use LoadBalancer or ClusterIP. | `LoadBalancer`
`repository` | Image base repository | `index.docker.io`
`analytics` | Analytics let us count how many people installed fission. Set to false to disable analytics | `true`
`analyticsNonHelmInstall` | Internally used for generating an analytics job for non-helm installs | `false`
`pruneInterval` | The frequency of archive pruner (in minutes) | `60`
`preUpgradeChecksImage` | Fission pre-install/pre-upgrade checks live in this image | `fission/pre-upgrade-checks`
`debugEnv` | If there are any pod specialization errors when a function is triggered and this flag is set to true, the error summary is returned as part of http response | `true`
`prometheusDeploy` | Set to true if prometheus needs to be deployed along with fission | `true` in `fission-all`, `false` in `fission-core`
`canaryDeployment.enabled` | Set to true if you need canary deployment feature | `true` in `fission-all`, `false` in `fission-core`
`extraCoreComponmentPodConfig` | Extend the container specs for the core fission pods. Can be used to add things like affinty/tolerations/nodeSelectors/etc. | None
### Extra configuration for `fission-all`
Parameter | Description | Default
--------- | ----------- | -------
`createNamespace` | If true, create `fission-function` and `fission-builder` namespaces | ` true`
_See [helm upgrade](https://helm.sh/docs/helm/helm_upgrade/) for command documentation._
### Upgrading an existing Release to a new major version
A major chart version change (like v1.2.3 -> v2.0.0) indicates that there is an incompatible breaking change needing manual actions.
### Upgrade from 1.18.x to 1.20.x
We have removed controller service from fission-all chart.
### Upgrade from 1.17.x to 1.18.x
With 1.18.x, we have major change in the way we are deploying Fission.
We have added parameters `defaultNamespace`, `additionalFissionNamespaces`, `functionNamespace` and `builderNamespace` to manage the namespaces.
We watch and manage specific namespaces for Fission resources configured via `defaultNamespace` and `additionalFissionNamespaces` parameters.
You dont need to worry about `builderNamespace` and `functionNamespace` parameters, unless you want to consider legacy Fission resources.
Please refer to [core changes](https://fission.io/docs/releases/v1.18.0/#fission-core-changes) for more details.
### Upgrade from 1.16.x to 1.17.x
By default, Fission runs with the default security context. This means that it will be run as root. We have added settings in Helm chart for securityContext across all services in Fission. You can enable recommended securityContext settings during Fission installation.
Please refer to [security context settings](https://fission.io/docs/releases/v1.17.0/#security-context-setting-for-fission-installation) for more details.
### Upgrade from 1.15.x to 1.16.x
If you have been using `prometheus.enabled=true` in your fission-all chart, you will need to deploy the prometheus using prometheus community supported chart.
We have removed prometheus dependency from fission-all chart.
We would recommend [prometheus-community/prometheus](https://artifacthub.io/packages/helm/prometheus-community/prometheus) or [prometheus-community/kube-prometheus-stack](https://artifacthub.io/packages/helm/prometheus-community/kube-prometheus-stack) chart.
### Upgrade from 1.14.x to 1.15.x
With 1.15.x release, following changes are made:
-`fission-core` chart is removed
-`fission-all` chart is made similar `fission-core` chart
- In the `fission-all` chart, the following components are disabled which were enabled by default earlier. If you want to enable them, please use `--set` flag.
- nats - Set `nats.enabled=true` to enable Fission Nats integration
- influxdb - Set `influxdb.enabled=true` to enable Fission InfluxDB and logger component
- prometheus - Set `prometheus.enabled=true` to install Prometheus with Fission
- canaryDeployment - Set `canaryDeployment.enabled=true` to enable Canary Deployment
## Migrating from fission-core chart
With the release of Fission v1.15.x, the fission-core chart was removed.
Fission-all is now exactly similar to fission-core and can be used to migrate from fission-core.
If you are upgrading from the fission-core chart, you can use the following command to migrate with required changes.
See [Customizing the Chart Before Installing](https://helm.sh/docs/intro/using_helm/#customizing-the-chart-before-installing). To see all configurable options with detailed comments:
```console
helm show values fission-charts/fission-all
```
You may also `helm show values` on this chart's [dependencies](#dependencies) for additional options.
### Multiple releases
The same chart can be used to run multiple Fission instances in the same cluster if required.
For Windows, you can use the linux binary on WSL. Or you can download this windows executable: https://github.com/fission/fission/releases/download/1.2.1/fission-cli-windows.exe
For Windows, you can use the linux binary on WSL. Or you can download this windows executable: https://github.com/fission/fission/releases/download/{{ .Chart.Version }}/fission-{{ .Chart.Version }}-windows-amd64.exe
2. You're ready to use Fission!
{{- if gt (len .Values.additionalFissionNamespaces) 0 }}
You can create fission resources in the namespaces "{{ .Values.defaultNamespace }},{{ join "," .Values.additionalFissionNamespaces }}"
{{- else }}
You can create fission resources in the namespace "{{ .Values.defaultNamespace }}"
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
