You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bigtop.apache.org by "Bruno Mahé (Created JIRA)" <ji...@apache.org> on 2012/01/25 22:08:38 UTC
[jira] [Created] (BIGTOP-367) Upgrade sequencing issue
Upgrade sequencing issue
------------------------
Key: BIGTOP-367
URL: https://issues.apache.org/jira/browse/BIGTOP-367
Project: Bigtop
Issue Type: Bug
Components: Debian, RPM
Affects Versions: 0.2.0, 0.3.0
Reporter: Bruno Mahé
There is an issue regarding the way services are condrestart after an upgrade.
To illustrate this issue, here is an upgrade sequence extracted from a very verbose rpm upgrade session of hadoop and hadoop-jobtacker:
{noformat}
%pre(hadoop-X)
installation of hadoop-X files
%post(hadoop-X)
%pre(hadoop-jobtracker-X)
install of hadoop-jobtracker-X files
%post(hadoop-jobtracker-X)
%preun(hadoop-jobtracker-X-1)
removal of hadoop-jobtracker-X-1 files
%postun(hadoop-jobtracker-X-1) => jobtracker service is restarted
%preun(hadoop-X-1)
removal of hadoop-X-1 files
%postun(hadoop-X-1)
{noformat}
So when the jobtracker is condrestart, both jars hod hadoop X and X-1 are presents. And if the jars have different versions, because of the way hadoop script pick up jars, the older version will be picked up first. There may also be other issues.
But this defeat the purpose of doing a condrestart.
I am not sure yet how to go about this issue, but here are some ideas:
* We don't deal with it. Bigtop stable releases only deal with bugfixes and we don't support upgrade between major Bigtop versions. Since there wouldn't be any bump in the jars' versions, this issue would not happen
* We stop doing condrestart on upgrade
* We push back the init scripts in their main package. But then, doing a chkconfig on install/upgrade may be a bad idea
* Do an ugly hack by moving the %postun of the service packages directly to the main package (with a if [ -x] around it for each service)
All ideas are welcome!
Note: I took hadoop as an example, but it can happen to any of our package which also provide a service
PS: This issue may need also to be confirmed on ubuntu/debian. I am not sure how the upgrade process is sequenced
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (BIGTOP-367) Upgrade sequencing issue
Posted by "Roman Shaposhnik (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BIGTOP-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Roman Shaposhnik updated BIGTOP-367:
------------------------------------
Fix Version/s: 0.4.0
0.3.0
> Upgrade sequencing issue
> ------------------------
>
> Key: BIGTOP-367
> URL: https://issues.apache.org/jira/browse/BIGTOP-367
> Project: Bigtop
> Issue Type: Bug
> Components: Debian, RPM
> Affects Versions: 0.2.0, 0.3.0
> Reporter: Bruno Mahé
> Assignee: Bruno Mahé
> Fix For: 0.3.0, 0.4.0
>
> Attachments: BIGTOP-367.patch
>
>
> There is an issue regarding the way services are condrestart after an upgrade.
> To illustrate this issue, here is an upgrade sequence extracted from a very verbose rpm upgrade session of hadoop and hadoop-jobtacker:
> {noformat}
> %pre(hadoop-X)
> installation of hadoop-X files
> %post(hadoop-X)
> %pre(hadoop-jobtracker-X)
> install of hadoop-jobtracker-X files
> %post(hadoop-jobtracker-X)
> %preun(hadoop-jobtracker-X-1)
> removal of hadoop-jobtracker-X-1 files
> %postun(hadoop-jobtracker-X-1) => jobtracker service is restarted
> %preun(hadoop-X-1)
> removal of hadoop-X-1 files
> %postun(hadoop-X-1)
> {noformat}
> So when the jobtracker is condrestart, both jars of hadoop X and X-1 are presents. And if the jars have different versions, because of the way hadoop script pick up jars, the older version will be picked up first. There may also be other issues.
> But this defeat the purpose of doing a condrestart.
> I am not sure yet how to go about this issue, but here are some ideas:
> * We don't deal with it. Bigtop stable releases only deal with bugfixes and we don't support upgrade between major Bigtop versions. Since there wouldn't be any bump in the jars' versions, this issue would not happen
> * We stop doing condrestart on upgrade
> * We push back the init scripts in their main package. But then, doing a chkconfig on install/upgrade may be a bad idea
> * Do an ugly hack by moving the %postun of the service packages directly to the main package (with a if [ -x] around it for each service)
> All ideas are welcome!
> Note: I took hadoop as an example, but it can happen to any of our package which also provide a service
> PS: This issue may need also to be confirmed on ubuntu/debian. I am not sure how the upgrade process is sequenced
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (BIGTOP-367) Upgrade sequencing issue
Posted by "Bruno Mahé (Updated JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BIGTOP-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bruno Mahé updated BIGTOP-367:
------------------------------
Description:
There is an issue regarding the way services are condrestart after an upgrade.
To illustrate this issue, here is an upgrade sequence extracted from a very verbose rpm upgrade session of hadoop and hadoop-jobtacker:
{noformat}
%pre(hadoop-X)
installation of hadoop-X files
%post(hadoop-X)
%pre(hadoop-jobtracker-X)
install of hadoop-jobtracker-X files
%post(hadoop-jobtracker-X)
%preun(hadoop-jobtracker-X-1)
removal of hadoop-jobtracker-X-1 files
%postun(hadoop-jobtracker-X-1) => jobtracker service is restarted
%preun(hadoop-X-1)
removal of hadoop-X-1 files
%postun(hadoop-X-1)
{noformat}
So when the jobtracker is condrestart, both jars of hadoop X and X-1 are presents. And if the jars have different versions, because of the way hadoop script pick up jars, the older version will be picked up first. There may also be other issues.
But this defeat the purpose of doing a condrestart.
I am not sure yet how to go about this issue, but here are some ideas:
* We don't deal with it. Bigtop stable releases only deal with bugfixes and we don't support upgrade between major Bigtop versions. Since there wouldn't be any bump in the jars' versions, this issue would not happen
* We stop doing condrestart on upgrade
* We push back the init scripts in their main package. But then, doing a chkconfig on install/upgrade may be a bad idea
* Do an ugly hack by moving the %postun of the service packages directly to the main package (with a if [ -x] around it for each service)
All ideas are welcome!
Note: I took hadoop as an example, but it can happen to any of our package which also provide a service
PS: This issue may need also to be confirmed on ubuntu/debian. I am not sure how the upgrade process is sequenced
was:
There is an issue regarding the way services are condrestart after an upgrade.
To illustrate this issue, here is an upgrade sequence extracted from a very verbose rpm upgrade session of hadoop and hadoop-jobtacker:
{noformat}
%pre(hadoop-X)
installation of hadoop-X files
%post(hadoop-X)
%pre(hadoop-jobtracker-X)
install of hadoop-jobtracker-X files
%post(hadoop-jobtracker-X)
%preun(hadoop-jobtracker-X-1)
removal of hadoop-jobtracker-X-1 files
%postun(hadoop-jobtracker-X-1) => jobtracker service is restarted
%preun(hadoop-X-1)
removal of hadoop-X-1 files
%postun(hadoop-X-1)
{noformat}
So when the jobtracker is condrestart, both jars hod hadoop X and X-1 are presents. And if the jars have different versions, because of the way hadoop script pick up jars, the older version will be picked up first. There may also be other issues.
But this defeat the purpose of doing a condrestart.
I am not sure yet how to go about this issue, but here are some ideas:
* We don't deal with it. Bigtop stable releases only deal with bugfixes and we don't support upgrade between major Bigtop versions. Since there wouldn't be any bump in the jars' versions, this issue would not happen
* We stop doing condrestart on upgrade
* We push back the init scripts in their main package. But then, doing a chkconfig on install/upgrade may be a bad idea
* Do an ugly hack by moving the %postun of the service packages directly to the main package (with a if [ -x] around it for each service)
All ideas are welcome!
Note: I took hadoop as an example, but it can happen to any of our package which also provide a service
PS: This issue may need also to be confirmed on ubuntu/debian. I am not sure how the upgrade process is sequenced
> Upgrade sequencing issue
> ------------------------
>
> Key: BIGTOP-367
> URL: https://issues.apache.org/jira/browse/BIGTOP-367
> Project: Bigtop
> Issue Type: Bug
> Components: Debian, RPM
> Affects Versions: 0.2.0, 0.3.0
> Reporter: Bruno Mahé
>
> There is an issue regarding the way services are condrestart after an upgrade.
> To illustrate this issue, here is an upgrade sequence extracted from a very verbose rpm upgrade session of hadoop and hadoop-jobtacker:
> {noformat}
> %pre(hadoop-X)
> installation of hadoop-X files
> %post(hadoop-X)
> %pre(hadoop-jobtracker-X)
> install of hadoop-jobtracker-X files
> %post(hadoop-jobtracker-X)
> %preun(hadoop-jobtracker-X-1)
> removal of hadoop-jobtracker-X-1 files
> %postun(hadoop-jobtracker-X-1) => jobtracker service is restarted
> %preun(hadoop-X-1)
> removal of hadoop-X-1 files
> %postun(hadoop-X-1)
> {noformat}
> So when the jobtracker is condrestart, both jars of hadoop X and X-1 are presents. And if the jars have different versions, because of the way hadoop script pick up jars, the older version will be picked up first. There may also be other issues.
> But this defeat the purpose of doing a condrestart.
> I am not sure yet how to go about this issue, but here are some ideas:
> * We don't deal with it. Bigtop stable releases only deal with bugfixes and we don't support upgrade between major Bigtop versions. Since there wouldn't be any bump in the jars' versions, this issue would not happen
> * We stop doing condrestart on upgrade
> * We push back the init scripts in their main package. But then, doing a chkconfig on install/upgrade may be a bad idea
> * Do an ugly hack by moving the %postun of the service packages directly to the main package (with a if [ -x] around it for each service)
> All ideas are welcome!
> Note: I took hadoop as an example, but it can happen to any of our package which also provide a service
> PS: This issue may need also to be confirmed on ubuntu/debian. I am not sure how the upgrade process is sequenced
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (BIGTOP-367) Upgrade sequencing issue
Posted by "Bruno Mahé (Assigned JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BIGTOP-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bruno Mahé reassigned BIGTOP-367:
---------------------------------
Assignee: Bruno Mahé
> Upgrade sequencing issue
> ------------------------
>
> Key: BIGTOP-367
> URL: https://issues.apache.org/jira/browse/BIGTOP-367
> Project: Bigtop
> Issue Type: Bug
> Components: Debian, RPM
> Affects Versions: 0.2.0, 0.3.0
> Reporter: Bruno Mahé
> Assignee: Bruno Mahé
> Attachments: BIGTOP-367.patch
>
>
> There is an issue regarding the way services are condrestart after an upgrade.
> To illustrate this issue, here is an upgrade sequence extracted from a very verbose rpm upgrade session of hadoop and hadoop-jobtacker:
> {noformat}
> %pre(hadoop-X)
> installation of hadoop-X files
> %post(hadoop-X)
> %pre(hadoop-jobtracker-X)
> install of hadoop-jobtracker-X files
> %post(hadoop-jobtracker-X)
> %preun(hadoop-jobtracker-X-1)
> removal of hadoop-jobtracker-X-1 files
> %postun(hadoop-jobtracker-X-1) => jobtracker service is restarted
> %preun(hadoop-X-1)
> removal of hadoop-X-1 files
> %postun(hadoop-X-1)
> {noformat}
> So when the jobtracker is condrestart, both jars of hadoop X and X-1 are presents. And if the jars have different versions, because of the way hadoop script pick up jars, the older version will be picked up first. There may also be other issues.
> But this defeat the purpose of doing a condrestart.
> I am not sure yet how to go about this issue, but here are some ideas:
> * We don't deal with it. Bigtop stable releases only deal with bugfixes and we don't support upgrade between major Bigtop versions. Since there wouldn't be any bump in the jars' versions, this issue would not happen
> * We stop doing condrestart on upgrade
> * We push back the init scripts in their main package. But then, doing a chkconfig on install/upgrade may be a bad idea
> * Do an ugly hack by moving the %postun of the service packages directly to the main package (with a if [ -x] around it for each service)
> All ideas are welcome!
> Note: I took hadoop as an example, but it can happen to any of our package which also provide a service
> PS: This issue may need also to be confirmed on ubuntu/debian. I am not sure how the upgrade process is sequenced
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (BIGTOP-367) Upgrade sequencing issue
Posted by "Bruno Mahé (Closed JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BIGTOP-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bruno Mahé closed BIGTOP-367.
-----------------------------
> Upgrade sequencing issue
> ------------------------
>
> Key: BIGTOP-367
> URL: https://issues.apache.org/jira/browse/BIGTOP-367
> Project: Bigtop
> Issue Type: Bug
> Components: Debian, RPM
> Affects Versions: 0.2.0, 0.3.0
> Reporter: Bruno Mahé
> Assignee: Bruno Mahé
> Attachments: BIGTOP-367.patch
>
>
> There is an issue regarding the way services are condrestart after an upgrade.
> To illustrate this issue, here is an upgrade sequence extracted from a very verbose rpm upgrade session of hadoop and hadoop-jobtacker:
> {noformat}
> %pre(hadoop-X)
> installation of hadoop-X files
> %post(hadoop-X)
> %pre(hadoop-jobtracker-X)
> install of hadoop-jobtracker-X files
> %post(hadoop-jobtracker-X)
> %preun(hadoop-jobtracker-X-1)
> removal of hadoop-jobtracker-X-1 files
> %postun(hadoop-jobtracker-X-1) => jobtracker service is restarted
> %preun(hadoop-X-1)
> removal of hadoop-X-1 files
> %postun(hadoop-X-1)
> {noformat}
> So when the jobtracker is condrestart, both jars of hadoop X and X-1 are presents. And if the jars have different versions, because of the way hadoop script pick up jars, the older version will be picked up first. There may also be other issues.
> But this defeat the purpose of doing a condrestart.
> I am not sure yet how to go about this issue, but here are some ideas:
> * We don't deal with it. Bigtop stable releases only deal with bugfixes and we don't support upgrade between major Bigtop versions. Since there wouldn't be any bump in the jars' versions, this issue would not happen
> * We stop doing condrestart on upgrade
> * We push back the init scripts in their main package. But then, doing a chkconfig on install/upgrade may be a bad idea
> * Do an ugly hack by moving the %postun of the service packages directly to the main package (with a if [ -x] around it for each service)
> All ideas are welcome!
> Note: I took hadoop as an example, but it can happen to any of our package which also provide a service
> PS: This issue may need also to be confirmed on ubuntu/debian. I am not sure how the upgrade process is sequenced
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (BIGTOP-367) Upgrade sequencing issue
Posted by "Bruno Mahé (Updated JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BIGTOP-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bruno Mahé updated BIGTOP-367:
------------------------------
Attachment: BIGTOP-367.patch
Here is a patch
> Upgrade sequencing issue
> ------------------------
>
> Key: BIGTOP-367
> URL: https://issues.apache.org/jira/browse/BIGTOP-367
> Project: Bigtop
> Issue Type: Bug
> Components: Debian, RPM
> Affects Versions: 0.2.0, 0.3.0
> Reporter: Bruno Mahé
> Assignee: Bruno Mahé
> Attachments: BIGTOP-367.patch
>
>
> There is an issue regarding the way services are condrestart after an upgrade.
> To illustrate this issue, here is an upgrade sequence extracted from a very verbose rpm upgrade session of hadoop and hadoop-jobtacker:
> {noformat}
> %pre(hadoop-X)
> installation of hadoop-X files
> %post(hadoop-X)
> %pre(hadoop-jobtracker-X)
> install of hadoop-jobtracker-X files
> %post(hadoop-jobtracker-X)
> %preun(hadoop-jobtracker-X-1)
> removal of hadoop-jobtracker-X-1 files
> %postun(hadoop-jobtracker-X-1) => jobtracker service is restarted
> %preun(hadoop-X-1)
> removal of hadoop-X-1 files
> %postun(hadoop-X-1)
> {noformat}
> So when the jobtracker is condrestart, both jars of hadoop X and X-1 are presents. And if the jars have different versions, because of the way hadoop script pick up jars, the older version will be picked up first. There may also be other issues.
> But this defeat the purpose of doing a condrestart.
> I am not sure yet how to go about this issue, but here are some ideas:
> * We don't deal with it. Bigtop stable releases only deal with bugfixes and we don't support upgrade between major Bigtop versions. Since there wouldn't be any bump in the jars' versions, this issue would not happen
> * We stop doing condrestart on upgrade
> * We push back the init scripts in their main package. But then, doing a chkconfig on install/upgrade may be a bad idea
> * Do an ugly hack by moving the %postun of the service packages directly to the main package (with a if [ -x] around it for each service)
> All ideas are welcome!
> Note: I took hadoop as an example, but it can happen to any of our package which also provide a service
> PS: This issue may need also to be confirmed on ubuntu/debian. I am not sure how the upgrade process is sequenced
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (BIGTOP-367) Upgrade sequencing issue
Posted by "Bruno Mahé (Commented JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BIGTOP-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13195180#comment-13195180 ]
Bruno Mahé commented on BIGTOP-367:
-----------------------------------
I have a much better fix for it thanks to dmorgan, and a patch is on its way
> Upgrade sequencing issue
> ------------------------
>
> Key: BIGTOP-367
> URL: https://issues.apache.org/jira/browse/BIGTOP-367
> Project: Bigtop
> Issue Type: Bug
> Components: Debian, RPM
> Affects Versions: 0.2.0, 0.3.0
> Reporter: Bruno Mahé
>
> There is an issue regarding the way services are condrestart after an upgrade.
> To illustrate this issue, here is an upgrade sequence extracted from a very verbose rpm upgrade session of hadoop and hadoop-jobtacker:
> {noformat}
> %pre(hadoop-X)
> installation of hadoop-X files
> %post(hadoop-X)
> %pre(hadoop-jobtracker-X)
> install of hadoop-jobtracker-X files
> %post(hadoop-jobtracker-X)
> %preun(hadoop-jobtracker-X-1)
> removal of hadoop-jobtracker-X-1 files
> %postun(hadoop-jobtracker-X-1) => jobtracker service is restarted
> %preun(hadoop-X-1)
> removal of hadoop-X-1 files
> %postun(hadoop-X-1)
> {noformat}
> So when the jobtracker is condrestart, both jars of hadoop X and X-1 are presents. And if the jars have different versions, because of the way hadoop script pick up jars, the older version will be picked up first. There may also be other issues.
> But this defeat the purpose of doing a condrestart.
> I am not sure yet how to go about this issue, but here are some ideas:
> * We don't deal with it. Bigtop stable releases only deal with bugfixes and we don't support upgrade between major Bigtop versions. Since there wouldn't be any bump in the jars' versions, this issue would not happen
> * We stop doing condrestart on upgrade
> * We push back the init scripts in their main package. But then, doing a chkconfig on install/upgrade may be a bad idea
> * Do an ugly hack by moving the %postun of the service packages directly to the main package (with a if [ -x] around it for each service)
> All ideas are welcome!
> Note: I took hadoop as an example, but it can happen to any of our package which also provide a service
> PS: This issue may need also to be confirmed on ubuntu/debian. I am not sure how the upgrade process is sequenced
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (BIGTOP-367) Upgrade sequencing issue
Posted by "Roman Shaposhnik (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BIGTOP-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13195208#comment-13195208 ]
Roman Shaposhnik commented on BIGTOP-367:
-----------------------------------------
+1. This is one heck of a trick -- but I like the fact that it is so simple.
> Upgrade sequencing issue
> ------------------------
>
> Key: BIGTOP-367
> URL: https://issues.apache.org/jira/browse/BIGTOP-367
> Project: Bigtop
> Issue Type: Bug
> Components: Debian, RPM
> Affects Versions: 0.2.0, 0.3.0
> Reporter: Bruno Mahé
> Assignee: Bruno Mahé
> Attachments: BIGTOP-367.patch
>
>
> There is an issue regarding the way services are condrestart after an upgrade.
> To illustrate this issue, here is an upgrade sequence extracted from a very verbose rpm upgrade session of hadoop and hadoop-jobtacker:
> {noformat}
> %pre(hadoop-X)
> installation of hadoop-X files
> %post(hadoop-X)
> %pre(hadoop-jobtracker-X)
> install of hadoop-jobtracker-X files
> %post(hadoop-jobtracker-X)
> %preun(hadoop-jobtracker-X-1)
> removal of hadoop-jobtracker-X-1 files
> %postun(hadoop-jobtracker-X-1) => jobtracker service is restarted
> %preun(hadoop-X-1)
> removal of hadoop-X-1 files
> %postun(hadoop-X-1)
> {noformat}
> So when the jobtracker is condrestart, both jars of hadoop X and X-1 are presents. And if the jars have different versions, because of the way hadoop script pick up jars, the older version will be picked up first. There may also be other issues.
> But this defeat the purpose of doing a condrestart.
> I am not sure yet how to go about this issue, but here are some ideas:
> * We don't deal with it. Bigtop stable releases only deal with bugfixes and we don't support upgrade between major Bigtop versions. Since there wouldn't be any bump in the jars' versions, this issue would not happen
> * We stop doing condrestart on upgrade
> * We push back the init scripts in their main package. But then, doing a chkconfig on install/upgrade may be a bad idea
> * Do an ugly hack by moving the %postun of the service packages directly to the main package (with a if [ -x] around it for each service)
> All ideas are welcome!
> Note: I took hadoop as an example, but it can happen to any of our package which also provide a service
> PS: This issue may need also to be confirmed on ubuntu/debian. I am not sure how the upgrade process is sequenced
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira