Re: [openstack-dev] [Neutron] Seeking opinions on scope of code refactoring...

2014-05-27 Thread Carl Baldwin
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) wrote: > So I hit some more complexity, when I got to the IPSec connection res

Re: [openstack-dev] [Neutron] Seeking opinions on scope of code refactoring...

2014-05-27 Thread Paul Michali (pcm)
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, ipsec_

Re: [openstack-dev] [Neutron] Seeking opinions on scope of code refactoring...

2014-05-27 Thread Paul Michali (pcm)
Thanks for the comments Mandeep! Responses in-line #PCM On May 23, 2014, at 8:57 PM, Mandeep Dhami 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 requirements > since the abs

Re: [openstack-dev] [Neutron] Seeking opinions on scope of code refactoring...

2014-05-23 Thread Mandeep Dhami
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) Ag

Re: [openstack-dev] [Neutron] Seeking opinions on scope of code refactoring...

2014-05-23 Thread Paul Michali (pcm)
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 wrote: > Paul

Re: [openstack-dev] [Neutron] Seeking opinions on scope of code refactoring...

2014-05-23 Thread Carl Baldwin
Paul, On Fri, May 23, 2014 at 8:24 AM, Paul Michali (pcm) 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 separated t

Re: [openstack-dev] [Neutron] Seeking opinions on scope of code refactoring...

2014-05-23 Thread Paul Michali (pcm)
On May 23, 2014, at 3:35 PM, Robert Kukura 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 the Cisco VPN,

Re: [openstack-dev] [Neutron] Seeking opinions on scope of code refactoring...

2014-05-23 Thread Robert Kukura
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 for

Re: [openstack-dev] [Neutron] Seeking opinions on scope of code refactoring...

2014-05-23 Thread Paul Michali (pcm)
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 modif

Re: [openstack-dev] [Neutron] Seeking opinions on scope of code refactoring...

2014-05-23 Thread Gary Duan
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, bu