<br><br><div class="gmail_quote">On Mon, Feb 4, 2013 at 8:18 AM, Paul Michali <span dir="ltr"><<a href="mailto:pcm@cisco.com" target="_blank">pcm@cisco.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">Anyone have thoughts on my questions, below?<div><br></div><div>Thanks</div><div><br><div><div>
<span style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:medium;white-space:normal;font-family:Helvetica;word-spacing:0px">PCM (Paul Michali)<br>
</span></div></div></div></div></blockquote><div><br></div><div>Hi Paul,</div><div><br></div><div>Well, I first want to apologize for leading you astray on this. I tagged this bug as a low-hanging-fruit appropriate for someone's first commit, but it certainly ended up having a lot of hidden complexity. You've done a great job working through all the comments. Some more inline.</div>
<div><br></div><div>Dan</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div><span style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:medium;white-space:normal;font-family:Helvetica;word-spacing:0px"><br>
</span></div><div><div class="h5"><div><span style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:medium;white-space:normal;font-family:Helvetica;word-spacing:0px"><br>
</span></div><div><div>On Feb 1, 2013, at 1:51 PM, Paul Michali wrote:</div><br><blockquote type="cite"><div style="word-wrap:break-word">Seeking some suggestions/comments/guidance on this…<div><br></div><div>Issue was that user started quantum server with the core config file specified, but not any plugin config file. As a result, it used sqlite, though the setup was using mysql. The goal is to try to prevent this issue. From some discussion already, it appears that the approach should be to "validate" the plugin config options, rather than checking for any file, as a user could aggregate config settings into one file, with both core and plugin config settings.</div>
<div><br></div><div>I've got a few questions for plugin agent developers (this is my first bug, so I'm trying to get up to speed).</div><div><br></div><div><ol><li>Would we be able to identify a set of plugin configuration options that <b><u>all</u></b> plugins must contain, or will they vary per plugin?</li>
</ol></div></div></blockquote></div></div></div></div></div></div></blockquote><div><br></div><div>If we go this direction, I would suspect this would vary by plugin. For example, a plugin that uses an external controller would require the IP of that controller, for which no reasonable default value is possible. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div><div class="h5"><div><blockquote type="cite"><div style="word-wrap:break-word">
<div><ol><li>If there is a <b><u>single</u></b> set of config options that can be considered "mandatory" would we be able to change their definition and mark them as "required" so that exclusion of them is automatically detected by cfg, or will that cause issues (it seems like the cfg is shared by the server and plugin agents)?</li>
<li>If the "required" configuration options vary per plugin, is it possible to push the validation of config down to the plugin (agent)?</li></ol></div></div></blockquote></div></div></div></div></div></div></blockquote>
<div>This was my original thinking, which is that a plugin could pass a list of config values that must be non-empty. However, it also seems likely that a plugin may well want to do more validation than just that the value is non-empty. So then the question is whether there's a point to doing the validation at the config layer at all given that a plugin SHOULD do its own more specific validation. The two possible reasons I can see are: </div>
<div><br></div><div>1) doing the check at the config layer may provide an error message that more usefully points to the actual cause (e.g., config value YYY not specified by any of the provided config files). Rather than a tricker message like unable to connect to controller '' (where '' is the empty string). </div>
<div>2) this may be lighter weight for plugin developers. </div><div> </div><div>This discussion has increased scope beyond the original bug, but its actually interesting to note that the original bug would not have been prevented by the mechanism I suggest, as plugins currently have their sql_connection field default to "sqlite://". Having this default built into the code was a mistake in my opinion. It makes sense for developers, but not for users. If nothing else, I think we should consider defaulting that field to empty string, at which point, at least the user would have gotten an error about not being able to connect to the database. </div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div><div class="h5"><div><blockquote type="cite"><div style="word-wrap:break-word">
<div><ol><li>If we do push down the validation, though, is there a way that this can be checked at the quantum server? IOW does the server invoke the agent(s) validator function?</li></ol></div></div></blockquote></div></div>
</div></div></div></div></blockquote><div>Presumably the agents should fail to start if not provided the proper config. I think this would manifest itself in yong's new agent API as that agent being down. </div><div>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div><div class="h5"><div><blockquote type="cite"><div style="word-wrap:break-word">
<div><ol><li>Is this bug even worth pursuing, or should the proper configuration inclusion be something handled by provisioning tools? IOW rely on tooling to make sure the right files are included and "expect" that the user knows what they are doing, if they do this manually? Guess I need to ask that "is it worth fixing this" question :)</li>
</ol></div></div></blockquote></div></div></div></div></div></div></blockquote><div><br></div><div>Given that quantum-server can always be executed directly on the CLI with no config files at all, I think this argues that we should at least make sure it fails if any value absolutely required by the plugin is not set.</div>
<div><br></div><div>Dan</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div>
<div class="h5"><div><blockquote type="cite"><div style="word-wrap:break-word"><div><div><br></div><div>Thanks in advance for any guidance!</div><div><span style="border-collapse:separate;font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><br>
</span></div><div><span style="border-collapse:separate;font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><br>
</span></div><div>
<span style="border-collapse:separate;font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium">PCM (Paul Michali)<br>
<br></span></div></div></div></blockquote></div><br></div></div></div></div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>Dan Wendlandt <div>Nicira, Inc: <a href="http://www.nicira.com" target="_blank">www.nicira.com</a><br><div>twitter: danwendlandt<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br></div></div>