Simplifying serverclass.conf?

[sowings]

Let's say that I have a class in my serverclass.conf that contains a pretty substantial
white/blacklist. This is in an effort to narrow down the hosts receiving a particular set
of apps. Further, let's assume that there are, say, two distinct subsets of the larger
class, that get data center specific apps (e.g. one containing outputs.conf). The docs
for serverclass.conf say that I can include whitelist.N or blacklist.N at the app level
in addition to the class level.

When I provide a filtering statement at the app level, am I overriding the existing one
from the class level, and therefore renumbering the entries, or clearing them, such as
blacklist.4 = ? Or instead is this a completely separate filter and my
numbering would start again at 0?

[hexx · Accepted solution]

According to serverclass.conf.spec:

# Property inheritance
# Stanzas in serverclass.conf go from general to more specific, in the following order:
# [serverClass] -> [serverClass:<name>] -> [serverClass:<scname>:app:<appname>]
#
# Some properties defined at a general level (say [serverClass]) can be
# overridden by the more specific stanzas as it applies to them. All inheritable
# properties are marked as such.
(...)

filterType = whitelist | blacklist
(...)  
* Can be overridden at the serverClass level, and the serverClass:app level.

It seems that a filtering statement at the app level (most specific) will override a colliding statement at the class-level (least specific).

[sowings]

Thanks, I finally worked it out. There was one more key piece of documentation that I had missed before:

# Note: Overriding one type of filter (whitelist/blacklist) causes the other to
# the overridden too. It is important to note that if you are overriding the
# whitelist, the blacklist will not be inherited from the parent - you must
# provide one in the stanza.

My instance used filterType = blacklist but initially failed to carry forward the blacklist entries. When I added that in at app level, that worked.