[Opensim-users] Sim Version Filtering (re: Mantis #0002361: adding simulator release control at grid level to avoid out of date simulator registration )

Tue Nov 4 16:56:04 UTC 2008

Good points all JustinCC :D

Consider, though, that this would be a feature that's enabled/disabled in
configuration, so change-impact would be minimal, breaking only the feature,
and that only until it was freshened up.

I do admit to some curiousity as to how this would impinge on
interoperability.

Also, we -do- already implement some code that scrapes the SVN revision from
somewhere; while it's certainly true two wrongs dont make a right, we could
perhaps rely on the same code for this purpose and hopefully have a single
point of focus in the source when it becomes time to adjust it.

OTH, it may be that there are better approaches I am not seeing (as I dont
code for the project, serialization of interfaces is not something that
would have occurred to me, for instance). Might you elaborate further on
this in terms of who it would impact and how the functionality would be
exposed at the configuration/operation level?

Cheers!
James

On Tue, Nov 4, 2008 at 10:42 AM, Justin Clark-Casey <
jjustincc at googlemail.com> wrote:

> I agree that there does need to be a way to stop regions registering that
> do not implement the required interface.
>
> I don't like revision number as a solution because
>
> a)  It may well not be present for people running binaries or building
> source that doesn't come straight from SVN
>
> b)  Revision numbers are specific to the source control system we happen to
> be using.  If we ever migrate this is bad.
> It may also be bad for people using git-svn.  It is also bad for interop
> with non-OpenSim virtual environment systems.
>
> Therefore, I tend to favour an approach where individual interfaces are
> manually versioned by the developer when the
> interface is changed.  I don't think that this is too much to ask.
>
> However, if somebody wants to supply a patch that implements filtering by
> revision that somehow avoids the problems in
> (a), then I will not object, though this will not be permanent.
>
>
> James Stallings II wrote:
> > Greetings Devs :)
> >
> > 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.
> >
> > As my thinking on this somewhat exceeds the scope of a note to the
> > mantis, I decided to make my post here instead.
> >
> > 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.
> >
> > 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.
> >
> > First, I'll address the issue of SVN revision number as a fingerprint:
> >
> > 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).
> >
> > Finally, I'll address the insufficiency of this approach as a solution:
> >
> > 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.
> >
> > 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 :)
> >
> > 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.
> >
> > I apologize for being so long winded - I hope you have made it through
> > my post without getting a headache.
> >
> > Cheers
> > James
> >
> >
> > --
> > ===================================
> > The wind
> > scours the earth for prayers
> > The night obscures them
> >
> > http://osgrid.org
> > http://del.icio.us/SPQR
> > http://twitter.com/jstallings2
> > http://www.linkedin.com/pub/5/770/a49
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Opensim-users mailing list
> > Opensim-users at lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-users
>
>
> --
> justincc
> Justin Clark-Casey
> http://justincc.wordpress.com
> _______________________________________________
> Opensim-users mailing list
> Opensim-users at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-users
>

-- 
===================================
The wind
scours the earth for prayers
The night obscures them

http://osgrid.org
http://del.icio.us/SPQR
http://twitter.com/jstallings2
http://www.linkedin.com/pub/5/770/a49
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-users/attachments/20081104/5736bbea/attachment.html>