Closed
Bug 557704
Opened 15 years ago
Closed 13 years ago
Find a way to keep non-MoCo build machines up to date
Categories
(Release Engineering :: General, defect, P3)
Release Engineering
General
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: kairo, Assigned: coop)
Details
(Whiteboard: [puppet][opsi][automation])
Before things like puppet and OPSI arrived in MoCo land, it was pretty easy for someone to maintain his own build machine (possibly dev/testing VM) or build environments for other apps (like me for SeaMonkey) to be as close to MoCo buildbot machines as possible by just following the step-by-step items being added to the docs at https://wiki.mozilla.org/ReferencePlatforms and mostly just copying those things to his own machines.
Nowadays, this does not work any more, as for someone not operating his own puppet and OPSI servers, the descriptions there are cryptic at worst, hard to follow at best.
We should try to find some way to not leave people like me as much in the dark as right now (e.g. I have no idea what I might need to do to get my pre-puppet linux64 machine to up par with Firefox slaves) but still not create too much of an overhead for MoCo RelEng people. I'm not sure how to achieve this, but I think it's better for me to file this and hopefully get thoughts and discussions going than to rant about it every time I run into difficulties. ;-)
Comment 1•15 years ago
|
||
What about a Linux (puppet) and a Windows (OPSI) machine to keep the community machines? Would this work?
Maybe write a note on how to do it without puppet/opsi as a side note?
Comment 2•15 years ago
|
||
(In reply to comment #1)
> What about a Linux (puppet) and a Windows (OPSI) machine to keep the community
> machines? Would this work?
It wouldn't be overly difficult for someone to run a second server of each with our configs.
> Maybe write a note on how to do it without puppet/opsi as a side note?
We already do that (or are supposed to do that, at least): https://wiki.mozilla.org/ReferencePlatforms/Linux-CentOS-5.0#Post-puppet_packages
Reporter | ||
Comment 3•15 years ago
|
||
(In reply to comment #1)
> What about a Linux (puppet) and a Windows (OPSI) machine to keep the community
> machines? Would this work?
That might be an interesting option, actually, at least for my immediate problems. I'm not sure how much resource those servers need, I'd guess that's pretty low overall, my problem in SeaMonkey is mostly that I lack dedicated hardware/VMs and would need to gather all the knowledge myself to set all that up (similar for bug 555449 on clobberer) - if we can mitigate those problems, my specific problems would probably be solved.
Oh, and you also have something similar running for Mac, right?
(In reply to comment #2)
> > Maybe write a note on how to do it without puppet/opsi as a side note?
>
> We already do that (or are supposed to do that, at least):
> https://wiki.mozilla.org/ReferencePlatforms/Linux-CentOS-5.0#Post-puppet_packages
Since it's not the exact steps any more (understandably, as you don't need to do/follow them that way yourself now), it's become harder for me or someone operating his own ref machine for testing to follow them, as some investigation of how to actually perform those steps is needed for every step now.
Esp. https://wiki.mozilla.org/ReferencePlatforms/Linux-CentOS-5.0_64-bit#Post_puppet_packages poses some significant opaqueness for me, for example.
Comment 4•15 years ago
|
||
(In reply to comment #3)
> I lack dedicated
> hardware/VMs and would need to gather all the knowledge myself to set all that
> up (similar for bug 555449 on clobberer) - if we can mitigate those problems,
> my specific problems would probably be solved.
https://wiki.mozilla.org/ReferencePlatforms/OPSI_Server
https://wiki.mozilla.org/ReferencePlatforms/Puppet_Server
should be good starting points if we're going that route.
> Oh, and you also have something similar running for Mac, right?
I believe Puppet handles both linux + mac.
Reporter | ||
Comment 5•15 years ago
|
||
(In reply to comment #4)
> (In reply to comment #3)
> > I lack dedicated
> > hardware/VMs and would need to gather all the knowledge myself to set all that
> > up (similar for bug 555449 on clobberer) - if we can mitigate those problems,
> > my specific problems would probably be solved.
>
> https://wiki.mozilla.org/ReferencePlatforms/OPSI_Server
> https://wiki.mozilla.org/ReferencePlatforms/Puppet_Server
>
> should be good starting points if we're going that route.
Those are good to know, thanks. Possibly even a clone/copy of what you guys are running might be a good start? Would someone on your side get those set up?
> > Oh, and you also have something similar running for Mac, right?
>
> I believe Puppet handles both linux + mac.
Ah, good to know.
Assignee | ||
Comment 6•15 years ago
|
||
(In reply to comment #5)
> Those are good to know, thanks. Possibly even a clone/copy of what you guys are
> running might be a good start? Would someone on your side get those set up?
bhearsum: would we have to sanitize the repos at all before cloning them for external consumption? Anything in there we shouldn't be redistributing?
Priority: -- → P3
Comment 7•15 years ago
|
||
(In reply to comment #6)
> (In reply to comment #5)
> > Those are good to know, thanks. Possibly even a clone/copy of what you guys are
> > running might be a good start? Would someone on your side get those set up?
>
> bhearsum: would we have to sanitize the repos at all before cloning them for
> external consumption? Anything in there we shouldn't be redistributing?
There's certainly some places where we need to scrub passwords. For Windows and Mac, I don't know if we can legally redistribute all the installation files. I doubt that's an issue with Linux.
Assignee | ||
Updated•15 years ago
|
Whiteboard: [puppet][opsi][automation]
Updated•14 years ago
|
Assignee: nobody → dustin
Updated•14 years ago
|
Assignee: dustin → nobody
Assignee | ||
Updated•13 years ago
|
Assignee: nobody → coop
Assignee | ||
Comment 8•13 years ago
|
||
(In reply to Ben Hearsum [:bhearsum] from comment #7)
> There's certainly some places where we need to scrub passwords. For Windows
> and Mac, I don't know if we can legally redistribute all the installation
> files. I doubt that's an issue with Linux.
I'm guessing that Callek is the new SeaMonkey point-of-contact for this.
Callek: do you currently have problems getting the software you need from us? I noticed you managed to get VS2010 from us without too much hassle this past week, but correct me if I'm wrong on that count.
If all we need is some process documentation on our side for when we deploy/customize new software, I'm willing to get that written up. I'd rather not add undue process if we're coping fine right now though.
Comment 9•13 years ago
|
||
(In reply to Chris Cooper [:coop] from comment #8)
> (In reply to Ben Hearsum [:bhearsum] from comment #7)
> > There's certainly some places where we need to scrub passwords. For Windows
> > and Mac, I don't know if we can legally redistribute all the installation
> > files. I doubt that's an issue with Linux.
>
> I'm guessing that Callek is the new SeaMonkey point-of-contact for this.
>
> Callek: do you currently have problems getting the software you need from
> us? I noticed you managed to get VS2010 from us without too much hassle this
> past week, but correct me if I'm wrong on that count.
Currently using up your resources by asking directly works, but overall, if possible I'd love to be able to get these files on demand (as in when I notice I need them, at that moment) then wait. Also having to use your man-hours for getting the files imo is also less than ideal all around.
That said, I have no problem with the response time, and the process itself. I don't mind continuing it if this bug is deemed "too much work". For info this bug was also filed before Joduinn gave the verbal ok for the current status quo.
Conclusion: a nice to have, but not a hard requirement.
Assignee | ||
Comment 10•13 years ago
|
||
(In reply to Justin Wood (:Callek) from comment #9)
> (In reply to Chris Cooper [:coop] from comment #8)
> That said, I have no problem with the response time, and the process itself.
> I don't mind continuing it if this bug is deemed "too much work". For info
> this bug was also filed before Joduinn gave the verbal ok for the current
> status quo.
Given this, and also given that our internal deployment system is not exactly smooth as butter, I'm fine with continuing the current status quo and trying to be as responsive as possible when the community needs something.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
Updated•11 years ago
|
Product: mozilla.org → Release Engineering
You need to log in
before you can comment on or make changes to this bug.
Description
•