Open Stack

On Aug 20, 2013, at 12:02 PM, Nachi Ueno <nachi at ntti3.com> wrote:
> Hi Paul
> 
> 2013/8/20 Paul Michali <pcm at cisco.com>:
>> Was the original reasoning to use StrongSwan over OpenSwan, only because of
>> community support? I vaguely recall something mentioned about StrongSwan
>> having additional capabilities or something. Can anyone confirm?
>> 
>> As far as which option, it sounds like B or C-2 are the better choices, just
>> because of the RHEL support. The two are very similar (from an end-user
>> standpoint), so the added doc/help shouldn't be too bad. From a  code
>> perspective, much of the code can be shared, so the added testing
>> requirements should also be minimal.
> 
> OK so C-2 has +3. (Salvatore, Paul and me)
> 
+1 for C-2 as well from me.

>> The only point to make about C-2 is it requires us to either take the extra
>> time now to support multiple drivers (we will have to eventually - I'll be
>> working on one), or do a refactoring later to support a hierarchy of
>> drivers. I brought that point up in the review of the reference driver, and
>> Nachi and I talked about this a bit yesterday. We both agreed that we could
>> do the refactoring later, to support drivers that are different than the
>> Swan family.
>> 
>> Related to that, I did have some question about multiple drivers...
>> 
>> How do we handle the case where the drivers support different capabilities?
>> For example, say one driver supports an encryption mode that the other does
>> not.
>> 
>> Can we reject unsupported capabilities at configuration time? That seems
>> cleaner, but I'm wondering how that would be done (I know we'll specify the
>> provider, but wondering how we'll invoke driver specific verification
>> routines - do we have that mechanism defined?).
> 
> There is two kind of drivers.
> - service_drivers (server side)
>  Handle API request and dispatch request for agent side
> #This is called plugin_driver in LBaaS, but I prefer service_driver
> because it is more specific name)
> 
> - device_drivers (agent side)
>  Get request from API then apply config for agent
> 
> So regarding to the capabilities, we should write new service_drivers.
> 
> Best
> Nachi
> 
>> Regards,
>> 
>> PCM (Paul Michali)
>> 
>> MAIL pcm at cisco.com
>> IRC   pcm_  (irc.freenode.net)
>> TW   @pmichali
>> 
>> On Aug 19, 2013, at 6:15 PM, Nachi Ueno <nachi at ntti3.com> wrote:
>> 
>> Hi folks
>> 
>> I would like to discuss whether supporting OpenSwan or StrongSwan or Both
>> for
>> ipsec driver?
>> 
>> We choose StrongSwan because of the community is active and plenty of docs.
>> However It looks like RHEL is only supporting OpenSwan.
>> 
>> so we should choose
>> 
>> (A) Support StrongSwan
>> (B) Support OpenSwan
>> (C) Support both
>>  (C-1) Make StrongSwan default
>>  (C-2) Make OpenSwan default
>> 
>> Actually, I'm working on C-2.
>> The patch is still WIP https://review.openstack.org/#/c/42264/
>> 
>> Besides the patch is small, supporting two driver may burden
>> in H3 including docs or additional help.
>> IMO, this is also a valid comment.
>> 
>> Best
>> Nachi
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev