Helm Manual instruction clearly says that to install helm - the M+x list-packages menu should contain one. There isn't one - What to do?
Related
I am upgrading my projects to helm 3.7 and the helm chart export command in no longer supported.
https://github.com/helm/helm/releases/tag/v3.7.0
Also there is no Documentation for versions previous to 3.7 available. I want to upgrade my project and need to know how to replace the code.
Helm chart export command was used to extract the helm chart to a specific destination after you pulled the helm chart image. On which destination you could then run for example helm install
Mine is a Windows 10 computer.
I ran the following command to install official kubernetes helm charts repository.
helm repo add stable https://charts.helm.sh/stable
The installation was successful as it says.
I wanted to understand where they are installed.
Searched on my home folder, and also ProgramData but could not find.
Any help would be appreciated.
Watching some videos, just found the answer.
Run the following command.
helm env
And you should see all the relevant locations.
And note, this works on ubuntu as well!
These docs describe the helm default file location per operating system.
According to them, your repository files should be under %TEMP%\helm.
Since OPAM 2.0, after installation one is required to create/select a "switch" before installing packages. If all I'm using OPAM for is Coq packages, what should I use as my switch?
here is a sequence of command I applied just yesterday to get coq up and running with opam, on a machine where I was not expecting anything. It happens to be a fedora-32 machine, but I expect a similar script to work on other architectures. Anyway, the only specific command is the one to install opam, and apparently this is already done on your machine.
# execute this command with root privileges, for instance via sudo
dnf install opam
For you, only the following lines should be needed.
# the rest shoud be done without root privilege, as the plain user
opam init # I usually answer no to the questions asked
# replace coq-experiment with the name you like
opam switch create coq-experiment ocaml-base-compiler
opam repo add coq-released https://coq.inria.fr/opam/released
opam install coq-interval --yes # just an example
The last --yes option is so that you don't have to answer an extra question, but you may want to omit this option to see what will be installed and agree to it.
Then it is often handy to type as the next command
eval $(opam env)
And you should have coqtop, coqc, available as shell command. If you wish to use coqide, you can simply request for its installation.
opam install coqide
and that should be it.
The opam switch command should only be needed if you wish to have several different version of Coq available at the same time on your computer. This is sometimes needed if some package has not been ported to a recent enough version of coq.
I'm currently running helm 3.0.0 in ubuntu and want to upgrade to helm > 3.0.2 for gitlab. The install instructions suggest it's as simple as deleting the helm binary and downloading the new one and the release notes all suggest there are no breaking changes. Could it possibly be that simple?
It should be that simple, provided you put the binary in the right place in your path (i.e. replace the one that you already get from which helm, assuming you're on unix).
You could test it by running some of the following helm commands:
helm version will tell you what you're running.
helm list will
tell you what you have installed in your cluster (add -n
<namespace> for a different namespace)
If you're ok to temporarily install something into the cluster, follow a helm example to install something and then delete it again with a helm delete
I'm using Ansible to deploy .deb packages from a custom repository.
Sometimes a developer can forget to change the package number, so the repository will have the new package with the old version. This is unnecessary, so I would like to always reinstall the package. How do I do that?
There is the force=yes option for apt module. Ansible documentation says:
If yes, force installs/removes.
But that seems to be about force-accepting any warnings. At least when I turn it off, Ansible gets blocked with a warning about an untrusted source. (Both the repository and the servers are in the same intranet, so that should not be an issue)
I could use this:
- name: force-reinstall myservice
shell: apt-get --reinstall install myservice
But this way I cannot use other options for apt module, and Ansible gets blocked on warnings the same way.
Is there a way to always reinstall a package and avoid blocking on any interactivity?
The proper way is definitely to use the correct version number. But if you don't want to enforce that then the easiest workaround is to first remove the package and then install it again. That is effectively same as reinstalling.
- name: remove package
apt: name=package_name state=absent
- name: install package
apt: name=package_name state=present update_cache=yes
Unfortunately I don't see any possibility for a "reinstall" with the apt package module.
The only possibility is the one already mentioned in the question via shell or better via command module.
- name: Reinstall of package by command.
command: "apt --reinstall install package"
With the apt module you only have the possibility to do an uninstall (state=absent) followed by a new install (state=present). I don't see a problem with the idempotent approach of Ansible, if you use an appropriate condition via when. For example:
- name: Reinstall of package by uninstall and new install.
apt:
name: package
state: "{{ item }}"
with_items: ['absent', 'present']
when: reinstall_is_required
But: An uninstall and a new install can be very risky depending on the package, also this is not the same as a reinstall like "apt --reinstall install package".
I faced the same problem of needing the option of a reinstall.
I installed an application and in the config of the application I changed the execution user for this application. Reinstall changes the owners for all files and folders accordingly.
Uninstall and new install: Uninstall removes all config files (including the one I changed) and the new install creates the package default config files.
Reinstall via apt: The config files remain unchanged (are not overwritten by the package default config) and the configuration of the application is applied with the customized config.
For this reason, the reinstall option of apt is the only option for me.