Odg: Proposal of new config property "ssl-server-name-extension"
Hi, Since this proposal is open for almost three weeks, and we have 2 plus one, We will continue with proposed solution. Regards, Mario Šalje: Mario Ivanac Poslano: 19. studenog 2019. 12:26 Prima: dev@geode.apache.org Predmet: Proposal of new config property "ssl-server-name-extension" Hi geode dev, as a part of solution for https://issues.apache.org/jira/browse/GEODE-7414 we would like to introduce new config property "ssl-server-name-extension". This property will contain generic string, which will be added as Server Name Indication (SNI) parameter to Client Hello message. Do you agree with this proposal? Thanks, Mario
Re: Odg: Proposal of new config property "ssl-server-name-extension"
Hi Mario,
I did have a question / suggestion about this proposal (possibly on a
different thread). Would you mind responding to that before proceeding
please. I'll just paste it in here too.
> Jens Deppe
> Tue, Nov 19, 4:42 PM
> to dev
> I'd like to add my comment from the original PR here again:
>
>
> Although I support the particular use case, I would prefer the
> implementation being a bit more abstracted. Specifically, if we provided an
> extension point which would allow modification of SSLParameters then we
> wouldn't be coupling to a particular use case. So I'm thinking that the
> user would define (via say a ssl-parameter-extension parameter) a class
> that takes in a SSLParameter and perhaps SSLConfig and whatever else for
> this use-case and does what it needs. The user class would need to
> implement an interface something like this:
>
> public interface SSLParameterExtension {
> SSLParameter modify(SSLParameter, SSLConfig);
> }
>
> I would imagine seeing the user implementation of this being attached to
> SSLConfig.
>
>
> (https://github.com/apache/geode/pull/4310)
>
> I don't mind (mis)using the Server Name field to convey some other
> information, but since it's possible to abstract the specific nature and
> application of that information, I think we should do so. Anyone else who
> looks at the code is going to wonder what the use is especially if the
> consumer of that particular piece of info is going to be provided via an
> external SSLEngine implementation.
>
>
Thanks!
--Jens
On Mon, Dec 9, 2019 at 2:37 AM Mario Ivanac wrote:
> Hi,
>
> Since this proposal is open for almost three weeks,
> and we have 2 plus one,
>
> We will continue with proposed solution.
>
> Regards,
> Mario
>
>
> Šalje: Mario Ivanac
> Poslano: 19. studenog 2019. 12:26
> Prima: dev@geode.apache.org
> Predmet: Proposal of new config property "ssl-server-name-extension"
>
> Hi geode dev,
>
> as a part of solution for https://issues.apache.org/jira/browse/GEODE-7414
> we would like to introduce new config property "ssl-server-name-extension".
>
> This property will contain generic string, which will be added as Server
> Name Indication (SNI) parameter to Client Hello message.
>
> Do you agree with this proposal?
>
> Thanks,
> Mario
>
Odg: Odg: Proposal of new config property "ssl-server-name-extension"
Hi,
I agree with your proposal/question,
and implementation will follow it.
BR,
Mario
Šalje: Jens Deppe
Poslano: 9. prosinca 2019. 15:55
Prima: dev@geode.apache.org
Predmet: Re: Odg: Proposal of new config property "ssl-server-name-extension"
Hi Mario,
I did have a question / suggestion about this proposal (possibly on a
different thread). Would you mind responding to that before proceeding
please. I'll just paste it in here too.
> Jens Deppe
> Tue, Nov 19, 4:42 PM
> to dev
> I'd like to add my comment from the original PR here again:
>
>
> Although I support the particular use case, I would prefer the
> implementation being a bit more abstracted. Specifically, if we provided an
> extension point which would allow modification of SSLParameters then we
> wouldn't be coupling to a particular use case. So I'm thinking that the
> user would define (via say a ssl-parameter-extension parameter) a class
> that takes in a SSLParameter and perhaps SSLConfig and whatever else for
> this use-case and does what it needs. The user class would need to
> implement an interface something like this:
>
> public interface SSLParameterExtension {
> SSLParameter modify(SSLParameter, SSLConfig);
> }
>
> I would imagine seeing the user implementation of this being attached to
> SSLConfig.
>
>
> (https://github.com/apache/geode/pull/4310)
>
> I don't mind (mis)using the Server Name field to convey some other
> information, but since it's possible to abstract the specific nature and
> application of that information, I think we should do so. Anyone else who
> looks at the code is going to wonder what the use is especially if the
> consumer of that particular piece of info is going to be provided via an
> external SSLEngine implementation.
>
>
Thanks!
--Jens
On Mon, Dec 9, 2019 at 2:37 AM Mario Ivanac wrote:
> Hi,
>
> Since this proposal is open for almost three weeks,
> and we have 2 plus one,
>
> We will continue with proposed solution.
>
> Regards,
> Mario
>
>
> Šalje: Mario Ivanac
> Poslano: 19. studenog 2019. 12:26
> Prima: dev@geode.apache.org
> Predmet: Proposal of new config property "ssl-server-name-extension"
>
> Hi geode dev,
>
> as a part of solution for https://issues.apache.org/jira/browse/GEODE-7414
> we would like to introduce new config property "ssl-server-name-extension".
>
> This property will contain generic string, which will be added as Server
> Name Indication (SNI) parameter to Client Hello message.
>
> Do you agree with this proposal?
>
> Thanks,
> Mario
>
Re: New geode-gfsh module
> I imagine once the Management v2 API's are GA (and feature complete), I don't see a reason why /gfsh/ should not be a stand alone module. It would definitely have to be updated to use the new v2 API's, which should not have any direct dependency on geode-core any more. There also is a big question here of how much of the current GFSH functionality needs to be there to fully replace the current GFSH. Looking at the functionality available right now, it seems like we have a very long way ahead of us. On Fri, Dec 6, 2019 at 12:32 PM Owen Nichols wrote: > Any standalone management API or client thereof would not be able to start > locator or start server. For that gfsh still needs a large chunk of > Geode. > > > > On Dec 6, 2019, at 12:25 PM, Udo Kohlmeyer wrote: > > > > I imagine once the Management v2 API's are GA (and feature complete), I > don't see a reason why /gfsh/ should not be a stand alone module. It would > definitely have to be updated to use the new v2 API's, which should not > have any direct dependency on geode-core any more. > > > > On 12/6/19 10:01 AM, Jacob Barrett wrote: > >> > >>> On Dec 6, 2019, at 9:44 AM, Jens Deppe wrote: > >>> > >>> Just to be clear, this effort does *not* result in a standalone gfsh > >>> executable/jar. > >> Is this a future plan? > >> > >> > >
Re: [DISCUSS] Replacing singleton PoolManager
+1 Aaron > On Dec 6, 2019, at 10:49 AM, Jacob Barrett wrote: > > > >> On Dec 6, 2019, at 9:40 AM, Dan Smith wrote: >> >> Regarding changing PoolManager to >> an interface, I guess originally I wasn't thinking we would still be >> backwards compatible if we did that. But as I think about it I think that >> might be ok. One slight issue with that approach is that we have to come up >> with new names for the methods - we can't have both an instance and a >> static method with the same name and args. Maybe still worth it > > Doh! I didn’t think about that. It sort of defeats the purpose of reusing the > class. So going with a whole new class probably makes more sense to remove > confusion. > > -Jake >
Re: New geode-gfsh module
Reading over the docs for gfsh - I don't support removing any functionality from a top level command perspective.It should be noted that I didn't go deeper then the top level commands, there might be some sub option on some command that could be dropped or tweaked. Charlie On Mon, Dec 9, 2019 at 8:32 AM Alexander Murmann wrote: > > I imagine once the Management v2 API's are GA (and feature complete), I > don't see a reason why /gfsh/ should not be a stand alone module. It > would definitely have to be updated to use the new v2 API's, which > should not have any direct dependency on geode-core any more. > > There also is a big question here of how much of the current GFSH > functionality needs to be there to fully replace the current GFSH. Looking > at the functionality available right now, it seems like we have a very long > way ahead of us. > > On Fri, Dec 6, 2019 at 12:32 PM Owen Nichols wrote: > > > Any standalone management API or client thereof would not be able to > start > > locator or start server. For that gfsh still needs a large chunk of > > Geode. > > > > > > > On Dec 6, 2019, at 12:25 PM, Udo Kohlmeyer wrote: > > > > > > I imagine once the Management v2 API's are GA (and feature complete), I > > don't see a reason why /gfsh/ should not be a stand alone module. It > would > > definitely have to be updated to use the new v2 API's, which should not > > have any direct dependency on geode-core any more. > > > > > > On 12/6/19 10:01 AM, Jacob Barrett wrote: > > >> > > >>> On Dec 6, 2019, at 9:44 AM, Jens Deppe wrote: > > >>> > > >>> Just to be clear, this effort does *not* result in a standalone gfsh > > >>> executable/jar. > > >> Is this a future plan? > > >> > > >> > > > > > -- Charlie Black | cbl...@pivotal.io
Re: [DISCUSS] Replacing singleton PoolManager
On Fri, Dec 6, 2019 at 10:45 AM Dale Emery wrote: > > > Dale - are you suggesting a ConnectionPoolService that returns > ConnectionPool instances? > > Yes. > > > Would that mean ConnectionPool would extend Pool and we would deprecate > Pool itself? > > Maybe extend. I worry about extending, for two reasons. > > First, extending would make the new interface depend on the deprecated > one. That feels awkward for reasons I can’t articulate > > Second, extending would mean that the new interface gets all the methods > of the deprecated one whether we want them or not. I don’t know enough > about Pool to have an opinion about whether we want to carry all of its > method signatures forward. > > An alternative to consider: Each ConnectionPool implementation delegates > to a Pool. I suspect that this would make it harder to migrate existing > uses from Pool to ConnectionPool. > We could flip what extends what - Have Pool extend ConnectionPool. Deprecate Pool. This would affect the following public APIs: Pool: Would need to extend a new parent interface called ConnectionPool PoolFactory: Would also need a new parent interface called ConnectionPoolFactory FunctionService: Would need to take ConnectionPool instead of Pool ClientCacheFactory: Deprecate all the setPoolXXX methods and add setConnectionPoolXXX? ClientCache: Deprecate getDefaultPool and add getDefaultConnectionPool? RegionFactory and RegionAttributes: Deprecate setPoolName and add setConnectionPoolName cache-1.0.xsd : Deprecate the elements and add elements instead. This will also affect downstream projects that use a pool such as Spring Data Geode - that project will maybe want to rename PoolFactoryBean, etc. I guess I'm not sold that making all these name changes is worth it to users. Just removing the singleton as the current proposal stands is a much smaller scope of change. What do you all think? -Dan
