Oz Linden

That is the plan, but we may yet have a few more weeks of irregular restarts. We regret the inconvenience.

and there is a weekly Open Development User Group in text (it's going on as I post this). Try stopping by some time.

No, it has not been ... I'm typing as fast as I can... If your avatar is working, you had a different problem.

There are many sorts of problems that can cause a bake fail; it's possible that you have a different one. The fix I'm working on now is for login, not the simulators, so simulator rolls won't fix them (the next agni login see on the status blog should be the fix being deployed, unless something worse happens in the mean time). For most inventory problems, we have an option that can be set by Support to fix them, and it will be applied the next time the account logs in (this avoids us having to worry about changing inventory while a user is logged in, or preventing logins while we are changing inventory). I'm extending that repair to include more of the ways that the Current Outfit can be messed up (including duplicates). We will try to automatically identify accounts that are in this most recent problematic state and queue up the fix for their next login.

this is not the Metachat related problem - that causes a complete bake fail

See

I'm testing the fix for this today; stay tuned. We understand what the problem is, but we are particularly cautious about testing code that makes changes to inventory, so please be patient. I suggest that you file a ticket with support for each account that has the problem (just reference "thanksgiving bakefail" since both internally and externally that's the name it's stuck with), and when the fix is deployed we will apply it to your account.

That's certainly our goal.

The main thrust of these rolls is to align the simulators with other uplift-related changes that are taking place "behind the scenes". There are a bare minimum of changes in the simulators themselves, and you should not expect any functional changes. It's possible (but not promised) that there may be some performance improvement for a few things.

Those efforts had pretty much stopped having Linden involvement by the time I joined the company in May of 2010 (which was also the time of that layoff - I was the last person to start before it happened). I discussed some aspects of it with my boss at the time (I'd worked on many standards efforts in the IETF and other orgs), and he told me that we had become convinced that standardizing on anything much like what we had then would not actually be in the interests of Virtual World technology evolution - put another way, we thought we should improve how things worked before standardizing. Having spent over 10 years now on making many of those improvements, he was right. Neither the layoff nor Second Life Enterprise had anything to do with it.

Geeky developer stuff alert ... if you don't understand it, ignore this post. The general case of the problem that Whirly asked about is really: Does the account for the bot have more than one folder that is type 46? The folder name does not matter - that type is the Current Outfit folder type (the name is actually not important). If you have more than one of those, the bake service will not generate a new appearance for you. I'm working on a fix that will enable Support to undo this problem safely; in the mean time, consider updating your bot driver software so that it does not ever create a Current Outfit folder. (I have no idea how this relates to your problem, @Michelle011997 ... off hand, I wouldn't know how to make that happen if I wanted to)

See https://jira.secondlife.com/browse/BUG-229735?focusedCommentId=640390&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-640390

It appears to be the case that these folders are created by version 1.2.9117 of the Metachat viewer (I don't know what action in that viewer causes this), and that the addition of that folder causes your appearance to be broken. Changing to another viewer does not correct the problem. Early next week we will attempt to undo the inventory changes responsible for the problem; in the mean time, if you are affected please file a support ticket.

For some usage patterns, using an Experience is good for this. Each object in the Experience can update its own address in the Key/Value store and that information is immediately available to all other objects in the Experience. We don't yet have a signalling mechanism to go with this, but doing a slow poll of the values is not expensive.

To be clear ... The change we made was to correct (or at least improve) the problem of teleports failing to complete in a timely way - it was not a viewer crash fix. According to our stats, it was successful - teleports are successful at approximately the same rate they were before the problem was introduced. My own experience has been that I encountered occasional teleport failures, but never crashed the viewer as a result (I have been running our viewer version 6.4.11.551711 - the current default)

There are definitely still things to do... the fact that we have effectively gotten all the simulators uplifted is a very major milestone, but isn't the end of the road quite yet. We'll be making more changes between now and the end of the year to uplift more of the web sites and backend systems. In the long run we're confident that this will mean improved performance and reliability, there may be some temporary glitches and it's possible that some services will need to be down for longer than we usually would allow (for example, the map tile generator is down at the moment).

Our best belief is that performance and stability will be significantly improved following this weeks rolls. For example, our monitors of teleport success rate have returned to normal.

The intent is that the simulator hostname should show as 'simhost-<id>.<grid>' as in your first image. The fact that it's updating that to the reverse-lookup name in amazon.com is the bug. LSL will return the full name 'simhost-<id>.<grid>.secondlife.io', and use names of that form for HTTP-in URLs.

This update has a couple of cloud configuration changes; these may improve some of the performance metrics, but otherwise should not be anything user visible.

The only way any failure is likely to be diagnosed and fixed is if it's reported in Jira. A report using the official viewer that includes the viewer log and is submitted promptly with the time and region where it occurred would be especially helpful.

We're looking into providing more time between when a restart is scheduled and when the region actually goes down (it will ordinarily be quicker if everyone leaves), and will make an effort to announce things as far in advance as we can. Once uplift is complete we expect to return to our traditional schedule (or perhaps something even friendlier, but that's another subject...)

As we've explained elsewhere, we are very much in the thick of uplift and things are moving unusually quickly. For the next few weeks, I'm afraid that we will usually not be able to provide as much advance warning of rolls as we'd like. We regret any inconvenience this causes, but it's all in service of getting you service that performs better.

What you did before was use the specific certificates installed on the individual simulator hosts; that works, but isn't very flexible. Since we changed the domain name in the cloud, those certificates would no longer match the hostname and would not be valid. Instead, we had to generate new certificates, but those new certificates are signed by the same Linden Lab Certificate Authority certificate that the datacenter hosts were. If you put that certificate in the set that your system trusts to sign host certificates, then you'll be able to validate any certificate it signs and trust it. The Linden Lab CA Certificate is at https://bitbucket.org/lindenlab/llca/raw/master/LindenLab.crt

I just downloaded both of the official zip files from the wiki successfully: Body and Clothing templates Avatar mesh What error did you get?

The uplifted regions do have a DNS name that isn't in amazon.com; they look like "simhost-0cfc9aaea518b73d2.agni.secondlife.io". Those names exist now: your viewer is using them internally, and if a script requests the simulator host name those names are what are returned. As @arabellajones said above, it's possible for an IP address to have more than one name, and our simulators do, so both the .amazon.com name you see now in your viewer and the .secondlife.io name that scripts get point to that same address. However, there isn't a way to query DNS with an IP address to get all the names that point to it - you can only get one answer, and the way we have things set up the answer you get now is the .amazon.com name. In our datacenter, we could just have one name so the address lookup got you the .secondlife.com name, so we never bothered to send the name explicitly to the viewer - it just did the address-to-name lookup to display in the About box. We've added explicitly sending the .secondlife.io name to the uplifted simulators, and we're modifying the viewer to use that name when it's available, so at some point the .amazon.com name (which will still exist) won't be displayed anywhere.