AppScale GTS 3.8: Updating Code On Demand

    Posted by Graziano Obertelli on 10/18/19, 10:36 AM
    Find me on:


    Updating code on demand

    With AppScale 3.8 we added an option to allow the AppScale administrator to control what should be updated upon starting a deployment. This feature is mostly relevant to developers and to deployments based on a customized branch.

    Previously...

    Before the 3.8 release, AppScale’s AppController would automatically check and update any package upon start. The packages here relates to AppScale’s datastore, taskqueue, et al. implementation, and since they are all implemented in Python, any changes would require a pip install to be effective. Thus the AppController was dutifully installing all the changed packages.

    As a note the rsync option in the AppScalefilec was part of this mechanism: when a repo was specified there, it would be copied over the deployment, and if the repo had changes (as reported by git) the AppController would detect them and trigger the rebuild and reinstall of the appropriate packages.

    Although this mechanism worked reasonably well, it would add the build time to the starting time of a deployment, and since we didn’t have a clear way to detect if a rebuild has been already done, it would add the build time to each restart no matter if it was needed or not.

    Admin is now in control

    AppScale 3.8 adds an option to the tools, in order to allow the AppScale administrator control over when and which packages should be rebuilt. The new option

    appscale up -update all

    instructs the AppController to rebuild all packages. Of course only the desired packages could be updated if specified in the command line instead of all. The list of supported packages at this time is: common, app_controller, admin_server, taskqueue, app_db, iaas_manager, hermes, api_server and appserver_java.

    If no option is specified, no update will take place: which was deemed the safest option for deployment in production. This new behavior will result in multiple developers wondering why the latest changes, or log message isn’t showing up properly, and it will require a restart of the deployment: in this case you can do

    appscale down

    and without the --terminate it will ensure what whatever instance you have started, won’t be terminated thus cutting down the time to restart.

    Topics: AppScale News, AppScale Release

    Subscribe to Email Updates

    Most Popular

    Recent Posts