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>
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>
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>
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>
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>
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
