[Sheepdog] [RFC PATCH] sheep: add nohalt to sheepdog_config

[Liu Yuan]

On 10/19/2011 03:43 PM, MORITA Kazutaka wrote:

> At Wed, 19 Oct 2011 14:35:05 +0800,
> Liu Yuan wrote:
>>
>> On 10/19/2011 02:25 PM, MORITA Kazutaka wrote:
>>
>>> Signed-off-by: MORITA Kazutaka <morita.kazutaka at lab.ntt.co.jp>
>>> ---
>>> Hi Yuan,
>>>
>>> Isn't it better to add a nohalt field instead of a generic name
>>> "flags"?  This would be the most intuitive way.  The size of config
>>> file wouldn't become a problem, so we don't need to save bits, I
>>> think.
>>>
>>> How do you think?
>>>
>>
>>
>> Hi Kazum,
>>
>> I think we'd better live with flags. with set/get_cluster_falgs(). Then
>> we can add more options (for e.g. noqlimit, no rquest queue limit later
> 
> I guess these options are not cluster-wide ones.  The size of the
> limit depends on each machine spec.  How about make them the sheep
> command line options?
> 


Hmm, the noqlimit is just my example, thought it is lame. For rquest
queue limit specifically, I agree with you.

>> for the cluster that doesn't need it at all. etc.), which will use this
>> interface to store it in the local storage.
>>
>> If not, we'll have to write functions to store those options locally
>> every time we add a new option.
> 
> But we need to define set/get functions in either case when we add a
> non-boolean option to sheepdog_config.  In addition, I'm not sure we
> really have so many cluster-wide options.


Ah, then 16 options would be good enough for cluster wide option. So
nohalt is the first one. And I think, there are more cases to come, that
just need one bit.

If non-boolean option really makes its debut, we can then write some
generic functions to handle those case.

> 
> Anyway, we should read sheepdog_config only when starting Sheepdog,
> then we don't need to implement a get function for each field.
>


Then, this does support flags!

Thanks,
Yuan