Closed Bug 722795 Opened 12 years ago Closed 12 years ago

Replace api-dev.bugzilla.mozilla.org by a puppetized RHEL system

Categories

(mozilla.org Graveyard :: Server Operations, task)

Product:
mozilla.org Graveyard
Component:
Server Operations
Platform:
All
Other
Type:
task
Priority:
Not set
Severity:
minor

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: kang, Assigned: fox2mike)

Details

api-dev.bugzilla.mozilla.org. (two ips: 63.245.212.105 and 63.245.210.151) are currently  Ubuntu systems managed by Gerv (contractor in UK).

We would like to have those systems reinstalled with our default RHEL6 install (which is puppetized and also has infrasec logging and monitoring).

Additionally, the puppetization let us deploy security fixes easily (currently, infra only support RHEL with puppet)

Gerv, would that be any problem for you?

Thanks!
(Please can this bug by removed from any groups, so that it's public, or a good reason given for keeping it private? :-)

No problem for me in principle. There may be a few practical issues to work out.

Firstly, this is a /de facto/ critical infrastructure system. The downtime associated with deleting everything and reinstalling is not an acceptable option. We should bring up parallel servers, test them, and switch over quickly with a DNS change.

Secondly, at the moment, I have root access on the server so I can push updates. However, development is now much slower than it used to be (we are in maintenance mode) so perhaps we could come to some different arrangement.

Gerv
Unchecked the group.

Having the systems in parallel until the switch over would be fine. The access you require on the system is fine too, and will be kept on the new system (they will have to add that for you in ldap_users puppet module)

To login on the new host when its ready please log as gerv@api-dev.bugzilla.mozilla.org then sudo (or sudo -s). It does not require a password.

Thanks!
Group: infra
:kang: surely if we are running the systems in parallel then, at least initially, my login will be to a different name?

Also, if we are productizing this, we should do the switchover by taking the opportunity to remove the "-dev" from the name. And then I can keep my dev server, too.

So, let's bring the new box up as api.bugzilla.mozilla.org, and we can encourage clients to switch over. At some later point, we could switch the name alias.

Also worth bearing in mind is that dkl is working on a replacement for BzAPI which is a proper Bugzilla extension, and that will obsolete BzAPI. dkl: care to give us a status update?

Gerv
yeah, i meant that you will be able to log as your user instead of root directly (in fact you'll probably be able to log as root as well but we want to phase that out eventually). The hostname will differ when it runs in parallel.

For the other details I will let infra handle it.
(In reply to Gervase Markham [:gerv] from comment #3)
> Also worth bearing in mind is that dkl is working on a replacement for BzAPI
> which is a proper Bugzilla extension, and that will obsolete BzAPI. dkl:
> care to give us a status update?

That is the plan yes. I am still not quite there yet so can't give a definite cutover date
but it is a 2012Q1 goal for our team.

dkl
If it's a Q1 goal and it deprecates what we have now I'm not sure we should be investing time in getting what we have now moved away to RHEL. 

Guillaume, would you be okay putting this on hold for a bit and seeing what David comes up with at the end of this quarter? Considering everything else we have on our plate, this seems like a reasonable alternative. If for some reason BzAPI gets delayed for a longer period, we can always re-visit this plan. Thoughts?
I'm fine with putting this on hold. Upgrading that system to a puppetized system is not a goal priority for us.

End of Q1 is perfectly fine. I hope it doesn't slip to Q2, Q3, etc however :)
(In reply to Guillaume Destuynder [:kang] from comment #7)
 
> End of Q1 is perfectly fine. I hope it doesn't slip to Q2, Q3, etc however :)

Thanks. Just to clarify :

1) If David gets the new api online, this server is deprecated and we have no use for it...therefore nothing to get into puppet.

2) If David can't get the new api online, we will look at puppetizing this server in Q2.

Does that sound alright? Alternatively, if David knows more definitively about BzAPI's status, we can revisit this bug at that point and decide on how we proceed.

I'll grab this for now and mark it WONTFIX, please re-open if BzAPI isn't going on track.
Assignee: server-ops → shyam
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
yep that was clear to me :)
The current VM, alternately known as
 api-dev (DNS),
 bugzilla-api01 (hostname), and
 dm-bugzilla-api02 (vmware)
is in sjc1, and will need to move or be turned off.  For now, I'll plan to move it to scl3, but it would probably be a lot more fun for everyone if one of (1) or (2) above came true first -- so, well before April 30.  I'll also fix up the name in vmware and get this added to inventory.  :gerv, I'll leave it to you if you want to change the hostname on the machine itself.
:dustin: Sorry, I lost you a bit there. Why and when would I want to change the hostname on the machine?

Gerv
Why: so it matches DNS
When: whenever it won't cause failures on your end

You don't have to if you don't want to -- I only mentioned that so it was clear I *didn't* change the hostname.

And now that I re-read, it's unclear what I meant with the numerals in
> would probably be a lot more fun for everyone if one of (1) or (2) above came true first -- so,
I was referring to comment 8 - specifically, either getting this API online, or puppetizing the box and using puppet to build a new one in scl3.

So, still no action here (other than an optional hostname change), so no need to re-open.
(In reply to Dustin J. Mitchell [:dustin] from comment #12)
> Why: so it matches DNS
> When: whenever it won't cause failures on your end

You've still lost me, sorry :-(. Why is this necessary or desirable after all this time? I thought this bug had resulted in no changes. If so, what's wrong with the status quo?

Gerv
Nothing, don't worry about it.
Any word on whether or not this does need moved to scl3? If it does, what kind of downtime is acceptable? When can it be scheduled to go?
rtucker: see bug 743916. :-\

Gerv
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.