|Anonymous | Login | Signup for a new account||2018-12-16 03:50 PST|
|Main | My View | View Issues | Change Log | Roadmap | Summary | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0008300||opensim||[REGION] OpenSim Core||public||2018-03-05 02:25||2018-03-11 14:59|
|Product Version||master (dev code)|
|Target Version||Fixed in Version|
|Summary||0008300: Request guidance on placement of money plugin economymodule setting|
|Description||In grids with multiple currencies, the presence of multiple money plugins (dlls) in the bin tree is expected. When simulators are started their individual opensim.ini files (set by command parameters) designate which money module (aka EconomyModule) is to be used. Properly written money modules check the EconomyModule setting and disable/enable themselves based on this setting. |
What has transpired recently is that the newer plugin, Gloebit, has chosen to place the EconomyModule setting in a different section of opensim.ini than existing older money module plugins (see Additional Information).
What is asked of core is a judgement call to standardize this setting in opensim.ini and its section placement. My preference is to retain compatibility with a number of existing plugins which place the EconomyModule setting in the [economy] section, instead of the [startup] section. Having them in two different sections breaks a consistency design pattern, creates confusion and errors.
In addition to the placement guidance, I also ask for an architectural statement about the behavior of money module plugins when the setting is absent. All the existing* plugins save one (Gloebit) disable themselves both when the EconomyModule setting does not select them or when the EconomyModule setting is absent. The Gloebit module ENABLES itself when the setting is absent.
Having architectural guidance will help clarify boundary conditions when a plurality of money modules are present. This is similar to several other services in which various implementations are present and one is enabled via selection.
* Note: the DTL money module plugin has an implementation bug that I repaired in which it remained enabled irrespective of the EconomyModule setting. I am happy to contribute the fix to the community.
|Additional Information||Summary of known money plugins or samples|
no mention of economymodule anywhere.
july 2015 - economymodule in section [economy]
Absence of economymodule setting auto-disables the plugin
2015 - NSLDTLmoneyserver, economymodule in section [economy] v0.8.x opensim
Errors in public API implementation neglected to ignore the calls when initialise
disables the plugin. This implementation error is fixed in my version (to be donated).
Absence of economymodule setting auto-disables the plugin
circa 2015 - economymodule in section [economy]
Absence of economymodule setting auto-disables the plugin
2015 - Plugin settings in [OpenMetaverseEconomy]
Absence of settings auto-disables the plugin
2015 - Sample money module. economymodule in [startup] other settings in [economy]
Note several errors in public APIs do not properly ignore the calls when disabled,
likely the reason DTL money module has similar errors.
Absence of economymodule setting auto-disables the plugin
6/2016 - mentions economymodule at end of [startup]
Incompatibile with previously existing practices.
Absence of economymodule setting auto-ENABLES the plugin. This conflicts with all
of the existing money module plugins.
|Tags||No tags attached.|
|Git Revision or version number|
|Run Mode||Grid (1 Region per Sim)|
|Environment||Mono / Linux64|
I'll add some context and slightly different view here, though my goal is the same, to have core decide whether the standard is to have the EconomyModule setting in [Startup] or in [Economy] section of the configs. It is not currently in the OpenSim.ini.example, which leaves some confusion.
I would not say it is standard for a grid to use an identical bin tree for all sims. All DLLs are loaded, whether enabled or not, so this creates bloat for a sim. Many service providers and grid owners I've spoken to intentionally don't include dll's of disabled modules for this reason and to avoid weird bugs like this. I can't say which practice is standard, but including dlls for disabled modules is certainly allowed in OpenSim and should ideally be handled properly.
I don't know the order of whether the SampleMoneyModule or the DTL was created first, but the SampleMoneyModule is included with core, and I would assume set the standard and that the DTL violated this and that Jopensim followed the DTL. Also, in the OpenSim.ini many modules (meshing, physics, DefaultScriptEngine, emailmodule) are selected in the [Startup] section, not in the section specific to their functionality, so this also seems to be the standard, though I haven't looked through the rest with enough detail to say whether this is always consistent. I don't care which location is the standard, just that we have clarity and to provide the basis for why Gloebit went with [Startup]. In my opinion, we followed existing practices and the standard set by core.
The GMM does indeed enable if no EconomyModule setting is found and if enabled=true is set in the Gloebit.ini file. This has caused an issue on Discovery Grid (and only on Discovery Grid) due to their deploy and this standard issue. We aren't finding the EconomyModule setting because they have followed the DTL and set it in the [Economy] section. This would still be fine if they either didn't include our DLL, or properly configured our Gloebit.ini as enabled=false on DTL enabled sims. But, in addition to using an identical bin tree, they supply the same Gloebit.ini to all sims. They effectively provide conflicting config settings to their sims. This should still work, and the Gloebit Money Module would still disable itself, except for the fact that we aren't seeing the EconomyModule setting. We will make sure our module looks in both locations on our next release, but we still need a decision on the standard for what we place in our documentation as to where to instruct customers to place this config setting in the future.
Gloebit defaulting the EconomyModule setting to "Gloebit" when it doesn't exist and our dll and ini are present and our ini is set to enabled is actually also following a standard set in the SampleMoneyModule (plus the extra safety of our config). Here is the code from the SampleMoneyModule that is relevant. You will see that it assumes it is active if no value is present. Since the EconomyModule is not in OpenSim.ini.example, the default setting is not clearly defined.
if (config == "Startup" && startupConfig != null)
m_enabled = (startupConfig.GetString("economymodule", "BetaGridLikeMoneyModule") == "BetaGridLikeMoneyModule");
I'm happy to receive guidance for what we should do here, but the statement about how others handle this that claims that Gloebit is the violator is inaccurate. The DTL ignored this setting and partially activated regardless of the value. You can read about that here - https://medium.com/@colosi/a-lesson-in-why-you-should-always-log-code-paths-you-never-expect-to-hit-45e18d2b1fb2 [^]
The OMC module ignores this setting entirely. I haven't looked through jOpenSim. The SampleMoneyModule sets itself active if the value is not present (which is the convention we followed). Unlike all of the other modules, we provided the ability to disable us from our own config, and most of customers use this config value to turn us off on sims where we are not in use. We are also the first module to allow ourselves to be turned on and off by region on the same sim, and since the EconomyModule is a sim-wide setting, we actually need to ignore that variable in this case. It is actually using this functionality which allowed Discovery Grid to get around this conflict (between the DTL and Gloebit) until now.
Happy to have core's guidance. You can also read a bit more about specifically what happened on Discovery Grid on the 3rd comment here - https://plus.google.com/+ChristopherColosi/posts/7GYHbewHze8?fscid=z13qufc4jy21gvj1522axnr4axrjjbmwq04.1520213438990667 [^]
Wouldn't mind some service providers who have to do a lot of this configuration chiming in as well to provide their two cents.
edited on: 2018-03-05 10:02
Also, I just git blamed the SampleMoneyModule, and the EconomyModule lines date to well before 2015
Jeff Ames 2008-05-01 14:31:3
Gloebit is perhaps the only module that followed the standard included in core and which predates the DTL and other modules which violated this standard. I don't care which location Core decides is best moving forward, but I do take umbrage with being told we violated the standard when we indeed followed it.
"In grids with multiple currencies, the presence of multiple money plugins (dlls) in the bin tree is expected."
That's a fairly false assumption to make. Most grids will run separate binaries for different money modules. The reason for this is that OpenSim will load any and all dlls in the binary folder no matter if they are disabled or not. This can cause issues during startup and makes it ever more difficult to debug anything. Beyond that maintaining different drop-in dll versions of OpenSim is not rocket science.
While some clear direction and standards on implementation for money modules would be appreciated it is also not going to stop anyone from just doing it differently. Gloebit is the only module that actually seems to be written properly in that regard. Not to mention that the entire system is far more secure than the money modules built on the sample module. If you will, Gloebit is the first production-grade module as it does not directly allow just adding balance to accounts via a quick mysql query.
The "problem" you are describing here is a self-made issue with not properly maintaining separation of binaries.
Having all the dlls loaded into memory also upsets me, but that is how modules where created, and improving that now is now that easy.
This of course means diferent configuration.
We will need to change configuration so only enabled modules will have their dlls loaded/linked at run time.
As is, Enabled check is done by each module code, so yeach.. some bad design choices here.
In fact we do have several diferent and incoerent modules configuration setups now.
This will also allow for optional local AOT post compile at first run etc, if not full native compile, but im going 2 far on this now :)
This is understandable considering the code evolution path (there where plugins before modules, etc)
Deleting by hand the unnecessary module dlls, is a valid thing to do, to save some memory (swap space at least) and upload time in current situation.
About the configuration question, as you know we do not suport Money on core because of ... reasons.. ;)
But we do need to provide a API and same dummy funtions, so we do have a dummy module and it does read from a "Economy" and "Startup" sections.
Startup section should define what module is in use
economymodule = moduleName
other settings should came for a section specific to the module, and/or
[Economy] if they are identical to our dummy "BetaGridLikeMoneyModule"
i will make some of this visible on OpenSimDefaults.ini
note that as rule (we also violate) OpenSimDefaults.ini should be the more complete file, and opensim.ini.example only the most used options.
well this is my opinion at this point, considering how code is and other modules work ie physics, script etc.
guess having all the settings on a module specific ini section makes life easier for users that want to setup just that module
just be aware there is a hidden section named "economy"
i did change my mind since Economy section was there very visible..
So i made it the natural place for the economymodule setting
Our module is enabled by default because there must be one money module active.
i did change it to look for economymodule in Economy and also Startup sections.
I will follow suit and look in both the Startup and Economy sections with the next release of the GMM (which is what I was planning).
To be clear, what section should I instruct users to place this setting in? It's fine to look in two places, but what is the standard you would like moving forward?
I see from this commit that the standard is now officially in the Economy section and a default is defined. Thanks.
also checking Startup mb still good, as our module now does, just in case...
I want to point out the various reasons given for/against can be separated into two broad categories: architecture and implementation optimizations. With feature conditioned plugins/dlls, there should be no difference if none, some or many unselected dlls are present or not. The architecture defines a consistent behavior whether or not the actual dlls are present or absent, when the parameters enabling those features either are absent or do not select them.
What this permits is wide latitude in packaging a system based on the various constraint dimensions such as memory footprint, flexible one-time install, etc. Yes, I understand that ripping out every dll not used in a deeply memory limited system (one example: Raspberry PI) makes sense, but not so much in a 128GB server or in one where they might be different sets of manual vs automatic management.
Whatever choices are made in the physical implementation, having present in a configuration, unselected conditional dlls must not change the external system behavior. This is why I pointed out that in this case the money module plugin dlls need to treat the absence of a selection parameter as do-not-enable. Here too there are implementation alternatives - it could just disable itself, ignore the API calls to it, or it could unload itself (if feasible). In any case the architectural behavior is paramount.
And too, the architecture should be consistent where the selection parameter is located. It should not be in two places.
This kind of architecture that permits a wide latitude of implementation and optimization possibilites is found throughout many operating systems, large applications, and even opensim itself.
When i spoke about (carefull) deleting unnecessary dlls files is a valid option, i did meant on the target machine, for example the PI.
For example Bullet and ubOde engine files, you only need one of those on a prodution machine.
Even considering big part of them do not trigger JIT, some virtual memory (ie swap + physical) and load time can be saved.
The distributions will include all, of course.
Hopefully one day we will have a configuration that does only load dlls on demand not needing to load them to check Enabled.
missed the question about when the setting economymodule is missing
- economymodule must be set to disable our module (BetaGridLikeMoneyModule)
(this was not a recent change, was like this before)
In current 0.9 release version (and older), economymodule must be set on Startup
In master (and httptests) and future it should be in Economy section
To avoid issues money modules should check both sections for now.
Please make a currency in OpenSim.
I do not always want to pay for play money.
We do not need EUR or USD, we want play money for trading simulations or the like.
OpenSimulator currency is OS$ basicly to make viewers happy
all operations should cost 0, All OpenSimulator economy is just the bare minimum to allow other parts of the code to work, and provide a API for optional money modules provided by other parts.
Those Money modules define their own currency and more complex economy.
The use of a internal simulation currency and eventual correlation to real money, is responsability the grids/standalones owners or whoever has the legal responsability for that, acording to the legal contracts established for that purpose.
OpenSimulator has no responsability on that or any loses that may happen by using OpenSimulator code.
|If you want play money, setup the DTL money server and just don't tie it to paypal .. Instant play money , used it for a long time on our roleplay sims ..|
DTL does not work this is a separate server that does not run on Windows.
All optional money modules have a difficult installation.
But money has to work standalone (offline/online) and on regions in any grid.
All modules that work well cost real money and I do not mean Paypal modules.
Everyone wants margin for sales in US dollars.
I'm just testing opensim.currency DTL/NFL again
Now I'm still having trouble with mysql_ to mysqli_
Test looks good but difficult for beginners.
|2018-03-05 02:25||Balpien||New Issue|
|2018-03-05 09:45||colosi||Note Added: 0032564|
|2018-03-05 10:00||colosi||Note Added: 0032565|
|2018-03-05 10:02||colosi||Note Edited: 0032565||View Revisions|
|2018-03-05 10:20||tampa||Note Added: 0032566|
|2018-03-05 10:34||UbitUmarov||Note Added: 0032567|
|2018-03-05 10:39||UbitUmarov||Note Added: 0032568|
|2018-03-05 12:54||UbitUmarov||Note Added: 0032569|
|2018-03-05 13:06||colosi||Note Added: 0032570|
|2018-03-05 13:09||colosi||Note Added: 0032571|
|2018-03-05 13:12||UbitUmarov||Note Added: 0032572|
|2018-03-05 13:48||Balpien||Note Added: 0032573|
|2018-03-05 14:02||UbitUmarov||Note Added: 0032574|
|2018-03-05 14:22||UbitUmarov||Note Added: 0032575|
|2018-03-09 10:31||Manni||Note Added: 0032579|
|2018-03-09 10:57||UbitUmarov||Note Added: 0032580|
|2018-03-09 11:48||BillBlight||Note Added: 0032581|
|2018-03-11 14:59||Manni||Note Added: 0032588|
|Copyright © 2000 - 2012 MantisBT Group|