Glastonbury: a new system image, with Python 3.9 and Ubuntu 20.04
If you signed up for an account on PythonAnywhere after 21 June 2021, you’ll have Python 3.9 available – you can use it just like any other Python version. Additionally, the underlying operating system for your account will be Ubuntu 20.04, rather than the 16.04 used by older accounts.
If you signed up before that date, you’ll be on an older “system image” – essentially the version of the operating system and the set of installed packages that you have access to. You can switch to the new system image from the “Account” page, but you may need to make changes to your code and/or virtualenvs to make everything work – there’s more information on the linked page.
This post has more details on what’s new in the glastonbury system image. There’s a lot!
June system update brings easier task management
The most recent system upgrade brings a new way to organize
A new optional description field, combined with sorting, allows you to manage
big herds of multiple tasks.
Under the hood there were some more, larger changes, but we’ll be announcing the
details of those later.
System updates on 10 February and 11 March
It’s been a year since PythonAnywhere went all-remote,
but it has not slowed us down, and today was the time to deploy an
exciting set of changes to our system.
PythonAnywhere is a UK-based company, and the transition period for the UK’s exit from the European
Union on will end on 31 December 2020. This will not have any visible effect for people who use our free
service. For our paying customers outside the EU, including in the UK, there will also
be no changes.
For paying customers inside the EU, the only effect should be that you’ll receive two billing reminders
for January, a “pro-forma” one that will come at the usual time, just before
your monthly payment is made, and another one later on in the month, which will
be the formal “VAT invoice” required by EU tax law.
of course, only be charged once; the second billing reminder will just provide
some extra tax information. The remainder of this post is the details of why those two billing reminders
will be sent, and we’re posting it here for those who like reading about tax
A Tale of Two Deployments
It was the best of times, it was the worst of times, it was the age of remote work, it was the age of pyjamas, it was the epoch of bread baking, it was the epoch of pineapple pizza, it was the season of Light, it was the season of Darkness…
This is a short but exciting story about two system updates. Spoiler alert: no one has been guillotined.
How to use Ansible to update your Django web app
Now, as you have overcome or evaded the reefs, shoals and swirls of initial development and deployment and your appetite
grows, you ask “How do I automate the update and restart of my web app when I change the code?” There is already
one simple and elegant method on our blog, that uses one of the possible
push to publish methods, but this time we will dip our toes into vast waters of Ansible automation.
Introduction to scheduled tasks helper scripts
For all PythonAnywhere users who like to automate their workflow using scripts there’s already the pythonanywhere package which provides an interface for some PythonAnywhere API features.
If you’re one of them, you might be interested in some recent additions for programmatic management of Scheduled Tasks.
Outage report 7 July 2020
We had an unplanned outage the day before yesterday; it was our first big one since July 2017. It was caused by an extremely unlikely storage system failure, but despite that it should not have led to such a lengthy downtime, and should not have affected so many people. We have some plans on what our next steps should be, and will be implementing at least some of them over the coming months.
At 16:06 UTC on 7 July 2020, a storage volume failure on one of our storage servers caused a number of outages, starting with our own site and also with our users’ programs (including websites) that were dependent on that volume, and later spreading to other hosted sites. Because all of the data that we store on behalf of our users is backed up and mirrored, no data was lost or at risk, but the outage was significantly longer than we would like.
The effects were:
- Our own site was unavailable or generating an excessive number of errors from 16:06 to 18:53 UTC.
- For accounts that were stored on the affected file storage:
- Websites were unavailable in general from 16:06 to 19:46 UTC, with some taking until 21:24 UTC to be fully available.
- Scheduled tasks did not run between 16:06 and 18:53-19:46 UTC (the precise end time depending on the account)
- Always-on tasks did not run between 16:06 and 18:53-19:46 UTC (the precise end time depending on the account)
- For accounts that were not using the affected file storage
- Scheduled tasks, and always-on tasks were unaffected apart from a short window of about five minutes between 18:53 and 19:46 UTC.
- Websites were also unaffected apart from that window if they were already up and running when the problems started at 16:06 UTC. However, they could not be started up or reloaded between 16:06 and 18:53, and would have had a brief outage sometime between 18:53 and 19:46 UTC.
- However, of course, the problems on our own site would also have affected the owners of these accounts if they needed to log in to run or change things.
This post gives a more detailed timeline of what happened, and describes what steps we are taking to prevent a recurrence.
COVID-19 update: PythonAnywhere is now all-remote
Scary times. We hope everyone reading this is well and keeping safe!
We thought it would be a good idea to tell you how we’re managing the current
crisis at PythonAnywhere. We switched over to remote working last Thursday, 12 March;
there are obviously private and public health reasons why that was a good idea,
but there’s a reason specific to us, which we thought would be worth sharing.
How to use shared in-browser consoles to cooperate while working remotely.
One of the challenges of remote work is when you need to work together on one thing.
Our in-browser consoles are one of the core features of our service. Almost since the beginning, PythonAnywhere
has been able to share consoles – you entered the name of another user or an email
address, and they got an email telling them how to log in and view your Python
(or Bash, or IPython) console. If you use an email, the person you invite doesn’t have to be PythonAnywhere registered user.