gaia-app / gaia Goto Github PK

for cloud-type modules, an estimated cost of ownership could be helpful for the users.

Is your feature request related to a problem? Please describe.
A healthcheck endpoint is necessary when gaia is deployed behind a load-balancer

Describe the solution you'd like
activate spring-boot-actuator ? only the /health endpoint ?

Describe alternatives you've considered
None

Additional context
N/A

Mesure job execution time and display it on the job list.

This could also help to estimate job duration and show it to the user in the job execution screen

Use either :

• travis-ci : https://github.com/marketplace/travis-ci
• circle-ci : https://github.com/marketplace/circleci
• gitlab-ci : https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/github_integration.html

Is your feature request related to a problem? Please describe.
It would be useful to be able to "retry" a job from the job screen.

Describe the solution you'd like
Maybe a simple "retry" button on the job page.

Describe alternatives you've considered
N/A

Additional context
N/A

A stack SHOULD have a description, which is displayed in its card in the "stacks" screen.

Is your feature request related to a problem? Please describe.
user actions should be logged, for security auditing reasons, and also to be able to see who did what (who deployed this new stack? who stopped my stack?)

Describe the solution you'd like
We should log :

• who created stacks
• who started job executions

It would be nice in the job list, to see who launched what...

Describe alternatives you've considered
N/A

Additional context
N/A

add the "destroy" stack feature.

Add a "destroy" button on the stack page, which starts a terraform destroy job.
The stack should then be in the state "DESTROYED".

Is your feature request related to a problem? Please describe.
In the stack screen , some fields should be mandatory:

