Greetings Devs :)<br><br>Sacha Magne had asked me to annotate this issue in the Mantis, perhaps unawares that it was an issue rather close to my heart, as I have been asking for something like this for some time.<br><br>As my thinking on this somewhat exceeds the scope of a note to the mantis, I decided to make my post here instead.<br>
<br>The short take: I think this is a feature very much in need of implementation, generally speaking - I think it impacts region (and therefore grid) stability in a sufficiently significant manner that it should take on an increased level of prioritization.<br clear="all">
<br>The long view: Simply put, refusing to register an out of date revision of the region is not sufficient to the cause. Additionally, there is the (valid) conern about SVN revision numbers being used to track the 'fingerprint' of a simulator that is being connected.<br>
<br>First, I'll address the issue of SVN revision number as a fingerprint:<br><br>While it may not be the most desireable means of identifying the region for these purposes, it is the one that has the ideal level of granularity - as quickly as the project moves, and as dramatic as changes in operations sometimes are, the release number is simply not sufficient to the cause as we currently stamp releases. So, in order to make this feature deliver acording to the need, we either must use the SVN revision number, or come up with some other methodology for identifying the age of the region in  terms of its functional age. The obvious thing to use is the revision number, as it tracks the level of change at precisely the right granularity. The question becomes then one of pinning the revision down in the runtime environment. There are already provisions in place for this to happen, and if the software is built to accomodate it, the revision will be available at run-time - it may be sufficient to say that from the point of the introduction of this feature, any region not built such that it identifies itself by revision number is disallowed from participation (provided, of course, that this feature is enabled in the approriate config file).<br>
<br>Finally, I'll address the insufficiency of this approach as a solution:<br><br>Denying registration of a new region for these purposes is good - but it's not the full solution to the problem. First, I suppose I need to point out the obvious in order to lay the groundwork for my assertion: a running simulator connected to a grid is not 'connected' in any meaningfull sense; rather, it is 'registered'. Registration means that the simulator has a) permission to use the grid services provided, and b) sufficient information on file in the grid backstore to facillitate the delivery of grid services to the simulator. This is significant because, for instance, one may upgrade a grid in the presence of many running and 'connected' simulators, and provided there is not sufficient change in the protocols, the simulator will never be the wiser for it.<br>
<br>Consequently, we need not only a way to refuse 'simulator X' registration on the grounds of it's revision relative to the grid, but also a mechanism for refusing service based on the relative simulator revision, and a mechanism for arbitrarily deregistering a simulator altogether. This will effectively temporarily or permanantly remove a region from the grid, given sufficient differences in the revision in the one instance, or operator intervention in the other. This will effectively implement the philosophy Sacha is attempting to express with his patch :)<br>
<br>I think it is fairly important that we do this; not just because I am constantly beset on some border by misconfigured regions, but because it will help to ensure a more 'statistically controlled' environment from a testing and debugging standpoint; in other words, we can count on regions to behave in particular ways when we have some control over what revision is talking with the grid or with other simulators.<br>
<br>I apologize for being so long winded - I hope you have made it through my post without getting a headache.<br><br>Cheers<br>James<br><br><br>-- <br>===================================<br>The wind<br>scours the earth for prayers<br>
The night obscures them<br><br><a href="http://osgrid.org">http://osgrid.org</a><br><a href="http://del.icio.us/SPQR">http://del.icio.us/SPQR</a><br><a href="http://twitter.com/jstallings2">http://twitter.com/jstallings2</a><br>
<a href="http://www.linkedin.com/pub/5/770/a49">http://www.linkedin.com/pub/5/770/a49</a><br>