From Doug.Leavitt at Sun.COM Tue Jan 8 19:10:28 2008 From: Doug.Leavitt at Sun.COM (Doug Leavitt) Date: Tue, 08 Jan 2008 21:10:28 -0600 Subject: [Duckwater-discuss] Versioning fast track draft Message-ID: <47843B24.3090909@sun.com> Attached is the current versioning fast track draft proposal. This is the proposed fast track that specifies the existence of the _nss_[backend]_version variable with a NULL pointer value as a signal that the backend has been updated to Sparks PSARC/2005/133 thereby allowing nscd to load the foreign backend. The draft states that duckwater will specify all the other finder APIs and additional post PSARC/2005/133 details as part of that project. The point is to deliver this subset of the duckwater enhancement as a patchable fix for s10, so that cluster and other backends can cache again. About 90-95% of the draft is explanation. About 5% content. Sparks/duckwater teams, Please review and comment. Stacey/Honsing, Are you ok with the wording/references and to the nss_cluster issues? If possible, I would like to get this sent to PSARC sometime in the next couple of days. Thanks in advance to all, Doug. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: version-fasttrack.txt URL: From Michen.Chang at Sun.COM Wed Jan 9 09:15:18 2008 From: Michen.Chang at Sun.COM (Michen.Chang at Sun.COM) Date: Wed, 09 Jan 2008 11:15:18 -0600 Subject: [Duckwater-discuss] Versioning fast track draft In-Reply-To: <47843B24.3090909@sun.com> References: <47843B24.3090909@sun.com> Message-ID: <47850126.30406@Sun.COM> Hi Doug, The proposal looks fine to me. Thanks, Michen Doug Leavitt wrote: > Attached is the current versioning fast track draft proposal. > > This is the proposed fast track that specifies the existence > of the _nss_[backend]_version variable with a NULL pointer > value as a signal that the backend has been updated to Sparks > PSARC/2005/133 thereby allowing nscd to load the foreign > backend. > > The draft states that duckwater will specify all the other > finder APIs and additional post PSARC/2005/133 details > as part of that project. > > The point is to deliver this subset of the duckwater enhancement > as a patchable fix for s10, so that cluster and other backends > can cache again. > > About 90-95% of the draft is explanation. About 5% content. > > Sparks/duckwater teams, > Please review and comment. > > Stacey/Honsing, > Are you ok with the wording/references and to the nss_cluster issues? > > If possible, I would like to get this sent to PSARC sometime in the next > couple of days. > > Thanks in advance to all, > Doug. > ------------------------------------------------------------------------ > > _______________________________________________ > duckwater-discuss mailing list > duckwater-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/duckwater-discuss From julian.pullen at sun.com Thu Jan 10 05:45:52 2008 From: julian.pullen at sun.com (Julian Pullen) Date: Thu, 10 Jan 2008 13:45:52 +0000 Subject: [Duckwater-discuss] [sparks-discuss] Versioning fast track draft In-Reply-To: <47843B24.3090909@sun.com> References: <47843B24.3090909@sun.com> Message-ID: <47862190.2010101@sun.com> Doug, You have not given any indication of how the _nss_[backend]_version pointer will be used in the future. You can either use it as a straight forward version or you could have an extensible capability structure that indicates what the backend provides. Regards Julian Doug Leavitt wrote: > Attached is the current versioning fast track draft proposal. > > This is the proposed fast track that specifies the existence > of the _nss_[backend]_version variable with a NULL pointer > value as a signal that the backend has been updated to Sparks > PSARC/2005/133 thereby allowing nscd to load the foreign > backend. > > The draft states that duckwater will specify all the other > finder APIs and additional post PSARC/2005/133 details > as part of that project. > > The point is to deliver this subset of the duckwater enhancement > as a patchable fix for s10, so that cluster and other backends > can cache again. > > About 90-95% of the draft is explanation. About 5% content. > > Sparks/duckwater teams, > Please review and comment. > > Stacey/Honsing, > Are you ok with the wording/references and to the nss_cluster issues? > > If possible, I would like to get this sent to PSARC sometime in the next > couple of days. > > Thanks in advance to all, > Doug. > > > ------------------------------------------------------------------------ > > _______________________________________________ > sparks-discuss mailing list > sparks-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/sparks-discuss From Tomas.Heran at Sun.COM Thu Jan 10 05:56:15 2008 From: Tomas.Heran at Sun.COM (Tomas Heran) Date: Thu, 10 Jan 2008 14:56:15 +0100 Subject: [Duckwater-discuss] [sparks-discuss] Versioning fast track draft In-Reply-To: <47862190.2010101@sun.com> References: <47843B24.3090909@sun.com> <47862190.2010101@sun.com> Message-ID: <478623FF.1000507@sun.com> Julian, Julian Pullen wrote: > Doug, > > You have not given any indication of how the _nss_[backend]_version > pointer will be used in the future. You can either use it as a > straight forward version or you could have an extensible capability > structure that indicates what the backend provides. the plan is to do the latter. The details will be specified and some of the new functionality used by Duckwater. Tomas > > Regards > > Julian > > Doug Leavitt wrote: >> Attached is the current versioning fast track draft proposal. >> >> This is the proposed fast track that specifies the existence >> of the _nss_[backend]_version variable with a NULL pointer >> value as a signal that the backend has been updated to Sparks >> PSARC/2005/133 thereby allowing nscd to load the foreign >> backend. >> >> The draft states that duckwater will specify all the other >> finder APIs and additional post PSARC/2005/133 details >> as part of that project. >> >> The point is to deliver this subset of the duckwater enhancement >> as a patchable fix for s10, so that cluster and other backends >> can cache again. >> >> About 90-95% of the draft is explanation. About 5% content. >> >> Sparks/duckwater teams, >> Please review and comment. >> >> Stacey/Honsing, >> Are you ok with the wording/references and to the nss_cluster issues? >> >> If possible, I would like to get this sent to PSARC sometime in the next >> couple of days. >> >> Thanks in advance to all, >> Doug. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> sparks-discuss mailing list >> sparks-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/sparks-discuss > _______________________________________________ > duckwater-discuss mailing list > duckwater-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/duckwater-discuss From Doug.Leavitt at Sun.COM Thu Jan 10 07:35:52 2008 From: Doug.Leavitt at Sun.COM (Doug Leavitt) Date: Thu, 10 Jan 2008 09:35:52 -0600 Subject: [Duckwater-discuss] Sparks: foreign backend support (PSARC/2005/133 versioning) Message-ID: <47863B58.1000608@sun.com> Hi Gary, Attached is the fast track I discussed with you late last year. It proposes a strict subset of the versioning feature to be discussed in detail in the Duckwater project (PSARC/2007/694). We plan to clean up our Duckwater materials this month and get on the PSARC calendar late January, perhaps early February. Inception date is TBD. This is an open fast track proposal whose draft was previously submitted to the respective Sparks and Duckwater mail aliases, reviewed by both teams, interested clustering team engineers and RPE engineers working on the clustering issue. All the interested parties have agreed with the proposal. Please let me know if you have any issues or have any changes that I should make before it should be submitted as a PSARC fast track. Thanks in advance for your help. Doug. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: version-fasttrack.txt URL: From Doug.Leavitt at Sun.COM Tue Jan 15 12:45:59 2008 From: Doug.Leavitt at Sun.COM (Doug Leavitt) Date: Tue, 15 Jan 2008 14:45:59 -0600 Subject: [Duckwater-discuss] Sparks: foreign backend support (PSARC/2005/133 versioning) In-Reply-To: <200801142356.m0ENuF18026080@marduk.eng.sun.com> References: <200801142356.m0ENuF18026080@marduk.eng.sun.com> Message-ID: <478D1B87.6070209@sun.com> Hi Gary, I pinged the team members and and we have no issue with your suggested fixes. I am attaching a modified fast track proposal with your suggestions incorporated and the contract-template for the fast track you requested. In sections: 0,4,6,12 of the contract template I left PSARC/2008/??? {search for ???} to mark the locations where the ARC number for this fast track should go. I am cc'ing our manager and our cluster team contact so they can start looking at the contract template at their convenience. One last thing, I think there was a typo in your proposed timer for the fast track. A timer of 25 Jan, 2008 would be fine with us. [vs 25 Dec, 2008] Thanks again in advance, and please let me know if there are any further issues. Doug. Gary Winiger wrote: > Doug, > >> Attached is the fast track I discussed with you late last year. > > Attached is my modified Fast track for your review. Changes > other than typos are noted with '|' or '+' in the first column. > If the team approves, say so and send a prototype contract for > approval. > > Cheers, > Gary.. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: contract-template URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: version-fasttrack.txt URL: From gww at eng.sun.com Tue Jan 15 17:07:30 2008 From: gww at eng.sun.com (Gary Winiger) Date: Tue, 15 Jan 2008 17:07:30 -0800 (PST) Subject: [Duckwater-discuss] Sparks: foreign backend support (PSARC/2005/133 versioning) Message-ID: <200801160107.m0G17UD5028672@marduk.eng.sun.com> Doug, > Hi Gary, > I pinged the team members and and we have no issue with your > suggested fixes. Case running. I hit send too soon in sac_next case, so there will be an empty mail along with the real one. Cheers, Gary.. From gww at eng.sun.com Tue Jan 15 17:01:19 2008 From: gww at eng.sun.com (Gary Winiger) Date: Tue, 15 Jan 2008 17:01:19 -0800 (PST) Subject: [Duckwater-discuss] PSARC/2008/035 - Sparks foreign backend support Message-ID: <200801160101.m0G11JCi028645@marduk.eng.sun.com> I'm sponsoring this case for Doug Leavitt and the Sparks and Duckwater project teams. Sparks: Name Service Switch 2 [PSARC/2005/133] was delivered into Nevada Build 50, see also the umbrella NSS2 (Sparks,Reno,Winchester,Duckwater) [PSARC/2006/247]. Duckwater: Simplified name services management (PSARC/2007/694) has not yet been heard by the ARC. This case wishes to bring forward a limited part of Duckwater to meet an immediate need to support clustering. The intent is to do so in a contracted way. A prototype contract is in the case directory. The proposed exported interfaces are Project Private and a Patch release binding is requested. The timer is set for 23 Jan, 2008. Gary.. =============================================================================== Background ========== The name service switch interfaces have been private [and mostly undocumented] since their development. While the private status of the interfaces has been restated multiple times, and explicitly documented as private as far back as 1994, this has not prevented uncontracted API usage outside the ON consolidation and unsupported usage by third parties. This is a well known problem that has been partly responsible for the lack of evolution of these APIs, until the initial delivery of the Sparks project [PSARC/2005/133], in snv_50. As a side note, the project team continues to learn about nsswitch backends that have been developed using the private APIs, both internal and external to Sun. It is still unclear how many "foreign" nsswitch backends actually exist. Realistically the number of "foreign" nsswitch backends is probably more than 10. The initial sparks project delivery has started down the path of documenting, updating and extending these interfaces with plans to eventually publish a set of public nsswitch interfaces. The sparks effort currently preserves backwards compatibility by keeping the old, backwards compatible, nsswitch interface code in it's original libc location. The new redesigned nsswitch is located in nscd. As discussed in PSARC/2005/133, the public APIs send requests to the new nsswitch which in turn can return a request back to the libc nsswitch via the TRYLOCAL protocol, if the new switch determines that the request must be executed by the old nsswitch to preserve backwards compatibility. Currently the name service switch has two classes of name service switch backends. The first class of backends are "foreign" or pre PSARC/2005/133 backends. Any backend that has not been updated to follow the behaviors documented in PSARC/2005/133 is considered foreign. In other words, any backend that is making unsupported or uncontracted use of the private nsswitch APIs. Foreign backends will almost always core dump the new name service switch in nscd and likely cause a disruption of service. The primary reason for nscd's inability to use a foreign backend is because prior to PSARC/2005/133 the data marshaling interfaces were undocumented, inconsistent and prone to usage error. The interface usage was very inconsistent even amongst the ON supported backends. This was a primary root cause for many naming service lookup and consistency bugs prior to Sparks. PSARC/2005/133 documented the expected behavior and spent a considerable part of the development effort towards updating all ON backends so they followed the newly documented behavior. All non-ON backends are considered 'foreign' to the new name service switch engine. The new name service switch engine returns requests that need to use a foreign backend to the original (obsolete) libc name service switch using the TRYLOCAL protocol for local processing on the client. This preserves full backwards compatibility with existing code that is using the private interfaces. However, this means databases, such as hosts or passwd, that specify a foreign backend in nsswitch.conf are not cached. The second class of backends are backends that are known have been updated to support the new interfaces. Nscd has a built-in "knowledge" of a core set of backends that are delivered in unison with nscd in the ON consolidation. These backends are required to always adhere to all the current latest [PSARC/2005/133 or later] nsswitch specifications. These are the backends that are used to test and qualify the name service switch in ON at each build/delivery via PIT and other methods. The current well known/built-in backends are those located in the ON consolidation tree: usr/src/lib/nsswitch. They currently include compat, dns, files, ldap, mdns, nis, nisplus user Problem ======= There is at least one Sun non-ON consolidation name service switch backend, nss_cluster, that should have appropriate private interface contracts with the naming service team, but doesn't, and that needs to be loadable by nscd, so nscd can cache appropriate hostname lookups. With the introduction of Sparks into s10u4, nscd has stopped using the nss_cluster backend, and has stopped caching hostname lookups when nss_cluster is one of the sources for hosts lookups. This causes a significant performance degradation on all clustering systems because the cluster nsswitch backend is used to map cluster private host names [for each node of a cluster] to the cluster public name, and host name lookups are used heavily in the clustering subsystem code base. The following CRs document this issue: CR 6632298 network/nscd nscd doesn't cache hosts for cluster after sparks project (120011-14) CR 6644077 network/nsswitch nscd rejects - foreign nsswitch backends Nscd needs a way to detect a non-ON, nsswitch backend that adheres to PSARC/2005/133 or later so that nscd can load, use and cache the results from that backend. Solution ======== This fast track specifies a new versioning API that will be delivered and used by nscd so that nscd can detect and load updated non-ON name service switch backends. Additionally, in order to close CR 6632298, the following tasks will need to be completed: 1) An interface contract needs to be written and agreed to between the cluster team and the netrep team to contract all the nsswitch private interfaces, including PSARC/2005/133 and this fasttrack. 2) The cluster team needs to revise and deliver and updated nss_cluster backend, to comply with the definitions set out by the contracted interfaces. A prototype contract is part of this case, the deliver of the cluster changes are outside the scope of this case. Versioning Details ================== The Duckwater project [PSARC/2007/694] will extend the nsswitch interfaces defined by PSARC/2005/133 with new set of versioning interfaces and extensions to the existing finder APIs so that the name service switch and name service switch configuration tools can detect extended characteristics of a nsswitch backend, including new configuration APIs. The intent of the versioning and finder APIs are to provide efficient, upward compatible and extensible APIs that allow for the addition of new XbyYs [get/put/ent etc.], new configuration interfaces (duckwater) and other extendable future nscd APIs. The specifics of the new finder interfaces will be detailed in PSARC/2007/694. These new interfaces will detect a nsswitch backend that has been versioned by looking for an externally defined version global symbol [dlsym retrievable] of the form: _nss_[backend-name]_version where backend-name corresponds to the backend name used in nsswitch.conf as in: _nss_nis_version, _nss_files_version etc. The contents of the variable are treated as a castable (void *) pointer in the native pointer size for the compiled library. This fast track defines a strict subset of the PSARC/2007/694 interfaces in the following manner: Existence of the symbol in a nsswitch backend with a value of NULL implies compliance with the specifications of PSARC/2005/133. If this NULL valued symbol exists, nscd will treat the nsswitch backend as eligible for being dlopen'd and used per PSARC/2005/133 specifications. The results from lookups will be cached along with other lookup results as applicable. Duckwater [PSARC/2007/694] will specify the additional behaviors when the value is non NULL. For this case specifically the solution proposed is: 1) to recognize _nss_[backend-name]_version loader symbols 2) to interpret a NULL value of such symbols to mean compliant with Sparks [PSARC/2005/133] 3) to contract with the cluster group. For the purposes of ARC classification, and because all the other nsswitch interfaces are currently classified as either Project Private or Committed Private, this interface is defined as project private, with a request for patch binding approval. Contracts against this interface will be signed as needed. [see above] This fast track requests that the discussion to reclassify any/all the nsswitch interfaces be held during either the PSARC/2007/694 full ARC review or until the future "sparks phase 2" ARC review. The Sparks team expects to re-classify this nsswitch interface into a stable public interface at some point in the future. Other Notes =========== It should be noted, that both Duckwater and Sparks are Open OpenSolaris development efforts, so this API and fast track are being discussed part of the respective open development efforts with the details published on the appropriate project sites and e-mail aliases. It is known that other unsupported third party nsswitch backends have been using the nsswitch private interfaces and their backends currently not being cached by nscd. Given that the Sparks and Duckwater projects are open development efforts, and the Sparks documentation is available on OpenSolaris, it is expected that some third parties might choose to use these private interfaces in an unsupported manner as well. Until these APIs are designated as public, third parties that choose to use this interface continue do so at their own risk and expense. From Doug.Leavitt at Sun.COM Fri Jan 18 10:13:44 2008 From: Doug.Leavitt at Sun.COM (Doug Leavitt) Date: Fri, 18 Jan 2008 12:13:44 -0600 Subject: [Duckwater-discuss] updated tip/mis-merge corrections Message-ID: <4790EC58.5080700@sun.com> We detected that on head 5213 and/or later, there was a mis-merge with the onnv-gate that affected the iscsi subsystem. The duckwater gate failed to build last night and this was part of the root cause. For corrective action, I did a tree diff of the duckwater gate and the onnv gate and resynced the offending files. this tip: changeset: 6046:8704aa519643 tag: tip user: Douglas Leavitt date: Fri Jan 18 10:10:44 2008 -0800 summary: mis-merge corrections from head 5213 and later. Corrective resync with has those corrections. Doug. From Doug.Leavitt at Sun.COM Tue Jan 22 11:54:07 2008 From: Doug.Leavitt at Sun.COM (Doug Leavitt) Date: Tue, 22 Jan 2008 13:54:07 -0600 Subject: [Duckwater-discuss] usr/src/lib/libsecdb/help/auths/SmfValueIscsitgt.html issue corrected. Message-ID: <479649DF.10404@sun.com> Hopefully with the re-addition of this commit: changeset: 6063:df95395a1f23 tag: tip user: Douglas Leavitt date: Tue Jan 22 09:25:18 2008 -0800 summary: usr/src/lib/libsecdb/help/auths/SmfValueIscsitgt.html the tree should be back to it's proper form. This file did not get properly committed during the failed resync or during the subsequent re-sync cleanup last week. Fresh builds are happening now. A DIY PIT (automated test submission) will be started once complete builds are done. Doug. From Doug.Leavitt at Sun.COM Wed Jan 23 10:09:45 2008 From: Doug.Leavitt at Sun.COM (Doug Leavitt) Date: Wed, 23 Jan 2008 12:09:45 -0600 Subject: [Duckwater-discuss] Sparks: foreign backend support (PSARC/2005/133 versioning) In-Reply-To: <200801160107.m0G17UD5028672@marduk.eng.sun.com> References: <200801160107.m0G17UD5028672@marduk.eng.sun.com> Message-ID: <479782E9.8000900@sun.com> FYI: This case was approved today at PSARC. We can move forward with delivery. Doug. From gww at eng.sun.com Wed Jan 23 10:54:44 2008 From: gww at eng.sun.com (Gary Winiger) Date: Wed, 23 Jan 2008 10:54:44 -0800 (PST) Subject: [Duckwater-discuss] PSARC/2008/035 - Sparks foreign backend support Message-ID: <200801231854.m0NIsiMi019572@marduk.eng.sun.com> This case was approved at today's PSARC meeting. Gary.. From Doug.Leavitt at Sun.COM Wed Jan 30 10:54:30 2008 From: Doug.Leavitt at Sun.COM (Doug Leavitt) Date: Wed, 30 Jan 2008 12:54:30 -0600 Subject: [Duckwater-discuss] [sparks-discuss] [request-sponsor] Request sponsor for bugt 6655471 In-Reply-To: <1201717455.2701.51.camel@xylabone> References: <1201643152.1624.15.camel@oberon> <1201646962.1624.63.camel@oberon> <1201706015.1624.78.camel@oberon> <47A0A365.7060300@sun.com> <1201712071.1624.108.camel@oberon> <47A0BBF6.90903@sun.com> <1201717455.2701.51.camel@xylabone> Message-ID: <47A0C7E6.1010806@sun.com> Milan Jurik wrote: >> Again, the right direction is in the promotion of syslog messages to LOG_INFO >> as necessary and dtrace moving forward. >> > > Does it mean, that actual syslog(LOG_DEBUG, ...) calls could be > evaluated and: > > a) some of them increased to LOG_INFO, if it makes sense for them Yes, if there are currently LOG_DEBUG syslog messages that really should be LOG_INFO messages so that people do not have to enable LOG_DEBUG, then these syslog messages should be changed. A request for someone to suggest such messages has been made at least once or twice by me. Feel free to suggest some options. > > b) the rest (and possibly other #ifdef fprint/syslog calls) converted to > dtrace probes I would state it in this manner: USDT dtrace probes are a much better way to do in the field debugging than LOG_DEBUG syslog messages or #ifdef DEBUG code. It makes sense to evaluate libsldap and update it with USDT probes. This implies cleaning up (removing/replacing as necessary) both #ifdef DEBUG and syslog(LOG_DEBUG.. replacing the important ones with USDT probes and adding (as appropriate) additional USDT probes where things make sense. I think (hope?) all would agree this would make libsldap easier to debug in all situations. It would require a ARC fast track to define the new USDT probes [DTrace provider for libsldap], but ARCing dtrace providers seems to be a fairly frequent [fast track or automatic approved fast track] process recently. See PSARC/2008/050 DTrace NFS v3 Provider as an example. I believe everyone on the team is for this approach. It hasn't happened because no one has had time to do it yet. The sparks team has discussed allocating time to do it during the next round of work. I don't see how the Duckwater team can add it to their overfull plate right now. If someone wants to jump in sooner, I would be happy to help sponsor such a change (in PSARC and via putback) and I suspect the other members of the teams would be happy to provide input/comments/code review etc. because it only benefits them. At the moment, the Duckwater-hg gate is the most up to date version of libsldap, but a discussion should occur on how best to coordinate any changes because both ongoing projects are changing libsldap right at the moment, and Winchester might start doing the same in the near future too. Doug. From Milan.Jurik at Sun.COM Wed Jan 30 11:09:55 2008 From: Milan.Jurik at Sun.COM (Milan Jurik) Date: Wed, 30 Jan 2008 20:09:55 +0100 Subject: [Duckwater-discuss] [sparks-discuss] [request-sponsor] Request sponsor for bugt 6655471 In-Reply-To: <47A0C7E6.1010806@sun.com> References: <1201643152.1624.15.camel@oberon> <1201646962.1624.63.camel@oberon> <1201706015.1624.78.camel@oberon> <47A0A365.7060300@sun.com> <1201712071.1624.108.camel@oberon> <47A0BBF6.90903@sun.com> <1201717455.2701.51.camel@xylabone> <47A0C7E6.1010806@sun.com> Message-ID: <1201720195.2701.90.camel@xylabone> Hi Doug, V st, 30. 01. 2008 v 19:54, Doug Leavitt p??e: > Milan Jurik wrote: > > >> Again, the right direction is in the promotion of syslog messages to LOG_INFO > >> as necessary and dtrace moving forward. > >> > > > > Does it mean, that actual syslog(LOG_DEBUG, ...) calls could be > > evaluated and: > > > > a) some of them increased to LOG_INFO, if it makes sense for them > > Yes, if there are currently LOG_DEBUG syslog messages that really should > be LOG_INFO messages so that people do not have to enable LOG_DEBUG, > then these syslog messages should be changed. > > A request for someone to suggest such messages has been made at > least once or twice by me. > > Feel free to suggest some options. > I could look at them and ask other colleagues from RPE to look if some are good for it, based on our experiencies, if it is OK for you? And during code reivew > > > > b) the rest (and possibly other #ifdef fprint/syslog calls) converted to > > dtrace probes > > I would state it in this manner: > > USDT dtrace probes are a much better way to do in the field debugging > than LOG_DEBUG syslog messages or #ifdef DEBUG code. > > It makes sense to evaluate libsldap and update it with USDT probes. > > This implies cleaning up (removing/replacing as necessary) both #ifdef DEBUG > and syslog(LOG_DEBUG.. replacing the important ones with USDT probes > and adding (as appropriate) additional USDT probes where things make sense. > > I think (hope?) all would agree this would make libsldap easier to debug > in all situations. > +1 > It would require a ARC fast track to define the new USDT probes > [DTrace provider for libsldap], but ARCing dtrace providers seems to be > a fairly frequent [fast track or automatic approved fast track] process recently. > See PSARC/2008/050 DTrace NFS v3 Provider > as an example. > > I believe everyone on the team is for this approach. It hasn't happened > because no one has had time to do it yet. The sparks team has discussed > allocating time to do it during the next round of work. I don't see how the > Duckwater team can add it to their overfull plate right now. > > If someone wants to jump in sooner, I would be happy to help sponsor > such a change (in PSARC and via putback) and I suspect the other members > of the teams would be happy to provide input/comments/code review etc. > because it only benefits them. > Maybe Marco can if he is willing to move it forward and help with this conversion to dtrace? > At the moment, the Duckwater-hg gate is the most up to date > version of libsldap, but a discussion should occur on how best > to coordinate any changes because both ongoing projects are > changing libsldap right at the moment, and Winchester might start > doing the same in the near future too. > Here I could help, during integration process, at least Tomas and David are sitting close to my office. Best regards, Milan From Tomas.Heran at Sun.COM Thu Jan 31 02:42:23 2008 From: Tomas.Heran at Sun.COM (Tomas Heran) Date: Thu, 31 Jan 2008 11:42:23 +0100 Subject: [Duckwater-discuss] [sparks-discuss] [request-sponsor] Request sponsor for bugt 6655471 In-Reply-To: <1201720033.5551.13.camel@oberon> References: <1201643152.1624.15.camel@oberon> <1201646962.1624.63.camel@oberon> <1201706015.1624.78.camel@oberon> <47A0A365.7060300@sun.com> <1201712071.1624.108.camel@oberon> <47A0BBF6.90903@sun.com> <1201717455.2701.51.camel@xylabone> <1201720033.5551.13.camel@oberon> Message-ID: <47A1A60F.9010100@sun.com> Hi Marco and everybody, I'd like to give my +1 for revision of (libsldap) debugging messages being, where some (very few though, as you stated) will be logged with LOG_INFO priority instead of LOG_DEBUG and the rest of them - i.e. the *real* debugging stuff - will be handled (and made available to the ones who care) by adding dtrace probes to the code. Marco van Wieringen wrote: >>> 3) One of the points of Duckwater is to get rid of the files in /var/ldap so >>> adding a new file is not in line with our current directions. Since we have already >>> announced our intentions to get rid of /var/ldap files, adding new ones >>> would not fall in line with our current stated directions. >>> > Ok what is replacing it then. I also don't see this as an long term > solution, that would be the dtrace probes. All the configuration files from /var/ldap are being removed and the configuration for LDAP naming subsystem will be stored in SMF configuration repository. For more info please see http://opensolaris.org/os/project/duckwater/. One of the goals of DW is to allow for having multiple different back-end and switch configurations and possibility to organize these into profiles. One could then have number of such profiles defined in the system and it'll be possible to switch very easily back and forth between them. We believe that not only users with laptops will benefit but it'll also make transitions between naming setups easier in enterprise. > >> I agree we should avoid new data in /var/ldap as much as possible, >> people are playing with its content too much already now :-) >> > The file I'm saying you can do with whatever you like it just needs > to be there nothing to do with the content of it. Just a way of > switching debug on and off. My understanding is that it doesn't matter whether you actually do read data from said file or not. Just the fact that some code in the system might change its behavior depending on existence of a file in the fs is making this file to form an "interface". So, again - ARC etc. But I guess I'm beating dead body here ;) > > Lets close the call as you were aiming at from the beginning. I have a > workaround for myself and whenever dtrace probes come in I hope it > catches all the real debug output. > I'm glad that you have a solution which works for you. Please know that we do take the approachability, observability and debugability of LDAP naming components very seriously and we more then welcome anybody to give us his opinions and share his experience with dealing with these issues. Also, if you chose to work on this subject (-> LOG_INFO, dtrace probes) more, I'd gladly give you all the support I can, to help you eventually integrate into OpenSolaris. The only thing I unfortunately can't commit to at the moment is working on the issue myself, since, as stated before, we in the Duckwater project team have quite a lot to do now to finish and eventually integrate Duckwater into OpenSolaris. Best regards, Tomas From Tomas.Heran at Sun.COM Thu Jan 31 03:04:36 2008 From: Tomas.Heran at Sun.COM (Tomas Heran) Date: Thu, 31 Jan 2008 12:04:36 +0100 Subject: [Duckwater-discuss] [sparks-discuss] [request-sponsor] Request sponsor for bugt 6655471 In-Reply-To: <1201725901.5551.34.camel@oberon> References: <1201643152.1624.15.camel@oberon> <1201646962.1624.63.camel@oberon> <1201706015.1624.78.camel@oberon> <47A0A365.7060300@sun.com> <1201712071.1624.108.camel@oberon> <47A0BBF6.90903@sun.com> <1201717455.2701.51.camel@xylabone> <1201720033.5551.13.camel@oberon> <1201720916.2701.103.camel@xylabone> <1201725901.5551.34.camel@oberon> Message-ID: <47A1AB44.40102@sun.com> Hi, Marco van Wieringen wrote: >>> >> The problem with /var/ldap is that it wasn't designed to be place, where >> administrators can do manual changes, so we just want to avoid the >> situation that they will learn to go there and play "file games" there >> :-) > Oh (I must say I do every now and then :-)) But the idea is some > binary format ? Well, I guess you can say so. Technically, the configuration data in SMF repository is stored in "binary" form (it's actually sqlite db), but that's not the point. The main point is that Duckwater will provide unified interfaces to deal with the name service subsystem configuration - nscfg(1M) and nsadm(1M), and/or (for tool writers etc.) we will also define configuration API for name service switch modules. Please see: http://opensolaris.org/os/project/duckwater/Documentation/nscfg_man/ http://opensolaris.org/os/project/duckwater/Documentation/nsadm_man/ http://opensolaris.org/os/project/duckwater/Documentation/nssconfig/ > > Do we have an example on how to implement dtrace probes in libs probably > we do and I could go trying google but are there any definitive insights > on how do to it. And I could invest some more time but would like that > this is really the direction we want/need to go. It doesn't make sense > to invest much time into something that wil never be used. > http://blogs.sun.com/tdd/entry/a_simple_dtrace_usdt_example http://docs.sun.com/app/docs/doc/817-6223/6mlkidlms?a=view http://blogs.sun.com/ahl/entry/user_land_tracing_gets_better http://blogs.sun.com/barts/entry/putting_user_defined_dtrace_probe Hope this helps, Tomas