• 
      

    Reinstall extension media when the version of the extension changes.

    Review Request #5673 — Created April 3, 2014 and submitted

    Information

    Djblets
    master
    c1e7873...

    Reviewers

    Upgrades for extensions which include static media (like javascript or CSS) are
    highly annoying, because in addition to installing the package, the user has to
    disable the extension, then re-enable it. This change fixes all that.

    When we install extension static media, we add a key to the extension settings
    dictionary called _extension_media_version. Then, when initializing the
    extension class, if the version stored in settings doesn't match the one for
    the running code, we'll re-install the media.

    This is fine and dandy for the single-threaded devserver, but it's possible
    that installing a new extension could cause a bunch of threads/processes to try
    to reinstall static media all at once on a production server. I've therefore
    created a relatively simple locking mechanism to ensure that only one thread
    will be installing media for any given extension at a time.

    Testing done:

    • Enabled a new extension and saw the media get installed.
    • Disabled an existing extension and re-enabled it, and saw media get installed.
    • Restarted my devserver and saw that static media versions were checked, but no re-installation occurred.
    • Updated the version of an extension, restarted the devserver, and saw that static media got upgraded.
    • Created a lock contention and saw that initializing the extension waited for the lock to clear.
    Description From Last Updated

    What happens if RB is scaled across servers, and two handle the same request at the same time? Especially with …

    chipx86chipx86

    Can we move this to the class definition? Also, I'm not sure we want to key this off on media …

    chipx86chipx86

    I don't know that this will actually re-fetch from the database. Settings sync won't kick in while we're in a …

    chipx86chipx86

    If we pull the key out above, we can reuse it here.

    chipx86chipx86
    chipx86
    1. 
        
    2. djblets/extensions/manager.py (Diff revision 1)
       
       
      Show all issues

      What happens if RB is scaled across servers, and two handle the same request at the same time? Especially with in-extension upgrades.

      Maybe instead of a file-based cache, we just do this with memcached?

      1. Don't we want extension media on all front-end servers?

      2. True, unless we're storing centrally somewhere. Guess my concern was more about the types of updates extensions might do.

    3. djblets/extensions/manager.py (Diff revision 1)
       
       
      Show all issues

      Can we move this to the class definition?

      Also, I'm not sure we want to key this off on media versions. I think we want a more general _installed_version or something, which we'd then use for handling any in-extension upgrading as well.

    4. djblets/extensions/manager.py (Diff revision 1)
       
       
      Show all issues

      I don't know that this will actually re-fetch from the database. Settings sync won't kick in while we're in a loop. I believe we're going to need to re-fetch the extension entry from the database.

    5. djblets/extensions/manager.py (Diff revision 1)
       
       
      Show all issues

      If we pull the key out above, we can reuse it here.

    6. 
        
    david
    chipx86
    1. Ship It!

    2. 
        
    chipx86
    1. Should update the description for the version key.

    2. 
        
    david
    Review request changed
    Status:
    Completed
    Change Summary:
    Pushed to master (c24221f).