<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 5/23/14, 3:07 PM, Paul Michali (pcm)
wrote:<br>
</div>
<blockquote
cite="mid:F6AE4BBE-F359-4ADB-BDDB-9ACA0907B0B5@cisco.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
Thanks for the comments Gary!
<div><br>
</div>
<div>Typically, the device driver (backend) and service driver,
for a provider won’t have any database requirements (at least
for VPN). For the Cisco VPN, the service driver has one
additional table that it maintains for mapping, but even in that
case, there is no modification to the built in tables for the
VPN plugin.</div>
</blockquote>
If these sorts of additional tables might use foreign keys, cascaded
deletes, etc., it probably make sense to go with the precommit
approach to make these explicitly part of the transactions.<br>
<br>
-Bob<br>
<blockquote
cite="mid:F6AE4BBE-F359-4ADB-BDDB-9ACA0907B0B5@cisco.com"
type="cite">
<div><br>
</div>
<div>So, the action is validation, persist, apply, with the
validation possibly having a provider override/extend, the apply
always having a provider action, and the persistence always
being the “core” persistence. It’s a question of being
validate, persist/commit, apply, or pre-commit, commit/persist,
post-commit, for naming.</div>
<div><br>
</div>
<div>Regards,</div>
<div><br>
</div>
<div><br>
<div>
<div apple-content-edited="true">
<div>
<div>PCM (Paul Michali)</div>
<div><br>
</div>
<div>MAIL …..…. <a moz-do-not-send="true"
href="mailto:pcm@cisco.com">pcm@cisco.com</a></div>
<div>IRC ……..… pcm_ (<a moz-do-not-send="true"
href="http://irc.freenode.com">irc.freenode.com</a>)</div>
<div>TW ………... @pmichali</div>
<div>GPG Key … 4525ECC253E31A83</div>
<div>Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525
ECC2 53E3 1A83</div>
</div>
<div><br>
</div>
<br class="Apple-interchange-newline">
</div>
<br>
<div>
<div>On May 23, 2014, at 12:40 PM, Gary Duan <<a
moz-do-not-send="true" href="mailto:garyduan@gmail.com">garyduan@gmail.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div dir="ltr">
<div>Hi, Paul,</div>
<div><br>
</div>
<div>If the backend driver maintains its own database, I
think the pre_commit and post_commit approach has an
advantage. The typical code flow is able to keep the
driver and plugin database consistent.</div>
<div><br>
</div>
<div>Regarding question 1, where validation methods
should be added, I am leaning towards A, but I also
agree validation hooks can be added later when they
are needed. It's more important to get provider and
flavor logic officially supported for services.</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Gary</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Fri, May 23, 2014 at 7:24
AM, Paul Michali (pcm) <span dir="ltr"><<a
moz-do-not-send="true" 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">Hi,
<div><br>
</div>
<div>I’m working on a task for a BP to separate
validation from persistence logic in L3 services
code (VPN currently), so that providers can
override/extend the validation logic (before
persistence).</div>
<div><br>
</div>
<div>So I’ve separated the code for one of the
create APIs, placed the default validation into
an ABC class (as a non-abstract method) that the
service drivers inherit from, and modified the
plugin to invoke the validation function in the
service driver, before doing the persistence
step.</div>
<div><br>
</div>
<div>The flow goes like this…</div>
<div><br>
</div>
<div>
<div> def create_vpnservice(self, context,
vpnservice):</div>
<div> driver =
self._get_driver_for_vpnservice(vpnservice)</div>
<div><b>
driver.validate_create_vpnservice(context,
vpnservice)</b></div>
<div> super(VPNDriverPlugin,
self).create_vpnservice(context, vpnservice)</div>
<div>
driver.apply_create_vpnservice(context,
vpnservice)</div>
</div>
<div><br>
</div>
<div>If the service driver has a validation
routine, it’ll be invoked, otherwise, the
default method in the ABC for the service driver
will be called and will handle the “baseline”
validation. I also renamed the service driver
method that is used for applying the changes to
the device driver as apply_* instead of using
the same name as is used for persistence (e.g.
create_vpnservice ->
apply_create_vpnservice).</div>
<div><br>
</div>
<div>The questions I have is…</div>
<div><br>
</div>
<div>1) Should I create new validation methods A)
for every create (and update?) API (regardless
of whether they currently have any validation
logic, B) for resources that have some
validation logic already, or C) only for
resources where there are providers with
different validation needs? I was thinking (B),
but would like to hear peoples’ thoughts.</div>
<div><br>
</div>
<div>2) I’ve added validation_* and modified the
other service driver call to apply_*. Should I
instead, use the ML2 terminology of pre commit_*
and post commit_*? I personally favor the
former, as it is more descriptive of what is
happening in the methods, but I understand the
desire for consistency with other code.</div>
<div><br>
</div>
<div>3) Should I create validation methods for
code, where defaults are being set for missing
(optional) information? For example, VPN IKE
Policy lifetime being set to units=seconds,
value=3600, if not set. Currently, provider
implementations have same defaults, but <b>could</b> potentially
use different defaults. The alternative is to
leave this in the persistence code and not allow
it to be changed. This could be deferred, if 1C
is chosen above.</div>
<div><br>
</div>
<div>Looking forward to your thoughts...</div>
<div><br>
</div>
<div><br>
</div>
<div>Thanks!</div>
<div><br>
</div>
<div>
<div>
<div>
<div>PCM (Paul Michali)</div>
<div><br>
</div>
<div>MAIL …..…. <a moz-do-not-send="true"
href="mailto:pcm@cisco.com"
target="_blank">pcm@cisco.com</a></div>
<div>IRC ……..… pcm_ (<a
moz-do-not-send="true"
href="http://irc.freenode.com/"
target="_blank">irc.freenode.com</a>)</div>
<div>TW ………... @pmichali</div>
<div>GPG Key … 4525ECC253E31A83</div>
<div>Fingerprint .. 307A 96BB 1A4C D2C7 931D
8D2D 4525 ECC2 53E3 1A83</div>
</div>
<div><br>
</div>
<br>
</div>
<br>
</div>
</div>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
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>
</div>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>