Sharing Minkata's administration duties

[Emor D'ni Lap]

(originally posted 8/20 in another thread, somewhat off-topic there)
---------------------------------------------------------------------------------
As others have noted here, it's now been over eight years since Cyan open-sourced URU, expressing their interest in hosting Explorer-Created content, and almost five years since Chogon set up a Cyan clone server as a last internal test bed for this purpose (his "staging server", or whatever it was ultimately called). Minkata, having been officially designated as the external testing ground before passing content to Cyan, now has an additional preliminary stage, so it seems the pipeline for approval of Fan Content looks like this:

1. Minkata-Alpha server
|
2. Minkata server
|
3. Cyan Staging server
|
4. Main Cyan server

I'm absolutely in awe of the work and time that all shard admins have put in over the years. I'm a big fan of rarified and his work. However, I know that we're all volunteers in this effort, and Real Life takes precedence over all else (I was unable to contribute for the better part of eight years, and have just now been away entirely for about three months). I understand that Minkata is rarified's own server, and that he has set it up according to his own needs and preferences. But this pipeline shouldn't be solely dependent on the available resources of one individual, not regarding time or labor - or finances, for that matter! With all possible respect to rarified, this inability to share or delegate has created a deadly bottleneck.

I'm saying this while admitting I know next to nothing about the options for safely sharing server administration duties among several people...nor the potential hazards in doing so. Yet I know it has been done successfully.

Can we have a discussion about how Minkata's admin responsibilities might be shared, such that when some member of a small admin team is inevitably unavailable, others could pick up the slack?

[Hoikas]

Given that it has been 8 days with no response, I think it safe to say the answer to your question is "no." It seems that any time anyone wants to see some actual improvement to Uru, the response from the brain trust here is distract, stonewall, and silence. Or, as our old friend veralun used to put it as he (ab)used his power, "this is a forum and not a place for a dialogue."

[Doobes]

It *does* seem a rather daunting task to dump onto what seems like just one person (rarified) who has RL responsibilities like the rest of us.

Due to the fact that it HAS been so many years since open source has happened and other shards have made so many leaps and bounds, perhaps it would be the best time to re-examine how the pipeline is working...and, more importantly, how it's not.

Also, no offense, but one thing that's been bugging me regarding this Minkata-alpha shard...isn't it kind of redundant? I mean, Minkata itself is supposed to be an alpha shard for MOULa, isn't it? The one we're supposed to be bug-testing, breaking, fixing, etc? Why have yet another shard for pre-pre-pre-testing?

[Christian Walther]

Also, no offense, but one thing that's been bugging me regarding this Minkata-alpha shard...isn't it kind of redundant? I mean, Minkata itself is supposed to be an alpha shard for MOULa, isn't it? The one we're supposed to be bug-testing, breaking, fixing, etc? Why have yet another shard for pre-pre-pre-testing?

These were my thoughts as well, but as long as it’s rarified who is putting in the work and not me, I’m not complaining, it’s up to him to run things the way he prefers. I am grateful anyone is doing it at all at a time when I have somewhat drifted away, with other interests taking up my time.

[rarified]

The reason for the Minkata-alpha shard has to do with the increased capabilities that new ages will taint the vault.

This way the Alpha shard can be cleaned (reset to Minkata) without impacting in a major way Minkata. It also makes it easier to do age iterations.

While I do have backups for Minkata, restoring them on the event of age errors or updates is significantly more work than cloning Minkata.

_R

[rarified]

In the spirit of seeking help with Minkata management, I could use an advanced PostgreSQL management expert to help with the problems between Minkata and Minkata-alpha.

It has to do with overlaying schema between two databases so that some but not all tables are shared between schema search paths.

Candidates?

_R

[Hoikas]

This way the Alpha shard can be cleaned (reset to Minkata) without impacting in a major way Minkata.

Please forgive me if I'm off the mark, but I'm not following how this is beneficial. My understanding is that Minkata is a testing shard. Now, there are lots of ways we can define "testing shard," but let's dispose of most of them. Minkata is, from what has been demonstrated so far, the place where changes are given their final integration testing. Not the primary testing. That should happen elsewhere to allow rapid iteration. By that time, the "vault-busting" bugs "should" be cleared out. In other words, I think of Minkata in terms of MOUL Rehearsal--that was a long time ago, but I don't think it ever required a database reset *during* testing. Further, if the shard does get so hopelessly hosed that a reset is needed, then it should just be reset. It is a testing shard, after all.

Additionally, I think most people are overestimating the potential for server database corruption and underestimating the resiliency of the game itself. I think a lot of that may stem from the Until Uru days when people would bring hacks onto public shards and accidentally trash them. This was back when the engine was not as well understood in general, anyone could easily bring any untested crap online, and with a fairly fragile server software. In reality, most (if not all) fan ages themselves and the fan written code in them does not interact with the vault database at all. If they do, it's standard client components (eg xAgeSDLBoolShowHide.py) that the age author has added. So the chance of corruption is the same as any other Cyan age, like Teledahn. Even if something bad does happen, it is difficult to do anything outside of the current age and current player vault in python code, so the damage would be minimized and could be isolated by deleting the age or player.

Further, it seems that by having this "mirroring" between Minkata prime and Minkata alpha introduces a whole new set of variables to the equation that may introduce more problems. We previously saw issues related to game states being copied over. I would much rather be testing the actual content itself, rather than the content plus some special case that doesn't actually matter outside the test environment. Therefore, I say it is better, IMO, to test on the Minkata prime server. If a problem arises, Minkata is already declared a test server, so there should be no hard feelings about blowing it away.

[Doobes]

...it’s up to him to run things the way he prefers.

Were it rarified's own private shard, I would wholeheartedly agree. However, since Minkata is supposed to be the preferred testing ground for MOULa itself, it really shouldn't be run by just one person. While I respect what rarified does and continues to do, it's too much and too important for any one person to shoulder.

One of the big reasons that the other shards have blasted so far ahead of Minkata (aside from less restrictions from Cyan) is because of community cooperation. While OU has talked this up in the past, I have just not seen it here. Ideas are presented for consideration and are met with "we'll get back to you on that"...then mostly nothing. This is likely why the shard has been pretty much stagnant, along with MOULa, for several years now. Real life can be to blame...understandably so...which is why having others with a hand on the wheel would be so much more beneficial. One person has to step away, another (or more) can pick up the slack. I believe that's how open source is supposed to work, but I could be crazy.

I realize there may be some "bad blood" between people, but we're all adults here and passionate fans of the game. It's time to put all that crap aside and truly get to work on this. No more bureaucracy, no more solo efforts, no more "We'll get back to you"s. Let's truly open things up here and get some new blood into URU.

[Christian Walther]

…, it really shouldn't be run by just one person.

I agree that it shouldn’t, but as long as nobody else steps up to help – more determinedly than I once did – that’s the way it is.

I guess the detail where we disagree is that in my view the initiative has to come from the contributor:

Ideas are presented for consideration …

Ideas are cheap, execution is what counts. There are things that can be done without requiring involvement by rarified, such as making sure we have a client that is compatible with both MOULa and Korman. But my impression – from back in the day, maybe things have changed – is that most of the people who are technically and availability-wise capable of it are not very interested in contributing to MOULa, due to mentioned restrictions from Cyan or whatever other reasons.

[Hoikas]

Ideas are cheap, execution is what counts.

This forum has historically had plenty of the former and not enough of the latter. Further, excuses are also cheap. I would argue the reason for this is the historical stonewalling, not disinterest. If you navigate away from this forum the amount of the latter you find increases exponentially. Hmmm... In fact, there has been so little of the latter here that the main game has fallen so far behind it would be amusing if not for the palpable confusion and failure to understand found here.

I could use an advanced PostgreSQL management expert

Forgot to answer this previously... I only know enough Postgres to get by when I absolutely must. I reiterate my recommendation of rethinking the approach, especially if it is causing a roadblock.