real-digital / pligos Goto Github PK

configuration files are often templated based on the helm environment (values.yaml). This makes the config files hard to access locally. A fuse file system, which allows mounting the rendered config files to the file system helps overcome this obstacle

There's nothing to be done here in the repository but in the real.digital side.

I'll add the issue here to centralize and control it in the proper place.

this would allow operators to choose, on their own time, when they want to update to a newer flavor version

Hello

I'm working on pligos and I just found that it is missing some documentation related to adding the dependencies. If i want to add some dependencies (for example mysql, pgsql etc) in my helm chart, then is there a way to add my dependencies automatically by just mentioning it in my pligos.yaml ?

I realized that we should maybe offer a standard set of types that users can use in any flavor. This potentially could also solve the issue of how to propagate the types alongside the flavor charts.

I'm facing issue while using the pligos. If I have the following directory structure of my flavor (that is webservice in the documentation)

templates
 └──tests
    └──test-connection.yaml

It contains the sub-folder in templates.
So, when I run the pligos, It throws the error that "test-connection.yaml: no such file or directory"

But If I move this file out from tests to the templates folder, then it works fine.

How to successfully run the pligos if the templates contain sub-folders ?

• secret management mainly means non-development keys, that are however still required for development environment (docker repository, certificates, ...)
• the idea is to use a secret provider (which initially will be a directory) in order to push the secrets to all generated helm charts, such that each helm chart independently has all secrets necessary
• further down the line any database could function as a secret provider, vault being the favorable choice

helm offers dependency management through the requirement.yaml. Pligos should support dependency management as well.

for @johnholiver the path doesn't matter and he is using istio, which might not be compatible with the current route API.

Currently, flavors are passed inside pligos configuration file as relative paths.
It would be better if we could enhance pligos to load them from a repository (potentially a helm repo).

We would like to have support for IDEs to improve text input on pligos configurations.
Much of the mistakes done by users can be traced to being unable to autocomplete, or having a text editor support for finding out mistakes.

Following the decision of Making Pligos a Helm Plugin, we need to just do it.
Support documentation of the design draft can be found in here.
https://github.com/real-digital/pligos/wiki/Design-Draft:-Pligos-as-a-helm-plugin

I see how it can be quite confusing when trying to use pligos. let's add a getting started in order to be more approachable

Pligos currently is really rough on it's user. There are a lot of ways the program can actually panic when there is a mistake in the configuration. Pligos should respond with meaningful error messages, that help the user to configure the application correctly. E.g. the error message 'Context "foo" not found should result in Available contexts are "bar", "biz" and "baz".'

Also pligos could help the user to create a new config based on a flavor. But this should probably a different issue

currently pligos heavily relies on creating helm charts locally. This is a problem for two reasons:

1. code architecture gets harder to design and the current codebase is harder to understand because you always have to keep the current state of the disk in your head
2. helmfs is really slow because on every request we have to write the complete helm chart tree.

I would like to keep everything in memory for helmfs and introduce two new commands install and template which would basically be the counter parts to their helm siblings.