<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><div apple-content-edited="true"><div><div><br></div></div></div><div><div>On May 23, 2014, at 3:35 PM, Robert Kukura <<a href="mailto:kukura@noironetworks.com">kukura@noironetworks.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="moz-cite-prefix" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="Apple-interchange-newline">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" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">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><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); float: none; display: inline !important;">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.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"></blockquote><div><br></div>Hi Bob,</div><div><br></div><div>In the Cisco case, it is a single table that has a key that is the IPSec site-to-site connection UUID, and then two numerical ID fields that are used to map OpenStack IPSec and IKE policy IDs to Cisco CSR ID numbers (they don’t support UUIDs). It’s the only table I’ve come across so far, so, not a common thing.</div><div><br></div><div><br></div><div><div apple-content-edited="true"><div><div>PCM (Paul Michali)</div><div><br></div><div>MAIL …..…. <a href="mailto:pcm@cisco.com">pcm@cisco.com</a></div><div>IRC ……..… pcm_ (<a 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></div><div apple-content-edited="true"><br></div></div><div><blockquote type="cite"><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); float: none; display: inline !important;">-Bob</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote cite="mid:F6AE4BBE-F359-4ADB-BDDB-9ACA0907B0B5@cisco.com" type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><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 …..….<span class="Apple-converted-space"> </span><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"><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 class="Apple-converted-space"> </span><span dir="ltr"><<a moz-do-not-send="true" href="mailto:pcm@cisco.com" target="_blank">pcm@cisco.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: 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<span class="Apple-converted-space"> </span><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 …..….<span class="Apple-converted-space"> </span><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 style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); float: none; display: inline !important;">_______________________________________________</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); float: none; display: inline !important;">OpenStack-dev mailing list</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><a href="mailto:OpenStack-dev@lists.openstack.org" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">OpenStack-dev@lists.openstack.org</a><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"></blockquote></div><br></div></body></html>