@MoritzMuehlenhoff : ganeti700[12] are ready for reimage but I've just run out of steam for today. If you don't get to their reimage on Wednesday I'll do so on my Wednesday AM.

Please note the workflow for racking tasks has changed this fiscal year, and we now require the puppet updates from the sub-team receiving the new servers. This is due to the majority of DC Ops not having root/merge puppet rights.

@Jclark-ctr or @VRiley-WMF if either of you can take a look at this ASAP and install some decom disks in here, it would asisst in Data-Platform-SRE's firefighting efforts on this service.

These shipped with (2) 400-AKJG : 200GB Solid State Drive SATA W rite Intensive 6Gbps 2.5in Hot -plug Drive, S3710 per host.

@wiki_willy: I just wanted to notify you of this task's resolution and you'll see the NRC disconnect fee, then no longer see this on our ulsfo invoice.

Please note the workflow for racking tasks has changed this fiscal year, and we now require the puppet updates from the sub-team receiving the new servers. This is due to the majority of DC Ops not having root/merge puppet rights.

"Created by: cbissell Cross connect has been disconnected, per our policy it will be removed after 48 hours"

I'd hand this over to either John or Valerie as ops-eqiad for them to remove any devices and cables.

I'll have the xconnect disconnected by remote hands during the cross-connect disconnection, putting in the cross connect d/c now for:

Please note the workflow for racking tasks has changed this fiscal year, and we now require the puppet updates from the sub-team receiving the new servers. This is due to the majority of DC Ops not having root/merge puppet rights.

Please note the workflow for racking tasks has changed this fiscal year, and we now require the puppet updates from the sub-team receiving the new servers. This is due to the majority of DC Ops not having root/merge puppet rights.

Please note the workflow for racking tasks has changed this fiscal year, and we now require the puppet updates from the sub-team receiving the new servers. This is due to the majority of DC Ops not having root/merge puppet rights.

Please note the workflow for racking tasks has changed this fiscal year, and we now require the puppet updates from the sub-team receiving the new servers. This is due to the majority of DC Ops not having root/merge puppet rights.

Please note the workflow for racking tasks has changed this fiscal year, and we now require the puppet updates from the sub-team receiving the new servers. This is due to the majority of DC Ops not having root/merge puppet rights.

Please note the workflow for racking tasks has changed this fiscal year, and we now require the puppet updates from the sub-team receiving the new servers. This is due to the majority of DC Ops not having root/merge puppet rights.

Please note the workflow for racking tasks has changed this fiscal year, and we now require the puppet updates from the sub-team receiving the new servers. This is due to the majority of DC Ops not having root/merge puppet rights.

Please note the workflow for racking tasks has changed this fiscal year, and we now require the puppet updates from the sub-team receiving the new servers. This is due to the majority of DC Ops not having root/merge puppet rights.

I think re-purposing these for rabbitmq is better than 'spares' which tend to age out and never get used. @wiki_willy: Would you agree with this?

Please note the workflow for racking tasks has changed this fiscal year, and we now require the puppet updates from the sub-team receiving the new servers. This is due to the majority of DC Ops not having root/merge puppet rights.

Please note the workflow for racking tasks has changed this fiscal year, and we now require the puppet updates from the sub-team receiving the new servers. This is due to the majority of DC Ops not having root/merge puppet rights.

Please note the workflow for racking tasks has changed this fiscal year, and we now require the puppet updates from the sub-team receiving the new servers. This is due to the majority of DC Ops not having root/merge puppet rights.

In T377568#10247706, @RobH wrote:

cloudcontrol2006-dev: increase memory in-place, or replace with another server with higher memory

This host was purchsed on 2023-07-24, and has quite a bit of support term remaining. Adding memory requires expendables budget and thus would need to have the WMCS manager and then Willy's approval as this is an unbudgeted request. Alternatively, this could be budgeted into next fiscal year. The host currently has 32B, would you want this increased to 64GB or 128GB? Once I know, I can get it quoted and we can determine if this can occur on this fiscal year (unbudgeted) or need to be pushed. We also may be able to snag from eqiad decom pile and ship to codfw, checking but need to know how much total memory is needed for this host?

There is only the 'test host' in codfw to replace with, no other standard configs. The test host is overkill, so it would likely be better to know your memory requirement before making a determination.

Answered inline, but 5 hosts all sat unused is a bit alarming to me, as each server all been using budget/power/space since purchase without being leveraged.

Neat toolforge tool, default values updated. Please note this will only update future requests.

Please note the workflow for racking tasks has changed this fiscal year, and we now require the puppet updates from the sub-team receiving the new servers. This is due to the majority of DC Ops not having root/merge puppet rights.

Please note the workflow for racking tasks has changed this fiscal year, and we now require the puppet updates from the sub-team receiving the new servers. This is due to the majority of DC Ops not having root/merge puppet rights.