brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Carrasco <jo...@lcc.uma.es>
Subject Re: PaaS Location Integration
Date Mon, 14 Dec 2015 13:32:08 GMT
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 <hzbarcea@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 <andrea.turli@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 <josec@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.
>> 
>> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message