<div dir="ltr">Hello,<br><div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
How much time?  In human terms, this should happen in very little time on a vm with llmount.sh created filesystem, should it not?</blockquote><div><br></div><div>I am not ready to give exact time. I believe it depends from configuration. But the time is same as for parameters that set up using "lctl conf_param" and stored in llog file, because the same mechanism is used for log propagation. Difference is only that another lock is canceled (CONFIG_T_PARAMS).</div><div><br></div><div>Nathan answered in previous message about exact "<span style="font-size:13px">jobid" case. </span></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Perhaps that is what is intended to happen, but is that working on master?</blockquote><div><br></div><div>It is designed such way. Please, report if any problem happened.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 >How would a normal system administrator go about finding out what<br>
settings are currently set permanently?<br>
<br>
Seme settings as "set_param" sets can be set using "set_param -P".<br>
Finally all command that stored using "set_param" executed using "lctl<br>
set_param" upcall on targets.<br>
</blockquote>
<br></span>
That was not the question.  I asked how a system administrator can get a listing of the parameters that have been permanently set.  It would appear that the only current method is to mount the underlying filesystem, locate the log file, and use llog_reader on it.  That is a software developer's interface, not an adequate interface for system administrators.</blockquote><div><br></div><div>Yes, the problem is the same as for parameters that stored in llog using "lctl conf_param". Probably we need add functionality to show such permanent parameter.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 >And what about sites that use an MGS per filesystem, rather than a<br>
single MGS for the entire site?  If one MGS says that the debug level<br>
should be one value, and another says that the debug value should be<br>
another value, is it entirely random which debug setting will appear on<br>
any given node?<br>
<br>
Good example there we could use reserved field. Do you think this can<br>
solve the issue? If so, we could extend "set_param -P" now.<br>
</blockquote>
<br></span>
I'm not so sure.  I have a feeling that really we need to consider and classify all of the configurables.<br>
<br>
Another use case:<br>
<br>
In WAN usage, two completely different organizations (two different universities, for instance) with separate security and administration policies may control different parts of the filesystem.  One organization runs the servers and some clients of its own.  A second organization runs clients that mount the first organization's servers over the internet.<br>
<br>
The second organization probably doesn't want the first organization to be setting _most_ of the settings that are available under lnet and lustre /proc trees.  But there are certainly some that are specific to the running of that filesystem that might be reasonable to pass to parts of the client that pertain to only that mount (keep in mind that the same client node may be mounting both local and remote lustre filesystems).</blockquote><div><br></div><div>Probably I don't understood this scheme, but first organization have access to MGS and can change any configuration it wants. It is non secure with our without "set_param -P"</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 >We might want to just remove the conf_param deprecation message<br>
altogether.  I think there is more than just a simple bug in the<br>
"set_param -P" implementation.<br>
<br>
I believe we need move to "set_param -P". Yes, this require some scripts<br>
to be changed, but fixing this now we get method with this benefits<br>
instead of conf_param:<br>
</blockquote>
<br></span>
I would agree if there was no change other than than interface, but this also changes underlying semantics.  That concerns me since there seems to be little information about the design and not much in the way of vetting said design.<br>
<br>
Is there more design information out there to which you can point us?</blockquote><div><br></div><div>It would be great if we could discuss all this problems during design phase, but this feature already landed. I believe we could show something like presentation about architecture of "set_param -P", because original arch doc is quite outdate because of changes during inspections and landing.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I belive we could solve found issues and move forward using "set_param -P"<br>
I offered "set_param -P topic to last LAD, but unfortunately it was not<br>
accepted. Lets' discuss this together. Moving conf_param discarding date<br>
forward gives us some time for this.<br>
</blockquote>
<br></span>
This mailing list reaches a greater number of Lustre developers than LAD or LUG can ever reach (travel is expensive, email is cheap).  This list is very good place to work through design and implementation issues.<br>
<br></blockquote><div><br></div><div>Yes, sure. Thank you for stating this thread. </div></div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Artem Blagodarenko Ph.D.<strong>·</strong> SW Developer on <a href="http://my.seagate.com" target="_blank">seagate.com</a><br>
Seagate Technology, LLC<br>
<a href="http://www.seagate.com" target="_blank">www.seagate.com</a><br></div></div>
</div></div>