Open Stack

Hi Liam,

 > I was recently looking at how to support custom configuration that 
relies on post deployment setup.

I would describe the problem in general as follows:

1) charms can get context not only from Juju (config options, relation 
data, leader data), environment (operating system release, OpenStack 
release, services running etc.) but also from a stateful data store 
(e.g. a Keystone database);
2) it's not easy to track application state from a charm because: 
authentication is needed to fetch persistent state, notifications from a 
data store cannot be reliably set up because charm code is ran 
periodically and it is not always present in memory (polling is neither 
timely nor efficient). Another problem is that software that holds the 
state needs to support data change notifications which raises version 
compatibility questions.

By using actions we move the responsibility for data retrieval and 
change notifications to an operator but a more generic scenario would be 
modeling a feedback loop from an application to Juju as a modeling 
system where changes can be either automatic or gated by an operator (an 
orchestrator). Making it automatic would mean that a service would get 
notifications/poll data from a state store and would be authorized to 
use Juju client to make certain changes.

Another problem to solve is maintenance of that state: if we start 
maintaining a key-value DB in leader settings we need to think about 
data migration over time and how to access the current state. In other 
words, in CRUD, the "C" part is relatively straightforward, "R" is more 
complicated with large data sets (if I have a lot of leader data, how do 
I interpret it efficiently?), "UD" is less clear - seems like there will 
have to be 3 or 4 actions per feature for C, [R], U and D or one action 
that can multiplex commands.

This brings me to the question of how is it different from 
state-specific config values with a complex structure. Instead of leader 
data, a per-charm config option could hold state data in some format 
namespaced by a feature name or config file name to render. A data model 
would be needed to make sure we can create versioned 
application-specific state buckets (e.g. for upgrades, hold both states, 
then remove the old one).

Application version-specific config values is something not modeled in 
Juju although custom application versions are present 
(https://jujucharms.com/docs/2.3/reference-hook-tools#application-version-set). 
Version information has to be set via a hook tool which means that it 
has to come from a custom config option anyway. Each charm has its own 
method to specify an application version and config dependencies are not 
modeled explicitly - one has to implement that logic in a charm without 
any Juju API for charms present the way I see it.

config('key', 'app-version') - would be something to aim for.

Do you have any thoughts about leader data vs a special complex config 
option per charm and versioning?

Thanks!