Hi Christian, Sorry to chime in late - I was out. Recently, I had also been thinking about splitting more static configure data (like the action) from highly transactional data like the activations. My reason was, however, to have an easier way forward to multi-datacenter deployments.
Regardless of the motivation for the split into activation-db and "static-db" I would like to make this comment: Now, that we split out the activation-db into its own separate API we should take the opportunity to design this API (interface) that truly allows pluggable implementations. I am particularly interested in an Elastic Search impl for the activation-db (as I believe that ES lends itself well to activations-workloads). There might be other interesting impls. Point being: let's iterate a bit over the interface to make sure it can be implemented in non-CouchDB deployments. I am convinced this will be helpful in the future in order to evolve OW. In the light of the above it would be useful to design the activation-db interface with a mindset that does not assume that activation-db and static-db are the same physical storage or even the same storage technology. Mentioning this to avoid assumptions about ID-semantics, joins, etc. Wdyt? Michael Sent from a mobile device _____________________________ From: [email protected]<mailto:[email protected]> Sent: Wednesday, April 12, 2017 1:37 PM Subject: Re: Save activations in a new activations DB To: <[email protected]<mailto:[email protected]>> Hi OpenWhisk developers, the first Pull Request I mentioned in the last mail (https://github.com/openwhisk/openwhisk/pull/2123) is merged now. If you use one of the three environments in open, the default will still be, that activations are saved in the whisks-db. But now you can set that flag to true. The next Pull request is opened now: https://github.com/openwhisk/openwhisk/pull/2134 It sets the default of the three environments to use the activations-db. It also requires this variable in your environment. It still can be set to true or false. If you have some OpenWhisk deployments, I'd suggest to set the variable to false, do your migration and set it to true afterwards. The migration is described here: https://gist.github.com/cbickel/37e651965781b27de245eac0ce831a53 My next, and last, PR will be to remove the ability to use that flag. If you have any problems with your migration or concerns just reach out to me. Greetings Christian April 10, 2017 2:56 PM, [email protected]<mailto:[email protected]> wrote: > Hi OpenWhisk developers, > > some weeks ago, I started working on some database performance and one item > affects the > whisks-database. > All actions, rules, triggers, packages and activations are stored in this > database. Because of all > the activations, this database becomes really huge over time. > To keep the database with the artifacts, created by the users (actions, ...), > small we had the idea > to put all activations into another database. The activations-db. > > To solve the problem of the migration of existing OpenWhisk deployments, my > proposal is to make the > split configurable with ansible. > PR 2123 (https://github.com/openwhisk/openwhisk/pull/2123) creates this flag. > By default, the > whisks database will be used to store activations. > After some time, I'll open another PR, that changes the default to use the > activations-db. > Again, after some time, I'll open a third PR to remove this flag again. By > default, all activations > will go into the activations-db. > The reason for removing this flag again is, that it will be easier to > maintain only one > configuration: the configuration to use two seperate dbs. > And we think, that all owners of OpenWhisk deployments agree that it would be > good to split > configuration data of the user (actions, ...) and logs (activations, ...). > > If you need to migrate your deployment, it would work with the steps on the > following document: > https://gist.github.com/cbickel/37e651965781b27de245eac0ce831a53 > (https://gist.github.com/cbickel/37e651965781b27de245eac0ce831a53) > > Does anyone have any concerns about this change or any comments? > > Greetings Christian
