This group is locked. No changes can be made to the group while it is locked.
Date
1 - 20 of 22
CLI commands removed in an Boron SR
|
Colin Dixon <colin@...>
So, in some downstream testing at Brocade we found that the AAA CLI commands were changed somewhat drastically between Boron-SR2 and Boron-SR3, which is probably not in the spirit of SRs. While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs. That being said, we're trying to make the best of it and looking for help in understanding how to get the functionality we rely on from AAA back in Boron-SR3. This patch seems to be the issue: Is there somebody that can comment on how we might recover the functionality that used to be provided by the gen-odl-ks and gen-trust-ks CLI commands? Would simply reverting that patch work or would it break other things as well? Thanks, --Colin
|
|
|
|
Ryan Goulding <ryandgoulding@...>
which is probably not in the spirit of SRs This was done for both usability and security purposes, as I explained via Skype already. The security advantages alone make it justifiable IMHO. While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs.j This isn't a feature, it is CLI. This patch seems to be the issue: https://git.opendaylight.org/ Yes, if you look at the bug actually, a member from your team commented on it [0] so I'd argue that it was at least somewhat well known ;). Reverting it shouldn't be particularly hard, but it could open you open to some security issues in your downstream distro! Regards, Ryan Goulding On Wed, Apr 26, 2017 at 3:03 PM, Colin Dixon <colin@...> wrote:
|
|
|
|
Colin Dixon <colin@...>
Putting the argument about what should go in an SR aside for the moment, is there a straightforward way to access the functionality that was provided by the removed commands? Specifically gen-odl-ks and gen-trust-ks? --Colin
On Wed, Apr 26, 2017 at 3:15 PM Ryan Goulding <ryandgoulding@...> wrote:
|
|
|
|
Mohamed ElSerngawy <melserngawy@...>
Hi Colin, You are not suppose to use them after the changes that we made in the patch. Basically these functionalities were there because of the keystores need to be generated after starting ODL. But now, the keystore will be created once you install the aaa-cert feature. keeping this functionalities could make a serious security thread. BR
On Wed, Apr 26, 2017 at 3:40 PM, Colin Dixon <colin@...> wrote:
|
|
|
|
Luis Gomez
hi guys, I just tested old-aaa-cert feature and couple of things:
toggle quoted messageShow quoted text
1) it does not work in Boron, I get 500 Server error + NPE [1] when I try: POST /restconf/operations/aaa-cert-rpc:getODLCertificate 2) When I try in carbon I see 2 store files: ctl.jks, truststore.jks are created under ~/temp folder. Is it possible to change the path for these files? [1] NPE <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/> <title>Error 500 Server Error</title> </head> <body> <h2>HTTP ERROR 500</h2> <p>Problem accessing /restconf/operations/aaa-cert-rpc:getODLCertificate. Reason: <pre> Server Error</pre> </p> <h3>Caused by:</h3> <pre>java.lang.NullPointerException at org.opendaylight.aaa.cert.impl.AaaCertRpcServiceImpl.getODLCertificate(AaaCertRpcServiceImpl.java:92) at org.opendaylight.yangtools.yang.binding.util.RpcMethodInvokerWithoutInput.invokeOn(RpcMethodInvokerWithoutInput.java:30) at org.opendaylight.yangtools.yang.binding.util.AbstractMappedRpcInvoker.invokeRpc(AbstractMappedRpcInvoker.java:52) at org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcImplementationAdapter.invoke(BindingDOMRpcImplementationAdapter.java:85) at org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcImplementationAdapter.invokeRpc(BindingDOMRpcImplementationAdapter.java:72) at org.opendaylight.controller.md.sal.dom.broker.impl.GlobalDOMRpcRoutingTableEntry.invokeRpc(GlobalDOMRpcRoutingTableEntry.java:39) at org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRoutingTable.invokeRpc(DOMRpcRoutingTable.java:177) at org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRouter.invokeRpc(DOMRpcRouter.java:102) at Proxye69c1788_e30d_4fd8_8d29_f7f08932a9e7.invokeRpc(Unknown Source) at org.opendaylight.netconf.sal.restconf.impl.BrokerFacade.invokeRpc(BrokerFacade.java:506) at org.opendaylight.netconf.sal.restconf.impl.RestconfImpl.invokeRpc(RestconfImpl.java:464) at org.opendaylight.netconf.sal.restconf.impl.StatisticsRestconfServiceWrapper.invokeRpc(StatisticsRestconfServiceWrapper.java:83) at org.opendaylight.netconf.sal.rest.impl.RestconfCompositeWrapper.invokeRpc(RestconfCompositeWrapper.java:64) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60) at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:185) at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75) at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302) at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147) at com.sun.jersey.server.impl.uri.rules.ResourceObjectRule.accept(ResourceObjectRule.java:100) at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147) at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84) at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1511) at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1442) at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1391) at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1381) at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:416) at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:538) at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:716) at javax.servlet.http.HttpServlet.service(HttpServlet.java:668) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1507) at org.eclipse.jetty.servlets.CrossOriginFilter.handle(CrossOriginFilter.java:247) at org.eclipse.jetty.servlets.CrossOriginFilter.doFilter(CrossOriginFilter.java:210) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478) at org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:82) at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:256) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478) at org.opendaylight.aaa.filterchain.filters.CustomFilterAdapter.doFilter(CustomFilterAdapter.java:85) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478) at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61) at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108) at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137) at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125) at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66) at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108) at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137) at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125) at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66) at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449) at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365) at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90) at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83) at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383) at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362) at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499) at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086) at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:240) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:427) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135) at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:75) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) at org.eclipse.jetty.server.Server.handle(Server.java:370) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:973) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1035) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:641) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:231) at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82) at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696) at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543) at java.lang.Thread.run(Thread.java:745)
On Apr 26, 2017, at 12:50 PM, Mohamed ElSerngawy <melserngawy@...> wrote:
|
|
|
|
Jamo Luhrsen <jluhrsen@...>
btw, I was also trying to help get a broken AAA CSIT job working and ran in to some
toggle quoted messageShow quoted text
troubles similar symptoms [0] to what Luis is reporting (500/NPE). Luis is playing with cert stuff, and my work was in user/domain auth. anyway, wondering if something fundamental is broken? JamO [0] https://lists.opendaylight.org/pipermail/aaa-dev/2017-April/001280.html
On 04/26/2017 06:21 PM, Luis Gomez wrote:
hi guys, I just tested old-aaa-cert feature and couple of things:
|
|
|
|
Colin Dixon <colin@...>
Do we have an idea of what the implications of just reverting that one patch are? Is it likely to work? --Colin
On Wed, Apr 26, 2017 at 11:11 PM Jamo Luhrsen <jluhrsen@...> wrote: btw, I was also trying to help get a broken AAA CSIT job working and ran in to some
|
|
|
|
Ryan Goulding <ryandgoulding@...>
The stuff you are referring to works, JamO, and is completely orthogonal to the issue Luis reports. If you paste the exact REST call I can assist. Also, if you are curious how to use those endpoints, refer to idmtool.py, which just wraps that interface. I just tested this morning.
I'll give it a shot and see what I get. Do we have an idea of what the implications of just reverting that one patch are? Is it likely to work? So far we haven't demonstrated that the patch does anything negative except deprecate some unsafe commands. Although revert may probably be easiest from your perspective, there are a lot of people who actually push their tests upstream and avoid this type of skew. Let's not start a witch hunt quite yet; I can pull up quite a few examples of far more risque changes in service releases ;). Regards, Ryan Goulding On Thu, Apr 27, 2017 at 9:11 AM, Colin Dixon <colin@...> wrote:
|
|
|
|
Mohamed ElSerngawy <melserngawy@...>
Hi Luis, 1) it does not work in Boron, I get 500 Server error + NPE [1] when I try: POST /restconf/operations/aaa-cert- This issue for Boron release it has beed fixed by patch [0]. so please try again and let me know if it still there. 2) When I try in carbon I see 2 store files: ctl.jks, truststore.jks are created under ~/temp folder. Is it possible to change the path for these files? For Carbon, The keystores stored at MD-SAL not as files OR if you will change the config to store the keystores as files, it will be under configuration/ssl/ . I guess Those files are created by the unit Test classes. BR
On Thu, Apr 27, 2017 at 9:11 AM, Colin Dixon <colin@...> wrote:
|
|
|
|
Ryan Goulding <ryandgoulding@...>
Works for me... ryan@ubuntu:/code/aaa-nitrogen/karaf/target/assembly$ curl -u admin:admin -X POST -v http://localhost:8181/restconf/operations/aaa-cert-rpc:getODLCertificate * Trying 127.0.0.1... * Connected to localhost (127.0.0.1) port 8181 (#0) * Server auth using Basic with user 'admin' > POST /restconf/operations/aaa-cert-rpc:getODLCertificate HTTP/1.1 > Host: localhost:8181 > Authorization: Basic YWRtaW46YWRtaW4= > User-Agent: curl/7.47.0 > Accept: */* > < HTTP/1.1 200 OK < Set-Cookie: JSESSIONID=1c7rj2qb91h8vpm7sba4j444r;Path=/restconf < Expires: Thu, 01 Jan 1970 00:00:00 GMT < Set-Cookie: rememberMe=deleteMe; Path=/restconf; Max-Age=0; Expires=Wed, 26-Apr-2017 14:06:26 GMT < Content-Type: application/yang.operation+json < Transfer-Encoding: chunked < * Connection #0 to host localhost left intact {"output":{"odl-cert":"MIICKTCCAZKgAwIBAgIEcp0NTDANBgkqhkiG9w0BAQUFADBZMQwwCgYDVQQDDANPREwxDDAKBgNVBAsMA0RldjEYMBYGA1UECgwPTGludXhGb3VuZGF0aW9uMRQwEgYDVQQHDAtRQyBNb250cmVhbDELMAkGA1UEBhMCQ0EwHhcNMTcwNDI3MTM1ODU4WhcNMTgwNDI3MTM1ODU4WjBZMQwwCgYDVQQDDANPREwxDDAKBgNVBAsMA0RldjEYMBYGA1UECgwPTGludXhGb3VuZGF0aW9uMRQwEgYDVQQHDAtRQyBNb250cmVhbDELMAkGA1UEBhMCQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJtRMT40niJzHGUewHeTKLujY3Wfp1A/AStwLsm554m4nKcq1g8+vkcQbfMijaDZkFRrKM/x7kI9BnjCkbADHbnYE3Zgf+o52wuUEHXeS21Bq2TL0+TFlazel+xlySUH+L+PAygs1Giq1WTf7to3VSStILzmL8DbjUrcsZPt/185AgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAbHA5eVO2KZQSMvFehH1/tGmqkUYzWRAq8wrOlD5zdGuqvv9YBuBL/rScytAJ9qTHvhVYcW17Ch2IHeuMoEyym6DCLSmgegPiCptdMjQ7+9FNzSFf/lIKhtDhK7Nzm0F2u44utAJ5qfj3ZUWnq5LjIWaxocfeYIi0KXKyaNZGPfE="}} Regards, Ryan Goulding
On Thu, Apr 27, 2017 at 9:34 AM, Mohamed ElSerngawy <melserngawy@...> wrote:
|
|
|
|
Ryan Goulding <ryandgoulding@...>
Actually scratch that @Luis, I get the same thing with boron-sr3. The output above is from carbon (I was confused due to the fact that the patch referenced was in carbon). There appears to be something screwy in boron-sr3... Regards, Ryan Goulding
On Thu, Apr 27, 2017 at 10:07 AM, Ryan Goulding <ryandgoulding@...> wrote:
|
|
|
|
Colin Dixon <colin@...>
That's a link to a patch in carbon, not boron. Is that to say the functionality is broken in Boron-SR3? If so, we need to figure out if there's a work-around and if so, document it in the Boron-SR3 release notes. Can we get documentation for how somebody is supposed to: 1.) create the ODK keystore and trust keystore (replacing gen-odl-ks and gen-trust-ks) 2.) add a certificate to the ODL and turst keystores (replacing add-odl-cert and add-trust-cert) I _think_ those are the only CLI commands we removed. It appears as though the replacement for 1.) is just feature:install odl-aaa-cert which will create the keystores automatically now. It's less clear what the replacement to 2.) is. It appears as though the RPCs which should replace them throw NPEs. Is the workaround until we fix that (in Boron-SR4?) to use keytool from the Linux CLI? --Colin
On Thu, Apr 27, 2017 at 9:34 AM, Mohamed ElSerngawy <melserngawy@...> wrote:
|
|
|
|
Mohamed ElSerngawy <melserngawy@...>
Hi Luis, I test the aa-cert RPCs with Boron and it works fine, did u change the aaa-cert-config.xml file ? I guess you may missed that. basically you need to change the <use-config> to true if you want to use keystore files and change <use-mdsal> true if you want to store the keystores in mdsal. Then don't forget to restart karaf. check the wiki for more info Hi Colin, Can we get documentation for how somebody is supposed to: 1.) create the ODK keystore and trust keystore (replacing gen-odl-ks and gen-trust-ks) yes, just after installing the aaa-cert feature and changing the aaa-cert-config the keystore will be created. You can also use the java keytool commands to create the keystore instead. Moreover, If you wish to use a pre-created keystores signed by CA just copy those files to directory configuration/ssl/ and change the aaa-cert-config.xml <use-config> to true odl will use those files 2.) add a certificate to the ODL and turst keystores (replacing add-odl-cert and add-trust-cert) use the RPCs to do this. BR
On Thu, Apr 27, 2017 at 11:46 AM, Colin Dixon <colin@...> wrote:
|
|
|
|
Ryan Goulding <ryandgoulding@...>
I admittedly missed this configuration as well!
On Apr 27, 2017, at 12:37 PM, Mohamed ElSerngawy <melserngawy@...> wrote:
|
|
|
|
Luis Gomez
Thanks Mohamed, it works in Boron with your suggestion. So what happens is that in Boron both <use-config> and <use-mdsal> are set to false by default and as a minimum you need to set the first to true for the feature to work. In Carbon both are set to true by default so the feature works out-of-the-box. BR/Luis
|
|
|
|
Ryan Goulding <ryandgoulding@...>
Confirmed here as well: ryan@ubuntu:~/Desktop/distribution-karaf-0.5.3-Boron-SR3$ curl -u admin:admin -X POST -v http://localhost:8181/restconf/operations/aaa-cert-rpc:getODLCertificate * Trying 127.0.0.1... * Connected to localhost (127.0.0.1) port 8181 (#0) * Server auth using Basic with user 'admin' > POST /restconf/operations/aaa-cert-rpc:getODLCertificate HTTP/1.1 > Host: localhost:8181 > Authorization: Basic YWRtaW46YWRtaW4= > User-Agent: curl/7.47.0 > Accept: */* > < HTTP/1.1 200 OK < Set-Cookie: JSESSIONID=c68vb1yxkgge1de3149bg89f4;Path=/restconf < Expires: Thu, 01 Jan 1970 00:00:00 GMT < Set-Cookie: rememberMe=deleteMe; Path=/restconf; Max-Age=0; Expires=Wed, 26-Apr-2017 17:05:02 GMT < Content-Type: application/yang.operation+json < Transfer-Encoding: chunked < Server: Jetty(8.1.19.v20160209) < * Connection #0 to host localhost left intact {"output":{"odl-cert":"MIICKjCCAZOgAwIBAgIFAMJ8aK8wDQYJKoZIhvcNAQEFBQAwWTEMMAoGA1UEAwwDT0RMMQwwCgYDVQQLDANEZXYxGDAWBgNVBAoMD0xpbnV4Rm91bmRhdGlvbjEUMBIGA1UEBwwLUUMgTW9udHJlYWwxCzAJBgNVBAYTAkNBMB4XDTE3MDQyNzE3MDQ1NFoXDTE4MDQyNzE3MDQ1NFowWTEMMAoGA1UEAwwDT0RMMQwwCgYDVQQLDANEZXYxGDAWBgNVBAoMD0xpbnV4Rm91bmRhdGlvbjEUMBIGA1UEBwwLUUMgTW9udHJlYWwxCzAJBgNVBAYTAkNBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCc0BBRpaAESyUD9PRTbpS3Qx39EIt3SvZKNqw9RnUes3h7AVaBIImbjpAkCVRYrM+e5f9l2kKraTbbSf2XBvS8GeyvGpTBONAgr/R1F6i1F10Pyw3kmUKjQu7/9kMa9M/9fnNREOvIO4hOwbUvLNeU9cjNOkpXsZRC/JDVZ9RpiQIDAQABMA0GCSqGSIb3DQEBBQUAA4GBAEOBewJgTHHdUMAG7H1yauAPKW1adKtgh1+hdasQVFz0QdzoraY8JHpffJguTB4cX0zaAen4rF5bbrY9I4KNGajrUND8WsjZ8BSOeGyX0i600ZCZxztYT2ETDKZPoWoKwONaJbdqbAuvD8RdPIW5kddZi2tOhNIsLh74NaQGMShj"}}ryan@ubuntu:~/Desktop/distribution-karaf-0.5.3-Boron-SR3$ Are we good with this? I.e., can you use RPC(s) instead of CLI commands? Trying to be helpful here :). Regards, Ryan Goulding
On Thu, Apr 27, 2017 at 1:01 PM, Luis Gomez <ecelgp@...> wrote:
|
|
|
|
Colin Dixon <colin@...>
We're testing things internally to make sure this all works the way we think it does. My guess is that this will get us over the hump, but either Luis or I will follow up if not. Thanks, --Colin
On Thu, Apr 27, 2017 at 1:06 PM, Ryan Goulding <ryandgoulding@...> wrote:
|
|
|
|
Ryan Goulding <ryandgoulding@...>
Please let us know if there is anything else we can do to help. I know that most of those karaf CLI commands were designed to be quite modular (thanks Moh), so we should be able to port them back in if absolutely necessary (w/ the security caveats surrounding what we discussed in the sync). Reach out if you are still running into show stoppers and we will do our best to help. Regards, Ryan Goulding
On Thu, Apr 27, 2017 at 1:08 PM, Colin Dixon <colin@...> wrote:
|
|
|
|
Luis Gomez
Mohamed, another thing I would like to confirm with you is that OVSDB SSL can use mdsal storage for cluster deployments but OpenFlow SSL cannot use mdsal yet, right? BR/Luis
|
|
|
|
Luis Gomez
Thanks Ryan, so far I think we are good, I will let you know otherwise.
|
|
|