>If we can consolidate that and use a single tool from the master neutron repository, that would be my vote.
+1 with a hook mechanism so the sanity checks stay in the *aas repos and they are only run if installed. > On Thu, Jan 22, 2015 at 7:30 AM, Kyle Mestery <mest...@mestery.com> wrote: > On Wed, Jan 21, 2015 at 10:27 AM, Ihar Hrachyshka <ihrac...@redhat.com> > wrote: > >> On 01/20/2015 05:40 PM, Paul Michali wrote: >> >> Review https://review.openstack.org/#/c/146508/ is adding support for >> StrongSwan VPN, which needs mount bind to be able to specify different >> paths for config files. >> >> The code, which used some older patch, does a test for /proc/1/ns/net, >> instead of /proc/1/ns/mnt, because it stated that the latter is only >> supported in kernel 3.8+. That was a while ago, and I'm wondering if the >> condition is still true. If we know that for Kilo and on, we'll be dealing >> with 3.8+ kernels, we could use the more accurate test. >> >> Can we require 3.8+ kernel for this? >> >> >> I think we can but it's better to check with distributions. Red Hat wise, >> we ship a kernel that is newer than 3.8. >> >> If so, how and where do we ensure that is true? >> >> >> Ideally, you would implement a sanity check for the feature you need from >> the kernel. Though it opens a question of whether we want to ship multiple >> sanity check tools for each of repos (neutron + 3 *aas repos). >> >> If we can consolidate that and use a single tool from the master neutron > repository, that would be my vote. > >> >> Also, if you can kindly review the code here: >> https://review.openstack.org/#/c/146508/5/neutron_vpnaas/services/vpn/common/netns_wrapper.py, >> I'd really appreciate it, as I'm not versed in the Linux proc files at all. >> >> Thanks! >> >> >> PCM (Paul Michali) >> >> IRC............ pc_m (irc.freenode.com) >> Twitter....... @pmichali >> >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Kevin Benton
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev