Στις 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 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 > > -- > 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
