User Details
- User Since
- Sep 30 2014, 4:39 PM (335 w, 2 d)
- Roles
- Administrator
- Availability
- Available
- IRC Nick
- mutante
- LDAP User
- Dzahn
- MediaWiki User
- Unknown
Wed, Mar 3
Please note gitlab1001/gitlab1002 with private IPs have been deleted and instead gitlab1001.wikimedia.org with public IP has been created, based on T274459#6877185 ff. The same puppet role is applied to shell access moved with that.
@wkandek @thcipriani A new VM gitlab1001.wikimedia.org in the public network has been created while gitlab1001.eqiad.wmnet has been deleted. Still using the same puppet role name so shell access is moving automatically with it.
dzahn@cumin1001:~$ sudo cookbook sre.ganeti.makevm eqiad_A --vcpus 8 --memory 12 --disk 100 --network public gitlab1001.wikimedia.org Ready to create Ganeti VM gitlab1001.wikimedia.org in the ganeti01.svc.eqiad.wmnet cluster on row A with 8 vCPUs, 12GB of RAM, 100GB of disk in the public network. >>> Is this correct? Type "go" to proceed or "abort" to interrupt the execution > go START - Cookbook sre.ganeti.makevm for new host gitlab1001.wikimedia.org Allocated IPv4 208.80.154.6/26 Set DNS name of IP 208.80.154.6/26 to gitlab1001.wikimedia.org Allocated IPv6 2620:0:861:1:208:80:154:6/64 with DNS name gitlab1001.wikimedia.org Generating the DNS records from Netbox data. It will take a couple of minutes.
This host is shut down (by the decom script) and gone from puppet repo.
Tue, Mar 2
Now this is either resolved (if we go unencrypted behind caching) or we can do the same thing for 443 but then we also need envoy and certs. It's possible but not sure if needed.
I merged and deployed 667733.
Mon, Mar 1
This is partially blocked on T276170 .
An issue here is that ATS normally speaks only https to backends. But this opens a bunch of questions that involve traffic.
Which of the 2 VMs should get the traffic for http/https? Assuming gitlab1001 is fine and gitlab1002 isn't a webserver.
17:05 < mutante> !log new Wikimedia project language - tay - Atayal is spoken by the Atayal people of Taiwan
Sat, Feb 27
switching eqiad scheduled for Monday, March 1st:
Not very high prio now that I manually deleted old stuff, but still should be fixed for the future to not build up again.
there is a "scap-sync-master" command which can be run manually on new deployment servers, it takes care of /srv/mediawiki-staging and /srv/patches.
Fri, Feb 26
T274170 introduced new hardware mwmaint2002 and can be used now. timing :p
Thu, Feb 25
This came up in the context of creating new deployment servers on buster (deploy1002, deploy2002) and wanting to keep all the /srv/ data in sync before switching over.
The /usr/local/bin/scap-master-sync command syncs /srv/mediawiki-staging and /srv/patches _from_ another deployment server.
Wed, Feb 24
I removed that setting from the testreduce1001 envoy, just to make sure.
Tue, Feb 23
I am closing this as resolved simply because the group exists now and is applied on the VMs requested in T274459.
The group has been created. Depending how you want to define this ticket, it is resolved now.
gitlab1001.eqiad.wmnet has address 10.64.0.93
gitlab1001.eqiad.wmnet has IPv6 address 2620:0:861:101:10:64:0:93
VMs have been created, with 8 VCPUs, 12 GB RAM, 100 GB disk as requested. both in eqiad. gitlab1001,gitlab1002.
ok, great :) then it's more like the opposite.. should the disk have been wiped and otherwise done:)
ACK, the first VM has been created in eqiad and next is doing the OS install, in progress.
Since we heard they started yesterday already, the access process can be sped up by asking the new users to sign up on Wikitech and create user profiles. After that they can sign in on Phabricator using those to see this ticket, create SSH keys and paste them.
Ready to create Ganeti VM gitlab1001.eqiad.wmnet in the ganeti01.svc.eqiad.wmnet cluster on row A with 8 vCPUs, 12GB of RAM, 100GB of disk in the private network.
Just to make sure, this is a request for 2 VMs, but BOTH in eqiad, so a 1001,1002 situation, NOT a 1001,2001 setup, where one is in eqiad and one is in codfw., right? And you are accepting that there won't be anything in codfw to fail-over to?
This should be part of T268524 ideally.
I am a bit concerned now that your new ticket mentions transferring data. this is already removed from rack.
Mon, Feb 22
MariaDB [wikistats]> insert into wikipedias (prefix,lang,loclang,method) values ('alt', 'Altai', 'алтай тил', 8);I was about to ask why this was missing in "Newprojects".
MariaDB [wikistats]> insert into wiktionaries (prefix,lang,loclang,method) values ('mni', 'Meitei', 'ꯃꯤꯇꯩꯂꯣꯟ', 8);