View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005984 | Taler | deployment and operations | public | 2019-12-03 13:30 | 2021-08-24 16:23 |
| Reporter | Florian Dold | Assigned To | Florian Dold | ||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Target Version | 0.8 | Fixed in Version | 0.8 | ||
| Summary | 0005984: usability of deployment.git must be improved | ||||
| Description | In order to upgrade an environment, currently we have to run an arcane set of commands in the right order. * When taler-deployment-sign is run before taler-deplyoment-keyup, a new and different key is created for the exchange. That's not really acceptable. * We frequently run info permissions problems on the demo-blue/demo-green split. The corresponding deployment scripts should make sure that permissions are correct. * The following "tools" should probably be folded into one command: (1) taler-deployment-config-generate (2) taler-deployment-keyup (3) taler-deployment-sign (4) taler-deployment-hier (what does this one even do?) (And what does taler-deployment-prepare even do? It looks like some unholy amalgamation of the previous commands *plus* running a re-build) * scripts for taler-deployment-start should probably *also* run some checks after it finishes and print the output of "taler-deployment-arm -I", so it is harder to forget checking manually | ||||
| Tags | No tags attached. | ||||
|
|
It seems the folding of the commands has been partially done with the creation of taler-deployment-prepare. However, more needs to be done here. I also find it confusing that some commands to be used are taler-deployment COMMAND and others are taler-deployment-COMMAND. If all commands to be actually (primarily) used were of the form "taler-deployment COMMAND" and all helper-scripts were "taler-deployment-helper-COMMAND", that might reduce confusion and improve consistency. And we should document each command and each helper script in the developer manual. |
|
|
> However it's not entirely clear what should happen or what should be > done if, say, you change the envcfg.py. Do you have to re-boostrap? Or > should "taler-deployment build" handle this? What if I want to not lose > my local modifications? Should "taler-deployment build" some option to > either fetch repos or not? Or update from envcfg.py? Etc ... Right now, the docs on 'updating' say that you have to $ rm -rf ~/sources ~/local. That seems both very expensive (lots of compile time) and prevents any kind of "not lose my local modifications". In general, I would argue that local modifications are just bad and should simply not be done: if the deployment.git is used, ALL modifications belong into the scripts, we do have cases for the different deployments in the scripts, so users MUST update the scripts (otherwise we have no versioning and just chaos). However, doing incremental builds (git pull, make install over the existing installation) and preserving existing *KEYS* and databases should be the default and supported during upgrades, so no more "$ rm -rf" and while the configuration is re-generated, the keys should be kept/migrated *unless* a specific version jump breaks something badly, and then that has to be in the instructions for updating to that version. Doing the full bootstrap, activate (missing in docs!), build, prepare, restart sequence seems fine, as deployment.git obviously needs to be updated (bootstrap), code needs to be build (gcc) and possibly databases/key material needs to be updated/migrated/etc. |
|
|
Florian, when you're ready please respond to Christian's comments. Also I would like to know: - what do you mean by "upgrade an environment" in general? What sort of environment? - What is the full and exact current process? - What is the general process you would like to see? - which scripts are you referring to? Are these in some private script repo? - Is this something that should be done by buildbot? Or unrelated? |
|
|
The deployment process is now much simpler, and also documented better. Most of the manual steps have been moved to "taler-deployment-prepare". |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2019-12-03 13:30 | Florian Dold | New Issue | |
| 2020-02-18 23:27 | Christian Grothoff | Note Added: 0015382 | |
| 2020-02-18 23:33 | Christian Grothoff | Note Added: 0015383 | |
| 2020-04-01 16:28 | Christian Grothoff | Assigned To | => buckE |
| 2020-04-01 16:28 | Christian Grothoff | Status | new => assigned |
| 2020-06-19 08:36 | buckE | Note Added: 0016318 | |
| 2020-06-19 08:36 | buckE | Assigned To | buckE => Florian Dold |
| 2021-05-20 21:44 | Florian Dold | Status | assigned => resolved |
| 2021-05-20 21:44 | Florian Dold | Resolution | open => fixed |
| 2021-05-20 21:44 | Florian Dold | Note Added: 0017886 | |
| 2021-07-30 13:56 | Christian Grothoff | Fixed in Version | => 0.8 |
| 2021-07-30 13:59 | Christian Grothoff | Target Version | => 0.8.1 |
| 2021-07-30 14:01 | Christian Grothoff | Target Version | 0.8.1 => 0.8 |
| 2021-08-24 16:23 | Christian Grothoff | Status | resolved => closed |
