On Aug 20, 2013, at 12:02 PM, Nachi Ueno <na...@ntti3.com> wrote: > Hi Paul > > 2013/8/20 Paul Michali <p...@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 p...@cisco.com >> IRC pcm_ (irc.freenode.net) >> TW @pmichali >> >> On Aug 19, 2013, at 6:15 PM, Nachi Ueno <na...@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@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
