[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

[Shane Kerr]

Jerry,

On Thu, 2010-10-14 at 13:50 -0700, Jerry Scharf wrote:
> First, I want to check my assumptions: 

These seem correct.

> Let's look from the datastore side first:



> 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.

This is "safe", but of course the trick is 'block datastore updates'....
more below...

> 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.

I would say "highly challenging".

> 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.

Yes, I think this is kind of what I'm leaning towards now.

While I think in-place data source updates would be sexy, it is also
something that is unlikely to be necessary for most users. Users will
small data sources can quickly run any necessary conversion. Users with
large data sources will have multiple servers for redundancy, and would
rarely trust an in-place data migration anyway. (At least, based on the
system administrators I know.)

Based on this, I think in-place update will be added to our feature
list, but with a lower priority.

> 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.

The only requirements about this was in the early requirements for the
"boss" process:

https://bind10.isc.org/wiki/MasterOfBindRequirements

        2.2.9 Upgrade MoB
        
        The MoB must be able to install a new version of itself without
        restarting the entire system.
        
        2.2.10 Upgrade component
        
        The MoB must be able to install a new version of any component.
        This may restart the component. 

However, these requirements were dropped because of the added
complexity.

Like in-place data source upgrades, I think these can safely be
relegated to the "that would be cool" list of functionality.
Hopefully. :)

--
Shane