Hi all Thanks for you response, Hadrian. We have updated the discussion on our proposal [1][2].
Jose [1] https://docs.google.com/document/d/1cgNqvXeuwOXa3CwQ_LWphU8mjKdwlVjB8JX8jIEEWSg/edit?usp=sharing [2] https://github.com/apache/incubator-brooklyn/pull/918 El 01/12/2015, a las 16:34, Hadrian Zbarcea <[email protected]> escribió: > Hi Jose, > > I think my proposal is related to this thread. I didn't want to hijack your > thread, but please feel free to provide feedback to the proposals. > > Hadrian > > On 11/30/2015 11:12 AM, Jose Carrasco wrote: >> Hi all, >> >> Currently, UMA team are 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 we 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 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. >> We have opened a PR (#918) and we have written a document explaining better >> our approach and our questions. >> >> WDYT about this? >> >> If you prefer, we could follow this discussions on the gdoc. >> >> Best. >> UMA >> >> >> El 02/07/2015, a las 16:57, Andrea Turli <[email protected]> >> escribió: >> >>> Thanks Miguel and Jose, >>> >>> what you are proposing here is very interesting! >>> >>> Could you summarize the previous conversation with @ahgittin and myself so >>> that everyone is aware of those discussions? >>> >>> We are looking forward to see the PaasLocation implementation so that we >>> can discuss the implementation details on the PR, I hope. >>> >>> I'll need some more context to understand the EffectorsFabric idea but I'm >>> sure it is something that will happen while we discuss the nice idea of >>> better PaasLocation support. >>> >>> Thanks! >>> Andrea >>> >>> On Mon, 8 Jun 2015 at 12:29 Jose Carrasco <[email protected]> wrote: >>> >>>> 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 >>>> >>>> >>>> >>>> >>> >>> -- >>> Cloudsoft Corporation Limited, Registered in Scotland No: SC349230. >>> Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP >>> >>> This e-mail message is confidential and for use by the addressee only. If >>> the message is received by anyone other than the addressee, please return >>> the message to the sender by replying to it and then delete the message >>> from your computer. Internet e-mails are not necessarily secure. Cloudsoft >>> Corporation Limited does not accept responsibility for changes made to this >>> message after it was sent. >>> >>> Whilst all reasonable care has been taken to avoid the transmission of >>> viruses, it is the responsibility of the recipient to ensure that the >>> onward transmission, opening or use of this message and any attachments >>> will not adversely affect its systems or data. No responsibility is >>> accepted by Cloudsoft Corporation Limited in this regard and the recipient >>> should carry out such virus and other checks as it considers appropriate. >> >>
