Thanks for the comments Mandeep! Responses in-line #PCM
On May 23, 2014, at 8:57 PM, Mandeep Dhami dh...@noironetworks.com wrote:
My preferences:
For where, I'd go with Gary's recommendation (A) for two reasons (1)
Consistency and (2) I don't think it will create any boilerplate
So I hit some more complexity, when I got to the IPSec connection resource’s
update API…
I was doing code like this:
In VPN plugin:
def create_ipsec_site_connection(self, context, ipsec_site_connection):
driver = self._get_driver_for_ipsec_site_connection(
context,
Paul, do you have enough to be able to put up a WIP in gerrit? This
discussion is getting to the point where having a discussion in gerrit
will be beneficial.
Carl
On Tue, May 27, 2014 at 12:37 PM, Paul Michali (pcm) p...@cisco.com wrote:
So I hit some more complexity, when I got to the IPSec
Hi,
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).
So I’ve separated the code for one of the create APIs, placed the default
validation into an
Hi, Paul,
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.
Regarding question 1, where validation methods should be added, I am
leaning towards A,
Thanks for the comments Gary!
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
On 5/23/14, 3:07 PM, Paul Michali (pcm) wrote:
Thanks for the comments Gary!
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
On May 23, 2014, at 3:35 PM, Robert Kukura kuk...@noironetworks.com wrote:
On 5/23/14, 3:07 PM, Paul Michali (pcm) wrote:
Thanks for the comments Gary!
Typically, the device driver (backend) and service driver, for a provider
won’t have any database requirements (at least for VPN). For
Paul,
On Fri, May 23, 2014 at 8:24 AM, Paul Michali (pcm) p...@cisco.com wrote:
Hi,
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).
So I’ve
Thanks for the comment Carl. See @PCM inline
PCM (Paul Michali)
MAIL …..…. p...@cisco.com
IRC ……..… pcm_ (irc.freenode.com)
TW ………... @pmichali
GPG Key … 4525ECC253E31A83
Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83
On May 23, 2014, at 6:09 PM, Carl Baldwin
My preferences:
For where, I'd go with Gary's recommendation (A) for two reasons (1)
Consistency and (2) I don't think it will create any boilerplate
requirements since the abstract class provides the default implementation.
For naming, I'd prefer to go with ML2 terminology for two reasons (1)
11 matches
Mail list logo
