[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