| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| | |
Default fam blocking to true
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In Bcfg2.Options.Parser._parse_config_options, if the "default" of the
option (perhaps set by the config file) evaluates to True, then it runs
the actions associated with the option. Otherwise, it just sets the
option to the default directly with setattr.
Since the default of a store_false action is True, the code will run
argparse's _StoreFalseAction function. Well, _StoreFalseAction, is a
subclass of _StoreConstAction where const=False. _StoreConstAction has a
call method which looks like this:
def __call__(self, parser, namespace, values, option_string=None):
setattr(namespace, self.dest, self.const)
So it completely ignores the value passed in and just sets the value of
the option to const (i.e. False).
Looking at fam_blocking
{None: _StoreFalseAction(option_strings='fam_blocking',
dest='fam_blocking', nargs=0, const=False, default=True, type=None,
choices=None, help='FAM blocks on startup until all events are
processed', metavar=None)}
start phase 3
fam_blocking config val is True
start phase 3
_parse_config_options: fam_blocking default is True
_parse_config_options: calling argparse.<class
'argparse._StoreFalseAction'> with value True on fam_blocking
_parse_config_options: after calling argparse.<class
'argparse._StoreFalseAction'> fam_blocking is False
after _parse_config_options fam_blocking is False
after phase 3 fam_blocking is False
after phase 4 fam_blocking is False
end of parser fam_blocking is False
CLI init fam_blocking is False
So how to fix it? Define a new Action? That seems like the most direct
approach since the problem really is that _StoreFalseAction does what it
says on the tin, it stores false no matter what.
The new action BooleanOptionAction works like store_true and store_false,
except that it stores the value that was passed in, or the default if there
was no value passed in.
|
| |
| |
| |
| |
| |
| |
| | |
There is a quirk in the configuration parser where a BooleanOption
with default=True will always return false __unless_ a command-line
option is provided. Not sure why that's the case, but this is a work-
around
|
| |
| |
| |
| |
| |
| |
| | |
Based on discussion in #bcfg2, the consensus seems to be that the
behavior provided by fam_blocking = True is the least surprising
of the two options (i.e. the server should not process data until
it is ready). 1.4 seems like a good time to make this change.
|
| |
| |
| |
| |
| |
| | |
needs
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
|/
|
|
| |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
|\
| |
| |
| | |
https://github.com/AlexanderS/bcfg2
|
| |
| |
| |
| |
| | |
Highligh additional special hosts in the grid view. Stale hosts get a
grey background and clean hosts with extra packages get a blue background.
|
| |
| |
| |
| | |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
|\ \ |
|
| |/
| |
| |
| |
| |
| | |
Add a new column "stale", that displays if a host is stale or not. It could be
determined by parsing the date column, but it would be more convenient to
have a separate column for that.
|
| |
| |
| |
| | |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
| |
| |
| |
| | |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
| |
| |
| |
| | |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
| |
| |
| |
| | |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
| |
| |
| |
| | |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
| |
| |
| | |
This should eventually be a configurable.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
Conflicts:
doc/server/plugins/structures/bundler/index.txt
src/lib/Bcfg2/Server/Admin/Init.py
src/lib/Bcfg2/Server/Plugins/GroupLogic.py
src/lib/Bcfg2/Server/Plugins/Properties.py
src/lib/Bcfg2/Server/Plugins/Reporting.py
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
This reverts commit 433974d9311f68f199bedf1c2710381e0bc8d34a.
python-nose is required by bcfg2-test.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
python-nose is only required for running the nosetests. It is not
required by bcfg2-server.
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
| | |
| | |
| | |
| | | |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
| | | |
|
| | |
| | |
| | |
| | | |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
| | |
| | |
| | |
| | |
| | | |
Avoid building client metadata while rereading those files, and expire
the metadata cache afterwards.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This makes a best effort to watch XIncluded files that do not exist.
Assume that you have XIncluded ``foo.xml``, the following (currently)
fails:
mv foo.xml /tmp
mv /tmp/foo.xml .
Bcfg2 processes the deletion event, and stops watching ``foo.xml``;
consequently, it receives no creation event when you put ``foo.xml``
back.
This does not fix the situation where you add a new file that is
matched by a wildcard XInclude, which turns out to be much more
difficult, and will likely require a significant restructuring of how
wildcard XIncludes are processed. (I.e., we'll need to place a
monitor on the directory or directories where the wildcard XInclude is
looking, and then filter events according to the wildcard.)
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
| | |
| | |
| | |
| | | |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
| | |
| | |
| | |
| | | |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
| |/
|/|
| |
| | |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
| |
| |
| |
| | |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
|\ \ |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The new FreeBSDInit tool uses the service and sysrc tools
to manage the FreeBSD rc.d services. There are no hardcoded
paths to /usr/local/etc/rc.d/ anymore and the service tool
handles rc.d scripts in /etc/rc.d/ as well.
Additional to that, the new tool also gathers information
about extra services that are enabled (using service -e)
and can enable new services with sysrc. This is a frontend
for /etc/rc.conf and therefore changes that file.
|
| | | |
|
| | |
| | |
| | |
| | | |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
| | | |
|
| | | |
|
| | | |
|
|/ / |
|
| | |
|
| |
| |
| |
| | |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
| |
| |
| |
| | |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
misc/bcfg2.spec
src/lib/Bcfg2/Client/Client.py
src/lib/Bcfg2/Client/Tools/APK.py
src/lib/Bcfg2/Client/Tools/MacPorts.py
src/lib/Bcfg2/Client/Tools/Pacman.py
src/lib/Bcfg2/Client/Tools/YUM.py
src/lib/Bcfg2/Server/Admin/Minestruct.py
src/lib/Bcfg2/Server/Admin/Pull.py
src/lib/Bcfg2/Server/Admin/Viz.py
src/lib/Bcfg2/Server/Core.py
src/lib/Bcfg2/Server/Plugins/Cfg/CfgEncryptedGenerator.py
src/lib/Bcfg2/Server/Plugins/Cfg/CfgPrivateKeyCreator.py
src/lib/Bcfg2/Server/Plugins/Properties.py
src/lib/Bcfg2/settings.py
src/sbin/bcfg2-crypt
src/sbin/bcfg2-info
src/sbin/bcfg2-lint
src/sbin/bcfg2-yum-helper
testsuite/Testsrc/Testlib/TestServer/TestPlugins/TestCfg/TestCfgEncryptedGenerator.py
testsuite/Testsrc/Testlib/TestServer/TestPlugins/TestProperties.py
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
For both Encrypting and Decrypting of Properties
files, we should by default only attempt to execute
on elements that have an "encrypted" attribute defined.
The code will already attempt to encrypt every element
if nothing in the current document matches this xpath,
which catches the case of a user trying to fully
encrypt a completely new properties file.
Conflicts:
src/lib/Bcfg2/Server/Encryption.py
|