You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by Sam Corbett <sa...@cloudsoftcorp.com> on 2015/06/11 13:24:16 UTC
JcloudsLocation behaviour
Hi all,
A couple of ideas for JcloudsLocation.
I'd like to make it possible to incorporate existing machines into Brooklyn
as Jclouds locations rather than bring-your-own-node locations. To do this
I'd like to add a new config key, named something like "provision mode".
Valid options are:
* obtain: The current behaviour. Always provisions a new machine.
* rebind: Attempt to rebind to an existing machine using the location
properties and entity's provisioning properties. Fail if no suitable
machine is found.
* rebind or obtain: As rebind but calling `obtain` rather than failing if
no existing machine is found.
Deployments would fail if an existing machine was found but Brooklyn cannot
connect to it.
To aid the rebind cases I would add a second config key that sets the
predicate used to determine whether an existing machine should be used. The
current predicate
(brooklyn.location.jclouds.JcloudsLocation.RebindToMachinePredicate)
cross-checks IDs and hostnames. An obvious extension would be to look at a
machine's tags.
I think this would be beneficial for users that want to bring existing
systems under Brooklyn's control.
Second, when stopping entities is there any way to distinguish between
stopping and destroying their locations? The stop effector currently
accepts "stopProcessMode" and "stopMachineMode" arguments. I'm wondering if
there's a case for a third argument named "destroyMachineMode" (with values
always/never/if-not-stopped) that allows the caller to distinguish between
suspending and destroying instances.
Any thoughts?
Thanks,
Sam
--
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: JcloudsLocation behaviour
Posted by Sam Corbett <sa...@cloudsoftcorp.com>.
Hi Svet
Thanks for your comments.
Re provision mode vs. byon locations:
A BYON location isn't incorporated into the rest of Brooklyn's
lifecycle, so for example you couldn't destroy the instance when
stopping the associated Brooklyn entity. (Correct me if I'm wrong or out
of date!) Of more interest is that a BYON location cannot create an
instance if the target does not exist (i.e. the rebind or obtain mode).
Within a single deployment it might seem strange that a user might not
know whether their location exists or not but it makes more sense if we
attempted to handle such a case across many deployments of the same
blueprint.
Perhaps simply starting with "obtain" and "rebind" is sufficient. If
there is demand for "rebind or obtain" it will be straightforward to
include later.
Re stop vs destroy:
I think it's as much to do with how users understand what "stop" means
to Brooklyn as much as how useful the proposed functionality is. Stop
and unmanage works but is unintuitive.
Sam
On 15/06/2015 12:18, Svetoslav Neykov wrote:
> Hi Sam,
> Could you describe what this approach gives in comparison with BYON location. In what cases should the one or the other be preferred. Or does this supersede BYON?
>
> Re stop vs destroy - If I've ever had a need to manage a machine outside of Brooklyn in any way I stop the process and then unmanage the entity. Adding the functionality to the STOP effector still has benefits, but no opinion about it. What I'd like to note is that when adding it we should do it in a backwards compatible way. Currently stopMachineMode will destroy the machine so we should keep it that way in case destroyMachineMode is not set.
>
> Svet.
>
>
>
>> On 11.06.2015 г., at 14:24, Sam Corbett <sa...@cloudsoftcorp.com> wrote:
>>
>> Hi all,
>>
>> A couple of ideas for JcloudsLocation.
>>
>> I'd like to make it possible to incorporate existing machines into Brooklyn
>> as Jclouds locations rather than bring-your-own-node locations. To do this
>> I'd like to add a new config key, named something like "provision mode".
>> Valid options are:
>> * obtain: The current behaviour. Always provisions a new machine.
>> * rebind: Attempt to rebind to an existing machine using the location
>> properties and entity's provisioning properties. Fail if no suitable
>> machine is found.
>> * rebind or obtain: As rebind but calling `obtain` rather than failing if
>> no existing machine is found.
>>
>> Deployments would fail if an existing machine was found but Brooklyn cannot
>> connect to it.
>>
>> To aid the rebind cases I would add a second config key that sets the
>> predicate used to determine whether an existing machine should be used. The
>> current predicate
>> (brooklyn.location.jclouds.JcloudsLocation.RebindToMachinePredicate)
>> cross-checks IDs and hostnames. An obvious extension would be to look at a
>> machine's tags.
>>
>> I think this would be beneficial for users that want to bring existing
>> systems under Brooklyn's control.
>>
>> Second, when stopping entities is there any way to distinguish between
>> stopping and destroying their locations? The stop effector currently
>> accepts "stopProcessMode" and "stopMachineMode" arguments. I'm wondering if
>> there's a case for a third argument named "destroyMachineMode" (with values
>> always/never/if-not-stopped) that allows the caller to distinguish between
>> suspending and destroying instances.
>>
>> Any thoughts?
>>
>> Thanks,
>>
>> Sam
>>
>> --
>> 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.
>
--
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: JcloudsLocation behaviour
Posted by Svetoslav Neykov <sv...@cloudsoftcorp.com>.
Hi Sam,
Could you describe what this approach gives in comparison with BYON location. In what cases should the one or the other be preferred. Or does this supersede BYON?
Re stop vs destroy - If I've ever had a need to manage a machine outside of Brooklyn in any way I stop the process and then unmanage the entity. Adding the functionality to the STOP effector still has benefits, but no opinion about it. What I'd like to note is that when adding it we should do it in a backwards compatible way. Currently stopMachineMode will destroy the machine so we should keep it that way in case destroyMachineMode is not set.
Svet.
> On 11.06.2015 г., at 14:24, Sam Corbett <sa...@cloudsoftcorp.com> wrote:
>
> Hi all,
>
> A couple of ideas for JcloudsLocation.
>
> I'd like to make it possible to incorporate existing machines into Brooklyn
> as Jclouds locations rather than bring-your-own-node locations. To do this
> I'd like to add a new config key, named something like "provision mode".
> Valid options are:
> * obtain: The current behaviour. Always provisions a new machine.
> * rebind: Attempt to rebind to an existing machine using the location
> properties and entity's provisioning properties. Fail if no suitable
> machine is found.
> * rebind or obtain: As rebind but calling `obtain` rather than failing if
> no existing machine is found.
>
> Deployments would fail if an existing machine was found but Brooklyn cannot
> connect to it.
>
> To aid the rebind cases I would add a second config key that sets the
> predicate used to determine whether an existing machine should be used. The
> current predicate
> (brooklyn.location.jclouds.JcloudsLocation.RebindToMachinePredicate)
> cross-checks IDs and hostnames. An obvious extension would be to look at a
> machine's tags.
>
> I think this would be beneficial for users that want to bring existing
> systems under Brooklyn's control.
>
> Second, when stopping entities is there any way to distinguish between
> stopping and destroying their locations? The stop effector currently
> accepts "stopProcessMode" and "stopMachineMode" arguments. I'm wondering if
> there's a case for a third argument named "destroyMachineMode" (with values
> always/never/if-not-stopped) that allows the caller to distinguish between
> suspending and destroying instances.
>
> Any thoughts?
>
> Thanks,
>
> Sam
>
> --
> 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.
--
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.