← Back to team overview

nova team mailing list archive

Gflags, Settings, Dependency Injection


I'm having some annoyances with gflags which I'd like to air out here.
 Maybe we can come to a consensus about how to move forward with them.  I
find gflags annoying in the following ways:

a) flags are irritating for global settings.  Settings that apply to the
project as a whole have to be set in multiple places so that the binaries
all get them properly.  This can be fixed somewhat by a shared flagfile.
 For example:
  --flagfile=/etc/nova/nova-common.conf # shared settings
  --otherflag=true #manage specific settings

The problem here is that the shared settings can only include settings that
are imported by EVERY binary, or one of the binaries will choke.  So if you
have a flag that 4 of 5 binaries use, you either have to set it in four
flagfiles or put it in common with an ugly undefok= line.  This all seems
nasty to me.  Other possibilities include moving truly common/settings
related flags into the common flags.py so that they are available to all
binaries.  It all seems a bit hackish.

b) including files for flags only

There are places where we need access to a flag, but we aren't actually
making calls in the file.  Pyflakes and pylint complain about unused
imports.  Perhaps we fix this by moving these flags into common flagfile?

c) dependency injection

This is related to the issue above.  If we are dynamically loading specific
drivers (for example the auth driver or a datastore backend) as specified by
a flag, the import is often done later than the parent file is imported.
 Therefore using flags to configure settings for the driver will fail,
because the binary recognizing the flags is dependent on the file that
contains the flags being imported.  Workarounds here include finding a
different method for dependency injection, hacking flags to search for flags
in injected dependencies somehow, or configuring drivers differently than
the rest of the system.

So I see 3 options for moving forward

1) ditch gflags completely and use a different method for specifying

2) use a combination of some kind of settings file for general
configuration, and flags for specific runtime settings/hacks

3) find good standard practices/workarounds for the above issues



Follow ups