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

[MORITA Kazutaka]

At Wed, 19 Oct 2011 16:01:42 +0800,
Liu Yuan wrote:
> 
> 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!

Okay, agreed, let's use flags :)

Thanks,

Kazutaka