https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-13055 Lustre <p>Currently Lustre Changelog consumers are always named e.g. "<tt>cl1</tt>" or "<tt>cl14</tt>". It would be useful to be able to declare the changelog username (e.g. "<tt>cl-rbh</tt>" or "<tt>cl-audit</tt>") so that it is clear who the Changelog users are, and to avoid duplicate changelog registrations. Otherwise, it can happen that the original Changelog user registration can be lost, and the application registers a new user, and the old user causes the Changelog records to accumulate.</p> LU-13055

add ability for named Changelog consumers

Improvement Minor Closed Fixed Mikhail Pershin Andreas Dilger Fri, 6 Dec 2019 21:27:52 +0000 Thu, 9 Nov 2023 21:40:11 +0000 Mon, 18 Oct 2021 14:18:23 +0000 Lustre 2.12.8 Lustre 2.15.0 0 7 <p>Andreas Dilger (adilger@whamcloud.com) uploaded a new patch: <a href="https://review.whamcloud.com/43380" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/43380</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-13055" title="add ability for named Changelog consumers" class="issue-link" data-issue-key="LU-13055"><del>LU-13055</del></a> mdd: allow registering named Changelog users<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 39a973f23455a8facd49a86e3ca044f055b37d7d</p> <p>Mike, the attached patch was my initial attempt at creating named changelog users with a configurable mask per user (<a href="https://jira.whamcloud.com/browse/LU-13338" title="add changelog mask per registered user" class="issue-link" data-issue-key="LU-13338"><del>LU-13338</del></a>).</p> <p>It has a reasonable start of how to configure the named users. They are currently of the form <tt>&lt;name&gt;&lt;number&gt;</tt>, in order to ensure uniqueness, but John should chime in whether it would be better to use only <tt>&lt;name&gt;</tt> and refuse to create multiple users with the same <tt>&lt;name&gt;</tt>. If no <tt>&lt;name&gt;</tt> is specified, then using "<tt>cl</tt>" would be best.</p> <p>There is also some work for per-user masks, to include a field in the config record to store the mask and check it at startup time. The idea is that the currently-set mask would be the union of the masks specified by all of the registered users, also including the global mask (if set). For compatibility reasons, users registered without a mask would need to enable the full default mask, so it would be desirable for most users to delete the old user and create a new limited-mask user.</p> <p>The mask in the config record is fine to specify the mask at creation time, but it would be somewhat tricky to change the mask for a specific user afterward. For most users that should be OK, since they would only be processing records that they originally registered for. If necessary, they could drain their pending log records, delete their user ID, and re-register their user with a different mask. If it wasn't possible to drain the log, setting the global mask could be used to temporarily enable additional records as needed until that could be done, so I don't think that is critical to implement in the first pass.</p> <p>there are couple questions related to proposed functionality. First, what name format will we allow? For example, name 'user1' would cause combined result as 'user11' or similar which is undistinguished from 'user' with ID 11. So either we prohibit digits in name or need separator like '.' between them, so that would be 'user1.1' and 'user.11' </p> <p>Another question is about deregister, right now tool demands it in form 'cl&lt;ID&gt;' and extract just ID to proceed with. While keeping old 'cl&lt;ID&gt;' format for compatibility is OK, wouldn't that be useful to support pure ID form: 'deregister ID' and/or name+ID form: 'deregister 'name&lt;ID&gt;'. In latter case we also have problem #1 with name and ID proper separation</p> <p>I think we should require a <tt>cl</tt> prefix on named changelogs. This will be less likely to break scripts that try to parse the changelog_users file.</p> <p>&gt; there are couple questions related to proposed functionality. First, what name format will we allow? For example, name 'user1' would cause combined result as 'user11' or similar which is undistinguished from 'user' with ID 11. So either we prohibit digits in name or need separator like '.' between them, so that would be 'user1.1' and 'user.11' </p> <p>I had imagined that we would use something like <tt>cl-$NAME</tt>. For example <tt>cl-lamigo</tt>. The <tt>-</tt> makes splitting between numbered and named changelogs easier. To make it totally unambiguous we should require that <tt>$NAME</tt> starts with a letter and contains only letters, digits, and dashes.</p> <p>Alternatively we could allow specifying <tt>$NAME</tt> when the changelog is registered. But the the actual changelog created is named <tt>cl$NUM-$NAME</tt> where <tt>$NUM</tt> is allocated sequentially as before. In this case we should ensure that <tt>$NAME</tt> is valid according to the same rules as above and that it is unique on the MDT. So if <tt>cl42-lamigo</tt> is already registered then we cannot register a new changelog with name <tt>lamigo</tt> on the same MDT.</p> <p>&gt; Another question is about deregister, right now tool demands it in form 'cl&lt;ID&gt;' and extract just ID to proceed with. </p> <p>I think it's much better if we can support a deregister command that uses a name. But if we use the <tt>cl$NUM-$NAME</tt> scheme and <tt>cl42-lamigo</tt> is registered then I think <tt>changelog_deregister cl42</tt> should deregister <tt>cl42-lamigo</tt>.</p> <p>&gt; So either we prohibit digits in name or need separator like '.' between them, so that would be 'user1.1' and 'user.11' </p> <p>I don't like dots. Please don't use them or allow them here. They'll be terrible if we ever want to use the changelog name in a param.</p> <p>John, as for the same names:</p> <blockquote><p>we should ensure that $NAME is valid according to the same rules as above and that it is unique on the MDT. So if cl42-lamigo is already registered then we cannot register a new changelog with name lamigo on the same MDT.</p></blockquote> <p>if we are using cl$ID-$name format then 'name' could be the same because ID is always unique, and even with same name these are different changelog users, so what is the point to require name uniqueness? </p> <p>Mike, the goal is for a service to be able to determine if it already has a registered changelog user or not at startup. Otherwise, if there are 2 changelog users "<tt>cl2</tt>" and "<tt>cl7</tt>" there is no way for the user or administrator to know whether those are being used by a particular service (audit, HSM, etc.), if a new user needs to be registered because the old one was idle and removed, or if the users are for some service that is no longer running. Allowing the service name in the username makes it totally clear that "<tt>cl2-audit</tt>" is for the audit service, "<tt>cl7-lamigo</tt>" is for lamigo, etc.</p> <p>Allowing only a single named user for a given service makes sense, since otherwise it is again ambiguous if both are in use, or one of them is stale. Then, if the service starts up and doesn't know what its changelog user is, it could first scan for it, or just try to register with the name and be given the old user back. If some service <b>really</b> needs to register two changelog users on the same MDT, then it can pick two different names (e.g. "<tt>robinhood</tt>" and "<tt>rbh-tmp-scan</tt>" or whatever).</p> <p>well, I was asking mostly because having unique names means changelog scan for all registered names upon new user registration, while right now the only ID is increased. That would require patch modification.</p> <p>Another problem I have right now is backward compatibility. New name format like 'cl$ID-$NAME' means that our scripts and any other one on customer side will get changelog user name in that format from the new server and later call to 'lfs changelog_clear' would return error because of sscanf() format in chgl_write(). That is not problem to change it or 'lfs' to skip '-$NAME' addition and still use cl$ID part after all but that is client side changes which means old client is not compatible with a new server changelog names. I am not sure if a client wants to work with any name registered from other client, so probably that is not problem, but if it is problem then I have no good solution except compatibility patch to an older Lustre client</p> <p>Patch is updated. For now name uniqueness is not provided, if you think it must be - let me know. The another patch for b2_12 branches is on its way to provide better compatibility during downgrade</p> <p>Mike Pershin (mpershin@whamcloud.com) uploaded a new patch: <a href="https://review.whamcloud.com/43710" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/43710</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-13055" title="add ability for named Changelog consumers" class="issue-link" data-issue-key="LU-13055"><del>LU-13055</del></a> mdd: don't assert on unknown changelog lrh_type<br/> Project: fs/lustre-release<br/> Branch: b2_12<br/> Current Patch Set: 1<br/> Commit: 1259811054a0e41f7fe646e8ad05307d693549f7</p> <p>Andreas Dilger (adilger@whamcloud.com) uploaded a new patch: <a href="https://review.whamcloud.com/43741" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/43741</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-13055" title="add ability for named Changelog consumers" class="issue-link" data-issue-key="LU-13055"><del>LU-13055</del></a> libcfs: allow comma-separated masks<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 17ed95152ff513dcfe4c1a8f36e66b8bfeeba895</p> <p>Mike Pershin (mpershin@whamcloud.com) uploaded a new patch: <a href="https://review.whamcloud.com/43892" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/43892</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-13055" title="add ability for named Changelog consumers" class="issue-link" data-issue-key="LU-13055"><del>LU-13055</del></a> mdd: make current changelog mask writable<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 11e30ad4770811df392870e09a92dda022574ee6</p> <p>Oleg Drokin (green@whamcloud.com) merged in patch <a href="https://review.whamcloud.com/43741/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/43741/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-13055" title="add ability for named Changelog consumers" class="issue-link" data-issue-key="LU-13055"><del>LU-13055</del></a> libcfs: allow comma-separated masks<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 6b6fde1026311a28595ea43af56392ca6ad24d79</p> <p>Mike Pershin (mpershin@whamcloud.com) uploaded a new patch: <a href="https://review.whamcloud.com/44022" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/44022</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-13055" title="add ability for named Changelog consumers" class="issue-link" data-issue-key="LU-13055"><del>LU-13055</del></a> doc: update changelog manpages<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 7bdb0af8f93a70ebf7f465da6c0ca49109aae723</p> <p>Oleg Drokin (green@whamcloud.com) merged in patch <a href="https://review.whamcloud.com/43380/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/43380/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-13055" title="add ability for named Changelog consumers" class="issue-link" data-issue-key="LU-13055"><del>LU-13055</del></a> mdd: per-user changelog names and mask<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: a15eb4f13224e148810015896101b2950c85adff</p> <p>Mike Pershin (mpershin@whamcloud.com) uploaded a new patch: <a href="https://review.whamcloud.com/44404" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/44404</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-13055" title="add ability for named Changelog consumers" class="issue-link" data-issue-key="LU-13055"><del>LU-13055</del></a> changelog: use default mask if server has no mask<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 17994d3fd5f294931ab30289c0dd565d08fb89ec</p> <p>Oleg Drokin (green@whamcloud.com) merged in patch <a href="https://review.whamcloud.com/44022/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/44022/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-13055" title="add ability for named Changelog consumers" class="issue-link" data-issue-key="LU-13055"><del>LU-13055</del></a> doc: update changelog manpages<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 393885c027793d27ec948fd4fccb47aa530d2bf8</p> <p>"Oleg Drokin &lt;green@whamcloud.com&gt;" merged in patch <a href="https://review.whamcloud.com/43710/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/43710/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-13055" title="add ability for named Changelog consumers" class="issue-link" data-issue-key="LU-13055"><del>LU-13055</del></a> mdd: don't assert on unknown changelog lrh_type<br/> Project: fs/lustre-release<br/> Branch: b2_12<br/> Current Patch Set: <br/> Commit: 7759078c2be6df278bcdfab3eced738496f87331</p> <p>"Oleg Drokin &lt;green@whamcloud.com&gt;" merged in patch <a href="https://review.whamcloud.com/44404/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/44404/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-13055" title="add ability for named Changelog consumers" class="issue-link" data-issue-key="LU-13055"><del>LU-13055</del></a> changelog: use default mask if server has no mask<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: ffe259f81cda5b5cd9241362308ec26ebad194b8</p> <p>It appears that every change tracked under this issue is merged or abandoned.</p> <p><a href="https://jira.whamcloud.com/secure/ViewProfile.jspa?name=tappro" class="user-hover" rel="tappro">tappro</a> is there anything left to do here?</p> <p>There is nothing left to do here</p> <p>Mike, one question that came to mind as I was describing this feature to someone - does the per-user changelog mask filter the records that are provided to the changelog user? I think it currently only affects the records that are recorded at the MDS, but it would possibly reduce some processing overhead (either at the MDS or the client) to skip records that are not in a user's mask.</p> <p>Andreas, right, mask is used to decide what record to write. As for processing case, if we know particular user doing that processing then I think it is possible to filter records</p> <p>For context, <tt>llapi_changelog_start()</tt> works by opening <tt>/dev/changelog-MDT<em>nnnn</em></tt> and then <tt>llapi_changelog_recv()</tt> reads from the file descriptor. There is no obvious way to make the kernel side aware of which changelog user is reading the log, so some new mechanism would have to be added.</p> Duplicate LU-8517 LU-13338 Related LU-13338 LU-14699 LU-16268 Development Rank 1|i00qlz: Rank (Obsolete) 9223372036854775807