Page MenuHomePhabricator

Nodepool can not delete/spawn instances anymore
Closed, ResolvedPublic


$ nodepool list

IDProviderLabelHostnameServer IDIPStateAge (hours)
2016-07-04 09:39:05,653 ERROR nodepool.NodeDeleter: Exception deleting node 168252:
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/nodepool/", line 297, in run
    self.nodepool._deleteNode(session, node)
  File "/usr/lib/python2.7/dist-packages/nodepool/", line 2159, in _deleteNode
  File "/usr/lib/python2.7/dist-packages/nodepool/", line 450, in waitForServerDeletion
  File "/usr/lib/python2.7/dist-packages/nodepool/", line 42, in iterate_timeout
    raise Exception("Timeout waiting for %s" % purpose)
Exception: Timeout waiting for server 6e0084f5-61a6-42f6-973c-d2f503792f66 deletion in wmflabs-eqiad

Looks similar to T135631: Nodepool can not spawn instances anymore on wmflabs


Related Gerrit Patches:
operations/puppet : productionRevert "nodepool: lower # of instances"
operations/puppet : productionnodepool: lower # of instances

Event Timeline

hashar created this task.Jul 4 2016, 9:43 AM
Restricted Application added subscribers: Zppix, Aklapper. · View Herald TranscriptJul 4 2016, 9:43 AM

Mentioned in SAL [2016-07-04T09:44:05Z] <hashar> Labs infra cant delete instances anymore (impacts CI as well) T139285

Paladox added a subscriber: Paladox.Jul 4 2016, 9:44 AM

I think this may be related to T137857

hashar added a comment.Jul 4 2016, 9:57 AM

Once labs is able to delete instances again, Nodepool would be able to delete them and thus spawn new ones. At worth we will have to manually delete the instance in the contintcloud project.

Status can be monitored on labnodepool1001.eqiad.wmnet with: nodepool list.

yuvipanda added a subscriber: yuvipanda.EditedJul 4 2016, 10:49 AM

I've shut down nodepool just now since it was still trying to create and delete instances. We're *very* resource constrainted in labs atm, so my first priority would be to restore labs to a working condition (T139264 etc are happening atm - random instances are shutting off, and if that reaches tools that'll cause a lot of issues) before re-evaluating turning on nodepool.

Just ran:

nova list --all-tenants | grep -i error | grep contintcloud | awk '{ print $2; }' | xargs -L1 nova delete

To delete all the contintcloud instances in ERROR state

A combination of restarting rabbitmq + moving more instances to labvirt1011 + deleting unused instances seems to have fixed this. Still, I'll advice not creating lots of new instances just now, because we're still on a resource crunch...

Paladox triaged this task as Unbreak Now! priority.Jul 4 2016, 12:25 PM
Restricted Application added subscribers: Luke081515, TerraCodes, Urbanecm. · View Herald TranscriptJul 4 2016, 12:25 PM

Mentioned in SAL [2016-07-04T12:33:21Z] <yuvipanda> reduced instances quota to 10 before starting it back up for T139285

Change 297256 had a related patch set uploaded (by Hashar):
nodepool: lower # of instances

Change 297256 merged by Yuvipanda:
nodepool: lower # of instances

Mentioned in SAL [2016-07-04T12:43:15Z] <hashar> Nodepool back up with 10 instances (instead of 20) to accomodate for labs capacity T139285

hashar closed this task as Resolved.Jul 4 2016, 12:44 PM
hashar assigned this task to yuvipanda.

It is degraded from 20 to 10 instances until labs has the capacity for more instances. That is not ideal but at least the service is backup and the queue of pending jobs is draining properly.

Thanks to @yuvipanda for the quick sync up ;)

Change 297512 had a related patch set uploaded (by Hashar):
Revert "nodepool: lower # of instances"

Paladox reopened this task as Open.Jul 5 2016, 8:56 PM

Re opening due to ci having problems again.

Change 297512 abandoned by Hashar:
Revert "nodepool: lower # of instances"

Andrew and/or Chase confirmed yesterday that it is going to hurt labs right now. No point in keeping this change open for now.

hashar closed this task as Resolved.Jul 6 2016, 9:00 AM

It is solved. What @Paladox noticed yesterday was the pool of instances being exhausted and the CI change being stuck in queue pending for instances to boot / be made available.

The root cause is that we are down to a maximum of 10 instances. See T139285 and b1d015b50ed404497a1f1c3b7ea67606a0d8181f

Restricted Application added a subscriber: Jay8g. · View Herald TranscriptJun 7 2017, 6:41 PM