<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none"><!-- p { margin-top: 0px; margin-bottom: 0px; }--></style>
</head>
<body dir="ltr" style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;">
<p>So let me make sure I understand this. You want to do a separate service plugin for what would normally be separate drivers under one service plugin. The reasons for this are:<br>
</p>
<p><br>
</p>
<p>1. You dont want users the ability to choose the type, you want it always to be the same one<br>
</p>
<p>2. Some types do want to be the source of truth of the data stored, instead of it being the service plugin database.<br>
</p>
<p><br>
</p>
<p>First, let me address the possibility of a solution using one service plugin and multiple drivers per type:<br>
</p>
<p><br>
</p>
<p>I think that you can overcome #1 in the instantiation of the service plugin to check if there are more than 1 provider active, if so you can just throw an exception saying you can only have 1. I'd have to look at it more to see if there are any caveats
to this, but I think that would work.<br>
</p>
<p><br>
</p>
<p>For #2, assuming #1 works, then the drivers that are defined can have some boolean that they set that will tell the plugin whether they are the source of truth or not, and depending on that you can store the data in the service plugin's db or just pass the
data along, also pass GET requests to the drivers as well.<br>
</p>
<p><br>
</p>
<p>As for making a service plugin for each type, I don't see why that wouldn't work. It seems a bit overkill to me though because you'd probably end up having 2 base classes for every service plugin type, one for using the service plugin database and another
for the data source of truth being external. Probably a better way to do this, I'm sure I'm oversimplifying. I don't see much technical reasons why you couldn't do this, though. It's just inconsistent and might cause some confusion. I'd need to spend some
time on it to really have an educated opinion.<br>
</p>
<p><br>
</p>
<p>Thanks,<br>
Brandon<br>
</p>
<div style="color: rgb(33, 33, 33);">
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Mathieu Rohon <mathieu.rohon@gmail.com><br>
<b>Sent:</b> Tuesday, August 18, 2015 7:13 AM<br>
<b>To:</b> OpenStack Development Mailing List<br>
<b>Subject:</b> [openstack-dev] [Neutron][bgpvpn] Service Plugin vs Service driver</font>
<div> </div>
</div>
<div>
<div dir="ltr">Adding the related subject :)<span id="transmark"></span><br>
<div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Aug 18, 2015 at 10:35 AM, Mathieu Rohon <span dir="ltr">
<<a href="mailto:mathieu.rohon@gmail.com" target="_blank">mathieu.rohon@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>Hi all,<br>
<br>
</div>
The current bgpvpn implementation is using the service type framework, with a service plugin and one or more service providers.<br>
</div>
<br>
After registering the bug [1], I wonder if we would rather use a service plugin per implementation type (bagpipe, ODL, OpenContrail, Nuage...) which handles API calls, instead of having one service plugin which forwards API calls to a service driver depending
on the provider chosen by the end user.</div>
<div><br>
</div>
I would like to better understand what would be the main drawbacks of such a move apart from the fact that a deployment would be tightly coupled to a bgpvpn plugin, and multiple implementations of the plugin couldn't coexist.<br>
<br>
</div>
Thanks,<br>
<br>
</div>
Mathieu<br>
<br>
[1]<a href="https://bugs.launchpad.net/bgpvpn/+bug/1485515" target="_blank">https://bugs.launchpad.net/bgpvpn/+bug/1485515</a><br>
<div>
<div>
<div></div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</body>
</html>