[rudder-dev] new autofs techniques

[Nicolas Charles]

On 26/03/2013 10:54, Michael Gliwinski wrote:
> On Monday 18 Mar 2013 18:49:51 Matthieu CERDA wrote:
>> Le 18/03/2013 01:11, Michael Gliwinski a écrit :
>>> I've a couple of techniques for managing AutoFS, mounts and maps.  So
>>> this isn't quite finished yet, it works, but could probably use some
>>> improvements. I'd appreciate feedback, so please, poke holes in it :D
>> I corrected some small reporting issues, and made a pull request for
>> your Techniques. =>  http://www.rudder-project.org/redmine/issues/3360
> Wow, thanks, I expected there would be a ton of things I need to correct first
> :)
>
>> There is still a little bit of work to do (principally, using the rudder
>> reporting bundle instead of "bare" ones), but you did a great job !
>>
>> Your technique is really well presented and commented, it is a pleasure
>> to read. Thanks a lot !
> Thanks!
>
> I read the comments on github, I must admit, I'm not really sure what
> TRACKINGVARIABLE and TRACKINGKEY are.  However that does remind me that I
> actually meant for AutoFSMaster to be unique (i.e. not multi-instance), I just
> forgotten to put that in metadata.xml.

They are the most complex part of the technique writing. When the 
promises are generated, Rudder "aggregates" together all the variables 
of all the directives based on the same Techniques; and it flattens all 
variables in multi-values sections.
So we need to keep a track of which variable value comes from with 
Directives, and there come the TRACKINGVARIABLE, which have the size of 
another variable if it is multivalued

With a small example issued from checkGenericFileContent, we have the 
TRACKINGVARIABLE with a SAMESIZEAS GENERIC_FILE_CONTENT_PATH
GENERIC_FILE_CONTENT_PATH is in a mutlivalued sections, meaning we can 
have several for each Directives

If we have three directives, configured as follow :

DirectiveA : file 1, file2
DirectiveB : file 3
DirectiveC : file 4, file 5, file 6

GENERIC_FILE_CONTENT_PATH will end up being a list of 6 elements :
file 1, file2, file 3, file 4, file 5, file 6
And TRACKINGKEY will also be a list of 6 elements :
DirectiveA, DirectiveA, DirectiveB, DirectiveC, DirectiveC, DirectiveC

So that we can iterate over each elements, as well as the reporting, to 
get proper report for each file

Note : we are looking forward into removing this overly complex system, 
and I apologise for creating something that complex

>
> I didn't use the new reporting bundles as I thought they are only in 2.5 and I
> needed to get it to somewhat work on 2.4 at least until I upgrade to 2.5
> (hopefully very soon).
>
>> I wiill keep you informed about updates on this subject. (Well,
>> especially when the pull request will be validated ! :) )
> I can submit a corrected patch, let me know if there are other things to
> correct.

Thank you very much Michael !

Nicolas