Page MenuHomePhabricator

End self-service new Trusty instance creation in Cloud VPS; standardize on Debian base images
Closed, ResolvedPublic

Description

We just closed the books on Precise and Trusty has a nice long 24 month life. I'm not saying atm we push for Trusty to go out the door for any existing function, but I would like to lay out our reasoning for continuing to allow new instances to be created.

Why I think we should consider standardizing on Jessie only (for new instances):

  • We can still create Trusty instances adhoc if we have to for users and I'm not yet convinced this is a need that outpaces the benefit
  • Every Trusty instance created is essentially tech debt
  • All trusty puppet code is legacy soon in prod and it would costs to maintain
  • Aside from a reason to get rid of it, do we have a reason to keep it?

Event Timeline

As soon as we disable Trusty we'll also be violating 'cattle, not pets' for most of our users. It will mean that anytime they need to recreate an instance they will also have to learn how to configure a new OS and adapt their work to run there.

We can't even create an SGE node on Jessie yet, so this kind of move seems highly premature.

As soon as we disable Trusty we'll also be violating 'cattle, not pets' for most of our users. It will mean that anytime they need to recreate an instance they will also have to learn how to configure a new OS and adapt their work to run there.

We can't even create an SGE node on Jessie yet, so this kind of move seems highly premature.

SGE on jessie I think is enough of an up-in-the-air consideration it's not worth including in the dialogue. SGE is an anomaly that no one else runs and we would still be able to spin up instances even if we took it out of horizon.

On the cattle vs pets thing, yeah it's the biggest sticking point. The counter point I think is we /have/ to do this. It's really just a matter of when. The longer we wait potentially the more difficult it will be for everyone involved, and especially the lower engagement users. It's not a matter of if but when. What's a good way to get some stats on creation flavor count in the last 6m? Do we have an idea if people are choosing Trusty out of a need for Trusty or if it's a quick click?

It should be possible to gather lifespan stats for existing instances and see what people are creating these days. Also, there are some half-measures that we definitely can take immediately:

  • Inform the users that they're better off not using Trusty (via email of via an in-gui warning or label)
  • Or, more draconian, disable public access to the image but keep maintaining it and add an additional 'you must ask an Op to make one of these' stumbling block

fwiw's the second is what I intended, a better title here would be Investigate ceasing self-service new Trusty instance creation in Labs. That's on me, I thought that was clearer.

chasemp renamed this task from Investigate ceasing new Trusty instance creation in Labs to Investigate ceasing self-service new Trusty instance creation in Labs.Apr 25 2017, 2:43 PM

fwiw's the second is what I intended, a better title here would be Investigate ceasing self-service new Trusty instance creation in Labs. That's on me, I thought that was clearer.

retitled

Another thing I'd suggest is that we get Stretch available to users before we start pushing them off Trusty. Jessie isn't in support for much longer than Trusty so we should jump ahead rather than migrating our users over and over.

bd808 renamed this task from Investigate ceasing self-service new Trusty instance creation in Labs to End self-service new Trusty instance creation in Cloud VPS; standardize on Debian base images.Oct 3 2017, 4:36 PM

Retitled the task yet again. The Foundation production networks are getting close to the long term goal of replacing all Ubuntu Trusty images. The long tail is largely related to the Cloud-VPS backend infrastructure (OpenStack components, etc). Beyond the hosts that the cloud-services-team controls, we have many Cloud-VPS tenants who are using Trusty images. These will all need to be replaced or deleted before SRE can completely drop Trusty support from Puppet. That removal is not eminent, but we know from our experience in the Precise deprecation process that this will take time.

I made our standard Trusty image 'private' by default, and announced here: https://lists.wikimedia.org/pipermail/cloud-announce/2017-November/000010.html

bd808 added a subscriber: bd808.