[Freeipa-devel] "Commit comments log" functionality in IPA

Dmitri Pal dpal at redhat.com
Fri Nov 7 16:33:16 UTC 2008


Simo Sorce wrote:
>
> I think comments may contain information that should not be widespread,
> so I do not think we should put them in the policy file (at least not in
> the clear, maybe encrypted).
>   

Yes they might contain information that should not be sent to clients.

> If disclosing comments to clients is not a problem, Sumit's 

IMO it is problem.

> suggestion
> seem to me *much* more appropriate. It will preserve all comments when
> you do changes to a policy on a staging test installation and then later
> on you transport them to the production environment (export policy,
> import policy). This would be an extremely valuable feature imo.
>
>   
In the test environment you are playing with the policy. You are 
polishing it so that it does what you need.
I would say that in this case the mandatory commenting should be disabled.
It might take multiple iterations and since it is not a production 
environment to come to a good state. You do not want to be  annoyed with 
these comments.
But once you import it into the production system it all becomes formal. 
When you apply policy to the production system that is when you are 
asked to provide a comment.
So really based on this comments inside the policy do not have much 
value IMO.



>> It will also cause more replication since policies a compressed XMLs. 
>>     
>
> No, you add a comment when you change a policy, so you are already
> rewriting the XML file.
>   

No  - you add a comment when you apply the policy not when you change it.
You can be editing and saving policy several times but until you click 
the "apply" button it is not offical.
Clicking apply button will just change the link object not the policy 
itself. More details about these things are coming in the DS schema  
spec I am writing so stay tuned.

>   
>> Change to a comment will trigger the update of the whole attribute.
>>     
>
> Your description of the feature sounded like comments cannot be changed
> once the operation is committed so this would not be a problem.
>
>   
I was planning to use the comments not only with policies but with role 
mapping and HBAC rules.
When you edit configuration policy (as I said above) you are not asked 
to provide a comment - only when you apply it.
HBAC rules and role mapping are different they become "official" when 
you save them so comment might be required when you save them.


> Simo.
>
>   

Any design solution I suggest is based on several principles:
a) User of the system goes first. Requirements take precedence over our 
convenience or desire to create a nice architecture.
b) Creating nice and logical architecture.
c) Use what you already have and do not invent the wheel (we have DS it 
is our data store - let us deal with it)
d) Keep things simple and self contained so that you do not create more 
dependencies out of box
e) Create a vision where you want to be from a big picture and go to it 
in incremental steps keeping in mind the ultimate goal. Do not try to 
boil an ocean. But do not grind everything to very small pieces this is 
unreasonable too.
f) Do not re-argue the decisions that were already made regardless 
whether you like them or not - they are a base for the new designs. You 
really need to have a solid foundation to steadily move forward.
g) While designing something I consider that:
   1) One data store is always better than more than one. It is always 
powers of magnitude more work to have data spread around.
   2) Do not send around extra data  if you do not need. Keep protocols 
crisp to contain only data needed.
   3) Follow standards where it makes sense. Cut the corners where it 
does not.
   4) Performance and scalability is important
   5) Early optimization is bad but design that does not require any 
further optimization is a good design.
  
This is not for discussion (or at least we can discuss it in a separate 
thread and share our contradicting positions).
This is just a statement to clarify my point of view and explain where I 
am coming from and why I am suggesting what I am suggesting.

Thanks
Dmitri




More information about the Freeipa-devel mailing list