https://icinga.wikimedia.org/cgi-bin/icinga/status.cgi?search_string=frdb1003

I don't know why but the alert in Icinga has cleared since 14 days.

In T202356#5719443, @sbassett wrote:

IMO, the largest gains for this proposal would be seen from also incorporating a private front-end (likely another gerrit) so as to provide consistency...

@Volans Thanks for reporting! The SPF record has been updated now in DNS. This should go away now.

@20after4 per recent talks we had.. is it still our goal?

also see support from releng at T236309#5693892

In T236309#5678505, @Andrew wrote:

For the new project, please file a ticket here: https://phabricator.wikimedia.org/project/profile/2875/

We requested a new unified project to replace this and 2 other projects at once. gerrit, git and phabricator.

We requested a new unified project to replace this and 2 other projects at once. gerrit, git and phabricator.

We requested a new unified project to replace this and 2 other projects at once. gerrit, git and phabricator.

These are actually on stretch. But they have been upgraded in place, that's why they pop-up on the jessie list.

@Weshouman I am not sure if that's what this is about but i want to point out there are Phabricator dumps at https://dumps.wikimedia.org/other/misc/ nowadays and the last comment on this ticket was a couple years ago.

We switched from phab1003 to phab1001.

In T238956#5712739, @Mainframe98 wrote:

I suspect that this move inadvertently caused T239786: Viewing MediaWiki repository in diffusion results in an Unhandled Exception ("CommandException") as I only started seeing it today.

This has been fixed. Sorry for the inconvenience.

Following the "cookie licking on Phab" discussion i'm unassigning this from me because i am not going to work on it soon and T185319 says that Analytics took over stewardship for RC feeds.

Is this really replacing the IRCd from T134271 ?

If you want to change the memory_limit for just Parsoid servers again that is now:

This was assigned to me to (make it possible to) raise the memory limit. That has happened now.

In T228575#5714168, @Aklapper wrote:

In T228575#5714093, @Dzahn wrote:

Don't they have to be nagged to .. do the review.. though?

Yes, but the person to do the review is not the assignee (patch author).

Thank you very much @Papaul.

I'm unassigning from me for now because i'll be on a vacation and don't want this to be blocked on me for no reason. If anyone else can push this forward meanwhile one way or the other, please do. Otherwise i'll take it back later.

Just a thought.. If the 2 machines for contint are granted (T239880) first and are taken from available spare pool.. then possibly one of them could work as temp Gerrit test machine and then become contint?

I'd be the one to take these from "role::spare"-state to serving the puppet roles. We'll see what breaks on buster and whether we can go to buster or just stretch for now.

If you (security-team) want to go through WMF volunteer NDA process, please contact Rachel in Legal, she'll follow-up.

In T228575#5688336, @thiemowmde wrote:

One could argue that it's even less of a problem to unassign people from effectively stalled tasks if these people don't even pay attention. As I tried to argue above: What would be the harm?

Don't they have to be nagged to .. do the review.. though?

In T239151#5711346, @MoritzMuehlenhoff wrote:

The old puppetdb hosts (puppetdb1001) should be ready to go away, @jbond merged the patches to stop broadcasting to it last week. It also has 16G RAM, so those would be freed up when that's done.

In T239151#5711306, @hashar wrote:

The way I understand the message: the virtualization servers in group row_A lack free memory to allocate a VM. But maybe another group would have memory available?
You should be able to list the group and free memory with:

sudo gnt-node list -o name,group,mfree

You can try another group, else bring down memory ? :)

Unfortunately we have to switch back to the server before, change a BIOS setting in the current server, reimage it and then switch back a third and hopefully final time.

i see your user exists now for example on bast1002:

https://ticket.wikimedia.org (OTRS) has been switched to use https://ticket.discovery.wmnet (envoy on mendelevium).

@Dzahn: Can we switch it over to AHCI in the bios? Do we need DC-Ops for that?

This is happening today, starting in about 15 minutes.

Also: I noticed in Icinga there is no "mw2259.mgmt" (while for example mw2247.mgmt exists). It's simply not there:

@Papaul Could you take a look at this onsite?

Resolved?

Both patches are merged now. Git status of /srv/docroot is clean.

I didn't add myself to the users because I wasn't sure what my uid was

+@Nuria per T239300#5710194

This ticket seems to be a duplicate of T239654. Adding her there as well. Linking Gerrit change i amended to.

fwiw, somebody on mysql support channel told me about "explicit_defaults_for_timestamp" that "scope is system and session.You can set it per session".

explicit_defaults_for_timestamp = 1 will become the standard in future mysql versions.

@hashar It's fixed for me now. It was missing the releases-jenkins.wikimedia.org as a SAN on the TLS certificate.

Tried to create it but unfortunately:

https://noc.wikimedia.org has been switched to use https://mwmaint.discovery.wmnet (envoy on mwmaint1002).

Approved in SRE meeting.

In T239151#5698138, @thcipriani wrote:

Lowered the memory request as that seems to be out-of-line with the usage of most Ganeti VMs, hopefully 16G would work for a Ganeti VM?