In T342291#9207501, @BTullis wrote:

@RobH I'm sorry to have to be a pain, but is there any chance that we can increase the RAM in these two servers, before they come into service?

I know I should have worked on any change of specs in T341264, but we didn't know at the time how our HDFS files usage was going to grow so rapidly. In fact, the Data-Engineering team have been working on bringing the number of files on HDFS down significantly. Unfortunaltey, it hasn't work out yet so now we're facing an increase in stability issues with the HDFS namenode services.

These two servers new servers (an-master100[3-4]) have got the same 128 GB of RAM as the servers they're replacing, but if these is any way we could increase it to, say 256 GB each, that would really help us out.
If it's not feasible, let us know and we will see if there are any alternative approaches. Thanks.

OS imaged, system ready for service owners.

Found error in partitioning, discussing with John.

In T342674#9198699, @MatthewVernon wrote:

@Jhancock.wm I think (from netbox) that moss-be2003 is a PowerEdge R740xd2 - ConfigJ 202107 system. We have a number of these nodes which are set up as JBOD in use in the ms-cluster - ms-be107[2-5]. There's also ms-be20[70-73], though those are PowerEdge R740xd2 systems (I'm not clear on the distinction). So I'd hope it was possible to make moss-be2003 do JBOD?

In T342674#9199689, @Jhancock.wm wrote:

I was trying to make it work and I consulted with @RobH. He said it wasn't going to work on this machine because of limitations of the hardware.

IRC update: Chatted with Moritz in IRC and we're no where near supporting UEFI mode anytime in near to mid term. We should likely return these.

So this system only supported UEFI mode, which we've not supported installing within WMF.

I was just pinged about this via irc by @Dwisehaupt, so to get an SSL certificate for this there are a few items to address:

Email sent, cc'd @aborrero so they can stay apprised of progress. If this follows the same cadence, our MM rep will work on this within 24 hours.

Update,

It turns out the other nameserver was migrated previously with no IP update either, so its currently incorrect on the MarkMonitor/registar side due to our lack of update to you.
ns0.openstack.eqiad1.wikimediacloud.org to 208.80.154.148
ns1.openstack.eqiad1.wikimediacloud.org to 185.15.56.163

Please let us know when you receive this request as it now turns out this domain is offline until we update this and it propagates out, thank you!

Naoya,

We're juggling around some nameservers in our cloud environment over here, and need to update one of them:

ns1.openstack.eqiad1.wikimediacloud.org to 185.15.56.163

Please let me know what authorizations are needed to make this happen and implement as soon as you can. Our sub-team over here already re-allocated that IP to the nameserver without realizing we had to let you know to update on your end.

Thanks!

In T346177#9161332, @cmooney wrote:

@RobH if we can ask the registrar to change the IP they have for ns1.openstack.eqiad1.wikimediacloud.org to 185.15.56.163 I think it should solve it.

In T342159#9067390, @ssingh wrote:

In T342159#9025176, @RobH wrote:

Please note parent task 341588 has the range of cp1[090-105] however, cp1090 is already live/in use. Additionally, we have 4 cp hosts from eqsin to use for CP in eqiad (so cp109[1-4], and another 4 coming from ulsfo cp109[5-8).

Also no racking info has been provided for these. Should they be distributed in any particular way for traffics needs/redundancy?

Assigning to @ssingh for followup on racking details and to clarify hostnames (and ensure the 8 old CP hosts from ulsfo/eqsin are still expected to be used.)

Hi @RobH,

Trying to get some context here and it's possible I am forgetting something: which old hosts are these? Also, the newer configuration in eqiad has dual NVMe disks for both text and upload whereas eqsin/ulsfo have just for upload, so if we are using some servers from there, we should keep that in mind.

wikibooks.org
wikidata.org
wikimedia.org
wikimediafoundation.org
wikinews.org
wikipedia.org
wikiquote.org
wikisource.org
wikiversity.org
wikivoyage.org
wiktionary.org
wmfusercontent.org
mediawiki.org
wikifunctions.org

In T336623#8856284, @wiki_willy wrote:

Agreed, I don't think there's any need to continue using "platform" in Netbox, especially since more than half the devices don't have it currently filled out. @Papaul, @RobH, @Jclark-ctr, @Jhancock.wm - feel free to chime in if you have any other thoughts.

Thanks,
Willy

In T336623#8855237, @Volans wrote:

@wiki_willy what's DCOps's position on this? Those are the current platform used: https://netbox.wikimedia.org/dcim/platforms/

I think we perhaps have to find a compromise on the single versus multi line.

In T343254#9067280, @Jhancock.wm wrote:

@RobH Yes, let's order the fan. Thank you!

In T343254#9063837, @Papaul wrote:

@RobH you right it is not the fan that has the issue it is the board i will have @Jhancock.wm check if it is the daughter board or if it is the mainboard the fan is plugged in tomorrow when she is on site since i am still doing some firmware upgrade on the server.

Thaks

@Papaul: Before I order a new fan, I want to confirm that it is indeed the fan and not the fan slot?