Closed Bug 1110213 Opened 10 years ago Closed 10 years ago

Deploy 1 VM for webQA

Categories

(Infrastructure & Operations :: Virtualization, task)

Product:
Infrastructure & Operations
Component:
Virtualization
Platform:
x86
macOS
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: bsilverberg, Assigned: cknowles)

References

Details

(Whiteboard: [vm-create:1])

As per the discussion in bug 1107286, please deploy the following VMs: Hostname: webqa-ci1 Specification: RHEL 6, 16GB RAM, 4 cores, 250G HDD This matches the instance currently used for B2G (jenkins1.qa.scl3.mozilla.com). We should have the latest Jenkins LTS version installed on this box. The Web QA team should have SSH access to this box, and will ideally have write access to the Jenkins home path. As much of this that can be automated via puppet or similar would be great. We should also have monitoring for this box, and ideally a backup solution for at least the Jenkins home path. Finally, the intention is that the instance is publicly accessible.
Summary: Deploy 1 VMs for webQA → Deploy 1 VM for webQA
So, per the VM requests guide: https://mana.mozilla.org/wiki/display/SYSADMIN/VM+Requests - I've got a couple questions Biggest bugaboo, we've been wrestling with jenkins1.dmz.phx1.mozilla.com, which may or may not be similar - a P2V attempt to make it a VM failed, as it used virtualbox for some of its work. virtualbox and VMware VMs don't seem to nest well, or at all, so if that's a need here, then we may not be happy. If it's not, then let us continue... Given the need to match the jenkins1.qa.scl3.m.c I think I understand the CPU/RAM/HDD needs. Who in the webqa group should have sudoers access to the VM? I need guidance as to the VLAN you'll need it to be in? will it be in qa? or DMZ? I've asked for a sec-review to help determine where this should go, with the idea that it is to be publicly accessible. I'm also assuming SCL3, let me know if that assumption is faulty. As for the other items, most of that will be handled by you or through other bugs, as this is really for the initial deploy of the VM. For example, when you have something to backup, a bug to "Infra: Other" with a subject like "hostname: backup /path" with descriptives will get you backed up. Default monitoring is part of the deploy, but anything beyond that will likely need to be a bug. Questions/concerns, don't hesitate to update.
Flags: sec-review?
(In reply to Chris Knowles [:cknowles] from comment #1) > So, per the VM requests guide: > https://mana.mozilla.org/wiki/display/SYSADMIN/VM+Requests - I've got a > couple questions Sorry for not following procedure here. This URL doesn't work for me though. :( > Biggest bugaboo, we've been wrestling with jenkins1.dmz.phx1.mozilla.com, > which may or may not be similar - a P2V attempt to make it a VM failed, as > it used virtualbox for some of its work. virtualbox and VMware VMs don't > seem to nest well, or at all, so if that's a need here, then we may not be > happy. If it's not, then let us continue... Had to look up 'P2V' :) I don't think this will be an issue. The Web QA Jenkins instance does not currently use virtualbox, and I don't think there are any plans to. > Given the need to match the jenkins1.qa.scl3.m.c I think I understand the > CPU/RAM/HDD needs. > > Who in the webqa group should have sudoers access to the VM? I'll let Stephen comment if anybody else needs access, but to start I would suggest: * Stephen Donner * Bob Silverberg * Dave Hunt (me, although I'm technically not part of the Web QA group) > I need guidance as to the VLAN you'll need it to be in? will it be in qa? > or DMZ? I've asked for a sec-review to help determine where this should go, > with the idea that it is to be publicly accessible. I'm also assuming SCL3, > let me know if that assumption is faulty. I'm not sure of the distinction here. We'll either need this VM to connect directly to selenium[1-6].qa.scl3.mozilla.com or to do so via another VM, which might make sense to be on qa.scl3.mozilla.com too. If making it public dictates the VLAN then that should take priority. > As for the other items, most of that will be handled by you or through other > bugs, as this is really for the initial deploy of the VM. > > For example, when you have something to backup, a bug to "Infra: Other" with > a subject like "hostname: backup /path" with descriptives will get you > backed up. That's good to know, thanks! > Default monitoring is part of the deploy, but anything beyond that will > likely need to be a bug. Great!
Alright, that covers most of it. Still leaves VLAN open. Since you mention that it is intended for public access, I still want opsec to weigh in on it. They'll likely have questions for you about what's going where, purpose, opened ports, etc. Sorry about the jargon. It's hard to avoid sometimes.
Where is the current instance of Jenkis? Dmz or QA? I'd see them all in the QA Vlan and public access done through Zeus, just to keep things sane and organized.
Given that the jenkins that they want to match is in the QA VLAN, I'd say that would work, and then access can be handled through zeus. (The mention of the DMZ instance is a red herring in this case, and I apologize for muddying the waters.) Dave: Any problem with my starting on the deploy of this to the QA VLAN, or do you have any questions you'd like answered before I get started?
(In reply to Chris Knowles [:cknowles] from comment #5) > Dave: Any problem with my starting on the deploy of this to the QA VLAN, or > do you have any questions you'd like answered before I get started? Please proceed. Thanks!
Alright, webqa-ci1.qa.scl3.mozilla.com is stood up. It's got 4 CPU, 16G RAM, and a 250G disk. Users sdonner and dhunt should have access and sudoers access. I'm having trouble finding Bob Silverberg's LDAP account name, if you can give me that I should be able to add him quickly. Initial Nagios stubs and puppet stubs have been created, should be ready for your customization. Let me know what else I can do/advise to help.
Whiteboard: [vm-create:1]
(In reply to Chris Knowles [:cknowles] from comment #7) > Alright, webqa-ci1.qa.scl3.mozilla.com is stood up. > > It's got 4 CPU, 16G RAM, and a 250G disk. > > Users sdonner and dhunt should have access and sudoers access. I'm having > trouble finding Bob Silverberg's LDAP account name, if you can give me that > I should be able to add him quickly. > > Initial Nagios stubs and puppet stubs have been created, should be ready for > your customization. > > Let me know what else I can do/advise to help. Thanks Chris. Is Bob not bsilverberg? I've now installed the latest Jenkins stable release, and I think the next thing to do is to start the process of getting it publicly accessible - should this be a separate bug?
Flags: needinfo?(bob.silverberg)
I couldn't find a bsilverberg in the VPN users groups, the webqa VPN group, etc. If bsilverberg is his LDAP username, we'll likely need another bug to get him access to this VM. (nor other obvious "silverberg" related usernames) Yes, public accessibility will be another bug, thought I can't say I know what component to put it under... perhaps Michal can guide us to where that needs to be filed.
Assignee: server-ops-virtualization → cknowles
(In reply to Chris Knowles [:cknowles] from comment #9) > I couldn't find a bsilverberg in the VPN users groups, the webqa VPN group, > etc. If bsilverberg is his LDAP username, we'll likely need another bug to > get him access to this VM. (nor other obvious "silverberg" related > usernames) Bob's on my team, and he's in Phonebook: https://phonebook.mozilla.org/#search/silverberg I'll get that bug to add him to those 2 groups and cross-reference it here. > Yes, public accessibility will be another bug, thought I can't say I know > what component to put it under... perhaps Michal can guide us to where that > needs to be filed. I can also reach out to Michal + Joe, to give a little more history + context -- thanks, Chris!
Michal: Could you answer the question about what component we would need to raise a bug for getting this VM publicly accessible?
Flags: needinfo?(mpurzynski)
Infrastructure & Operations:: WebOps: Other If not, you will get a redirect, but at least that's the right team.
Flags: needinfo?(mpurzynski)
Bob, you should be able to get access - go to https://login.mozilla.com/ and upload your public key, and puppet should take care of the rest of it. Is there anything else we need this bug open for?
(In reply to Chris Knowles [:cknowles] from comment #13) > Is there anything else we need this bug open for? Nope, anything else can be taken care of by other bugs. Thanks Chris!
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(bob.silverberg)
Resolution: --- → FIXED
See Also: → 1148714
Chris, I've just tried to access the VM via ssh as per davehunt's request. I was unable to access it and he pointed me to comment #13. I just uploaded my public key to login.mozilla.com. Is there anything else I need to do? When I try to ssh I get: ~$ ssh webqa-ci1.qa.scl3.mozilla.com Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
Flags: needinfo?(cknowles)
That should be all ... I'm assuming your local username is bsilverberg... if not, you'll need to specify that as well. Just checked, the authorized_keys in /home/bsilverberg/.ssh just updated 12 minutes ago, so I'm hoping it should "just work" Obviously, let me know if that's not the case.
Flags: needinfo?(cknowles)
Thanks Chris. It did, indeed, eventually, just work. :)
You need to log in before you can comment on or make changes to this bug.