AppScalefile: Simply Better

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: