[bind10-dev] How to have a pleasant conversation with the administrator about life, the universe, and everything, OR The Problem of the Unused SQL Column

[Jerry Scharf]

Shane,

I think we are looking at this at too low a level and with a case that 
doesn't bring out the corner cases that a real discussion of this kind 
of problem needs.

First, I want to check my assumptions: The data we are talking about is 
auth data stored in a server local datastore and accessed through a set 
of interface routines that provide a implementation independent view of 
the data. The data for this local datastore comes from several sources: 
loading zone files, dynamic update, local administrative action. As 
such, there may or may not be a single external record of the data in 
this datastore. The modules that are clients of this store are the auth 
server module, xfrin and out, loadzone, ddns module (if different than 
auth server) and admin. [what about these assumptions are wrong or 
incomplete?]

Let's look from the datastore side first:

To my simple mind, the datastore is tightly coupled to the interface 
routines. It is the interface routines that determine the schema needed 
in the datastore. So I would argue that the real thing that we are 
talking about is the interface routines are changing in a way that the 
datastore needs to also be modified.

All this may seem needlessly picky, but I think it is important to be 
exactly clear what we are talking about. Version N of the interface 
needs version M of the datastore and version N+1 of the interface needs 
version M+1 of the datastore.

To me, the safest way to go is to block datastore updates, dump version 
M of the datastore and feed it into a M+1 datastore. This could be 
direct or using a neutral format in the middle. This makes it a 
preprocessing step for the interface upgrade. Once the M+1 is ready, the 
interface routines are replaced, all the modules are touched to use the 
new interface N+1 and then updates are reenabled. There would be a 
significant delay for updates, but the system can keep on chugging along 
while this happens. The good thing about this is that there is no time 
at which the database access is mixed, you are either at N/M or N+1/M+1.

A more challenging way to do this is with an in-place upgrade to the 
database while the server is live. This becomes hairy in the general 
case because you will have to have several states handling by the live 
server. The original state in N/M. Then you have N+1/M and N+1/M+1 
operating concurrently on the datastore, then you finally end up with 
N+1/M+1 only. There still needs to be the thing that either as part of 
the library code or as an external processing step needs to convert the 
data from M to M+1 in the datastore. Handling failures and rollbacks 
also becomes more challenging with in-place work.

Taking down the server to make the change seems like a poorer idea to 
me, but it would make the in-place update much simpler.


Next comes a separate question of generically, "how are software updates 
to the server done and how are they controlled by the server 
administrator?" I have seen no specific discussion of this in any docs. 
If we had a single O/S, I would think we would default to the O/S 
preferred method of component update so as to get the pre and post 
processing hooks built in. With a more general solution, we can either 
have the individual O/Ses use their native update mechanism or we 
develop/borrow/adapt something that OS independent. One part of this 
becomes scheduling of upgrades. Is this part of the control tools or 
outside? With BIND 9, it is clearly outside, but the multiple module 
design makes having it internal be more attractive. I will watch the 
discussions and see if there is more work coming my way.


jerry



On 10/14/2010 05:32 AM, Shane Kerr wrote:
> Hello,
>
> I noticed there is a column called "dnssec" in the "zones" table. I
> checked with Evan, and he says this column is unused.
>
> I'd like to remove it. Presumably this means a new schema_version (2 I
> think).
>
> We had some discussion earlier over what is involved with such a change.
> Ideally the system would detect that an earlier version is in use and
> automatically upgrade if possible. (In this case it is quite easy.)
>
> This becomes tricky because we need to know *when* to upgrade. For
> example, this may take a long time if the system has very large zones,
> and administrators may upgrade the software, and then not want to wait
> while the SQL database grinds away changing tables.
>
> What I we may want is a way for a module to indicate that it wants some
> administrator action. The way that this information actually gets to the
> administrator can vary; the bindctl can display a message when it starts
> up, or it can appear in syslog (perhaps repeated each day?), or we can
> create a module which sends a status e-mail periodically about how the
> server is running.
>
> This is a bit like logging, but I think also perhaps different. I
> consider it a bit like your operating system reminding you with a little
> icon that it is time to reboot after applying security patches.
>
> While the idea occurred to me in the context of upgrading a table, it
> can be used for anything that requires an administrator to do something.
>
> Anyway, once we have a system that expects administrators to do
> something, then we have to have a way for them to do the upgrade. I
> think in this case a little script is probably the answer, although we
> also need to send a message to the c-channel to let all of the tasks
> know they need to re-connect to the data source.
>
> Thoughts?
>
> --
> Shane
>
> _______________________________________________
> bind10-dev mailing list
> bind10-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind10-dev
>