<div dir="ltr">I don't think that a common area as being proposed is a silver bullet for solving packaging issues, such as this one. Knowing that the right source tree bits are dropped onto the file system is not enough to guarantee that the end-to-end solution will work on a specific distro. Other issues may arise after configuration and execution.<br>
<div></div><div><br></div><div>IMO, this is a bug in the packages spec, and should be taken care of during the packaging implementation, testing and validation.</div><div><br></div><div>That said, I think the right approach is to provide a 'python-neutron' package that installs the entire source tree; the specific plugin package can then take care of the specifics, like config files. <br>
<div><br></div><div><div><div><div><div>Armando</div>
</div></div></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 17 June 2014 06:43, Shiv Haris <span dir="ltr"><<a href="mailto:sharis@brocade.com" target="_blank">sharis@brocade.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;color:rgb(0,0,0);font-size:12px;font-family:'Lucida Grande',sans-serif"><div><div>Right Armando.</div><div><br></div><div>Brocade’s mech driver problem is due to NETCONF templates - would also prefer to see a common area for such templates – not just common code.</div>
<div><br></div><div>Sort of like:</div><div><br></div><div>common/brocade/templates</div><div>common/bigswitch/*</div><div><br></div><div>-Shiv</div></div><span><div style="font-family:Calibri;font-size:11pt;text-align:left;color:black;BORDER-BOTTOM:medium none;BORDER-LEFT:medium none;PADDING-BOTTOM:0in;PADDING-LEFT:0in;PADDING-RIGHT:0in;BORDER-TOP:#b5c4df 1pt solid;BORDER-RIGHT:medium none;PADDING-TOP:3pt">
<span style="font-weight:bold">From: </span> "Armando M." <<a href="mailto:armamig@gmail.com" target="_blank">armamig@gmail.com</a>><br><span style="font-weight:bold">Reply-To: </span> "OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">To: </span> "OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span> Re: [openstack-dev] [Neutron] - Location for common third-party libs?<br></div><div><div class="h5"><div><br></div><blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5">
<div dir="ltr">I believe the Brocade's mech driver might have the same problem.<div><br></div><div>That said, if the content of the rpm that installs the BigSwitch plugin is just the sub-tree for bigswitch (plus the config files, perhaps), you might get away with this issue by just installing the bigswitch-plugin package. I assume you tried that and didn't work?</div>
<div><br></div><div>I was unable to find the rpm specs for CentOS to confirm.</div><div><br></div><div>A.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 17 June 2014 00:02, Kevin Benton <span dir="ltr"><<a href="mailto:blak111@gmail.com" target="_blank">blak111@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>Hello,</div><div><br></div><div>In the Big Switch ML2 driver, we rely on quite a bit of code from the Big Switch plugin. This works fine for distributions that include the entire neutron code base. However, some break apart the neutron code base into separate packages. For example, in CentOS I can't use the Big Switch ML2 driver with just ML2 installed because the Big Switch plugin directory is gone.</div>
<div><br></div><div>Is there somewhere where we can put common third party code that will be safe from removal during packaging? </div><div><br></div><div><br></div><div>Thanks</div><span><font color="#888888">-- <br><div>
Kevin Benton</div></font></span></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br><a 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></blockquote></div></div></span></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a 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>