auto-detection featured few bugs lately which convinced me that it must be deprecated/removed from the code in favor of adding manual set of the provider type. main reasons for that: a. the provider is type is known by the user b. identifying a provider by the rootDSE attributes is error-prone, not reliable etc... specially if the support matrix is growing c. auto-detection logic is duplicated (and not shared) between the backend code and the manage-domains tool (nevermind the reasons now) A manual set of the provider type requires a new configuration field for a domain and the question is the upgrade path which may look like * set the provider type to default Active Directory (because its more likely to be the provider type)

* things not working - use the engine-manage-domains and choose the provider type. * optionally - keep the auto-detection (of the tool only!) if user wants to use it. your suggestion and thoughts...

Thanks, Roy

From: "Livnat Peer" <lpeer(a)redhat.com&gt; To: "Roy Golan" <rgolan(a)redhat.com&gt; Cc: "Oved Ourfalli" <ovedo(a)redhat.com&gt;, engine-devel(a)ovirt.org Sent: Monday, April 9, 2012 12:11:55 PM Subject: Re: [Engine-devel] deprecating auto-detection of Ldap provider types On 09/04/12 11:42, Roy Golan wrote: > auto-detection featured few bugs lately which convinced me that it > must > be deprecated/removed from > the code in favor of adding manual set of the provider type. > > main reasons for that: > a. the provider is type is known by the user > b. identifying a provider by the rootDSE attributes is error-prone, > not > reliable etc... specially if the support matrix is growing > c. auto-detection logic is duplicated (and not shared) between the > backend code and the manage-domains tool (nevermind the reasons > now) > +1 for removing this 'feature'

> A manual set of the provider type requires a new configuration > field for > a domain and the > question is the upgrade path which may look like > > * set the provider type to default Active Directory (because its > more > likely to be the provider type) > * things not working - use the engine-manage-domains and choose > the > provider type. > * optionally - keep the auto-detection (of the tool only!) if user > wants to use it. I think we should require that the user specifies the provider type (from now on), and enable editing this field of course. Another upgrade proposal is to populate the provider type only upon the first time we need to use this domain (and it is not populated) by using the current 'auto-detect' mechanism. By taking the above approach we don't break behavior for the user and we enable manually fixing of the domain provider type (which is a bypass for all current bugs in the auto-detect). Livnat > > your suggestion and thoughts... > > Thanks, > Roy > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

On 04/09/2012 12:11 PM, Livnat Peer wrote: > On 09/04/12 11:42, Roy Golan wrote: >> auto-detection featured few bugs lately which convinced me that it must >> be deprecated/removed from >> the code in favor of adding manual set of the provider type. >> >> main reasons for that: >> a. the provider is type is known by the user >> b. identifying a provider by the rootDSE attributes is error-prone, not >> reliable etc... specially if the support matrix is growing >> c. auto-detection logic is duplicated (and not shared) between the >> backend code and the manage-domains tool (nevermind the reasons now) >> > +1 for removing this 'feature' > >> A manual set of the provider type requires a new configuration field for >> a domain and the >> question is the upgrade path which may look like >> >> * set the provider type to default Active Directory (because its more >> likely to be the provider type) >> * things not working - use the engine-manage-domains and choose the >> provider type. >> * optionally - keep the auto-detection (of the tool only!) if user >> wants to use it. > I think we should require that the user specifies the provider type > (from now on), and enable editing this field of course. > > Another upgrade proposal is to populate the provider type only upon the > first time we need to use this domain (and it is not populated) by using > the current 'auto-detect' mechanism. and remove it the next version?

this means the auto-detection code remains in the backend code.

I think its the best to remove it totally but If we want to keep this functionality I rather just leave it in manage-domains alone,although if its another step for the user.

> > By taking the above approach we don't break behavior for the user and we > enable manually fixing of the domain provider type (which is a bypass > for all current bugs in the auto-detect). > > > Livnat > > >> your suggestion and thoughts... >> >> Thanks, >> Roy >> >> >> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel

Excuse my ignorance... but I would like to understand the "new" behavior on: - clean install? POC?

- How do I change the provider, after installation?

- upgrade path.

Miki ----- Original Message ----- > From: "Livnat Peer&quot;&lt;lpeer(a)redhat.com&gt; > To: "Roy Golan&quot;&lt;rgolan(a)redhat.com&gt; > Cc: "Oved Ourfalli&quot;&lt;ovedo(a)redhat.com&gt;, engine-devel(a)ovirt.org > Sent: Monday, April 9, 2012 2:47:50 PM > Subject: Re: [Engine-devel] deprecating auto-detection of Ldap provider types > > On 09/04/12 14:42, Roy Golan wrote: >> On 04/09/2012 12:11 PM, Livnat Peer wrote: >>> On 09/04/12 11:42, Roy Golan wrote: >>>> auto-detection featured few bugs lately which convinced me that >>>> it must >>>> be deprecated/removed from >>>> the code in favor of adding manual set of the provider type. >>>> >>>> main reasons for that: >>>> a. the provider is type is known by the user >>>> b. identifying a provider by the rootDSE attributes is >>>> error-prone, not >>>> reliable etc... specially if the support matrix is growing >>>> c. auto-detection logic is duplicated (and not shared) between >>>> the >>>> backend code and the manage-domains tool (nevermind the reasons >>>> now) >>>> >>> +1 for removing this 'feature' >>> >>>> A manual set of the provider type requires a new configuration >>>> field for >>>> a domain and the >>>> question is the upgrade path which may look like >>>> >>>> * set the provider type to default Active Directory (because its >>>> more >>>> likely to be the provider type) >>>> * things not working - use the engine-manage-domains and choose >>>> the >>>> provider type. >>>> * optionally - keep the auto-detection (of the tool only!) if >>>> user >>>> wants to use it. >>> I think we should require that the user specifies the provider >>> type >>> (from now on), and enable editing this field of course. >>> >>> Another upgrade proposal is to populate the provider type only >>> upon the >>> first time we need to use this domain (and it is not populated) by >>> using >>> the current 'auto-detect' mechanism. >> and remove it the next version? > yes > >> this means the auto-detection code remains in the backend code. > only until next version > >> I think its the best to remove it totally but If we want to keep >> this >> functionality I rather just leave it in manage-domains >> alone,although if >> its another step for the user. > I don't *want* to keep it but unless we want to set it hard coded > during > upgrade I don't see how can we remove it. > > BTW if we have to leave it in I would say to remove it from the tool > and > leave in the backend (you have to have it in the backend for > transparent > upgrade) > > >>> By taking the above approach we don't break behavior for the user >>> and we >>> enable manually fixing of the domain provider type (which is a >>> bypass >>> for all current bugs in the auto-detect). >>> >>> >>> Livnat >>> >>> >>>> your suggestion and thoughts... >>>> >>>> Thanks, >>>> Roy >>>> >>>> >>>> >>>> _______________________________________________ >>>> Engine-devel mailing list >>>> Engine-devel(a)ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel >