877922 - please set up additional seamicro to support git conversion

Status: RESOLVED FIXED

(Developer Services :: General, task)

Description

[hwine]

+++ This bug was initially created as a clone of Bug #802702 +++

Set up an additional seamicro to support b2g mozilla-central w/ cvs history work with vcs2vcs app.

Box & netflows should be configured identical to
  github-sync2.dmz.scl3.mozilla.com

with the following exceptions:
 - skip the nfs mount - we're not using that
 - tweak the inode count up slightly when formatting the drive
   * I _think_ we used 4x normal inode count - a bit higher would be nice - we've hit >95% inode used with < 80% disk used (so we're close)

Any setup questions should be directed to :aki - he'll be primary user of the box.

Comment 1

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

(not sure if this is correct component after all the recent bug cleanup work.)

fox2mike/cshields - 1) I believe we have extra seamicro machines already racked and powered, can you confirm? 2) Do you know who can help move this bug forward?

Comment 2

[Shyam Mani [:fox2mike]]

302 jakem.

Comment 3

[Shyam Mani [:fox2mike]]

John,

For some more context :

1) We might have some spare seamicro nodes, yes.

2) Work needs to be done to get this into puppet first. We've been deploying what seems to be critical software by hand now, for a few quarters and we need to move that to a more formal process, so we don't run into trouble. 

3) Jake is now in-charge of developer services, therefore it'll be on him and his team to help with this moving forward.

From a prior discussion with Hal and Corey, https://infra.etherpad.mozilla.org/vcs2vcs was what we were discussing as the path forward.

Comment 4

[hwine]

(In reply to Shyam Mani [:fox2mike] from comment #3)
> John,
> 
> For some more context :

We've got wires crossed -- this request related not the etherpad discussion you, cshields and myself had -- that is for the "production" hardware.

This is purely a 2nd dev node for the phase II software development. As I understand it, those were built using the base puppet config.


> 3) Jake is now in-charge of developer services, therefore it'll be on him
> and his team to help with this moving forward.

Yes, we'll be working with Jake on production hardware.

Comment 5

[hwine]

Shyam - can you clarify who has the ball on providing this dev machine? Not sure if that's SE's or Developer Services.

Comment 6

[Shyam Mani [:fox2mike]]

This is on Jake to decide. We say this is dev, but there are now 4 machines :) I'll let him spec out what you need and let the SREs know, so we can provision the hardware for you.

Comment 7

[hwine]

Jake -- what do you need to approve this?

Shyam's counting is a bit off - this app and these machines have been in production since last October (see bug 789352 comment 11 for details). We only moved 1 to dev status in April (see bug 864877).

The current allocation is: 3 production machines and 1 dev machine:

The production machines are:
 github-sync3.dmz.scl3.mozilla.com (hp blade)
 github-sync1.dmz.scl3.mozilla.com (seamicro)
 github-sync1-dev.dmz.scl3.mozilla.com (seamicro)

The existing dev machine is:
 github-sync2.dmz.scl3.mozilla.com (seamicro)

I'll note that the sea micros are not capable of being full production boxes, due to limited disk size. A real dev/staging for this would need lots more disk.

Comment 8

[Jake Maul [:jakem]]

Have talked to Hal on this... we're going to try this:

get a stock VM... not too critical on resources
add an extra disk to it - preferably 200GB
    might want to consider filesystems other than ext4 for repo performance
name will be github-sync4.dmz.scl3.mozilla.com

Will pass it to Hal for some quick testing, then over to aki for actual usage.

Need to open a bug for virtualization/storage folks...

Comment 9

[Shyam Mani [:fox2mike]]

The SREs will kick a seamicro for this as per this morning's engops meeting. 

Dev services can handle any flows etc needed with netops.

Comment 10

[hwine]

github-sync4.dmz.scl3.mozilla.com is up and running.

Closing this for now -- may need to reopen