View Issue Details

IDProjectCategoryView StatusLast Update
0005984Talerdeployment and operationspublic2020-06-19 08:36
ReporterFlorian DoldAssigned ToFlorian Dold 
PrioritynormalSeverityminorReproducibilityhave not tried
Status assignedResolutionopen 
Product Version 
Target VersionFixed in Version 
Summary0005984: usability of deployment.git must be improved
DescriptionIn 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
TagsNo tags attached.

Activities

Christian Grothoff

2020-02-18 23:27

manager   ~0015382

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.

Christian Grothoff

2020-02-18 23:33

manager   ~0015383

> 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.

buckE

2020-06-19 08:36

developer   ~0016318

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?

Issue History

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