CloudFoundry Location Integration

[Jose Carrasco <jo...@lcc.uma.es>]

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

Re: PaaS Location Integration

[Jose Carrasco <jo...@lcc.uma.es>]

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 <hz...@gmail.com> 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 <an...@cloudsoftcorp.com> 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 <jo...@lcc.uma.es> 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.
>> 
>> 

Re: PaaS Location Integration

[Hadrian Zbarcea <hz...@gmail.com>]

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 <an...@cloudsoftcorp.com> 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 <jo...@lcc.uma.es> 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.
>
>

PaaS Location Integration

[Jose Carrasco <jo...@lcc.uma.es>]

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 <an...@cloudsoftcorp.com> 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 <jo...@lcc.uma.es> 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.

Re: CloudFoundry Location Integration

[Andrea Turli <an...@cloudsoftcorp.com>]

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 <jo...@lcc.uma.es> 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.