On Mon, Dec 21, 2015 at 2:10 PM, Yedidyah Bar David wrote: > On Sun, Dec 20, 2015 at 9:50 PM, Martin Perina wrote: > > > > >
[snip] > >> > >> So you should run engine-setup after you update this package. > >> > >> Martin - is this intentional? Why not update the package automatically > >> during engine-setup? > >> > >> Or even version-lock it? I do not think people should expect their > engine > >> to not allow logins after they run 'yum update'. Adding also Sandro. > > > > Hi, > > > > there are several reasons for this: > > > > 1. aaa-jdbc is an engine 3.6 extension, engine requires its presence to > > provide 'internal' domain but it doesn't require any specific version, > > so users may update aaa-jdbc independently on engine if they need > > features provided provided by new version > > > > 2. engine-setup automatically configures/upgrades 'internal' domain, but > > users may define manually other domains (as described in README.admin) > > and those domains are not touched by engine-setup at all > > > > 3. Due to 1. and 2. we decided not to define version specific requirement > > between engine and aaa-jdbc in engine-setup (same behaviour as already > > exists for other engine extensions). So users may for example upgrade > > engine, but leave aaa-jdbc as is or leave engine as is and upgrade > > aaa-jdbc if they need it. Users just need to get used to read doc > > before doing upgrade. > > Now filed: https://bugzilla.redhat.com/show_bug.cgi?id=1293338 > > Best, > -- > Didi > Thanks, I gave my contribute inside the bugzilla. I personally felt this behavior could potentially break many oVirt and possibly RHEV installations based on the internal profile and your action seems to confirm it. As a user I disagree with Martin point in 3. as I'm usually inclined to read the docs but not all the READMEs provided by any single package in the system. I didn't find a clear reference to this step inside the oVirt web documentation, but I could be wrong. I rememebr about it only when I played with FreeIPA authentication in oVirt, but not in internal usage. But if this problem can become an opportunity to make both docs and users better entities it's not a problem for me... Gianluca
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users