<julm>
eeva: nixops pour préparer dans une VM ce que je vais mettre sur du métal quand ce sera prêt
<julm>
j'ai pas trop à me plaindre de nixops, si ce n’est qu'il est un peu lent à se lancer (peut-être parce que c du python, peut-être parce qu'il fait des choses)
<eeva>
Pas mal!
<julm>
en attendant je lutte pas mal pour installer des plugins dans redmine
<julm>
le code .nix de redmine est très brouillon
<julm>
et je ne connais pas bien ruby ni le support ruby de nixpkgs
<eeva>
Bon courage :D
<eeva>
(on a plein de ruby dans ma boîte et mon espoir est de ne jamais devoir y toucher)
<julm>
heh
<eeva>
tiens, je pense que je vais aller nixopsizer ma config locale (et ajouter le support des secrets de elvishjerricco)
<julm>
cool
<julm>
nixops apporte essentiellement que config.deployment pour plusieurs machines, le reste c'est la config de nixos
<julm>
en général on scinde la config en deux : nixops create install/logical.nix install/physical.nix
<julm>
où physical.nix peut soit changer, soit être : with builtins; import (toPath ./. + "/physical/" + getEnv "NIXOPS_DEPLOYMENT" + ".nix")
<julm>
et là c'est la variable d'env NIXOPS_DEPLOYMENT qui change
<julm>
et pour les secrets via extraBuiltins, je construis une dérivation qui rassemble le code que je veux
<eeva>
(oopsie, sorry about that :D didn't mean anything, was vacuum cleaning too close to the keyboard ><')
<eeva>
(erf, et c'est channel en français, aucune raison d'écrire en anglais)
<julm>
:)
<julm>
bon, j'ai avancé un petit peu sur cette histoire de plugin redmine
<julm>
je me disais de faire peut-être une install déclarative comme les plugins Eclipse (cf. eclipseWithPlugins) mais en fait je pense que ça ne permettrait pas ensuite de désinstaller proprement les plugins de la base de données de Redmine
<julm>
du coup je vais plutôt poursuivre une install déclarative non pas dans pkgs/ mais dans nixos/, qui installe les plugins dans /var/lib/redmine plutôt que dans /nix/store
<samueldr>
y'a probablement deux écoles de pensées là-dedans: 1. ignorer la désinstallation, laisser ça comme étape manuelle (c'est ce qui est fait pour tout ce qui est stateful) 2. automatiser ça *d'une manière ou d'une autre*, mais j'ai pas vraiment de pistes
<julm>
de sorte à pouvoir faire un diff des plugins dans /var/lib/redmine, et désinstaller proprement les plugins ôtés
<julm>
ou alors, hmm
<samueldr>
je connais pas redmine, mais est-ce que ce sont seulement des fichiers dans un sous-dossier ou est-ce que c'est éparpillé et avec de la config dans une BDD?
<julm>
faire une install stateful mais conserver un lien vers les anciens plugins dans /var/lib/redmine tant qu'ils ne sont pas supprimés
<julm>
c'est un gem dans un dossier et une migration de db
<samueldr>
et j'imagine que ça casse si les infos dans la BDD ne sont pas retirées(?) avant de supprimer la gem?
<julm>
du coup, ôter le plugin en remplaçant directement pkgs.redmine (ou pkgs.redmineWithPlugins), ça complique la désinstalle
<julm>
je me dis qu'il vaut mieux coller au mieux INSTALL.md de Redmine
<julm>
+au
<julm>
qui dit de faire ça
<samueldr>
de mémoire, la gestion de certaines app PHP automatisée avec Apache sur NixOS se fiche de désinstaller, c'est-à-dire que si tu enlèves quelque chose, le plugin ne sera plus dans les dossiers de ta version de l'app, mais ne fait rien pour tout ce qui est stateful
<julm>
si je fais un pkgs.redmineWithPlugins (comme pkgs.eclipseWithPlugins, mais en ruby plutôt qu'en java), le seul truc que je vois après c'est d'avoir encore dans /var/lib/redmine des liens vers les anciens plugins et de les désinstaller proprement
<julm>
samueldr: mouais, mais bon c'est nul
<julm>
samueldr: ça devrait pouvoir être gérer un minimum
<julm>
géré*
<samueldr>
(d'une manière, je trouve ça correct parce que supprimer tout proprement c'est difficile, et c'est risqué: un utilisateur supprime le plugin de la liste par erreur et perd tout ce qui était stateful en rapport?)
<julm>
hmm
<julm>
pas faux
<samueldr>
c'est comme ça pour pas mal tout ce qui est stateful: ajoute mysql à ta config, start le, fais une table; retire le de ta config -> /var/ va encore contenir les fichiers stateful
<julm>
voui
<samueldr>
(et de toute manière, même un utilisateur avec une app installée à la main pourrait vouloir différents résultats après avoir retiré un plugin, j'imagine?)
<julm>
faudrait p'têtre une option pour choisir quoi faire
<julm>
dans tous les cas, au moins permettre de chdir qqpart pour pouvoir faire une uninstall manuelle propre
<samueldr>
(faut dire aussi que je connais pas redmine, donc je parle un peu à travers mon chapeau)
<julm>
ou bien dans un preStart nixos
<julm>
samueldr: tkt, je connais très peu aussi, merci en tout cas
<julm>
je me dis que vu le nombre de plugins disponibles ça va être pénible de tous les mettre dans pkgs (apparemment faut modifier la Gemfile, passer par bundle install puis bundix pour générer gemset.nix… lourd), je trouve plus simple de lancer bundle install directement sur le /var/lib/redmine du target
<julm>
ce qui veut dire pouvoir avoir un environnement bundle évolutif dans /var/lib/redmine
<julm>
pkgs/applications/version-management/redmine/Gemfile a un bout intéressant que je ne comprends pas encore :
<julm>
# Load plugins' Gemfiles
<julm>
Dir.glob File.expand_path("../plugins/*/{Gemfile,PluginGemfile}", __FILE__) do |file|
<julm>
eval_gemfile file
<julm>
end
<julm>
je comprends pas encore comment l'utiliser, mais comme le Gemfile se reste dans /nix/store/29akhf9qx6irycdib3r7lpcy38mhlka5-redmine-3.4.6/share/redmine/Gemfile je me dis que ça peut être une piste