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
On 30 March 2012 17:17, Kevin Fenzi kevin@scrye.com wrote:
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.
Actually I think I do have the time to do this. I can start on this after I get back from recovery.. late next week early week after.
- 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.
I actually would like to pursue this over bcfg. I don't think we have any bcfg experts but we do have ansible experts.
So
a) I give bcfg2 a go and see how it looks. Report back by end of 3rd week of april. b) I then work on ansible. and see if it is better/harder/easier than bcfg2.
or
a) I just go for ansible and give bcfg2 the heave ho?
- 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
infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
On Sat, 31 Mar 2012 14:25:35 -0600 Stephen John Smoogen smooge@gmail.com wrote:
On 30 March 2012 17:17, Kevin Fenzi kevin@scrye.com wrote:
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.
Actually I think I do have the time to do this. I can start on this after I get back from recovery.. late next week early week after.
- 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.
I actually would like to pursue this over bcfg. I don't think we have any bcfg experts but we do have ansible experts.
So
a) I give bcfg2 a go and see how it looks. Report back by end of 3rd week of april. b) I then work on ansible. and see if it is better/harder/easier than bcfg2.
or
a) I just go for ansible and give bcfg2 the heave ho?
One concern I have with bcfg2 is lack of momentum. Since, for all intents and purposes it is just puppet but in python.
One of the reasons I've been looking so hard at ansible is simple - it doesn't require a client-side. It's all push-based. From a logging and quietness-standpoint it should be significantly better especially for our environment where if a host cannot reach lockbox01 we know we cannot do anything else.
-sv
On 31 March 2012 15:29, seth vidal skvidal@fedoraproject.org wrote:
On Sat, 31 Mar 2012 14:25:35 -0600 Stephen John Smoogen smooge@gmail.com wrote:
One concern I have with bcfg2 is lack of momentum. Since, for all intents and purposes it is just puppet but in python.
Well I am more worried about xml versus playbooks. in any case I think I will go with ansible .. will see how much I can learn while on Percacet (hey its QA environment right before release.. how bad could it be :)?)
One of the reasons I've been looking so hard at ansible is simple - it doesn't require a client-side. It's all push-based. From a logging and quietness-standpoint it should be significantly better especially for our environment where if a host cannot reach lockbox01 we know we cannot do anything else.
-sv
On Sat, 31 Mar 2012 18:45:49 -0600 Stephen John Smoogen smooge@gmail.com wrote:
On 31 March 2012 15:29, seth vidal skvidal@fedoraproject.org wrote:
On Sat, 31 Mar 2012 14:25:35 -0600 Stephen John Smoogen smooge@gmail.com wrote:
One concern I have with bcfg2 is lack of momentum. Since, for all intents and purposes it is just puppet but in python.
Well I am more worried about xml versus playbooks. in any case I think I will go with ansible .. will see how much I can learn while on Percacet (hey its QA environment right before release.. how bad could it be :)?)
One of the reasons I've been looking so hard at ansible is simple - it doesn't require a client-side. It's all push-based. From a logging and quietness-standpoint it should be significantly better especially for our environment where if a host cannot reach lockbox01 we know we cannot do anything else.
well, if QA folks are willing to give that a try, sounds reasonable to me. ;)
I'd suggest we leave the autoqa machines alone until after release, but instead look at the other not very used ones in the list to try things on.
Perhaps Tim can chime in here and explain the kinds of things they are doing now that they would like to not have to do once things are automated...
kevin
On Mon, 2 Apr 2012 08:22:39 -0600 Kevin Fenzi kevin@scrye.com wrote:
On Sat, 31 Mar 2012 18:45:49 -0600 Stephen John Smoogen smooge@gmail.com wrote:
On 31 March 2012 15:29, seth vidal skvidal@fedoraproject.org wrote:
On Sat, 31 Mar 2012 14:25:35 -0600 Stephen John Smoogen smooge@gmail.com wrote:
One concern I have with bcfg2 is lack of momentum. Since, for all intents and purposes it is just puppet but in python.
Well I am more worried about xml versus playbooks. in any case I think I will go with ansible .. will see how much I can learn while on Percacet (hey its QA environment right before release.. how bad could it be :)?)
One of the reasons I've been looking so hard at ansible is simple
- it doesn't require a client-side. It's all push-based. From a
logging and quietness-standpoint it should be significantly better especially for our environment where if a host cannot reach lockbox01 we know we cannot do anything else.
well, if QA folks are willing to give that a try, sounds reasonable to me. ;)
I'd suggest we leave the autoqa machines alone until after release, but instead look at the other not very used ones in the list to try things on.
Either that or limit work to staging (autoqa-stg01 and associated clients). We're not really doing much in the way of development work right now since F17 testing is in full swing so it doesn't matter so much if staging goes down or has issues.
Perhaps Tim can chime in here and explain the kinds of things they are doing now that they would like to not have to do once things are automated...
In my mind, there are two types of things that would be nice to automate: - Server configuration - Client configuration
The server configuration is relatively static for now and would be as much for disaster recovery and configuration backup as anything. If/when we start doing more functional self-testing and re-deployment of AutoQA, this would be very helpful but we aren't doing that at the moment.
The client configuration is what we're more interested in at the moment and as we go forward (disposable single-use clients will happen at some point). This is a matter of configuring the AutoQA yum repo, installing some packages and manipulating a few files. I don't have a link for the documentation off hand but can find/create it.
Another thing that we're looking to do is automate the maintenance and monitoring of the clients. I'm not sure how applicable this is to the current discussion and I think this will mostly involve some scripting on our end. We occasionally have problems with the clients running out of disk space and failing tests. We'd like to have an automated method for cleaning up and updating all of the test clients and possibly some monitoring so that we are notified of low disk space before the tests start failing.
The only snag to that is that the cleanup would have to run when there are no active test runs going on. If done at the wrong time, said maintenance could cause random and difficult-to-diagnose test failures. We don't currently do this, but my thought is to have regular downtime so that any of the updates and maintenance could be done.
Let me know if there is anything you'd like to see expanded or clarified. F17 beta testing is pretty much consuming all of my available sanity and time (I should have waited to ask nirik about all this) but I will do my best to keep up with the discussion.
Tim
On Mon, 2 Apr 2012 08:22:39 -0600 Kevin Fenzi kevin@scrye.com wrote:
On Sat, 31 Mar 2012 18:45:49 -0600 Stephen John Smoogen smooge@gmail.com wrote:
On 31 March 2012 15:29, seth vidal skvidal@fedoraproject.org wrote:
On Sat, 31 Mar 2012 14:25:35 -0600 Stephen John Smoogen smooge@gmail.com wrote:
One concern I have with bcfg2 is lack of momentum. Since, for all intents and purposes it is just puppet but in python.
Well I am more worried about xml versus playbooks. in any case I think I will go with ansible .. will see how much I can learn while on Percacet (hey its QA environment right before release.. how bad could it be :)?)
One of the reasons I've been looking so hard at ansible is simple
- it doesn't require a client-side. It's all push-based. From a
logging and quietness-standpoint it should be significantly better especially for our environment where if a host cannot reach lockbox01 we know we cannot do anything else.
well, if QA folks are willing to give that a try, sounds reasonable to me. ;)
I'd suggest we leave the autoqa machines alone until after release, but instead look at the other not very used ones in the list to try things on.
Perhaps Tim can chime in here and explain the kinds of things they are doing now that they would like to not have to do once things are automated...
Is there still some interest in doing this? We're starting to think about replacing our F15 systems before it goes EOL, so it might be a good time to try getting some of this working.
Tim
On 4 June 2012 11:59, Tim Flink tflink@redhat.com wrote:
Is there still some interest in doing this? We're starting to think about replacing our F15 systems before it goes EOL, so it might be a good time to try getting some of this working.
Still interest on my part. Just wanted to get past F17 so we could see what you wanted.
On Mon, 4 Jun 2012 14:50:52 -0600 Stephen John Smoogen smooge@gmail.com wrote:
Still interest on my part. Just wanted to get past F17 so we could see what you wanted.
Cool - is there anything specific that we should be providing/doing?
I assume that the following information would be useful: - list of required repos - list of packages on the systems - configuration details
Is there anything that I'm missing? Is there a particular format that's preferred?
On 5 June 2012 14:09, Tim Flink tflink@redhat.com wrote:
On Mon, 4 Jun 2012 14:50:52 -0600 Stephen John Smoogen smooge@gmail.com wrote:
Still interest on my part. Just wanted to get past F17 so we could see what you wanted.
Cool - is there anything specific that we should be providing/doing?
I assume that the following information would be useful: - list of required repos - list of packages on the systems - configuration details
Is there anything that I'm missing? Is there a particular format that's preferred?
1) How you prefer to install things (via pxe, etc). 2) What you want in any side repos (eg stuff you use but isn't in a normal repo)
that be it.
On Sat, 31 Mar 2012 18:45:49 -0600 Stephen John Smoogen smooge@gmail.com wrote:
On 31 March 2012 15:29, seth vidal skvidal@fedoraproject.org wrote:
On Sat, 31 Mar 2012 14:25:35 -0600 Stephen John Smoogen smooge@gmail.com wrote:
One concern I have with bcfg2 is lack of momentum. Since, for all intents and purposes it is just puppet but in python.
Well I am more worried about xml versus playbooks. in any case I think I will go with ansible .. will see how much I can learn while on Percacet (hey its QA environment right before release.. how bad could it be :)?)
Just piping up from an AutoQA perspective. We don't really have much of a preference on tooling since AFAIK, none of us have much experience with puppet, bcfg2 or ansible.
I just request that if anyone does start on this, please let at least one of us (kparal, jsladan or myself) know. We're up to (or past, depending on the day) our eyeballs in F17 beta testing at the moment and I tend to drop what I'm doing if I get unexpected nagios notifications about hosts being down or reports that AutoQA isn't working.
We also have some unpackaged tools that need to stick around if that's an issue. One of them is a tool that I wrote and I plan to package it, just haven't made the time to do so yet. The other is pending discussion once things calm down a bit in QA land
Tim
infrastructure@lists.fedoraproject.org
-
Kevin Fenzi -
Seth Vidal -
Stephen John Smoogen -
Tim Flink