• name
• variables if specified (see #72)

Describe the solution you'd like
Make the fields mandatory. If a mandatory field is empty, the input should be highlighted in red and the save should not be executed.
Check the fields in the view and in the controller.

Describe alternatives you've considered
In creation mode, the mandatory fields could be autofilled by default from the module fields.

Additional context
For the variables part, issue #72 should treated first.

Some variables could be made "unmodifiable" by module users.

To do so, add a switch or a checkbox in the module definition, next to each variables in the module edit view.
A default value MUST be declared to do so.

Then in the stack view, the variable MUST not be visible or editable by users.

gaia url MUST be added to settings, in order to be able to setup backend configuration

Describe the bug
When one a page if the sidebar is collapsed, changing the page makes the sidebar to be expanded. The sidebar should stay collapsed.

To Reproduce
Steps to reproduce the behavior:

1. Go to any page
2. Click on the sidebar toggle to collapse the left menu
3. Go to any other page
4. The sidebar is expanded again

Expected behavior
The status of the sidebar should remained untouched when changing routes.

Screenshots
N/A

Desktop (please complete the following information):

• OS: Arch Linux (kernel 5.2.5-arch1-1)
• Browser: Firefox Developer Edition 69.0b8 (64-bit)
• Version: Gaia 1.0.0

Additional context
N/A

use https://sonarcloud.io

job scripts could be externalized in a dedicated file, and can be processed using a template

Is your feature request related to a problem? Please describe.
The job screen could be extended with job details such as :

• its date
• the time it tooks
• a simple status view (success/failed)
• who launched it
  job logs could be displayed bellow the job details

Describe the solution you'd like
We can take some inspiration on travis-ci or gitlab-ci :

travis :

gitlab:

Describe alternatives you've considered
N/A

Additional context
N/A

The docker runner MUST be configurable as a properties and in app.

Is your feature request related to a problem? Please describe.
Currently, a stack can be destroyed, which is an irreversible action. One should be able to preview the destruction.

Describe the solution you'd like
Add a button in the stack page to visualize the impacts of the destroy action by launching the command terraform plan destroy

Describe alternatives you've considered
N/A

Additional context
N/A

In the stack screen, clicking on "stop" should be followed by an opening modal asking for confirmation

Is your feature request related to a problem? Please describe.
Some modules and stacks may be sensitve, so we want to make them invisible to other users.

Describe the solution you'd like
In the module & stack screen, we can add a simple checkbox to mark the module/stack private.
private module or stacks can only be seen by their owner.

Describe alternatives you've considered
N/A

Additional context
N/A

Spotify has discontinued support of docker-client.

We may need to use another lib, or wait for a valuable fork to be created.

Is your feature request related to a problem? Please describe.
we should log using logback logger

Describe the solution you'd like
Use the logback logger

Describe alternatives you've considered
N/A

Additional context
N/A

As a simple user, I want to be able to see module details, in order to be able to choose the right module that suits my needs.

The module details screen could be inspired by terraform module screens in the terraform hub :
https://registry.terraform.io/modules/terraform-aws-modules/security-group/aws/3.0.1

The module details screen MUST contain :

• short description of the module (name + description)
• readme contents
• input variables description
• output variables description
• a link to start using this module

The module details screen MAY contain :

• estimated cost of ownership (see #43)
• estimated duration of provisionning (see #37)

This screen should be read-only.

https://choosealicense.com/licenses/

Mozilla Public License 2.0
or
Apache License 2.0

Is your feature request related to a problem? Please describe.
When launching jobs, is would be nice to have a "autoscroll" or "follow logs" functionnality

Describe the solution you'd like
N/A

Describe alternatives you've considered
N/A

Additional context
N/A

admin role has all access
user role has dashboard and stacks access

Is your feature request related to a problem? Please describe.
In the stack screen , some fields should be mandatory:

• name
• variables if specified (see #72)

Describe the solution you'd like
Make the fields mandatory. If a mandatory field is empty, the input should be highlighted in red and the save should not be executed.
Check the fields in the view and in the controller.

Describe alternatives you've considered
N/A

Additional context
For the variables part, issue #72 should treated first.

Some modules may be written for terraform 0.11, others for terraform 0.12...

Add a way to specify which terraform version should be used for each module (in the module page). Maybe simply specify which docker image to use?

Ouputs should be visible on the "stack" screen

default favicon doesn't show up on all screens.

also, we should use a custom favicon, here is one i've generated from the icon's website (rename it to favicon.ico before using it)

Add breadcrumbs on some screens :

• job screen should have a link to go back to stack screen

Is your feature request related to a problem? Please describe.
We should use the TF_IN_AUTOMATION env var when running jobs, as described in terraform documentation : https://learn.hashicorp.com/terraform/development/running-terraform-in-automation#controlling-terraform-output-in-automation

Describe the solution you'd like
Just pass the env var to the job container

Describe alternatives you've considered
N/A

Additional context
N/A

Is your feature request related to a problem? Please describe.
In the stack screen, if a job is currently running, it should be visible in the job history part.

Describe the solution you'd like
Save the job once it is launched, not only it is finished. The job ill be saved with the status IN PROGRESS.

Describe alternatives you've considered
N/A

Additional context
N/A

Is your feature request related to a problem? Please describe.
In the module screen, some fields should be mandatory:

• name
• cli version
• git repository url

Describe the solution you'd like
Make the fields mandatory. If a mandatory field is empty, the input should be highlighted in red and the save should not be executed.
Check the fields in the view and in the controller.
For field"CLI", by default, the value should be the lastest one.

Describe alternatives you've considered
N/A

Additional context
N/A

Is your feature request related to a problem? Please describe.
we should provide a custom login screen to our users. a nice one here :
https://codepen.io/ainalem/pen/EQXjOR

Describe the solution you'd like
custom login screen

Describe alternatives you've considered
N/A

Additional context
N/A

Is your feature request related to a problem? Please describe.
We should be able to :

• send webhook notifications (to send notification to discord or slack when a stack is deployed or destroyed=
• send mail notifications
• receive webhook notifications (to refresh a stack state using a "plan", when the code for a module changes)

Describe the solution you'd like
TBD

Describe alternatives you've considered
N/A

Additional context
N/A

Connecting to a OAuth/OpenId seems complicated and does not allow to fetch user authorities for the application.

Maybe we should think of a simpler system (using a custom auth, with database user storage), and integrate with a LDAP server, as we do in gitlab or sonarqube as an example

Is your feature request related to a problem? Please describe.
Admin password should be configurable, to replace the default one

Describe the solution you'd like
Use a properties gaia.admin-password

Describe alternatives you've considered
N/A

Additional context
N/A

simple stack state & jobs history mgmt

Users should be able to create new stacks based on existing modules.

add some toast notifications after actions (success or failures) :

• saving data (stack or modules)

Is your feature request related to a problem? Please describe.
Settings are mainly configured using properties or env vars.
As some settings may be modifiable via the "settings" screens, these should be made persistent.

Describe the solution you'd like
Settings should be persisted in database.

Describe alternatives you've considered
N/A

Additional context
N/A

Is your feature request related to a problem? Please describe.
we should provide a simple way to manage users:

• users can be added to groups
• module access can be granted on users/groups
  we can also create a set of roles :
• READ (read only access on modules/stacks)
• DEPLOY (run start/preview/destroy jobs)

Describe the solution you'd like
To be defined

Describe alternatives you've considered
N/A

Additional context
N/A

Is your feature request related to a problem? Please describe.
/api/state endpoint may expose sensitive information.
This endpoint MUST be secured.
terraform httpd backend supports BASIC http authentication, so /api/state should support this kind of auth.
When the endpoint is secured, the backend configuration should be generated using credentials that allow a specific module to connect to its backend.

See https://www.terraform.io/docs/backends/types/http.html

Describe the solution you'd like
Maybe we should generate a "one-time" couple of credentials when generating a backend configuration for a stack. Or at least, a unique couple of credentials for each stack, so that a stack owner cannot see other stacks information.
We may need to implement a custom spring UserDetailsService for this purpose.

Describe alternatives you've considered
N/A

Additional context
N/A

When I open a stack, and I change some variables, clicking on "run" or "update" should either :

• be disabled
• warn the user about unsaved changes

Is your feature request related to a problem? Please describe.
In the module screen, one should be able to specify if a variable is mandatory or not.

Describe the solution you'd like
Add a checkbox for each variable part to specify if it should be mandatory or not.

Describe alternatives you've considered
N/A

Additional context
N/A

A job should have a type.

The type of the job is displayed on the "stack" screen.

The currently implemented types are "preview" and "run", which are terraform plan and terraform apply. We can rename "preview" and "run" to comply with terraform vocabulary...