Hi all, Miguel Barrientos (@mbarrientos) and I are currently working on integrating CloudFoundry as a Brooklyn location, as suggested on the 2nd section of the Pivotal CF integration proposal, so we would like to let the rest of the mailing list to know about the status of the discussion.
Following the @andreaturli and @ahgittin’s advices for the PaaS approach that Miguel and I are developing, we think the next step may be to unify the current Brooklyn entities which represent the SoftwareProcess, such as JBossService, TomcatService, etc… and the entities that we have defined for CloudFoundry. These entities are oriented to be deployed only in CloudFoundry and they use a new location, CloudFoundryLocation, which are not based on MachineLocation. This unification process should allow to deploy the current Brooklyn entities on PaaS or SshMachines depending on a specific location, for example aws-ec2:us-west-2, localhost, or pivotal-cloud-foundry. For this feature, we think that the entities should use a driver depending on the target location (e.g., TomcatSshDriver / TomcatCloudFoundryDriver) which allows to manage the deployment and configuration process. For example, SSH drivers are based on provisioning a machine where the required software needs to be downloaded, installed and configured. For a PaaS provider like CF, the expected software have already been installed and configured, so the application will be directly uploaded and started. Then, depending on the expected location, the entity should use a driver for accomplishing the necessary steps. We have already defined a new location, PaasLocation (@mbarrientos PR), representing a target PaaS, and a simple driver selection rule. Then as we mentioned, our next step should adapt the current Brooklyn entities to support the PaasLocation and the driver oriented to PaaS. Currently, the aforementioned Brooklyn entities extend SoftwareProcess (SoftwareProcessImpl), which define an effector set that is focused on Ssh Machine. These effector are not defined by the entity, but is attached to the entity in runtime fromSoftwareProcessDriverLifecycleEffectorTasks instance (which is a subclass of MachineLifecycleEffectorTasks). These effectors are focus on machine management, so we will need new effectors to deal with PaaS features (PaasLocation). As these effectors are added in runtime, we could create a new class, something like PaasProcessDriverLifeEffectorTasks which contains the effectors oriented to PaaS management (we could to call these classes "EffectorsFrabric"). Then depending on the target location of an entity, an effector fabric will be instantiated and the effectors according to the location will be attached to the entity. We think it is the best way to reach the PaaS features to Brooklyn, without adding out several changes on the current Brooklyn entities. Probably, we need to modify the SoftwareProcess, SoftwareProcessDriverLifecycleEffectorTasks and the subclass for accomplishing our goals. We have found some of issues that we’d like to discuss. Following Brooklyn philosophy, an entity shouldn't know about the location where it will be deployed. At the moment, it looks like the location where the entity will be deployed is not known until the "start" effector is executed (the final location is received as input parameter). Then, if we add support for new location types different to MachineLocation (i.e. PaasLocation), entities won't be able to load any effectors by default, making the process to fail. A possible solution for this could be to use an EffectorsFabric inside the start effector (which seems strange) that generates a set of effectors depending on the input location. However, we are not sure if this is the best way of accomplishing this task. WDYT about this? If you prefer, we could follow this discussions on the gdoc. Miguel & Jose
