On Fri, 02 Dec 2011, Jan Cholasta wrote:
> >>I don't like the idea of introducing a new class every time we need a
> >>ReadOnly attribute to be writable. There's quite a few places in the
> >>code where we do object.__setattr__ on ReadOnly objects. IMO the right
> >>thing to do would be to add means of whitelisting ReadOnly attributes
> >>that need to stay writable after locking.
> >>>You can move those _select_ca(), _select_any_master(),
> >>>_host_has_service() to CaCache as they seem to not depend on anything
> >>>in class ca but rather use global api.env.
> >>>This way you will get is a fairly simple CaCache class reusable both
> >>>in ca and ra classes.
> >What is the status of this patch?
> It fixes the issue and I wouldn't mind leaving it as it is.
I still don't like it. There is nothing in CA that really requires
enabling writting to ReadOnly after locking. ReadOnly is a fundamental
promise of our API and breaking it should be possible only for cases
where any other approach will be ineffective. This particular case is
rather poor implementation of CA/RA classes that could be solved in a
Sometimes you need to hold promises. ;)
/ Alexander Bokovoy
Freeipa-devel mailing list