View Issue Details

IDProjectCategoryView StatusLast Update
0004447Talerdeployment and operationspublic2016-04-28 22:18
ReporterFlorian Dold Assigned ToFlorian Dold  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionwon't fix 
Product Version0.0 
Target Version0.0Fixed in Version0.0 
Summary0004447: move arm-related things from deployment.git to the respective taler repos
Description... so that we can use gnunet-arm (or the alias taler-arm) to start installed components without having the deployment stuff, which should be mostly about build automation / ci.
TagsNo tags attached.

Relationships

related to 0004460 closedMarcello Stanisci simplify taler installation process 

Activities

Florian Dold

2016-04-22 15:40

manager   ~0010536

This is actually not easily possible, since we would then mix GNUnet config files with taler config files.

The GNUnet config files still have to be there so that gnunet-arm works (even just to find gnunet-service-arm).

The Taler config files obviously have to be there for the services (exchange, merchant, ...) that we want to run.

Florian Dold

2016-04-22 15:46

manager   ~0010537

Maybe gnunet-arm should gain the ability to read configuration files for services from a completely different directory?

Then we could have a taler-arm wrapper and ship each taler component with an arm service file.

But then we'd effectively have three configuration namespaces:
1. GNUnet (to find e.g. gnunet-service-arm)
2. Taler (for exchange, merchant ...)
3. taler-arm

We can't combine (2) and (3), since then gnunet-arm would have to understand the defaulting mechanism for config files that taler uses (instead of just being pointed to one directory).

Florian Dold

2016-04-22 17:16

manager   ~0010538

Right now we're basically implementing (3) by having a separate GNUnet config directory in the deployment.git that just contains paths.conf, arm.conf and taler-{exchange,bank...}.conf

Florian Dold

2016-04-26 14:46

manager   ~0010560

Due to the issues discussed previously here, I propose we not integrate arm deeply into the individual taler repositories, but keep everything separate and specific for our deployments on taler.net and maybe some container test environment.

Issue History

Date Modified Username Field Change
2016-04-19 15:30 Florian Dold New Issue
2016-04-19 15:30 Florian Dold Status new => assigned
2016-04-19 15:30 Florian Dold Assigned To => Florian Dold
2016-04-22 15:03 Florian Dold Description Updated
2016-04-22 15:40 Florian Dold Note Added: 0010536
2016-04-22 15:46 Florian Dold Note Added: 0010537
2016-04-22 16:03 Florian Dold Relationship added related to 0004460
2016-04-22 17:16 Florian Dold Note Added: 0010538
2016-04-26 14:46 Florian Dold Note Added: 0010560
2016-04-26 14:46 Florian Dold Status assigned => resolved
2016-04-26 14:46 Florian Dold Resolution open => fixed
2016-04-26 14:46 Florian Dold Resolution fixed => won't fix
2016-04-28 22:18 Christian Grothoff Status resolved => closed
2016-04-28 22:18 Christian Grothoff Product Version => 0.0
2016-04-28 22:18 Christian Grothoff Fixed in Version => 0.0
2016-04-28 22:18 Christian Grothoff Target Version => 0.0