The only thing I'd argue with here is the log level, Robert. Logstash on the gate doesn't index trace/debug, so info or above would be far more helpful, so that we can have a logstash query for the issue
On 25 February 2015 at 01:20, Robert Collins <robe...@robertcollins.net> wrote: > On 23 February 2015 at 13:54, Michael Bayer <mba...@redhat.com> wrote: > > > Correct me if I'm wrong but the register_after_fork seems to apply only > to > > the higher level Process abstraction. If someone calls os.fork(), as is > > the case now, there's no hook to use. > > > > Hence the solution I have in place right now, which is that Oslo.db *can* > > detect a fork and adapt at the most basic level by checking for > os.getpid() > > and recreating the connection, no need for anyone to call > engine.dispose() > > anywhere. But that approach has been rejected. Because the caller of the > > library should be aware they're doing this. > > > > If we can all read the whole thread here each time and be on the same > page > > about what is acceptable and what's not, that would help. > > I've read the whole thread :). > > I don't agree with the rejection you received :(. > > Here are my principles in the design: > - oslo.db is meant to be a good [but opinionated] general purpose db > library: it is by and for OpenStack, but it can only assume as givens > those things which are guaranteed the same for all OpenStack projects, > and which we can guarantee we don't want to change in future. > Everything else it needs to do the usual thing of offering interfaces > and extension points where its behaviour can be modified. > - failing closed is usually much much better than failing open. Other > libraries and app code may do things oslo.db doesn't expect, and > oslo.db failing in a hard to debug fashion is a huge timewaste for > everyone involved. > - faults should be trapped as close to the moment that it happened as > possible. That is, at the first sign. > - correctness is more important than aesthetics : ugly but doing the > right thing is better than looking nice but breaking. > - where we want to improve things in a program in a way thats > incompatible, we should consider a deprecation period. > > > Concretely, I think we should do the following: > - in olso.db today, detect the fork and reopen the connection (so the > users code works); and log a DEBUG/TRACE level message that this is a > deprecated pattern and will be removed. > - follow that up with patches to all the projects to prevent this > happening at all > - wait until we're no longer doing security fixes to any branch with > the pre-fixed code > - at the next major release of oslo.db, change it from deprecated to > hard failure > > That gives a graceful migration path and ensures safety. > > As to the potential for someone to deliberately: > - open an oslo.db connection > - fork > - expect it to work > > I say phoooey. Pre-forking patterns don't need this (it won't use the > connect before work is handed off to the child). Privilege dropping > patterns could potentially use this, but they are rare enough that > they can explicitly close the connection and make a new one after the > fork. In general anything related to fork is going to break and one > should re-establish things after forking. The exceptions are > sufficiently rare that I think we can defer adding apis to support > them (e.g. a way to say 'ok, refresh your cache of the pid now') until > someone actually wants that. > > -Rob > > > -- > Robert Collins <rbtcoll...@hp.com> > Distinguished Technologist > HP Converged Cloud > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Duncan Thomas
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
