We currently run many test servers, 3 app servers and 10 Build servers off of Fedora 6. Do we
A) Upgrade everything to Fedora 7 B) Upgrade nothing to Fedora 7 C) Upgrade things as needed.
I'm for C. I think the mash server may already have a request to be upgraded. The others I don't think there is a compelling reason to upgrade and we should wait for Fedora 8 or until something comes up that may require it.
Thoughts?
-Mike
On Thursday 07 June 2007 11:39:15 Mike McGrath wrote:
We currently run many test servers, 3 app servers and 10 Build servers off of Fedora 6. Do we
A) Upgrade everything to Fedora 7 B) Upgrade nothing to Fedora 7 C) Upgrade things as needed.
I'm for C. I think the mash server may already have a request to be upgraded. The others I don't think there is a compelling reason to upgrade and we should wait for Fedora 8 or until something comes up that may require it.
Thoughts?
My personal thought is anything that doesn't require the specifics of a Fedora release should be on RHEL5/CentOS5. I can only think of a couple things that need the specifics, the mash box and the updates system, and those should be on Fedora 7.
Jesse Keating wrote:
My personal thought is anything that doesn't require the specifics of a Fedora release should be on RHEL5/CentOS5. I can only think of a couple things that need the specifics, the mash box and the updates system, and those should be on Fedora 7.
I agree, I had no plans on upgrading any of our RHEL boxes (except for cvs and db1 but will stay in the RHEL upgrade path). For those of you that are new on the list we've had a lot of discussions about this in the past. Our team, for the most part, agrees that its about picking the right tool for the job. For boxes that don't need brand new technologies (like cvs) its nice to be able to set them up and forget about them. But for some boxes that do need the latest and greatest (like our builders) we've always had and kept them on Fedora.
-Mike
On Thursday 07 June 2007 11:49:57 Mike McGrath wrote:
I agree, I had no plans on upgrading any of our RHEL boxes (except for cvs and db1 but will stay in the RHEL upgrade path). For those of you that are new on the list we've had a lot of discussions about this in the past. Our team, for the most part, agrees that its about picking the right tool for the job. For boxes that don't need brand new technologies (like cvs) its nice to be able to set them up and forget about them. But for some boxes that do need the latest and greatest (like our builders) we've always had and kept them on Fedora.
With RHEL5 out, I question the need for Fedora on the builders. In fact, before the merge, all the internal Core builders were running RHEL4. Can we not use RHEL5 on the builders now?
On Thu, 2007-06-07 at 11:53 -0400, Jesse Keating wrote:
On Thursday 07 June 2007 11:49:57 Mike McGrath wrote:
I agree, I had no plans on upgrading any of our RHEL boxes (except for cvs and db1 but will stay in the RHEL upgrade path). For those of you that are new on the list we've had a lot of discussions about this in the past. Our team, for the most part, agrees that its about picking the right tool for the job. For boxes that don't need brand new technologies (like cvs) its nice to be able to set them up and forget about them. But for some boxes that do need the latest and greatest (like our builders) we've always had and kept them on Fedora.
With RHEL5 out, I question the need for Fedora on the builders. In fact, before the merge, all the internal Core builders were running RHEL4. Can we not use RHEL5 on the builders now?
Will we want to pull in new features for the builders? Something like a change in rpm is needed for a new version of mock. We want that change and so we need to upgrade?
I just want to avoid flip-flopping between RHEL and Fedora.
-Toshio
I would also prefer to standardize everything, unless necessary. But for now Glezos requests that publictest4 be upgraded to F7, since he needs some packages that exist in F7 and not in FC6.
Thanks, Paulo
On 6/7/07, Toshio Kuratomi a.badger@gmail.com wrote:
On Thu, 2007-06-07 at 11:53 -0400, Jesse Keating wrote:
On Thursday 07 June 2007 11:49:57 Mike McGrath wrote:
I agree, I had no plans on upgrading any of our RHEL boxes (except for cvs and db1 but will stay in the RHEL upgrade path). For those of you that are new on the list we've had a lot of discussions about this in the past. Our team, for the most part, agrees that its about picking the right tool for the job. For boxes that don't need brand new technologies (like cvs) its nice to be able to set them up and forget about them. But for some boxes that do need the latest and greatest (like our builders) we've always had and kept them on Fedora.
With RHEL5 out, I question the need for Fedora on the builders. In
fact,
before the merge, all the internal Core builders were running
RHEL4. Can we
not use RHEL5 on the builders now?
Will we want to pull in new features for the builders? Something like a change in rpm is needed for a new version of mock. We want that change and so we need to upgrade?
I just want to avoid flip-flopping between RHEL and Fedora.
-Toshio
Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Paulo Santos wrote:
I would also prefer to standardize everything, unless necessary. But for now Glezos requests that publictest4 be upgraded to F7, since he needs some packages that exist in F7 and not in FC6.
Items like this will always come up. It seems the general feel is to move towards the most recent RHEL version. Unfortunately RHEL doesn't always do what we want it to (which is why we also have production FC boxes).
Its been an unspoken rule I guess to use RHEL when possible and to use Fedora when we need Fedora's features. I have a feeling we'll always be running Fedora in production for our application servers, that's not a bad thing at all. But as far as managing risk (which, at the end of the day, is what this is all about) we just have to be smart about the decisions we make. Upgrading publictest4 isn't a problem at all. But when Glezos's project is ready to be published to the world we'll have to make sure we either A) test our current FC6 boxes for an upgrade or B) Move all our FC6 stuff to RHEL and then start over with some F7 boxes.
-Mike
On Thursday 07 June 2007 12:28:17 Toshio Kuratomi wrote:
Will we want to pull in new features for the builders? Something like a change in rpm is needed for a new version of mock. We want that change and so we need to upgrade?
I just want to avoid flip-flopping between RHEL and Fedora.
Well, one of the things we've been very careful with is making sure we don't put ourselves in this position, and sometimes that does mean limiting the kind of changes we can do to things like rpm in Fedora, or spec files or whatnot. While I appreciate not wanting to flip/flop between RHEL and Fedora, I don't want to upgrade the builders every 6~13 months either (:
Jesse Keating said the following on 06/07/2007 08:53 AM Pacific Time:
On Thursday 07 June 2007 11:49:57 Mike McGrath wrote:
I agree, I had no plans on upgrading any of our RHEL boxes (except for cvs and db1 but will stay in the RHEL upgrade path). For those of you that are new on the list we've had a lot of discussions about this in the past. Our team, for the most part, agrees that its about picking the right tool for the job. For boxes that don't need brand new technologies (like cvs) its nice to be able to set them up and forget about them. But for some boxes that do need the latest and greatest (like our builders) we've always had and kept them on Fedora.
With RHEL5 out, I question the need for Fedora on the builders. In fact, before the merge, all the internal Core builders were running RHEL4. Can we not use RHEL5 on the builders now?
What are the arguments against "eating our own dogfood" and running on FedoraX? I know there are probably good reasons, but thought it would be good to get it out in the open as others less informed (like myself) will probably ask :)
Thanks, John
John Poelstra wrote:
What are the arguments against "eating our own dogfood" and running on FedoraX? I know there are probably good reasons, but thought it would be good to get it out in the open as others less informed (like myself) will probably ask :)
Its been discussed in previous threads and in this one. Its about picking the right tool for the job. No one wants us to schedule cvs outages regularly just to upgrade the OS. The least risky route is to set stuff like that up with an OS that A) doesn't need to be re-installed often and B) doesn't need very many updates. RHEL has far fewer updates then Fedora and we don't benefit any from running it on fedora.
-Mike
On Thu, 2007-06-07 at 10:39 -0500, Mike McGrath wrote:
We currently run many test servers, 3 app servers and 10 Build servers off of Fedora 6. Do we
A) Upgrade everything to Fedora 7 B) Upgrade nothing to Fedora 7 C) Upgrade things as needed.
I'm for C. I think the mash server may already have a request to be upgraded. The others I don't think there is a compelling reason to upgrade and we should wait for Fedora 8 or until something comes up that may require it.
Depends...
What is the reason for those boxes to be on Fedora instead of RHEL? If it's because FC6 had things not in RHEL4 maybe we can make a switch to RHEL5 at some point. If the reason is we want the flexibility of moving to the latest code along with Fedora instead of waiting for RHEL to upgrade/backport then perhaps they should be on the latest Fedora where the latest code is more likely to land sooner.
In the case of the app servers running TurboGears, I think that it was a lack of TG requirements on RHEL4 that held us back. I also think we're close to having TG for RHEL5 so we might want to move test servers to RHEL5, check that the applications run there, and then move the app servers handling those to RHEL.
-Toshio
Toshio Kuratomi wrote:
Depends...
What is the reason for those boxes to be on Fedora instead of RHEL? If it's because FC6 had things not in RHEL4 maybe we can make a switch to RHEL5 at some point. If the reason is we want the flexibility of moving to the latest code along with Fedora instead of waiting for RHEL to upgrade/backport then perhaps they should be on the latest Fedora where the latest code is more likely to land sooner.
In the case of the app servers running TurboGears, I think that it was a lack of TG requirements on RHEL4 that held us back. I also think we're close to having TG for RHEL5 so we might want to move test servers to RHEL5, check that the applications run there, and then move the app servers handling those to RHEL.
This is very true as well, I've not tested the TG status in RHEL5. Has anyone else? Luke?
-Mike
On Thu, Jun 07, 2007 at 12:19:01PM -0500, Mike McGrath wrote:
Toshio Kuratomi wrote:
Depends...
What is the reason for those boxes to be on Fedora instead of RHEL? If it's because FC6 had things not in RHEL4 maybe we can make a switch to RHEL5 at some point. If the reason is we want the flexibility of moving to the latest code along with Fedora instead of waiting for RHEL to upgrade/backport then perhaps they should be on the latest Fedora where the latest code is more likely to land sooner.
In the case of the app servers running TurboGears, I think that it was a lack of TG requirements on RHEL4 that held us back. I also think we're close to having TG for RHEL5 so we might want to move test servers to RHEL5, check that the applications run there, and then move the app servers handling those to RHEL.
This is very true as well, I've not tested the TG status in RHEL5. Has anyone else? Luke?
Looks like we're just waiting on python-kid[0].
luke
[0]: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239134
Would'nt it be a good idea to make respins of the fedora core 7 for internal use. Like For app servers we can have a permanent set of features and for test servers we can have another. there will be too many respins but it will make it easier later on in the future when we can just upgrade a respin to newer versions. That way we can avoid RHEL as such and run Fedora on all systems. I dont know but i seem to prefer Fedora over RHEL. There might still be some packages that are proprietary.... that will be the only problem faced is it not..... just a suggestion
Jose M manimala
On Saturday 09 June 2007 02:48:05 jose manimala wrote:
Would'nt it be a good idea to make respins of the fedora core 7 for internal use. Like For app servers we can have a permanent set of features and for test servers we can have another. there will be too many respins but it will make it easier later on in the future when we can just upgrade a respin to newer versions. That way we can avoid RHEL as such and run Fedora on all systems. I dont know but i seem to prefer Fedora over RHEL. There might still be some packages that are proprietary.... that will be the only problem faced is it not..... just a suggestion
Respins aren't really that useful in this context. We can easily choose what we want to install, and we can easily apply the updates either during or after install. A respin won't help us in these manners. What we don't like about Fedora is there is not really any attempt to keep a non abi changing platform, the updates are fast and loose, and the distribution releases get flushed quickly.
Fedora is great for short term or developmental servers, whereas RHEL/CentOS is far more suited for long term production environments.
I agree with Jesse. We should keep to a more stable platform with fewer updates for production servers. As far as eating our own dog food. I think this is also necessary in order to ensure that we are familiar with the same sort of problems that our users face. The happy medium here might be run Fedora 7 in a virtual machine and have that available when we want to test a feature/service for that OS, but ensure that domain 0 is run by RHEL/CentOS. Just my 2 cents. :)
On 6/9/07, Jesse Keating jkeating@redhat.com wrote:
On Saturday 09 June 2007 02:48:05 jose manimala wrote:
Would'nt it be a good idea to make respins of the fedora core 7 for internal use. Like For app servers we can have a permanent set of features and for test servers we can have another. there will be too many respins but it will make it easier later on in the future when we can just upgrade a respin to newer versions. That way we can avoid RHEL as such and run Fedora on all systems. I dont know but i seem to prefer Fedora over RHEL. There might still be some packages that are proprietary.... that will be the only problem faced is it not..... just a suggestion
Respins aren't really that useful in this context. We can easily choose what we want to install, and we can easily apply the updates either during or after install. A respin won't help us in these manners. What we don't like about Fedora is there is not really any attempt to keep a non abi changing platform, the updates are fast and loose, and the distribution releases get flushed quickly.
Fedora is great for short term or developmental servers, whereas RHEL/CentOS is far more suited for long term production environments.
-- Jesse Keating Release Engineer: Fedora
Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Freddie Rosario wrote:
I agree with Jesse. We should keep to a more stable platform with fewer updates for production servers. As far as eating our own dog food. I think this is also necessary in order to ensure that we are familiar with the same sort of problems that our users face. The happy medium here might be run Fedora 7 in a virtual machine and have that available when we want to test a feature/service for that OS, but ensure that domain 0 is run by RHEL/CentOS. Just my 2 cents. :)
we really can't blanket say "RHEL" "CentOS" or "Fedora". We have to take each task off of its own merit. Though, in general, for most of our Web Apps, RHEL does a great job (for now) though I suspect in a year and a half we'll have a lot more Fedora as RHEL gets longer in the tooth :)
-Mike
On Saturday 09 June 2007 15:47:39 Mike McGrath wrote:
we really can't blanket say "RHEL" "CentOS" or "Fedora". We have to take each task off of its own merit. Though, in general, for most of our Web Apps, RHEL does a great job (for now) though I suspect in a year and a half we'll have a lot more Fedora as RHEL gets longer in the tooth :)
+1
Toshio Kuratomi (a.badger@gmail.com) said:
Depends...
What is the reason for those boxes to be on Fedora instead of RHEL?
For the mash/bodhi box, it's because it requires yum-3.2.x and current createrepo. At the moment it's running them recompiled for FC6, and, well, I'd rather not do that long term (or do that on RHEL.)
Bill
infrastructure@lists.fedoraproject.org
-
Bill Nottingham -
Freddie Rosario -
Jesse Keating -
John Poelstra -
Jose Manimala -
Luke Macken -
Mike McGrath -
Paulo Santos -
Toshio Kuratomi