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/08/17 20:03:47 UTC
JcloudsLocation#rebindMachine and Windows machines
Hi all,
A fairly technical question. I'd like to understand the implications of a
problem before I try to fix it.
Brooklyn has a class called JcloudsLocation that is the main point of
interaction with jclouds. Its duty is to orchestrate jclouds to either
provision new machines or to connect to existing ones.
The two main methods for this are:
public MachineLocation obtain(ConfigBag setup) throws
NoMachinesAvailableException
public JcloudsSshMachineLocation rebindMachine(ConfigBag setup) throws
NoMachinesAvailableException
Calling the first of these causes a new machine to be provisioned. Calling
the latter causes an existing machine to be found and connected to.
Their return types differ. Obtain returns a MachineLocation but rebind a
JcloudsSshMachineLocation. A MachineLocation allows obtain to handle both
Windows and non-Windows machines. A JcloudsSshMachineLocation can only be a
non-Windows VM, and thus my problem: rebindMachine cannot be used to
reconnect to a Windows machine. Unfortunately, rebindMachine is publicly
accessible. There are a number of cases within Brooklyn that expect to get
a JcloudsSshMachineLocation and probably more in downstream projects.
Do I have any other option than to deprecate all of the methods named
`rebindMachine` in favour of a new method named something slightly
different that returns a MachineLocation? Or can I get away with changing
the signature of the method (as was done to obtain earlier this year)?
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#rebindMachine and Windows machines
Posted by Aled Sage <al...@gmail.com>.
Hi Sam,
Good question. In my opinion...
If rebindMachine(ConfigKey) is the best name then let's change the
return type to MachineLocation (or to JcloudsMachineLocation?), rather
than living with a worse name moving forwards. Include in the javadoc
what type the response will be if it's an ssh'able machine versus a
windows machine.
If there is a better name, then let's deprecate + create the new method.
I can't think of a better name.
---
This doesn't follow my memory of our deprecation policy (which I'm
failing to find!).
It doesn't look like we've included it in the docs [1], so we should add
that - let's discuss in a separate thread with a different title.
Aled
[1] https://brooklyn.incubator.apache.org/documentation
On 17/08/2015 19:03, Sam Corbett wrote:
> Hi all,
>
> A fairly technical question. I'd like to understand the implications of a
> problem before I try to fix it.
>
> Brooklyn has a class called JcloudsLocation that is the main point of
> interaction with jclouds. Its duty is to orchestrate jclouds to either
> provision new machines or to connect to existing ones.
>
> The two main methods for this are:
>
> public MachineLocation obtain(ConfigBag setup) throws
> NoMachinesAvailableException
>
> public JcloudsSshMachineLocation rebindMachine(ConfigBag setup) throws
> NoMachinesAvailableException
>
> Calling the first of these causes a new machine to be provisioned. Calling
> the latter causes an existing machine to be found and connected to.
>
> Their return types differ. Obtain returns a MachineLocation but rebind a
> JcloudsSshMachineLocation. A MachineLocation allows obtain to handle both
> Windows and non-Windows machines. A JcloudsSshMachineLocation can only be a
> non-Windows VM, and thus my problem: rebindMachine cannot be used to
> reconnect to a Windows machine. Unfortunately, rebindMachine is publicly
> accessible. There are a number of cases within Brooklyn that expect to get
> a JcloudsSshMachineLocation and probably more in downstream projects.
>
> Do I have any other option than to deprecate all of the methods named
> `rebindMachine` in favour of a new method named something slightly
> different that returns a MachineLocation? Or can I get away with changing
> the signature of the method (as was done to obtain earlier this year)?
>
> Sam
>
Re: JcloudsLocation#rebindMachine and Windows machines
Posted by Sam Corbett <sa...@cloudsoftcorp.com>.
I like your thinking. The connotations of "re" has annoyed me too.
Thanks,
Sam
On 18/08/2015 11:15, Alex Heneveld wrote:
>
> +1
>
> On 18/08/2015 11:14, Aled Sage wrote:
>> +1
>>
>> Actually, I'd prefer registerMachine(ConfigBag).
>>
>> The return type means we can only ever register one machine with this
>> method. But the name "register" is ambiguous for what is being
>> registered.
>>
>> Aled
>>
>>
>> On 18/08/2015 11:05, Alex Heneveld wrote:
>>>
>>> Sam-
>>>
>>> Some people have been using the word "register" for blueprints which
>>> attach to existing systems to bring them under Brooklyn management.
>>> I like it. "rebind" is currently overloaded as it is used mainly
>>> for items coming from persisted state, and the prefix "re" is
>>> misleading in the case where we are bringing something into Brooklyn
>>> for the first time.
>>>
>>> (And I submit that prefix is not present in the word "register"
>>> despite appearances to the contrary!)
>>>
>>> So my suggestion would be to add a new method "register(ConfigBag)"
>>> which returns a MachineLocation, and deprecate rebindMachine(...).
>>>
>>> Best
>>> Alex
>>>
>>>
>>> On 17/08/2015 19:03, Sam Corbett wrote:
>>>> Hi all,
>>>>
>>>> A fairly technical question. I'd like to understand the
>>>> implications of a
>>>> problem before I try to fix it.
>>>>
>>>> Brooklyn has a class called JcloudsLocation that is the main point of
>>>> interaction with jclouds. Its duty is to orchestrate jclouds to either
>>>> provision new machines or to connect to existing ones.
>>>>
>>>> The two main methods for this are:
>>>>
>>>> public MachineLocation obtain(ConfigBag setup) throws
>>>> NoMachinesAvailableException
>>>>
>>>> public JcloudsSshMachineLocation rebindMachine(ConfigBag setup) throws
>>>> NoMachinesAvailableException
>>>>
>>>> Calling the first of these causes a new machine to be provisioned.
>>>> Calling
>>>> the latter causes an existing machine to be found and connected to.
>>>>
>>>> Their return types differ. Obtain returns a MachineLocation but
>>>> rebind a
>>>> JcloudsSshMachineLocation. A MachineLocation allows obtain to
>>>> handle both
>>>> Windows and non-Windows machines. A JcloudsSshMachineLocation can
>>>> only be a
>>>> non-Windows VM, and thus my problem: rebindMachine cannot be used to
>>>> reconnect to a Windows machine. Unfortunately, rebindMachine is
>>>> publicly
>>>> accessible. There are a number of cases within Brooklyn that expect
>>>> to get
>>>> a JcloudsSshMachineLocation and probably more in downstream projects.
>>>>
>>>> Do I have any other option than to deprecate all of the methods named
>>>> `rebindMachine` in favour of a new method named something slightly
>>>> different that returns a MachineLocation? Or can I get away with
>>>> changing
>>>> the signature of the method (as was done to obtain earlier this year)?
>>>>
>>>> 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#rebindMachine and Windows machines
Posted by Alex Heneveld <al...@cloudsoftcorp.com>.
+1
On 18/08/2015 11:14, Aled Sage wrote:
> +1
>
> Actually, I'd prefer registerMachine(ConfigBag).
>
> The return type means we can only ever register one machine with this
> method. But the name "register" is ambiguous for what is being
> registered.
>
> Aled
>
>
> On 18/08/2015 11:05, Alex Heneveld wrote:
>>
>> Sam-
>>
>> Some people have been using the word "register" for blueprints which
>> attach to existing systems to bring them under Brooklyn management.
>> I like it. "rebind" is currently overloaded as it is used mainly for
>> items coming from persisted state, and the prefix "re" is misleading
>> in the case where we are bringing something into Brooklyn for the
>> first time.
>>
>> (And I submit that prefix is not present in the word "register"
>> despite appearances to the contrary!)
>>
>> So my suggestion would be to add a new method "register(ConfigBag)"
>> which returns a MachineLocation, and deprecate rebindMachine(...).
>>
>> Best
>> Alex
>>
>>
>> On 17/08/2015 19:03, Sam Corbett wrote:
>>> Hi all,
>>>
>>> A fairly technical question. I'd like to understand the implications
>>> of a
>>> problem before I try to fix it.
>>>
>>> Brooklyn has a class called JcloudsLocation that is the main point of
>>> interaction with jclouds. Its duty is to orchestrate jclouds to either
>>> provision new machines or to connect to existing ones.
>>>
>>> The two main methods for this are:
>>>
>>> public MachineLocation obtain(ConfigBag setup) throws
>>> NoMachinesAvailableException
>>>
>>> public JcloudsSshMachineLocation rebindMachine(ConfigBag setup) throws
>>> NoMachinesAvailableException
>>>
>>> Calling the first of these causes a new machine to be provisioned.
>>> Calling
>>> the latter causes an existing machine to be found and connected to.
>>>
>>> Their return types differ. Obtain returns a MachineLocation but
>>> rebind a
>>> JcloudsSshMachineLocation. A MachineLocation allows obtain to handle
>>> both
>>> Windows and non-Windows machines. A JcloudsSshMachineLocation can
>>> only be a
>>> non-Windows VM, and thus my problem: rebindMachine cannot be used to
>>> reconnect to a Windows machine. Unfortunately, rebindMachine is
>>> publicly
>>> accessible. There are a number of cases within Brooklyn that expect
>>> to get
>>> a JcloudsSshMachineLocation and probably more in downstream projects.
>>>
>>> Do I have any other option than to deprecate all of the methods named
>>> `rebindMachine` in favour of a new method named something slightly
>>> different that returns a MachineLocation? Or can I get away with
>>> changing
>>> the signature of the method (as was done to obtain earlier this year)?
>>>
>>> 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#rebindMachine and Windows machines
Posted by Aled Sage <al...@gmail.com>.
+1
Actually, I'd prefer registerMachine(ConfigBag).
The return type means we can only ever register one machine with this
method. But the name "register" is ambiguous for what is being registered.
Aled
On 18/08/2015 11:05, Alex Heneveld wrote:
>
> Sam-
>
> Some people have been using the word "register" for blueprints which
> attach to existing systems to bring them under Brooklyn management. I
> like it. "rebind" is currently overloaded as it is used mainly for
> items coming from persisted state, and the prefix "re" is misleading
> in the case where we are bringing something into Brooklyn for the
> first time.
>
> (And I submit that prefix is not present in the word "register"
> despite appearances to the contrary!)
>
> So my suggestion would be to add a new method "register(ConfigBag)"
> which returns a MachineLocation, and deprecate rebindMachine(...).
>
> Best
> Alex
>
>
> On 17/08/2015 19:03, Sam Corbett wrote:
>> Hi all,
>>
>> A fairly technical question. I'd like to understand the implications
>> of a
>> problem before I try to fix it.
>>
>> Brooklyn has a class called JcloudsLocation that is the main point of
>> interaction with jclouds. Its duty is to orchestrate jclouds to either
>> provision new machines or to connect to existing ones.
>>
>> The two main methods for this are:
>>
>> public MachineLocation obtain(ConfigBag setup) throws
>> NoMachinesAvailableException
>>
>> public JcloudsSshMachineLocation rebindMachine(ConfigBag setup) throws
>> NoMachinesAvailableException
>>
>> Calling the first of these causes a new machine to be provisioned.
>> Calling
>> the latter causes an existing machine to be found and connected to.
>>
>> Their return types differ. Obtain returns a MachineLocation but rebind a
>> JcloudsSshMachineLocation. A MachineLocation allows obtain to handle
>> both
>> Windows and non-Windows machines. A JcloudsSshMachineLocation can
>> only be a
>> non-Windows VM, and thus my problem: rebindMachine cannot be used to
>> reconnect to a Windows machine. Unfortunately, rebindMachine is publicly
>> accessible. There are a number of cases within Brooklyn that expect
>> to get
>> a JcloudsSshMachineLocation and probably more in downstream projects.
>>
>> Do I have any other option than to deprecate all of the methods named
>> `rebindMachine` in favour of a new method named something slightly
>> different that returns a MachineLocation? Or can I get away with
>> changing
>> the signature of the method (as was done to obtain earlier this year)?
>>
>> Sam
>>
>
>
Re: JcloudsLocation#rebindMachine and Windows machines
Posted by Alex Heneveld <al...@cloudsoftcorp.com>.
Sam-
Some people have been using the word "register" for blueprints which
attach to existing systems to bring them under Brooklyn management. I
like it. "rebind" is currently overloaded as it is used mainly for
items coming from persisted state, and the prefix "re" is misleading in
the case where we are bringing something into Brooklyn for the first time.
(And I submit that prefix is not present in the word "register" despite
appearances to the contrary!)
So my suggestion would be to add a new method "register(ConfigBag)"
which returns a MachineLocation, and deprecate rebindMachine(...).
Best
Alex
On 17/08/2015 19:03, Sam Corbett wrote:
> Hi all,
>
> A fairly technical question. I'd like to understand the implications of a
> problem before I try to fix it.
>
> Brooklyn has a class called JcloudsLocation that is the main point of
> interaction with jclouds. Its duty is to orchestrate jclouds to either
> provision new machines or to connect to existing ones.
>
> The two main methods for this are:
>
> public MachineLocation obtain(ConfigBag setup) throws
> NoMachinesAvailableException
>
> public JcloudsSshMachineLocation rebindMachine(ConfigBag setup) throws
> NoMachinesAvailableException
>
> Calling the first of these causes a new machine to be provisioned. Calling
> the latter causes an existing machine to be found and connected to.
>
> Their return types differ. Obtain returns a MachineLocation but rebind a
> JcloudsSshMachineLocation. A MachineLocation allows obtain to handle both
> Windows and non-Windows machines. A JcloudsSshMachineLocation can only be a
> non-Windows VM, and thus my problem: rebindMachine cannot be used to
> reconnect to a Windows machine. Unfortunately, rebindMachine is publicly
> accessible. There are a number of cases within Brooklyn that expect to get
> a JcloudsSshMachineLocation and probably more in downstream projects.
>
> Do I have any other option than to deprecate all of the methods named
> `rebindMachine` in favour of a new method named something slightly
> different that returns a MachineLocation? Or can I get away with changing
> the signature of the method (as was done to obtain earlier this year)?
>
> 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.