AppScalefile: Simply Better

Posted by Dmitrii Calzago on 10/23/17 3:30 PM

3.4 Release blog v1-1.png

Simply better. Starting  with the release of AppScale 3.4, the syntax of AppScalefile - the definition of an AppScale deployment - will change. (Further changes may be introduced in a future release.) For the timebeing, old syntax will be recognized,albeit with a deprecation warning. Thus, AppScale users will have time to make the necessary syntax adjustments, described below.

AppScalefile was long overdue for a facelift. It evolved over time as AppScale grew in features, with parameters thrown in as needed, not always named consistently. The file’s structure ended up reflecting needs of AppScale developers better than the needs of those deploying AppScale. That deficiency became especially noticeable on large installations, resulting in AppScalefiles that were difficult to understand.

To improve readability of AppScalefiles with a large number of nodes, the syntax for mapping nodes to service roles is changing. The old mapping required separate lists of node IPs for each role:

ips_layout :  
   zookeeper :  
      - <Private IP 1>  
      - <Private IP 2>  
   database :  
      - <Private IP 1>  
      - <Private IP 2>  
   appengine :  
      - <Private IP 3>  
      - <Private IP 4>  
      - <Private IP 5>  

 

Instead, starting from 3.4, roles that share a node can be listed together, without the need to repeat node IPs:

ips_layout :  
-  
   roles: [zookeeper, database]  
   nodes:  
     - <Private IP 1>  
     - <Private IP 2>  
-  
   roles: appengine  
   nodes:  
      - <Private IP 3>  
      - <Private IP 4>  
      - <Private IP 5>  

 

The advantages of the new format are especially evident in a one-node deployment spec:     

ips_layout :  
-  
   roles:   
      - master  
      - appengine  
      - database  
      - zookeeper  
  nodes: <Private IP>  

               

And in a specification for a large cloud-based deployment (in which numbers of nodes rather than specific IPs are used):

ips_layout :  
-  
     roles: master  
     nodes: 1  
 -  
     roles: database  
     nodes: 2  
     disks:  
         - disk_1  
         - disk_2  
-  
     roles: zookeeper # Zookeeper needs a majority of peers
     nodes: 3
-
     roles: appengine
     nodes: 64

Note that disks can now be specified for each role. In the above example, disk_1 and disk_2 would be volume or persistent disk IDs on the cloud infrastructure being used. The number of disks must be equal to the number of nodes.

When we reviewed service roles supported by AppScalefile as of 3.3, it became clear that many of them outgrew their usefulness or were never used in practice separate from other roles, making them redundant. Thus, we decided to deprecate the following seven roles in 3.4:

* Because of the way the AppScale autoscaler works,

deprecated role role to use instead
open appengine *
shadow master
db_master database
db_slave database
taskque_master taskqueue
taskque_slave taskqueue

* Because of the way the AppScale autoscaler works,

an open node will only be used for appengine.

 

The login role has also been deprecated. Instead, use the login option in the AppScalefile or configure the login dynamically via `appscale set login <value>`, where ‘value’ is either the public IP address of the load balancer or a DNS record associated with all load balancers (this value is used to generate login URLs for applications).

To make some of the keywords clearer, we’re renaming the following options in 3.4:

old name new name
n replication
scp rsync_source
appengine default_min_appservers
max_memory default_max_appserver_memory  
min / max min_machines / max_machines

For the detailed 3.4 Release Changelog check our Github release pages.

Try AppScale!

Get all your questions answered, check out our Technical FAQ

Technical FAQs 

 

Topics: AppScale News, AppScale Release, Best Practices

Subscribe to Email Updates

Recent Posts