qa machine management

Kevin Fenzi kevin at scrye.com
Fri Mar 30 23:17:16 UTC 2012


Greetings. 

Just had a talk with tflink on IRC about the management of the qa
network machines. Long ago when we setup those machines we were
thinking we could use them as a testbed for bcfg2 to see if we wanted
to start using it or if it worked ok, etc. I setup a bcfg2 server to
try this with, but sadly have never found the time to even start
configuring it. 

Machines involved: 

virthost-comm01.qa (real hardware)
autoqa01.qa (guest)
autoqa-stg01.qa (guest)
lockbox-comm01.qa (guest)
bastion-comm01.qa (guest)
(someday we may add a sign-bridge-comm01 and sign-vault-comm01 to allow
secondary archs like ppc and arm to sign packages). 

Options: 

- Try and push forward with a bcfg2 setup on lockbox-comm01.qa and
  evaluate it. This would be nice, but I'm really not sure anyone has
  the time to do it. 

- Just add all the above machines to our puppet repo and configure them
  there and call it done. This would mean they wouldn't be seperate
  from us and we just update and configure and monitor them like any
  other machine. 

- Try and work out some setup with ansible or the like to see if it
  could manage them. Again, this would be a learning and tweaking
  curve, so not sure we have the time. 

- We could setup a new puppet for them on lockbox-comm01.qa and use
  that to manage them. We could reuse a lot of our current puppet
  setup, but it would still be a fair bit of work to get it all
  configured. 

Thoughts? Brilliant ideas? 

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20120330/1e08f089/attachment.sig>


More information about the infrastructure mailing list