I look at this help requirement:
dependencies:
- name: postgresql
version: 8.6.2
repository: https://kubernetes-charts.storage.googleapis.com/
condition: postgresql.installdep.enable
Source: https://github.com/reportportal/kubernetes/blob/master/reportportal/v5/requirements.yaml
Postgres 8 is very very old. I guess this version is just the version of some package.
But how can I get more information about this package?
I look at https://kubernetes-charts.storage.googleapis.com/. But this URL seems made for robots, not for humans.
How can I (as a human) find more details about this dependency?
It looks like you can find the chart here: https://github.com/helm/charts/tree/master/stable/postgresql
It's current version is 8.6.4.
Your dependency looks like it references this PR and this version.
Also, as an aside that refers to the Chart version, not the postgres version. It looks like the current Chart is for postgres 11.
You can use helm dependency update locally: https://helm.sh/docs/helm/helm_dependency_update/
This will download all the dependencies to the ./charts subdir where you can check its contents and default vars.
Requirements.yaml is used to list Chart dependencies. Those dependencies can be built using helm dependency build from requirement.lock file.
Version describes chart version, not the image itself.
All necessary information about the chart are described in values.yaml- you can find there information about images to be installed, it's version etc. In this case it's postgresql:11.7.0.
You can retrieve information about the chart by using helm show values <chart_name> (chart doesn't have to be installed in the cluster) or it can be found on chart's github/ helm hub repository.
Related
lately I was experimenting with Skaffold with our Helm Charts and I am in little bit in a dilemma that our Helm Chart \ Sub Charts are compatible with Skaffold or not.
Our helm Charts are looking like the following
my-helm-charts
+-charts
+-project1
+-project2
+-project3
+-project4
+-infrastructure_kafka
+-charts
+-kafka
+-zookeeper
+-infrastructure_cassandra
+-infrastructure_elasticsearch
+-Charts.yaml
+-Values.yaml
The reason we choosed to structure the Helm Charts this way, is that if necessary to spin up extra stages for our project.
Now when I want to develop project2 with Google Cloud Code / Skaffold (which I configured correctly and I can start without problem in IntelliJ) I have to start whole my-helm-charts.
That is actually Ok but the problem is, if I use Debug in Kubernetes, I have a feeling Google Cloud Code/Skaffold can really locate the project2 and no debugging occurs.
My feeling is Google Cloud/Skaffold is more oriented to work with following contruct...
project2-helm
+-templates
+-Charts.yaml
+-Values.yaml
My Subcharts contructs starts in Google Cloud Code/Skaffold without any exception but I can't debug, is it possible to achieve want I want with my structure and if yes, how?
Or is it not possible at all...
Thx for answers...
We recently added a feature called config dependencies which might help here. It allows you to create more specific skaffold.yamls and then map them together with a "requires" field:
https://skaffold.dev/docs/design/config/#configuration-dependencies
Once you have the skaffold.yamls created and the right dependency mapping you can run skaffold with the -m flag to choose once slice of your services:
skaffold dev -m project3
Cloud Code support for modules is incoming.
Cloud Code IntelliJ and Cloud Code VS Code recently added preview level support for deploying and debugging modules of a larger application which uses Skaffold. See more here https://cloud.google.com/code/docs/intellij/skaffold-modules
When adding a new project to a Rush monorepo, is there a way for Rush to automatically insert the dev dependencies into the package.json? For example I want to use the same test frameworks between projects so it would be good to have Rush sync the dev dependencies.
No, there is no way to do this. rush has no idea which package requires which dependencies and, as such, you'll need to add them manually to each.
However, once you've configured your package.json's accordingly, rush will help you maintain dependency versioning across your monorepo. The precise behaviour can be configured by:
setting preferredVersions in the common-versions.json file
using a version policy such as lockStepVersion
(I presume you found this answer already but in case any stumbles across this in the future)
If you run rush add -h you get the usage.
[usage: rush add [-h] -p PACKAGE [--exact] [--caret] [--dev] [-m] [-s] [--all]]
--dev If specified, the package will be added to the
"devDependencies" section of the package.json
The command you are looking for is
rush add -p PACKAGENAME --dev
I have just started experimenting with Helm kubernetes package manager.
But chart vs template topic seems a bit confusing to me.
I understand that by template I will create kubernetes yaml, which will create the objects and install them.
However the same is true for charts as well, but this latter is an abstraction over the yamls. And ./Charts containns standalone charts, while ./templates is valid only for the base chart. So I know that. But when should I include an other chart or just create a template?
Looking for different kind of charts through the web I still don't know which to use.
Say I have a project called MyApp, which has one component named MyServer which will communicate to MySql.
So I created a chart and put in it MyServer as a template :
./MyApp/templates/MyServer.yaml
What should I do with MySql?
I have seen both solutions in different projects, one just creates an other template:
./MyApp/templates/MySQL.yaml
on other project I saw a chart for MySql from a chart repository:
./MyApp/charts/mysql-version.tgz
On the top of that I have seen a bigdata project (hdfs,kafka,zookeeper,ELK,oracle db..etc) and one component was included as chart in ./charts other was created as a template in./templates.
This whole decision between chart and template seems random and confusing to me.
Could you explain it please when to use which?
A chart is a collection of templates, plus a little extra information like the metadata in the Chart.yaml file and the default values.yaml. In your example, MyApp is itself a chart.
For well-known dependencies (particularly things in the Helm charts repository and especially the stable charts) you're probably better off using the external chart; declare the dependency in your requirements.yaml or (Helm v3) Chart.yaml file and run helm dependency update. This lets you import the chart with two lines, rather than reproducing the StatefulSet, PersistentVolumeClaim, etc. that are included in the chart.
Looks like there is a request for this (link below) but the issue is still in open state:
https://github.com/helm/helm/issues/2205
I was wondering if there is any workaround so that I can pull a chart from chart museum and override one or more versions via command line to point to a different version?
I have a problem trying to add Material-UI to my existing CRA project.
I run:
yarn add material-ui#next
I run:
yarn start
I get:
Module not found: Can't resolve 'material-ui/FlatButton' in 'C:\Users\...\src\components\DialogModal'
Looking in node_modules under material-ui, many folders (including FlatButton) have no content. What went wrong?
The installation worked fine. The problem is that material-ui v1 has many breaking API changes from material-ui v0. One of these is the removal of the FlatButton component in favor of a Button with props. Many other components have also been changed, renamed, or removed entirely.
When you installed material-ui#next, you installed v1 instead of v0, because the #next flag points to v1. So, the absence of these folders and components is expected. You can take a look at which components should be available in the v1 docs.
You have a couple of options:
Uninstall v1 and install v0 instead. You can install v0 by installing material-ui (without flags).
Migrate your code over to v1. You're going to have to do this eventually anyways, and v1 has many improvements over v0, so if this is a possibility for you I would recommend it.