On 24/02/09 08:20 AM, Michael Schuster wrote:
> Darren,
>
> thx for your comments, some answers inline:
>
> On 02/23/09 18:30, Darren Reed wrote:
>> On 23/02/09 02:39 PM, Michael Schuster wrote:
>>> All,
>>>
>>> I'm now working on getting the recently discussed server IDs in 
>>> place; here's a question:
>>>
>>> What do we do with a server's ID when it is removed from a 
>>> servergroup? Do we want to "remember" its ID for re-use, in case the 
>>> same server (identified by IP address) ever comes back, and also to 
>>> make sure no other server gets assigned the same ID, and causes 
>>> confusion?
>>
>> So rather than worry about what to do when it is removed,
>> concentrate on asking and answering the question about
>> what is it intended to mean. And how you want the
>> number space to behave. Also, do you mean the base
>> name of the serverID or the individual numbers or
>> the combination of the string and number?
>
> the latter, ie the individual server's unique ID (as you correctly 
> infer).
>
>> According to your email, the serverID is just the string
>> given to the server group, but in that case it makes no
>> sense to allow for "remembering" if an IP# goes away,
>> so I'm concluding that you mean the individual serverID
>> and not the base name.
>>
>> For example:
>> - for what purpose is the serverID being published?
>
> to give the user a unique handle that easier to memorise and 
> manipulate than IP addresses (esp. IPv6).
>
>> - how do you intend for it to be used and for how long?
>
> for as long as the load balancer is up and the server in question is 
> in use.

Therefore the id can be reused.


>> - how will a reboot impact serverIDs?
>
> it shouldn't at all if the configuration doesn't change.
>
>> - do you want the numbers to simply increase?
>
> yes.
>
>> - what is the range of numbers intended to be?
>
> We haven't fleshed that out, but I guess 10^5 is a sufficient range 
> (input welcome!)

Given the answer to the previous question, why do you suppose 10^5 is 
big enough?


>> - is the system admin allowed to control the id#?
>
> ATM there's no provision for that.

That's not an answer to the question, which expects either "yes" or "no".


>> - if the id is assigned automagically but I have to replace a box 
>> with id#X, why can't I reassign id#X?
>
> do you mean
> a) use the same id#X for a different box that replaced the old one? 
> does it use the same IP? if so, just disable the back end server, 
> replace it, re-enable it.
> b) assign a new id# to the same server or the id# of the replaced 
> server to one with a different IP address?

yes.


hmm... rather than invent a new term, serverID, why not just call it an 
"alias"?

Darren


Reply via email to