Hi everyone,
I was planning on making a new release of pagure today, not realizing that we were entering freeze.
I would like to hear more opinions about pushing this release, here is the current changelog: - Include the tags in the JSON representation of a project - Add the ability to open a pull-request from a git repo not hosted on pagure - Fix pagination when browsing the list of commits - Fix the fork button when viewing the Settings of a project - Adjust the example apache configuration file - Add a favicon with pagure's logo - Fix asynchronous commentting on pull-requests - Start working on some documentation on how to install pagure - Do no flash messages when a comment is submitted via javascript (ie: async) - Do not blink the tittle of the page if the page is already on focus - Retrieve ssh key from FAS and set it up in pagure if none is currently set-up
The remote PR needs a small DB change, everything else is pretty much bug fixes or minor improvements.
Thoughts?
Thanks, Pierre
In doing something like this we would need to know what the impact is. What parts of production of an Alpha would be down during the upgrade? I think there things releng has in pagure but I don't know if those would make any release parts impossible if it was down for 2-3 hours.
If there are no impacts on production then it isn't covered by a freeze. If there are few impacts on production then a freeze break request can be granted. If there are many impacts on production then FBR probably won't be granted unless not doing so makes things worse.
On 29 July 2015 at 05:06, Pierre-Yves Chibon pingou@pingoured.fr wrote:
Hi everyone,
I was planning on making a new release of pagure today, not realizing that we were entering freeze.
I would like to hear more opinions about pushing this release, here is the current changelog:
- Include the tags in the JSON representation of a project
- Add the ability to open a pull-request from a git repo not hosted on pagure
- Fix pagination when browsing the list of commits
- Fix the fork button when viewing the Settings of a project
- Adjust the example apache configuration file
- Add a favicon with pagure's logo
- Fix asynchronous commentting on pull-requests
- Start working on some documentation on how to install pagure
- Do no flash messages when a comment is submitted via javascript (ie: async)
- Do not blink the tittle of the page if the page is already on focus
- Retrieve ssh key from FAS and set it up in pagure if none is currently set-up
The remote PR needs a small DB change, everything else is pretty much bug fixes or minor improvements.
Thoughts?
Thanks, Pierre
infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
On Wed, Jul 29, 2015 at 07:31:15AM -0600, Stephen John Smoogen wrote:
In doing something like this we would need to know what the impact is. What parts of production of an Alpha would be down during the upgrade? I think there things releng has in pagure but I don't know if those would make any release parts impossible if it was down for 2-3 hours.
That is also something I don't know, git access will remain available (via ssh always, via http most of the time (except when I restart apache)). The update only influences the web-UI part, not gitolite in anyway.
Not knowing how rel-eng relies on pagure I can't estimate the impact. I can however estimate the down-time to be very short (in the order of the 10s of minutes), it's updating the package, calling alembic to upgrade the database and restart apache.
Pierre
If there are no impacts on production then it isn't covered by a freeze. If there are few impacts on production then a freeze break request can be granted. If there are many impacts on production then FBR probably won't be granted unless not doing so makes things worse.
On 29 July 2015 at 05:06, Pierre-Yves Chibon pingou@pingoured.fr wrote:
Hi everyone,
I was planning on making a new release of pagure today, not realizing that we were entering freeze.
I would like to hear more opinions about pushing this release, here is the current changelog:
- Include the tags in the JSON representation of a project
- Add the ability to open a pull-request from a git repo not hosted on pagure
- Fix pagination when browsing the list of commits
- Fix the fork button when viewing the Settings of a project
- Adjust the example apache configuration file
- Add a favicon with pagure's logo
- Fix asynchronous commentting on pull-requests
- Start working on some documentation on how to install pagure
- Do no flash messages when a comment is submitted via javascript (ie: async)
- Do not blink the tittle of the page if the page is already on focus
- Retrieve ssh key from FAS and set it up in pagure if none is currently set-up
The remote PR needs a small DB change, everything else is pretty much bug fixes or minor improvements.
Thoughts?
Thanks, Pierre
infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
-- Stephen J Smoogen. _______________________________________________ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
On 29 July 2015 at 07:54, Pierre-Yves Chibon pingou@pingoured.fr wrote:
On Wed, Jul 29, 2015 at 07:31:15AM -0600, Stephen John Smoogen wrote:
In doing something like this we would need to know what the impact is. What parts of production of an Alpha would be down during the upgrade? I think there things releng has in pagure but I don't know if those would make any release parts impossible if it was down for 2-3 hours.
That is also something I don't know, git access will remain available (via ssh always, via http most of the time (except when I restart apache)). The update only influences the web-UI part, not gitolite in anyway.
Not knowing how rel-eng relies on pagure I can't estimate the impact. I can however estimate the down-time to be very short (in the order of the 10s of minutes), it's updating the package, calling alembic to upgrade the database and restart apache.
I would ping dgilmore/pbrobinson then to get their take on it.. but it does sound like this falls into the second category since the main service used gitolite is not affected.
On Wed, 29 Jul 2015 07:58:57 -0600 Stephen John Smoogen smooge@gmail.com wrote:
On 29 July 2015 at 07:54, Pierre-Yves Chibon pingou@pingoured.fr wrote:
On Wed, Jul 29, 2015 at 07:31:15AM -0600, Stephen John Smoogen wrote:
In doing something like this we would need to know what the impact is. What parts of production of an Alpha would be down during the upgrade? I think there things releng has in pagure but I don't know if those would make any release parts impossible if it was down for 2-3 hours.
That is also something I don't know, git access will remain available (via ssh always, via http most of the time (except when I restart apache)). The update only influences the web-UI part, not gitolite in anyway.
The dependency here is two things:
1) buildrawhide and buildbranched scripts are pulled from there now each day when their cron job runs. If things are down, they would fail. However, this is just a few minutes around the time the cron jobs run, so as long as those are avoided that should be fine.
2) releng uses pagure.io now for a bunch of things. If we needed a change to build fedora 23 and pagure was down it would affect things, but that would need to be a lengthy downtime (like days/weeks). I can't imagine an upgrade causing that, especially since we have backups and could just restore from them in a matter of hours.
Anyhow, I am +1 to this. We should be able to backout if it causes a big problem (change db back and downgrade rpm).
kevin
OK with that information I am +1 also.
On 29 July 2015 at 08:46, Kevin Fenzi kevin@scrye.com wrote:
On Wed, 29 Jul 2015 07:58:57 -0600 Stephen John Smoogen smooge@gmail.com wrote:
On 29 July 2015 at 07:54, Pierre-Yves Chibon pingou@pingoured.fr wrote:
On Wed, Jul 29, 2015 at 07:31:15AM -0600, Stephen John Smoogen wrote:
In doing something like this we would need to know what the impact is. What parts of production of an Alpha would be down during the upgrade? I think there things releng has in pagure but I don't know if those would make any release parts impossible if it was down for 2-3 hours.
That is also something I don't know, git access will remain available (via ssh always, via http most of the time (except when I restart apache)). The update only influences the web-UI part, not gitolite in anyway.
The dependency here is two things:
- buildrawhide and buildbranched scripts are pulled from there now
each day when their cron job runs. If things are down, they would fail. However, this is just a few minutes around the time the cron jobs run, so as long as those are avoided that should be fine.
- releng uses pagure.io now for a bunch of things. If we needed a
change to build fedora 23 and pagure was down it would affect things, but that would need to be a lengthy downtime (like days/weeks). I can't imagine an upgrade causing that, especially since we have backups and could just restore from them in a matter of hours.
Anyhow, I am +1 to this. We should be able to backout if it causes a big problem (change db back and downgrade rpm).
kevin
infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
On Wed, Jul 29, 2015 at 08:46:43AM -0600, Kevin Fenzi wrote:
On Wed, 29 Jul 2015 07:58:57 -0600 Stephen John Smoogen smooge@gmail.com wrote:
On 29 July 2015 at 07:54, Pierre-Yves Chibon pingou@pingoured.fr wrote:
On Wed, Jul 29, 2015 at 07:31:15AM -0600, Stephen John Smoogen wrote:
In doing something like this we would need to know what the impact is. What parts of production of an Alpha would be down during the upgrade? I think there things releng has in pagure but I don't know if those would make any release parts impossible if it was down for 2-3 hours.
That is also something I don't know, git access will remain available (via ssh always, via http most of the time (except when I restart apache)). The update only influences the web-UI part, not gitolite in anyway.
The dependency here is two things:
- buildrawhide and buildbranched scripts are pulled from there now
each day when their cron job runs. If things are down, they would fail. However, this is just a few minutes around the time the cron jobs run, so as long as those are avoided that should be fine.
Do you know when these cron jobs are running? Just to be sure I don't run into Murphy :)
Thanks, Pierre
On Wed, 29 Jul 2015 18:06:22 +0200 Pierre-Yves Chibon pingou@pingoured.fr wrote:
Do you know when these cron jobs are running? Just to be sure I don't run into Murphy :)
05:15 UTC for rawhide 07:15 UTC for branched.
kevin
On Wed, Jul 29, 2015 at 08:46:43AM -0600, Kevin Fenzi wrote:
On Wed, 29 Jul 2015 07:58:57 -0600 Stephen John Smoogen smooge@gmail.com wrote:
On 29 July 2015 at 07:54, Pierre-Yves Chibon pingou@pingoured.fr wrote:
On Wed, Jul 29, 2015 at 07:31:15AM -0600, Stephen John Smoogen wrote:
In doing something like this we would need to know what the impact is. What parts of production of an Alpha would be down during the upgrade? I think there things releng has in pagure but I don't know if those would make any release parts impossible if it was down for 2-3 hours.
That is also something I don't know, git access will remain available (via ssh always, via http most of the time (except when I restart apache)). The update only influences the web-UI part, not gitolite in anyway.
The dependency here is two things:
- buildrawhide and buildbranched scripts are pulled from there now
each day when their cron job runs. If things are down, they would fail. However, this is just a few minutes around the time the cron jobs run, so as long as those are avoided that should be fine.
- releng uses pagure.io now for a bunch of things. If we needed a
change to build fedora 23 and pagure was down it would affect things, but that would need to be a lengthy downtime (like days/weeks). I can't imagine an upgrade causing that, especially since we have backups and could just restore from them in a matter of hours.
Anyhow, I am +1 to this. We should be able to backout if it causes a big problem (change db back and downgrade rpm).
I have added 2 bug fixes: - Fix the anchors for the comments of a pull-request - Fix internal server error when someone not logged in sees PR
I will cut the release and push it to stg where we can test and ensure it's all running fine.
Pierre
On Wed, 2015-07-29 at 15:54 +0200, Pierre-Yves Chibon wrote:
On Wed, Jul 29, 2015 at 07:31:15AM -0600, Stephen John Smoogen wrote:
In doing something like this we would need to know what the impact is. What parts of production of an Alpha would be down during the upgrade? I think there things releng has in pagure but I don't know if those would make any release parts impossible if it was down for 2-3 hours.
That is also something I don't know, git access will remain available (via ssh always, via http most of the time (except when I restart apache)).
Unrelated to this freeze request, but I'm curious: what happens if you restart apache right in the middle of someone pushing over http?
On Wed, Jul 29, 2015 at 04:07:46PM +0200, Mathieu Bridon wrote:
On Wed, 2015-07-29 at 15:54 +0200, Pierre-Yves Chibon wrote:
On Wed, Jul 29, 2015 at 07:31:15AM -0600, Stephen John Smoogen wrote:
In doing something like this we would need to know what the impact is. What parts of production of an Alpha would be down during the upgrade? I think there things releng has in pagure but I don't know if those would make any release parts impossible if it was down for 2-3 hours.
That is also something I don't know, git access will remain available (via ssh always, via http most of the time (except when I restart apache)).
Unrelated to this freeze request, but I'm curious: what happens if you restart apache right in the middle of someone pushing over http?
My first reaction was like: no clue, but in fact I have a 2 parts answer: a/ we do not support push over http, only clone, pull and fetch b/ apache on RHEL7 has this tendency to wait for all the connection to close before actually doing the restart. This is really quite annoying sometime but might save us this time.
Pierre
infrastructure@lists.fedoraproject.org