Στις 19 Νοε 2013, 11:38 π.μ., ο/η Spyros Trigazis <[email protected]> έγραψε:

> 
> Στις 19 Νοε 2013, 10:49 π.μ., ο/η Michele Tartara <[email protected]> 
> έγραψε:
> 
>> On Tue, Nov 19, 2013 at 9:37 AM, Helga Velroyen <[email protected]> wrote:
>>> 
>>> 
>>> 
>>> On Tue, Nov 19, 2013 at 9:28 AM, Spyros Trigazis <[email protected]> wrote:
>>>> 
>>>> 
>>>> Στις 19 Νοε 2013, 9:55 π.μ., ο/η Helga Velroyen <[email protected]>
>>>> έγραψε:
>>>> 
>>>> Hi!
>>>> 
>>>> some thoughts:
>>>> 
>>>> On Fri, Nov 15, 2013 at 8:02 PM, Spyros Trigazis <[email protected]>
>>>> wrote:
>>>>> 
>>>>> Hello team,
>>>>> 
>>>>> I'm working on how to pass parameters to the iallocator. Currently the
>>>>> default iallocator doesn't accept any parameters from the user. To add
>>>>> this functionality a new field named "default_iallocator_parameters" (or
>>>>> something shorter) is going to be added to config.data under cluster.
>>>>> Since --mond and --ignore-dynu are both opt-in options the field will be
>>>>> empty by default and the user could modify it calling gnt-cluster
>>>>> modify.
>>>>> 
>>>>> Two questions (with obvious answers):
>>>>> * The new field in the rpc defs should be a string?
>>>> 
>>>> 
>>>> Can  you give some examples for those parameters?
>>>> 
>>>> 
>>>> --mond and --ignore-dynu are the only one and it doesn't make sense to
>>>> use them combined at the moment since hail queries only the CPU load
>>>> data collector. But in the future such need might occur.
>>> 
>>> 
>>> I see, I would also leave it open for other allocators to be used, but let's
>>> see what michele says about it.
>> 
>> Yes, the idea of accepting any parameter and just "passing it along"
>> came up exactly as a way to allow other allocators to be used, given
>> that we cannot know what parameters they have.
> 
> This means that ganeti is agnostic to the parameters of any allocator.
> 
>> 
>> 
>>> 
>>>> 
>>>> 
>>>> I would imagine them being a string when called on the commandline,
>>>> similar to the disk specifications, something like
>>>> 
>>>> --default-iallocator-parameters=key1=value2,key2=value2...
>>>> (make the separators consistent, I am not sure they are right in this
>>>> example)
>>>> 
>>>> Once the parameters reach RPC level, I would expect them to be in a
>>>> dictionary already (similar to hvparams then)
>>>> 
>>>> 
>>>> ack
>> 
>> Yes, I agree to. Transform the string into a dictionary and then pass
>> that along.
> 
> I'm a bit confused. When using a data structure like dictionary means
> that we are going to handle the contents of it in some way, check if
> something is missing, sorting etc. In our case we are simply passing
> them to the next method. Another problem with the dict is the following:
> 
> --mond is a parameter that does take any values. It indicates to query

does -> doesn't

> or not MonD (True/False) but it isn't something like --mond=yes or
> --mond=true. So, what is going to be the key value pair? Say, mond:
> true. But, another parameter might be --aparameter=2.5. In this case the
> key, value pair in the dict is going to be aparameter: 2.5. Finally,
> ganeti should know handle them. What do you think?
> 
>> 
>>>> 
>>>> 
>>>> Btw. shouldn't it be only "default_allocator_parameters" (without the
>>>> "i"?) since other (hypothetical) allocator implementations could uke sense,
>>>> but maybe give first some examples what the parameters are that you have in
>>>> mind? We se them, too?
>>>> 
>>>> 
>>>> ack
>> 
>> I think default_iallocator_parameters is the correct name. The generic
>> name, the name of the interface, is iallocator
>> (http://docs.ganeti.org/ganeti/master/html/iallocator.html), whereas
>> the name of our iallocator is hail.
> 
> ack
> 
>> 
>>>> 
>>>> 
>>>>> 
>>>>> * gnt-cluster info must return the new field, too?
>>>> 
>>>> 
>>>> I would suggest that, yes.
>>>> 
>>>> 
>>>> ack
>>>> 
>>>> 
>>>>> 
>>>>> 
>>>>> And two more:
>>>>> * What kind of tests should I right?
>>>> 
>>>> 
>>>> Check that setting and changing and resetting (if reasonable) of the
>>>> parameter is done correctly (compare to vgname for example). Add tests to
>>>> iallocator_unittest.py that check if the parameters are read and processed
>>>> correctly. There might be even more chances to test this, those are just 
>>>> the
>>>> ones that come in to my mind directly.
>>>> 
>>>> 
>>>> ack
>>>> 
>>>> 
>>>>> 
>>>>> * Should the user pass parameters to iallocator when invoking
>>>>> gnt-instanse add, or he should only modify config.data to do that?
>>>> 
>>>> 
>>>> I think that would make sense, but maybe give first some examples what the
>>>> parameters are that you have in mind? We could also do that later and first
>>>> go with the one in the cluster config.
>>>> 
>>>> 
>>>> ack
>>>> 
>>>> Thanks,
>>>> Spyros
>>>> 
>>> 
>>> Cheers,
>>> Helga
>>>> 
>>>> 
>>>> Cheers,
>>>> Helga
>>>> 
>>>> --
>>>> --
>>>> Helga Velroyen | Software Engineer | [email protected] |
>>>> 
>>>> Google Germany GmbH
>>>> Dienerstr. 12
>>>> 80331 München
>>>> 
>>>> Registergericht und -nummer: Hamburg, HRB 86891
>>>> Sitz der Gesellschaft: Hamburg
>>>> Geschäftsführer: Graham Law, Christine Elizabeth Flores
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> --
>>> Helga Velroyen | Software Engineer | [email protected] |
>>> 
>>> Google Germany GmbH
>>> Dienerstr. 12
>>> 80331 München
>>> 
>>> Registergericht und -nummer: Hamburg, HRB 86891
>>> Sitz der Gesellschaft: Hamburg
>>> Geschäftsführer: Graham Law, Christine Elizabeth Flores
>> 
>> Thanks,
>> Michele
> 
> Thanks,
> Spyros

Spyros

> 
>> 
>> -- 
>> Google Germany GmbH
>> Dienerstr. 12
>> 80331 München
>> 
>> Registergericht und -nummer: Hamburg, HRB 86891
>> Sitz der Gesellschaft: Hamburg
>> Geschäftsführer: Graham Law, Christine Elizabeth Flores
> 

Reply via email to