Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.2.0, 0.3.0
    • Fix Version/s: 0.3.0, 0.4.0
    • Component/s: Debian, RPM
    • Labels:
      None

      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:

      %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)
      

      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

        Activity

        Bruno Mahé created issue -
        Bruno Mahé made changes -
        Field Original Value New Value
        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 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
        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
        Bruno Mahé made changes -
        Assignee Bruno Mahé [ bmahe ]
        Bruno Mahé made changes -
        Attachment BIGTOP-367.patch [ 12512254 ]
        Bruno Mahé made changes -
        Status Open [ 1 ] Patch Available [ 10002 ]
        Bruno Mahé made changes -
        Status Patch Available [ 10002 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Bruno Mahé made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Roman Shaposhnik made changes -
        Fix Version/s 0.3.0 [ 12317841 ]
        Fix Version/s 0.4.0 [ 12318889 ]
        Gavin made changes -
        Workflow no-reopen-closed, patch-avail [ 12650548 ] patch-available, re-open possible [ 12665793 ]

          People

          • Assignee:
            Bruno Mahé
            Reporter:
            Bruno Mahé
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development