So one of the things moving from EPEL to RHEL in EL-6 is the TurboGears 2 stack. We recently had TG-2.1 pushed into EPEL-5 testing. this is newer than what is in EL-6. TG-2.1 broke a couple of things in Moksha(community) because its using internal api's that changed, the public api is stable. but it brings up the maintenance burden for when we start migrating to EL-6 on app servers. Moksha would ethier need to work with 2.0 and 2.1? not sure if its doable. or the version for EL-6 will need to use the old api. or something else ive not mentioned/thought of.
another option is replace the TG stack. which then means for the life of us using EL-6 we will need to maintain the TG stack in the infra repo and any packages we use on top of it. it also means we cant put TG apps into EPEL-6 since they wont work.
alternatively we could use some fedora app servers where we can put everything into fedora. maintain an updated stack in fedora, but have the additional cost of greater maintenance needed for the fedora based servers.
I don't have the answer but we need to start the discussion now so that we have a plan and dont get blindsided by this.
Dennis
On Tue, 8 Jun 2010, Dennis Gilmore wrote:
So one of the things moving from EPEL to RHEL in EL-6 is the TurboGears 2 stack. We recently had TG-2.1 pushed into EPEL-5 testing. this is newer than what is in EL-6. TG-2.1 broke a couple of things in Moksha(community) because its using internal api's that changed, the public api is stable. but it brings up the maintenance burden for when we start migrating to EL-6 on app servers. Moksha would ethier need to work with 2.0 and 2.1? not sure if its doable. or the version for EL-6 will need to use the old api. or something else ive not mentioned/thought of.
FWIW, when I tested 2.1 with virt_web (it was written against 2.0) so I suspect the changes are small.
another option is replace the TG stack. which then means for the life of us using EL-6 we will need to maintain the TG stack in the infra repo and any packages we use on top of it. it also means we cant put TG apps into EPEL-6 since they wont work.
alternatively we could use some fedora app servers where we can put everything into fedora. maintain an updated stack in fedora, but have the additional cost of greater maintenance needed for the fedora based servers.
I don't have the answer but we need to start the discussion now so that we have a plan and dont get blindsided by this.
Also right now we only have one tg2 app/stack deployed in community. It exists fine with the 1.x tree. Luke's already got a working moksha with 2.1 so I think keeping our apps in line will be pretty easy, the bigger question is what will ship with RHEL. if they do ship 2.0, will EPEL allow a 2.1 fork or will we have to run our own? Will it not matter? I think I have more questions then answers on that but yeah thanks for getting the conversation started.
-Mike
On Tue, Jun 08, 2010 at 02:13:22PM -0500, Mike McGrath wrote:
On Tue, 8 Jun 2010, Dennis Gilmore wrote:
So one of the things moving from EPEL to RHEL in EL-6 is the TurboGears 2 stack. We recently had TG-2.1 pushed into EPEL-5 testing. this is newer than what is in EL-6. TG-2.1 broke a couple of things in Moksha(community) because its using internal api's that changed, the public api is stable. but it brings up the maintenance burden for when we start migrating to EL-6 on app servers. Moksha would ethier need to work with 2.0 and 2.1? not sure if its doable. or the version for EL-6 will need to use the old api. or something else ive not mentioned/thought of.
FWIW, when I tested 2.1 with virt_web (it was written against 2.0) so I suspect the changes are small.
another option is replace the TG stack. which then means for the life of us using EL-6 we will need to maintain the TG stack in the infra repo and any packages we use on top of it. it also means we cant put TG apps into EPEL-6 since they wont work.
alternatively we could use some fedora app servers where we can put everything into fedora. maintain an updated stack in fedora, but have the additional cost of greater maintenance needed for the fedora based servers.
I don't have the answer but we need to start the discussion now so that we have a plan and dont get blindsided by this.
Also right now we only have one tg2 app/stack deployed in community. It exists fine with the 1.x tree. Luke's already got a working moksha with 2.1 so I think keeping our apps in line will be pretty easy, the bigger question is what will ship with RHEL. if they do ship 2.0, will EPEL allow a 2.1 fork or will we have to run our own? Will it not matter? I think I have more questions then answers on that but yeah thanks for getting the conversation started.
Just judging by the way the infrastructure repo has grown over the course of RHEL5, I think that it's inevitable that we eventually roll our own version of tings that we are developing against. However, for the sake of reducing the maintainance burden we carry, I think it would be great if we could defer this for as long as possible.
In TG2 vs TG2.1's case, most of the improvements seem to be speed. If we aren't having problems keeping up with the number of requests, perhaps we want to wait to switch to TG-2.1 on the app servers. Luke, does that sound right for now?
-Toshio
On Wed, 2010-06-09 at 12:22 -0400, Toshio Kuratomi wrote:
On Tue, Jun 08, 2010 at 02:13:22PM -0500, Mike McGrath wrote:
On Tue, 8 Jun 2010, Dennis Gilmore wrote:
So one of the things moving from EPEL to RHEL in EL-6 is the TurboGears 2 stack. We recently had TG-2.1 pushed into EPEL-5 testing. this is newer than what is in EL-6. TG-2.1 broke a couple of things in Moksha(community) because its using internal api's that changed, the public api is stable. but it brings up the maintenance burden for when we start migrating to EL-6 on app servers. Moksha would ethier need to work with 2.0 and 2.1? not sure if its doable. or the version for EL-6 will need to use the old api. or something else ive not mentioned/thought of.
FWIW, when I tested 2.1 with virt_web (it was written against 2.0) so I suspect the changes are small.
another option is replace the TG stack. which then means for the life of us using EL-6 we will need to maintain the TG stack in the infra repo and any packages we use on top of it. it also means we cant put TG apps into EPEL-6 since they wont work.
alternatively we could use some fedora app servers where we can put everything into fedora. maintain an updated stack in fedora, but have the additional cost of greater maintenance needed for the fedora based servers.
I don't have the answer but we need to start the discussion now so that we have a plan and dont get blindsided by this.
Also right now we only have one tg2 app/stack deployed in community. It exists fine with the 1.x tree. Luke's already got a working moksha with 2.1 so I think keeping our apps in line will be pretty easy, the bigger question is what will ship with RHEL. if they do ship 2.0, will EPEL allow a 2.1 fork or will we have to run our own? Will it not matter? I think I have more questions then answers on that but yeah thanks for getting the conversation started.
Just judging by the way the infrastructure repo has grown over the course of RHEL5, I think that it's inevitable that we eventually roll our own version of tings that we are developing against. However, for the sake of reducing the maintainance burden we carry, I think it would be great if we could defer this for as long as possible.
In TG2 vs TG2.1's case, most of the improvements seem to be speed. If we aren't having problems keeping up with the number of requests, perhaps we want to wait to switch to TG-2.1 on the app servers. Luke, does that sound right for now?
Speed, and a lot of bugfixes.
http://trac.turbogears.org/wiki/2.0/ChangeLog
Also, TG2.1, which is in EL-5 testing, is already on our app servers as of yesterday. If we need to pull 2.1 out of EL-5, we'll want to downgrade.
luke
On Wed, Jun 09, 2010 at 01:54:13PM -0400, Luke Macken wrote:
On Wed, 2010-06-09 at 12:22 -0400, Toshio Kuratomi wrote:
Just judging by the way the infrastructure repo has grown over the course of RHEL5, I think that it's inevitable that we eventually roll our own version of tings that we are developing against. However, for the sake of reducing the maintainance burden we carry, I think it would be great if we could defer this for as long as possible.
In TG2 vs TG2.1's case, most of the improvements seem to be speed. If we aren't having problems keeping up with the number of requests, perhaps we want to wait to switch to TG-2.1 on the app servers. Luke, does that sound right for now?
Speed, and a lot of bugfixes.
http://trac.turbogears.org/wiki/2.0/ChangeLog
Since there's a lot of bugfixes, it seems likely that we'll just have to suck it up and maintain our own copy in the infrastructure repo
Also, TG2.1, which is in EL-5 testing, is already on our app servers as of yesterday. If we need to pull 2.1 out of EL-5, we'll want to downgrade.
Yeah -- EPEL is somewhat of a separate issue but we (EPEL) may not want to have EPEL-5 at a higher evr than RHEL-6 when we can help it. I don't know that there's actually a policy on this, though. I'll ask around on #epel.
-Toshio
On Wed, Jun 09, 2010 at 02:44:00PM -0400, Toshio Kuratomi wrote:
On Wed, Jun 09, 2010 at 01:54:13PM -0400, Luke Macken wrote:
Also, TG2.1, which is in EL-5 testing, is already on our app servers as of yesterday. If we need to pull 2.1 out of EL-5, we'll want to downgrade.
Yeah -- EPEL is somewhat of a separate issue but we (EPEL) may not want to have EPEL-5 at a higher evr than RHEL-6 when we can help it. I don't know that there's actually a policy on this, though. I'll ask around on #epel.
Sounds like people usually need to reinstall between RHEL major releases, upgrades are not possible. So we can have versions go backwards if we want to. From that standpoint, EL-5 can go to a higher version than what's in base RHEL-6.
Whether the internal API was widely enough used by third parties to warrant not pushing to EPEL I don't know. Sounds like the template API changes, at least, would be esoteric enough to not affect too many people. (Unless, people writing their own connectors between templating languages and TG2 depend on those internal APIs.)
-Toshio
infrastructure@lists.fedoraproject.org