Lab notes updates to SL simulator deployments

It has long been a tradition in Second Life that the main grid simulators and the regions they support are split between a number of channels:

  • The main channel, called Second Life Server, or SLS, which has the majority of simulators / regions running on it (roughly about 70%).
  • Three core release candidate (RC) channels, code-named BlueSteel, Magnum and LeTigre – each of which may account for roughly 10% of the simulators / regions.
  • Assorted smaller RC channels (such as Snack and Cake), that come and go according to needs – they may draw their simulators / regions from the SLS channel or the main RCs or a combination thereof.

This division is designed to allow a flexibility of approach to deploying updates, particularly those that may contain new features or have specialist updates such a new throttles or security changes, as these can be deployment to one or two of the RC channels first to test how they work under fully 2live” conditions (which the Lab, with the best will in the world cannot possibly fully test prior to deployment), and then removed with minimal grid disruption should anything untoward happen.

These RC deployments generally take place every Wednesday. If all goes well, and depending on how many different simulator updates are on the larger RCs, one will generally be “promoted” to the SLS channel the following Tuesday, having spent a week on one or more RCs. there are some variances in this, depending on what is going on (significant changes or new feature might be gradually deployed from one to two to all three RCs over a period of time, and then to the SLS channel, for example), but you should get the general idea from this, if you weren’t previously aware of how things work.

These (generally) weekly deployments are reflected in my Simulator User Group updates, where I list the deployments in terms of the SLS channel and the three core RC channels (the Lab doesn’t always acknowledge when a very small RC is being used).

However, on Monday, August 26th, Linden Lab announced upcoming changes to how simulator changes are going to be handled, and while the deployment methodology will remain the same (SLS channel deployments on Tuesdays, RC deployments on Wednesdays), there will be some differences, notably:

  • Starting with a deployment to one of the RC channels, the channel name will no longer be visible through the viewer (Help > About) nor will it be open to LEL query  – the channel name will simply be listed as “Second Life Server”, the same as the “main” channel. Over the next couple of weeks this will be true for all RC channels.
  • This means that when reporting simulator issues, just referencing the channel name will no longer be sufficient – users must use the simulator version number. This is displayed in Help > About, alongside the channel name:
Going forward from week =35, simulator issues should be reported using the simulator code version number, not the channel name (“SLS”, “BlueSteel”, etc.).

The reasons for making these changes are defined as being twofold:

  • To provide the Lab with better data on the performance and reliability of the server updates, and allow for better monitoring (presumably via the additional tools and internal changes the Lab has been making to the simulator code for the last few months).
  • To avoid spurious associations between the RC channels and capabilities. For example, the idea that one RC channel runs on better (or worse) hardware than another or the SLS channel; or that issues being experienced *must* be the result of an RC deployment, purely on the basis that that was either the last deployment made, or the user happened to be on an RC channel when they encountered an issue (regardless of whether the code may actually have caused the problem or not).

It is also noted in the official blog post that while simulator code version numbers will be the preferred means of reporting issues, channel names will continue to be recognised by Support for matters of testing:

Future improvements will make each RC channel a better model of the Grid as a whole. Support will continue to be able to accommodate Region owners’ requests that a Region be in the RC for a particular feature or fix they want as soon as possible, or that it be excluded from any RC.

It’s currently not clear if these changes will also impact the channel reporting capabilities in TPVs like Firestorm (which can pop-up the name of the simulator channel when moving from one to another) or not.

A final note in the official blog indicates that simulator release notes will be moving to the same system as is now used for viewer release notes. When this happens, I can only hope it is managed better than is currently the case for viewer release notes, where updates viewers may be references on the Release Notes page OR the Alternate Viewers page OR the Available Viewers Index on what seems to be the flip of a coin.

Please refer to the official blog post for full details of the changes.

4 thoughts on “Lab notes updates to SL simulator deployments

  1. Seems likely the region exposes the same version identification text to the viewer as it does to LSL scripts, which will now start omitting the release channel name. I doubt there’s anywhere else for a TPV to get that name.

    I do wonder how dynamic the channel assignments will be, week-to-week. If the sets are reasonably stable, one could deduce which regions are members of the same channel based on whether they get the same versions each week.

    Like

    1. Yeah, I don’t know enough about where the likes of Firestorm grab the channel name – I assumed it would be using the same mechanism as LSL, which is going away, as you and I note, and thus my assumption is the pop-up will be deprecated. I just didn;t like to commit to saying so until FS have had a chance to poke around 🙂 .

      Like

  2. The Lab doesn’t have linear straight thinkers. Like the Trulia mess. The current crowd in control may know their tech stuff but epic fail in how it works with the customers.

    For a business to respond to stuff like this:”This is simply to avoid spurious associations between the RC names (“BlueSteel”, “LeTigre”, “Magnum”, and occasionally other smaller ones); we hear interesting but incorrect assumptions that are made about those channel names, such as that one channel runs on better (or worse) hardware than another one does . ”

    You don’t redo your backroom to address rumors! The cost of that project should get removed from that person’s bonus.

    The next time servers are addressed in a forum , a mature business head could then slap down the theory of better servers in a side note and move on. Not blow programming money to please the chattering class.

    Someone got Peter Principled I think.

    Like

    1. I don’t think the reason for these changes is “just” because of the misapprehension among users concerning the RC channel hardware, etc; the “masking” of channel names is simply being done because of all the other work going on in terms of improved monitoring and feedback (and is relatively simple to do). It’s being highlighted here simply because it is one of the more visible by-products of the overall changes being made, and the Lab are trying to get ahead of the curve by explaining why and get ahead of the potential rumour that they must be doing it because they are trying to “hide” something, yadd, yadda.

      “he next time servers are addressed in a forum , a mature business head could then slap down the theory of better servers in a side note and move on. ”

      Actually, that happens a lot at places such as the weekly Simulator User Group, the fortnightly TPVD meetings, etc. Some raises the theory, it gets knocked down / refuted … and a week or two weeks later, up it pops again. The same happens on the forums with assorted rumours and misinformed theories – hence constantly dealing with the statements / beliefs can get to feel like a game of whack-a-mole.

      Which is not to say trying to get it out there that theories on the relative “value” of RC channels (other than when it comes to testing features) are misinformed in a manner like this will reduce the rumours / belief / speculation, but I actually don’t blame the Lab for trying. As notes, I’ve sat through meetings where such ideas of “X running on better hardware then Y” has popped up enough times over the weeks and months to cause a certain amount of mental eye-rolling when it gets brought up again.

      I’m more concerned about how RC release notes will be managed with the move to the web-based service. As noted in the article, this has been a source of frustration when trying to grab viewer release notes, simply because the Lab doesn’t appear to know which page to use when posting them (and why have three separate pages anyway? That’s utter overkill).

      Like

Comments are closed.