Theory and Practice of Formal Methods

On the Expressiveness of Synchronization in Component Deployment Jacopo Mauro, Gianluigi Zavattaro To cite this version: Jacopo Mauro, Gianluigi Zavattaro. On the Expressiveness of Synchronization in Component Deployment. Theory and Practice of Formal Methods , 9660 pp.344-359, 2016, Lecture Notes in Computer Science, ฀10.1007/978-3-319-30734-3฀. ฀hal-01334772฀ HAL Id: hal-01334772 https://hal.inria.fr/hal-01334772 Submitted on 21 Jun 2016 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés. On the Expressiveness of Synchronization in Component Deployment⋆ Jacopo Mauro1 and Gianluigi Zavattaro2 1 2 Department of Informatics, University of Oslo (Norway) Dep. of Computer Science and Engineering - Univ. Bologna / INRIA FoCUS (Italy) Abstract. The Aeolus component model has been introduced to formally address the problem of automatic deployment of complex distributed component systems. In the general setting, the task of checking if a distributed application can be deployed is an undecidable problem. However, the current undecidability proof in Aeolus assumes the possibility to perform in a synchronized way atomic configuration actions on a set of interdependent components: this feature is usually not supported by deployment frameworks. In this paper we prove that even without synchronized configuration actions the Aeolus component model is still Turing complete. On the contrary, we show that other Aeolus features like capacity constraints and conflicts are necessary: if we remove the former the deployment problem becomes non-primitive recursive, while in the latter it becomes poly-time. 1 Introduction Expressiveness of models for concurrent computation is one of those interest that accompanied Frank de Boer in his extremely productive and diversified research activity. For instance, in the early 90’s he investigated the use of embedding as a tool for concurrent language comparison [6] and more recently he considered decidability/undecidability of termination problems to evaluate the expressiveness of basic features of the Actor concurrency model [5]. This paper falls in this line of research, by considering the Aeolus component model tailored to the analysis of automatic component deployment. The specific contribution of this paper is the study of the expressiveness of a specific mechanism for component configuration used to synchronously configure interdependent components. This is useful, for instance, when two components are mutually dependent and the easiest way to deploy them is to install them contemporaneously. Especially in a distributed component environment, such a synchronized installation is of difficult implementation. For this reason we have decided to investigate the impact of the elimination of this mechanism from the Aeolus model. ⋆ Supported by the EU projects FP7-610582 Envisage: Engineering Virtualized Services (http://www.envisage-project.eu) and FP7-644298 HyVar: Scalable Hybrid Variability for Distributed, Evolving Software Systems (http://www.hyvar-project.eu). The Aeolus component model has been proposed in [4, 8] as a formal model to reason on the component deployment problem. Deployment and management of modern large scale component-based applications is a challenging task, and several tools and technologies are under development to support application architects and managers in these complex activities. According to the current mainstream approaches, such applications are either deployed by exploiting pre-configured virtual machines images, which already contain all the needed software components (see, e.g., Bento Boxes [9], Cloud Blueprints [3], or AWS CloudFormation [2]), or are designed by using drag-and-drop graphical tools like Juju [10] leaving the low-level component configuration to pre-programmed scripts or to automatic configuration tools like Puppet [16] or Chef [15]. Aeolus extends the classical notion of component, seen as a black-box that exposes provide and require ports, with a finite state automaton describing the component configuration life-cycle. The automaton states correspond to different configuration modalities, like uninstalled, installed, running, stopped, etc. and the transitions represent configuration actions like install, run, stop, etc. Depending on the internal state, the ports on the interface can be either active or inactive. For instance, an uninstalled component usually does not activate any require port, while it can activate require ports when it is in the installed state, and finally activate some provide port when it actually enters the running state. Another specific feature of the Aeolus model is that capacity constraints can be associated to the ports: a provide port could have a maximal number of connected require ports or a require port can ask for multiple providers offering a given functionality.3 Additionally, in Aeolus it is also possible to express conflicts: components can activate special ports that forbids the activation of provide ports of a given type in the rest of the system. In [4, 8] we have investigated the expressiveness of the Aeolus component model, showing that it is Turing complete. From this expressiveness result we have, as a negative consequence, that in general the component deployment problem is not computable. More precisely, we proved the undecidability of the achievability problem. Given a finite universe of component types, a target component and a target state, the achievability problem consists of deciding if it possible to reach a final configuration containing at least one instance of the target component type in the target state by assuming the availability of an unbounded number of instances of the component types of the universe in their initial state. The undecidability of achievability is proved by encoding counter machines, from which follows the Turing completeness of the Aeolus model. The proof relies on a specific feature of Aeolus called multiple state change: if there is a group of components that reciprocally depend one on another to advance in their internal configuration life-cycle, it is possible to synchronously and atomically change their state to allow all of them to progress. This specific feature of the model is clearly of non trivial implementation in distributed component systems 3 This feature of the model is used to capture replication or fault tolerance requirements. since it would require distributed synchronization and is usually not supported by deployment frameworks. In this paper we investigate the impact of the removal of multiple state changes on the expressiveness of the Aeolus component model. The main result is that the model is still Turing complete, thus showing that the undecidability of achievability follows from its intrinsic complexity, and not from the expressive power of distributed synchronization. As additional results, we show that this Turing completeness result relies on both capacity constraints and conflicts. In fact, if we remove at least one of these two features, achievability turns out to be decidable. In particular, if we remove conflicts it becomes poly-time, while if we remove capacity constraints (keeping conflicts), it turns out to be decidable but non-primitive recursive. Comparison with previous work The Aeolus component model was initially proposed in [8] where its Turing completeness was proved. In that paper, also the fragment of the Aeolus model without conflicts and capacity constraints was considered, showing that the achievability problem is poly-time for that fragment. In [7] the fragment without capacity constraints was studied, showing that the problem is decidable; its Ackerman-hardness was proved in [4]. A fragment of the Aeolus model without multiple state change (and without capacity constraints and conflicts) has been considered in [11, 12] where a tool for automatic cloud application deployment was presented. In this paper we complete the analysis of the remaining relevant fragments without multiple state changes. Structure of the paper In Section 2 we report the formal definition of the Aeolus component model following [4]. Turing completeness without multiple state change actions is proved in Section 3. In Sections 4 and 5 we consider the two fragments obtained by removing, besides multiple state change actions, also capacity constraints or conflicts, respectively. Finally, in Section 6 we draw some concluding remarks. 2 The Aeolus model In this section we give a recap of the Aeolus model following [4]. We assume given the following disjoint sets: I for interfaces and Z for components. We use N to denote strictly positive natural numbers, N∞ for N ∪ {∞}, and N0 for N ∪ {0}. We model component types as finite state automata indicating all possible component states and state transitions. When a component changes state, the sets of ports it requires from/provide to other components will also change: intuitively, the active ports changes depending on the internal state. A provide port represents the possibility of furnishing a functionality having a given interface. Similarly, a require port represents the need for a functionality with a given interface. Definition 1 (Component type). The set Γ of component types of the Aeolus model, ranged over by T1 , T2 , . . . contains 5-ple hQ, q0 , T, P, Di where: – Q is a finite set of states; – q0 ∈ Q is the initial state and T ⊆ Q × Q is the set of transitions; – P = hP, Ri, with P, R ⊆ I, is a pair composed of the set of provide and the set of require ports, respectively; – D is a function from Q to 2-ple in (P → 7 N∞ ) × (R → 7 N0 ). Given a state q ∈ Q, D(q) returns two partial functions (P → 7 N∞ ) and (R → 7 N0 ) that indicate respectively the provide and require ports that q activates. The functions associate to the activate ports a numerical constraint indicating: – for provide ports, the maximum number of bindings the port can satisfy, – for require ports, the minimum number of required bindings to distinct components, • as a special case: if the number is 0 this indicates a conflict, meaning that there should be no other active port, in any other component, with the same interface. When the numerical constraint is not explicitly indicated, we assume ∞ as default value for provide ports (i.e., they can satisfy an unlimited amount of requires) and 1 for require ports (i.e., one provide is enough to satisfy the requirement). We also assume that the initial state q0 has no demands (i.e., the second function of D(q0 ) has an empty domain). We now define configurations that describe systems composed by component instances and bindings that interconnect them. A configuration, ranged over by C1 , C2 , . . ., is given by a set of component types, a set of deployed components with a type and an actual state, and a set of bindings. Formally: Definition 2 (Configuration). A configuration C is a 4-ple hU, Z, S, Bi where: – U ⊆ Γ is the finite universe of all available component types; – Z ⊆ Z is the set of the currently deployed components; – S is the component state description, i.e., a function that associates to components in Z a pair hT , qi where T ∈ U is a component type hQ, q0 , T, P, Di, and q ∈ Q is the current component state; – B ⊆ I ×Z ×Z is the set of bindings, namely 3-ples composed by an interface, the component that requires that interface, and the component that provides it; we assume that the two components are distinct. In the following we will use a notion of configuration equivalence that relate configurations having the same instances up to renaming. This is used to abstract away from component identifiers and bindings. Definition 3 (Configuration equivalence). Two configurations hU, Z, S, Bi and hU, Z ′ , S ′ , B ′ i are equivalent, noted hU, Z, S, Bi ≡ hU, Z ′ , S ′ , B ′ i, iff there exists a bijective function ρ from Z to Z ′ s.t.: 1. S(z) = S ′ (ρ(z)) for every z ∈ Z; and 2. hr, z1 , z2 i ∈ B iff hr, ρ(z1 ), ρ(z2 )i ∈ B ′ . Notation: we write C[z] as a lookup operation that retrieves the pair hT , qi = S(z), where C = hU, Z, S, Bi. On such a pair we then use the postfix projection operators .type and .state to retrieve T and q, respectively. Similarly, given a component type hQ, q0 , T, hP, Ri, Di, we use projections to (recursively) decompose it: .states, .init, and .trans return the first three elements; .prov, .req return P and R; .P(q) and .R(q) return the two elements of the D(q) tuple. When there is no ambiguity we take the liberty to apply the component type projections to hT , qi pairs. For example, C[z].R(q) stands for the partial function indicating the active require ports (and their arities) of component z in configu# ration C when it is in state q. We denote with ChT ,qi the number of components of type T in state q in the configuration C. We are now ready to formalize the notion of configuration correctness: Definition 4 (Configuration correctness). Let us consider the configuration C = hU, Z, S, Bi. We write C |=req (z, r, n) to indicate that the require port of component z, with interface r, and associated number n is satisfied. Formally, if n = 0 all components other than z cannot have an active provide port with interface r, namely for each z ′ ∈ Z \ {z} such that C[z ′ ] = hT ′ , q ′ i we have that r is not in the domain of T ′ .P(q ′ ). If n > 0 then the port is bound to at least n active ports, i.e., there exist n distinct components z1 , . . . , zn ∈ Z \ {z} such that for every 1 ≤ i ≤ n we have that hr, z, zi i ∈ B, C[zi ] = hT i , q i i and r is in the domain of T i .P(q i ). Similarly for provides, we write C |=prov (z, p, n) to indicate that the provide port of component z, with interface p, and associated number n is not bound to more than n active ports. Formally, there exist no m distinct components z1 , . . . , zm ∈ Z \ {z}, with m > n, such that for every 1 ≤ i ≤ m we have that hp, zi , zi ∈ B, S(zi ) = hT i , q i i and p is in the domain of T i .R(q i ). The configuration C is correct if for each component z ∈ Z, given S(z) = hT , qi with T = hQ, q0 , T, P, Di and D(q) = hP, Ri, we have that (p 7→ np ) ∈ P implies C |=prov (z, p, np ), and (r 7→ nr ) ∈ R implies C |=req (z, r, nr ). We now formalize how configurations evolve from one state to another one, by means of atomic actions: Definition 5 (Actions). The set A contains the following actions: – – – – – stateChange(z, q1 , q2 ) where z ∈ Z; bind (r, z1 , z2 ) where z1 , z2 ∈ Z and r ∈ I; unbind (r, z1 , z2 ) where z1 , z2 ∈ Z and r ∈ I; new (z : T ) where z ∈ Z and T is a component type; del (z) where z ∈ Z. The execution of actions can now be formalized using a labelled transition system on configurations, which uses actions as labels. Definition 6 (Reconfigurations). Reconfigurations are denoted by transitions α C− → C ′ meaning that the execution of α ∈ A on the configuration C produces a new configuration C ′ . The transitions from a configuration C = hU, Z, S, Bi are defined as follows: stateChange(z,q1 ,q2 ) C −−−−−−−−−−−−−→ hU, Z, S ′ , Bi if C[z].state = q1 and (q1 , q2 ) ∈C[z].trans hC[z].type, q2 i if z ′ = z and S ′ (z ′ ) = C[z ′ ] otherwise bind(r,z1 ,z2 ) C −−−−−−−−→ hU, Z, S, B ∪ hr, z1 , z2 ii if hr, z1 , z2 i 6∈ B and r ∈ C[z1 ].req ∩ C[z2 ].prov unbind(r,z1 ,z2 ) C −−−−−−−−−−→ hU, Z, S, B \ hr, z1 , z2 ii if hr, z1 , z2 i ∈ B new (z:T ) C −−−−−−→ hU, Z ∪ {z}, S ′ , Bi if z 6∈ Z, T ∈U hT , T .initi if z ′ = z and S ′ (z ′ ) = C[z ′ ] otherwise del(z) C −−−−→ hU, Z\ {z}, S ′ , B ′ i ⊥ if z ′ = z if S ′ (z ′ ) = C[z ′ ] otherwise ′ and B = {hr, z1 , z2 i ∈ B | z 6∈ {z1 , z2 }} Notice that in the definition of the transitions there is no requirement on the reached configuration: the correctness of these configurations will be considered at the level of deployment runs as later detailed. Also, we observe that there are configurations that cannot be reached through sequences of the actions we have introduced. In Figure 1, for instance, there is no way for package a and b to reach the installed state, as each package requires the other one to be installed first. In practice, when confronted with such situations—that can be found for example in FOSS distributions in the presence of loops of Pre-Depends that impose an order in the installation of two depending packages—current tools either perform all the state changes atomically, or, more often, they abort deployment. The Aeolus model allows for simultaneous installations by introducing the notion of multiple state change. Fig. 1. On the need of a multiple state change: how to install a and b? Definition 7 (Multiple state change). A multiple state change action M = {stateChange(z 1 , q11 , q21 ), · · · , stateChange(z l , q1l , q2l )} is a set of actions of type state change on different components (i.e., z i 6= z j for every 1 ≤ i < j ≤ l). M We use hU, Z, S, Bi −−→ hU, Z, S ′ , Bi to denote the effect of the simultaneous execution of the state changes in M: formally, stateChange(z 1 ,q 1 ,q 1 ) stateChange(z l ,q l ,q l ) 2 hU, Z, S, Bi −−−−−−−−−−−−1−−2→ . . . −−−−−−−−−−−−1−− → hU, Z, S ′ , Bi Notice that the order of execution of the state change actions does not matter as all the actions are executed on different components. We can now define a deployment run, which is a sequence of actions that transform an initial configuration into a final correct one without violating correctness along the way. A deployment run is the output we expect from a planner, when it is asked how to reach a desired target configuration. Definition 8 (Deployment run). A deployment run is a sequence α1 . . . αm of actions and multiple state changes such that there exist Ci such that C = C0 , αj Cj−1 −→ Cj for every j ∈ {1, . . . , m}, and the following conditions hold: configuration correctness for every i ∈ {0, . . . , m}, Ci is correct; multiple state change minimality if αj is a multiple state change then there exists no proper subset M ⊂ αj , or state change action α ∈ αj , and correct M α configuration C ′ such that Cj−1 −−→ C ′ , or Cj−1 − → C′. We now have all the ingredients to define the notion of achievability, that is our main concern: given a universe of component types, we want to know whether it is possible to deploy at least one component of a given component type T in a given state q. Definition 9 (Achievability problem). The achievability problem has as input a universe U of component types, a component type T , and a target state q. It returns as output true if there exists a deployment run α1 . . . αm such that α1 α2 α hU, ∅, ∅, ∅i −→ C1 −→ · · · −−m → Cm and Cm [z] = hT , qi, for some component z in Cm . Otherwise, it returns false. Notice that the restriction in this decision problem to one component in a given state is not limiting. One can easily encode any given final configuration by adding a dummy provide port enabled only by the required final states and a dummy component with requirements on all such provides. 3 Turing completeness without multiple state changes In [4, 8] it is proved that the Aeolus component model is Turing complete. More precisely, we show how to reduce termination for 2 Counter Machines [14], a wellknown Turing-complete computational model, in the achievability problem for the Aeolus component model. The presented reduction makes use of the multiple state change actions. In this section, we revisit that proof, showing that multiple state changes are not strictly necessary. Before entering into the details, we observe that given a component type T it is always possible to modify it in such a way that its instances are persistent. To avoid the component deletion it is sufficient to impose a reciprocal dependence with a new auxiliary type of components. When this dependence is established the components cannot be deleted without violating configuration correctness. In [4] this reciprocal dependence was established via a multiple state change. However, multiple state changes are not the only way to enforce the persistence of an instance since the reciprocal dependence can be established by creating one binding at the time following a precise protocol. qf ... q0 e qb e qa ... all states except q'0 enable b, require a ... ≤1 b b a a ≤1 q0 q0 q'a f q'a f q'0 Fig. 2. Component type transformation ϕ. In Figure 2 we show an example of how a component type can be modified in order to reach our goal. Three new auxiliary states q0′ , qa′ , and qb′ are created, with q0′ becoming the new initial state. States qa′ and qb′ require and provide respectively ports a and b. Only one instance of T can be present at once in these two states. This is enforced by simultaneously providing and requiring the port e. The original states of T are modified to require the port a and provide the port b. Dually, the auxiliary component Taux has an initial state q0 , a final one qf , and two intermediate states qa and qb providing and requiring respectively ports a and b. Also in this case, at most one instance of Taux can be in states qa or qb . We assume that the ports a, b, e and f are fresh, that is, they are not used by any other component type in the considered universe. Given a component type T we denote this component type transformation with ϕ(T ). The ϕ transformation is defined to guarantee the establishment of two reciprocal bindings between pairs of T and Taux instances that forbid their deletion. In particular, an instance of T cannot be deleted after the state qb′ was left while the instance of Taux cannot be deleted after state qa . This is due to the fact that after these states are left the instances are guaranteed to provide # something required by the other instance. If we denote with Chpi the number of instances providing the port p, this property is captured as follows. # # Property 1 (ϕ-persistence). A configuration C is ϕ-persistent if Chai −ChT = aux ,qa i # # Chbi − ChT ,q ′ i b The encoding ϕ preserves the ϕ-persistence. α Lemma 1. If C − → C ′ and C is ϕ-persistent than also C ′ is ϕ-persistent. Proof. The proof can be done considering the type of α actions. Since ϕ-persistence considers just the amount of active ports of type a and b we can restrict to consider only actions that can alter these quantities. If α = stateChange(z, q0 , qa ) a new port a is provided but at the same # # unaltered. − ChT time an instance of type Taux leaving the quantity Chai aux ,qa i The same happens with α = stateChange(z, qa , qb ) and for port b when α = stateChange(z, qa′ , qb′ ) or stateChange(z, qb′ , q0 ). When a and b are provided, by construction, the only way to reduce their amount is by deleting a component. A deletion of an instance of type Taux in state q0 , qa or the deletion of type T in states q0′ , qa′ , qb′ does not alter the amount of a or b ports provided. A deletion of an instance z of T or Taux in a different # state q ′ is not possible. In fact, if z is of type T than its deletion reduces Chbi by # # # # 1. But since there are exactly Chai − ChT = Chbi − ChT ,qb′ i instances requiring aux ,qa i a port b the deletion of z violates the configuration correctness. Similarly, the configuration correctness is violated also if z is of type Taux . ⊔ ⊓ We can therefore consider, without loss of generality, components that can be deployed in a persistent way. This can lead to a modification of the proof of the undecidability of achievability for Aeolus [4] that does not assume to use multiple state changes. The original prove was by reduction from the termination problem in 2 Counter Machines (2CMs) [14], a well-known Turing-complete computational model. A 2CM is a machine with two registers R1 and R2 holding arbitrary large natural numbers and a program P consisting of a finite sequence of numbered instructions of the two following types: deci qm+1 ... b b offi q0 ri onei deci ql deci offi onei qm ... qj+1 inci a a oni TR ... all states enable e inci e inci i oni ... qj ... conflict i.e. =0 e q1 q0 Tp Fig. 3. Modeling 2 counter machines (2CMs) in the Aeolus model. – j : Inc(Ri ): increments Ri and goes to the instruction j + 1; – j : DecJump(Ri , l): if the content of Ri is not zero, then decreases it by 1 and goes to the instruction j + 1, otherwise jumps to the l instruction. A state of the machine is given by a tuple (i, v1 , v2 ) where i indicates the next instruction to execute (the program counter) and v1 and v2 are the values contained in the two registers, respectively. For modelling 2CMs a component to simulate the execution of the program instructions was used. The content vi of the register Ri is modelled by vi components in a particular state ri . Increment instructions add one component in this state ri , while decrement instructions move one component in state ri to a different state. The state ri activates a provide port onei , so the simulation of a test for zero has simply to check the absence in the environment of active onei ports. In particular, as depicted in Figure 3, a component type TP was used to simulate the execution of the program instructions while TR1 and TR2 were used for the two registers. All these components where made persistent by forcing the initial execution of multiple state changes creating reciprocal bindings with an additional component. However, the same can be obtained without the use of the multiple state change simply by applying the ϕ transformation. We can therefore prove a stricter undecidability result. Theorem 1. The achievability problem is undecidable in the fragment of the Aeolus component model that does not support multiple state changes. Proof. The proof follows the same technique as the one used in [4] by considering ⊔ ⊓ the universe U = ϕ(TP ) ∪ ϕ(TR1 ) ∪ ϕ(TR2 ). 4 Ackermann-hardness without capacity constraints and multiple state changes In [4] the achievability problem was proven to be decidable but Ackermann-hard in the fragment of Aeolus without capacity constraints. Even in this case the complexity does not decrease if we also remove multiple state changes. The complexity result in [4] was obtained by reduction from the coverability problem in reset Petri nets, a problem which is indeed known to be Ackermannhard [17]. We start with some background on reset Petri nets. A reset Petri net RN is a tuple hP, T, m0 i such that P is a finite set of places, T is a finite set of transitions, and m0 is a marking, i.e., a mapping from P to N that defines the initial number of tokens in each place of the net. A transition t ∈ T is defined by a mapping • t (preset) from P to N, a mapping t• (postset), and by a set of reset arcs t ↓⊆ P . A configuration is a marking m. Transition t is enabled at marking m iff • t(p) ≤ m(p) for each p ∈ P . Firing t at m leads to a new marking m′ defined as m′ (p) = m(p) −• t(p) + t• (p) if p 6∈ t ↓, and m′ (p) = 0 otherwise; we denote this marking transformation with m 7→ m′ . A marking m is reachable from m0 if m0 7→∗ m, i.e., it is possible to produce m after firing finitely many times transitions in T . Given a reset net hP, T, m0 i and a marking m, the coverability problem consists in checking for the existence of a reachable marking m′ such that m ≤ m′ , i.e. m(p) ≤ m′ (p) for every p ∈ P . In [17] it is proved that the coverability problem for reset nets is Ackermann-hard. The encoding of reset Petri nets into Aeolus presented in [4] relied on three types of component types: Tp for modelling the tokens, Tt for the transitions, and log(n) component types TCi (for 1 ≤ i ≤ log(n)) for modeling the bits in a binary counter used to count the tokens to be produced or consumed during the simulation of a transition firing. Here n is the maximal number of tokens that one transition can produce or consume. The proof technique requires that the components for the transitions and the counter bits are unique and persistent. This was ensured via a transformation that exploited conflicts but also multiple state changes. This however, following the example of the ϕ transformation defined in the previous section, can be obtained also without the use of multiple state changes. The key idea to avoid a multiple state change is to create a mutual dependency between pairs of components in two phases and use the conflicts to ensure that only one component at a time can be present. Figure 4 depicts the transformation η that guarantees persistence and forbids the presence of two distinct instances of the same component. This is obtained by requiring that all the states except the initial ones activate contemporaneously a require and a conflict port on the same interface (in the two component ... qf ... ... q0 η q0 ... all states except q'0 enable f and b, require a, conflict with f e qb b b q'b f e qa a a q'a f q0 q'0 Fig. 4. Component type transformation η. types in the Figure we use the fresh interfaces e and f , respectively). The interdependencies among the two component types are similar to those used in the ϕ transformation to guarantee persistency. The unique difference is that no capacity constraint is considered; indeed, this is no longer needed because, thanks to the simultaneous requirement and conflict on the interfaces e and f , and the freshness of the ports a and b, a configuration has at most one a and one b provide port active. Note that the size of η(T ) is polynomial w.r.t. the size of T because we are just introducing a new component type Taux of constant size and we modify T by adding three new states and three ports. We can now conclude the new version of the Ackermann-hardness result for the fragment of Aeolus without capacity constraints and multiple state changes. Theorem 2. The achievability problem is Ackermann-hard for the fragment of the Aeolus component model that does not support capacity constraints and multiple state changes. Proof. The proof follows the same technique as the one used in [4] with the difference that now the encoding of the Petri net RN = (P, T, m0 ) is ΓRN = {Tp | p ∈ P }∪{η(TCi ) | i ∈ [1..⌈log(n)⌉]}∪{η(TT )} where n is the largest number of tokens that can be consumed or produced by a transition in T and η is the transformation depicted in Figure 4. ⊔ ⊓ 5 Poly-time without conflicts and multiple state changes In [12] it was proven that the achievability problem is poly-time considering the fragment of Aeolus where no capacity constraint, no multiple state changes, and no conflicts can be used. This was done by means of an algorithm that builds a reachability graph used to check whether a given target component-state pair may be obtained. As detailed in Algorithm 1, the nodes of the reachability graph are organized in layers N odes0 , N odes1 , · · · , N odesn that are generated in subsequent phases. Initially, N odes0 contains all the pairs hT , T .initi corresponding to the initial states. Given N odesj , N odesj+1 is generated by copying the pairs already available in N odesj and by adding those new pairs that can be reached by transitions from states in N odesj , assuming the availability in the context of components of type and state hT , qi already in N odesj . The reachability analysis terminates since there is a finite number of possible component type-state pairs. Luckily, the same reachability technique can be used to decide achievability also when capacity constraints can be used. Indeed, we prove that at each layer N odesj a sufficient number of components can be created to satisfy all the constraints that will be activated by the new components at layer N odesj+1 . The reachability algorithm is therefore correct also in the presence of capacity constraints. Algorithm 1 reachabilityAnalysis() S 1: Nodes 0 = {hT , T .initi | T ∈ U }; provPort = hT ,qi∈Nodes 0 {T .P(q)}; n = 0 2: repeat 3: n=n+1 4: Arcsn = ∅; N odesn = ∅ 5: for all hT , qi ∈ Nodes n−1 do 6: for all (q, q ′ ) ∈ T .trans do 7: if T .R(q ′ ) ⊆ provPort then 8: Nodesn .add(hT , q ′ i) 9: for all hT , qi ∈ Nodesn do 10: provPort.add(T .P(q)) 11: Nodes n = Nodes n−1 ∪ Nodesn 12: for all hT , qi ∈ Nodes n−1 , hT , q ′ i ∈ Nodes n do 13: if (q, q ′ ) ∈ T .trans then 14: Arcsn .add(hT , q ′ i −→ hT , qi) 15: if q == q ′ then 16: Arcsn .add(hT , q ′ i hT , qi) 17: until N odesn−1 == N odesn Lemma 2. Given a universe of components U , a component type Ttarget , and a state qtarget , we have that hT , qi belongs to the reachability graph computed by Algorithm 1 if and only if there exists a deployment plan that deploys at least one component of type T in state q. Proof. We first consider the only if part. We prove that given hhT ,qi > 0 for every hT , qi ∈ N odesn , and given hp > 0 for every provide port p activated by the component type-state pairs hT , qi ∈ N odesn , there exists a deployment plan from an empty configuration to a configuration containing at least hhT ,qi components of type T in state q, in which at least hp provide ports with inter- face p have no incoming bindings (thus they are available to satisfy additional complementary require port with interface p). We proceed by induction on n. The base case holds because N odes0 contains all the pairs with just initial states (Line 1) and components could always be created in their initial state because they have no requirements by definition. In the inductive case we have that for every pair hT , qi ∈ N odesi+1 \ N odesi there exists a pair hT , q ′ i ∈ N odesi where q ′ is a predecessor of q (Lines 5-8 of Algorithm 1). Moreover, for every require port r activated by the components of type-state hT , qi ∈ N odesi+1 \ N odesi there exists a pair hT ′′ , q ′′ i ∈ N odesi that activates a provide port r (Line 7). By inductive hypothesis it is possible to obtain a configuration such that: 1. for every hT , q ′ i ∈ N odesi it has at least X hhT ,q′ i + (hhT ,qi + maxp ) hT ,qi∈N odesi+1 \N odesi components of type T in state q ′ . By maxp we mean the maximal value among all the hp ; 2. for every provide port p activated by a component type-state pair hT ′′ , q ′′ i ∈ N odesi in N odesi there are at least X hp + (maxRequirep + 1) × (hhT ,qi + maxp ) hT ,qi∈N odesi+1 \N odesi active provide port p that have no incoming binding. By maxRequirep we mean the maximal number of provide ports with interface p that are necessary to satisfy the requirements of one component instances of any possible type, in any possible state. Thanks to point 1, starting from this configuration it is possible to perform for every pair hT , qi of N odesi+1 \ N odesi exactly hhT ,qi + maxp (hp ) state changes to obtain components of type T in state q. Indeed, point 2 guarantees there are enough free provide ports to satisfy the requirements of these components. Moreover, if the new state q activates new provide ports that were inactive in the previous state, we have the guarantee that it is possible to unbind these ports so that these components will have no incoming binding. Hence, for these interfaces p we will have at least hp free provide ports. Concerning pairs hT ′′ , q ′′ i ∈ N odesi+1 ∩N odesi , thanks to point 1 the reached configuration will contain at least hhT ′′ ,q′′ i instances of type T ′′ in state q ′′ . By point 2, we also have the guarantee that for provide ports p activated by these pairs hT ′′ , q ′′ i at least hp instances remain P free in the new configuration. In fact, some of them (at most maxRequirep × hT ,qi∈N odesi+1 \N odesi (hhT ,qi + maxp )) will be used to satisfy theP requirements of the new component type-state pairs, and some other (at most hT ,qi∈N odesi+1 \N odesi (hhT ,qi + maxp )) could become inactive due to a state change. We now move to the if part. We proceed by contradiction. Let us suppose α1 α2 α the existence of a deployment plan hU, ∅, ∅, ∅i −→ C1 −→ . . . −−m → Cm such that Cm contains a component of type T in state q while hT , qi is not present in the reachability graph. It is not restrictive to assume that Cm is the first configuration of the plan having such property (i.e., all the pairs hT ′ , q ′ i of the components in C1 , · · · , Cm−1 are present in the reachability graph). Obviously q cannot be an initial state of T since all the component types with their initial states are added in N odes0 (Line 1). Therefore we have that stateChange(i,s,q) the last transition of the plan is Cm−1 −−−−−−−−−−−−→ Cm . This action can be executed only if all the require ports activated by q are fulfilled by components in Cm−1 . For the previous assumption, we have that hT , si, as well as all the pairs hT ′ , q ′ i of types and states of components in Cm−1 , are part of the computed reachability graph. Let N odesj be the first layer containing all such pairs: by construction (Lines 5-8) we will have that hT , qi ∈ N odesj+1 , thus contradicting the hypothesis. ⊔ ⊓ As a consequence of Lemma 2 we have the following result. Theorem 3. The achievability problem is poly-time for the fragment of the Aeolus component model that does not support multiple state changes and conflicts. The proof immediately follows from Lemma 2 and the fact that Algorithm 1 is poly-time [12]. 6 Conclusions To the best of our knowledge Aeolus is the first formal model that is designed on purpose to address the specific problem of software component deployment in the cloud. It was first introduced in [8]. Differently from the definition of the language presented here, in [8] an additional kind of requirements—called weak requirements—was present. Differently from the requirements presented in this paper (formerly known as strong requirements) that needs to be enforced at every deployment step, weak requirements must be satisfied only at the end of a deployment run. The notion of weak requirement was removed from the model because we found out that their behavior could be simulated with normal requirements. In this paper we proved that also the notion of multiple state change can be removed because from the complexity point of view it does not have an impact. It is interesting to point out that this new foundational result reflects a recent technic adopted in the context of deployment tools for packagebased software distributions [1] that replaces synchronous installation of circular dependent packages with multi-stage configuration protocol. In this work we have considered the deployment of an application from scratch. If we assume the initial configuration is not empty, we move to a socalled reconfiguration problem. It is interesting to observe that this problem is harder than the achievability problem for the fragment without multiple state change and conflicts for which we prove in this paper that achievability is polytime. In fact, in [13] we have recently proved that reconfiguration is PSpace complete already for the fragment without multiple state change, conflicts and capacity constraints. References 1. Pietro Abate and Schauer Johannes. Bootstrapping Software Distributions. In CBSE’13, pages 131–142. ACM, 2013. 2. Amazon. AWS CloudFormation. http://aws.amazon.com/cloudformation/. 3. CenturyLink. Cloud Blueprints. http://www.centurylinkcloud.com/products/ management/blueprints. 4. Roberto Di Cosmo, Jacopo Mauro, Stefano Zacchiroli, and Gianluigi Zavattaro. Aeolus: A component model for the cloud. Inf. Comput., 239, 2014. 5. Frank S. de Boer, Mohammad Mahdi Jaghoori, Cosimo Laneve, and Gianluigi Zavattaro. Decidability problems for actor systems. Logical Methods in Computer Science, 10(4), 2014. 6. Frank S. de Boer and Catuscia Palamidessi. Embedding as a tool for language comparison. Inf. Comput., 108(1):128–157, 1994. 7. Roberto Di Cosmo, Jacopo Mauro, Stefano Zacchiroli, and Gianluigi Zavattaro. Component Reconfiguration in the Presence of Conflicts. In ICALP, volume 7966 of LNCS, 2013. 8. Roberto Di Cosmo, Stefano Zacchiroli, and Gianluigi Zavattaro. Towards a Formal Component Model for the Cloud. In SEFM 2012, volume 7504 of LNCS, 2012. 9. Flexiant. Bento Boxes. http://www.flexiant.com/2012/12/03/ application-provisioning/. 10. Juju, devops distilled. https://juju.ubuntu.com/. 11. Tudor A. Lascu, Jacopo Mauro, and Gianluigi Zavattaro. A Planning Tool Supporting the Deployment of Cloud Applications. In ICTAI, 2013. 12. Tudor A. Lascu, Jacopo Mauro, and Gianluigi Zavattaro. Automatic Component Deployment in the Presence of Circular Dependencies. In FACS, 2013. 13. Jacopo Mauro and Gianluigi Zavattaro. On the Complexity of Reconfiguration in Systems with Legacy Components. In MFCS, 2015. 14. Marvin Minsky. Computation: finite and infinite machines. Prentice Hall, 1967. 15. Opscode. Chef. http://www.opscode.com/chef/. 16. Puppetlabs. Puppet. http://puppetlabs.com/. 17. Philippe Schnoebelen. Revisiting Ackermann-Hardness for Lossy Counter Machines and Reset Petri Nets. In MFCS, 2010.