FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Infrastructure

 
 
LinkBack Thread Tools
 
Old 03-30-2012, 11:17 PM
Kevin Fenzi
 
Default qa machine management

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
_______________________________________________
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
 
Old 03-31-2012, 08:25 PM
Stephen John Smoogen
 
Default qa machine management

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



--
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me." ¬*‚ÄĒJames Stewart as Elwood P. Dowd
_______________________________________________
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
 
Old 03-31-2012, 09:29 PM
seth vidal
 
Default qa machine management

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
_______________________________________________
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
 
Old 04-01-2012, 12:45 AM
Stephen John Smoogen
 
Default qa machine management

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



--
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me." ¬*‚ÄĒJames Stewart as Elwood P. Dowd
_______________________________________________
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
 
Old 04-02-2012, 02:22 PM
Kevin Fenzi
 
Default qa machine management

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

_______________________________________________
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
 
Old 04-02-2012, 06:29 PM
Tim Flink
 
Default qa machine management

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 mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
 
Old 04-02-2012, 07:39 PM
Tim Flink
 
Default qa machine management

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
_______________________________________________
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
 

Thread Tools




All times are GMT. The time now is 09:58 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org