[Opensim-users] [Fwd: [PROPOSAL]: Sim version filtering (was Re: Sim Version Filtering (re: Mantis #0002361...)]
Justin Clark-Casey
jjustincc at googlemail.com
Tue Nov 11 17:25:25 UTC 2008
Okay, the proposal below has now been implemented as of r7252.
Interface version number is indicated in OpenSim.Framework.Servers.VersionInfo.MajorInterfaceVersion. This needs to be
incremented every time a developer makes a change that renders the new OpenSim revision completely incompatible with the
previous revision. Non exception spewing incompatibilities do not require a version number bump.
Regions now send their major interface version on login. If this number is not the same as the grid service's major
interface version number, then the region is not allowed to connect (and the region owner is advised of the problem).
This is compatible with 0.6 since if no interface version number is given, we assume 0 (which is what the current
VersionInfo.MajorInterfaceVersion is).
What this doesn't do is deal with regions that are already connected. At the moment, these would need to be manually
kicked off the grid just before or just after upgrading the services. I'm not sure if such a facility currently exists
(if not, then patches are welcome).
This is the minimum possible implementation for region filtering (and slightly experimental). As well as a major
version there may also be a need for a 'minor' version number to allow grid owners to stop even slightly incompatible
regions from connecting, or to tell the region owner that their region doesn't have all the capabilities that it could
have. It should be fairly easy to add this if there is a need for it.
-------- Original Message --------
Subject: [PROPOSAL]: Sim version filtering (was Re: [Opensim-users] Sim Version Filtering (re: Mantis #0002361...)
Date: Wed, 05 Nov 2008 14:23:25 +0000
From: Justin Clark-Casey <jjustincc at googlemail.com>
To: opensim-users at lists.berlios.de, opensim-dev at lists.berlios.de
References: <170fa1780811040825m3be9b863h99066cbb45a5dbca at mail.gmail.com> <49107B6A.2090307 at googlemail.com>
<170fa1780811040856i56ea2472o774fdc9337142896 at mail.gmail.com>
PROPOSAL FOR SIM VERSION FILTERING
Not being able to stop sim versions that implement obsolete comms interfaces from connecting to a grid is becoming an
increasingly awkward problem. As you can imagine, it leads to a high volume of support requests, particular if the grid
is upgrading quite often (which is the case in large development test grids).
There has been a proposal (in http://opensimulator.org/mantis/view.php?id=2361) to have the region server send its SVN
revision number to enable filtering by the grid server. However, I'm not a fan of this idea for the reasons outlined in
the e-mails further below (ties us into a source control system, not necessarily present in binaries/source, not
friendly to non OpenSim implementations).
Therefore, I am going to propose that there is an interface version number in OpenSim.Framework.Servers.VersionInfo.cs.
This is separate from the OpenSim version, and would increase by 1 every time a change was made to OGS1 or interregion
interfaces that was incompatible with older versions.
So the sequence would be 1, 2, 3, 4, ...
On region connection, the version number would be sent. If it differs from that of the grid, the grid would refuse
connection with a message advising version upgrade (or possibly downgrade)
The advantages of this approach are that
a) We don't use the SVN revision number
b) Grid operators don't have to manually determine which regions are compatible
The disadvantages are
a) Developers have to upgrade the number themselves. I don't believe this is a huge burden. It's also not a disaster
if this is forgotton - one just upgrades it on the next commit.
This may be the simplest thing that could possibly work whilst avoiding the disadvantages of using the SVN number. One
can get more elaborate (e.g. minor verion numbers for compatible changes) but I don't think the complication is
worthwhile or known to be workable at this point.
Comments?
James Stallings II wrote:
> 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 <mailto: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
> <mailto: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 <mailto: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
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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
--
justincc
Justin Clark-Casey
http://justincc.wordpress.com
More information about the Opensim-users
mailing list