July 2017 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-8057) AdminOperation task engine does not adhere to API

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-8057?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-8057: -------------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > AdminOperation task engine does not adhere to API > ------------------------------------------------- > > Key: ISPN-8057 > URL: https://issues.jboss.org/browse/ISPN-8057 > Project: Infinispan > Issue Type: Bug > Components: Server, Tasks > Affects Versions: 9.1.0.CR1 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 9.1.0.Final > > > The AdminOperation task engine returns a Set<Class> instead of Set<Task> for getTasks() -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8058) The org.infinispan.tasks.Task interface should be in the tasks-api package

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-8058?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-8058: -------------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > The org.infinispan.tasks.Task interface should be in the tasks-api package > -------------------------------------------------------------------------- > > Key: ISPN-8058 > URL: https://issues.jboss.org/browse/ISPN-8058 > Project: Infinispan > Issue Type: Task > Components: Tasks > Affects Versions: 9.1.0.CR1 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 9.1.0.Final > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7973) Investigate Service Brokers

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-7973?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec commented on ISPN-7973: ------------------------------------------- A very good API walk through: https://www.youtube.com/watch?v=0aLqc-o256w&list=PL69nYSiGNLP2k9ZXx9E1MvR... > Investigate Service Brokers > --------------------------- > > Key: ISPN-7973 > URL: https://issues.jboss.org/browse/ISPN-7973 > Project: Infinispan > Issue Type: Feature Request > Components: Cloud Integrations > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7998) Multi-key write commands assume all segments have CH.getNumOwners() owners

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-7998?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-7998: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Multi-key write commands assume all segments have CH.getNumOwners() owners > -------------------------------------------------------------------------- > > Key: ISPN-7998 > URL: https://issues.jboss.org/browse/ISPN-7998 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.1.0.Beta1, 9.0.3.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.1.0.Final > > > When handling multi-key write commands, both {{TriangleDistributionInterceptor}} and {{NonTxDistributionInterceptor}} assume that there are no backup owners when {{consistentHash.getNumOwners() == 1}}. But during rebalance some segments can have more than {{getNumOwners()}} owners, as the write CH is a union of the current and future CHs, while {{getNumOwners()}} always returns the value in the cache configuration. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7973) Investigate Service Brokers

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-7973?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec commented on ISPN-7973: ------------------------------------------- Things to clarify and other issues: * No UI for creating/deleting/editing ServicePlans. It is also worth to mention that OpenShift Origin (with {{oc cluster up}}) comes with one default plan (use {{oc edit ServiceClass infinispan-ephemeral}} to view it). * Shall we create separate separate service or one service with multiple plans? > Investigate Service Brokers > --------------------------- > > Key: ISPN-7973 > URL: https://issues.jboss.org/browse/ISPN-7973 > Project: Infinispan > Issue Type: Feature Request > Components: Cloud Integrations > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7973) Investigate Service Brokers

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-7973?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec edited comment on ISPN-7973 at 7/12/17 4:08 AM: -------------------------------------------------------------------- Based on [discussion between Marko Luksa and Emmanuel Bernard|https://bluejeans.com/s/uij6Y]: * Marko implemented En Masse. * The Broker controls instances it created. E.g. we might imagine having a JDG Broker which will add a cache to all living instances. * The {{ServicePlan}} is a resource incorporated into {{ServiceClass}}. It is not separate. * The Broker can instantiate the service synchronously or asynchronously. * The client can specify the name of a {{Secret}} with credentials. Currently users need to preconfigure their apps (to use the secret provided by the Catalog). There are plans to make it the other way around. * An {{Endpoints}} object contains a list of IP addresses and ports to desired Pods (or other type of services) * The Boker Pod can provide its own UI (it's just a running Pod). Things to clarify and other issues: * No UI for creating/deleting/editing ServicePlans. It is also worth to mention that OpenShift Origin (with {{oc cluster up}}) comes with one default plan (use {{oc edit ServiceClass infinispan-ephemeral}} to view it). * Shall we create separate separate service or one service with multiple plans? was (Author: sebastian.laskawiec): Based on [discussion between Marko Luksa and Emmanuel Bernard|https://bluejeans.com/s/uij6Y]: * Marko implemented En Masse. * The Broker controls instances it created. E.g. we might imagine having a JDG Broker which will add a cache to all living instances. * The {{ServicePlan}} is a resource incorporated into {{ServiceClass}}. It is not separate. * The Broker can instantiate the service synchronously or asynchronously. * The client can specify the name of a {{Secret}} with credentials. Currently users need to preconfigure their apps (to use the secret provided by the Catalog). There are plans to make it the other way around. * An {{Endpoints}} object contains a list of IP addresses and ports to desired Pods (or other type of services) * The Boker Pod can provide its own UI (it's just a running Pod). * Ideas: * We may use the Broker to instrument the deployed JDG instances * We may use the Broker to instantiate JDG instances outside of the cloud. During the Bind step we could provide credentials to connect to it. In addition to that we'd need to manually facilitate {{Endpoints}} objects pointing to the cluster. * During the bind operation we should provide {{hotrod-client.properties}}. * Things to clarify and other issues: * No UI for creating/deleting/editing ServicePlans. It is also worth to mention that OpenShift Origin (with {{oc cluster up}}) comes with one default plan (use {{oc edit ServiceClass infinispan-ephemeral}} to view it). * Shall we create separate separate service or one service with multiple plans? > Investigate Service Brokers > --------------------------- > > Key: ISPN-7973 > URL: https://issues.jboss.org/browse/ISPN-7973 > Project: Infinispan > Issue Type: Feature Request > Components: Cloud Integrations > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7973) Investigate Service Brokers

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-7973?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec commented on ISPN-7973: ------------------------------------------- Ideas: * We may use the Broker to instrument the deployed JDG instances * We may use the Broker to instantiate JDG instances outside of the cloud. During the Bind step we could provide credentials to connect to it. In addition to that we'd need to manually facilitate {{Endpoints}} objects pointing to the cluster. * During the bind operation we should provide {{hotrod-client.properties}}. > Investigate Service Brokers > --------------------------- > > Key: ISPN-7973 > URL: https://issues.jboss.org/browse/ISPN-7973 > Project: Infinispan > Issue Type: Feature Request > Components: Cloud Integrations > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7973) Investigate Service Brokers

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-7973?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec edited comment on ISPN-7973 at 7/12/17 4:09 AM: -------------------------------------------------------------------- Based on [discussion between Marko Luksa and Emmanuel Bernard|https://bluejeans.com/s/uij6Y]: * Marko implemented En Masse. * The Broker controls instances it created. E.g. we might imagine having a JDG Broker which will add a cache to all living instances. * The {{ServicePlan}} is a resource incorporated into {{ServiceClass}}. It is not separate. * The Broker can instantiate the service synchronously or asynchronously. * The client can specify the name of a {{Secret}} with credentials. Currently users need to preconfigure their apps (to use the secret provided by the Catalog). There are plans to make it the other way around. * An {{Endpoints}} object contains a list of IP addresses and ports to desired Pods (or other type of services) * The Boker Pod can provide its own UI (it's just a running Pod). was (Author: sebastian.laskawiec): Based on [discussion between Marko Luksa and Emmanuel Bernard|https://bluejeans.com/s/uij6Y]: * Marko implemented En Masse. * The Broker controls instances it created. E.g. we might imagine having a JDG Broker which will add a cache to all living instances. * The {{ServicePlan}} is a resource incorporated into {{ServiceClass}}. It is not separate. * The Broker can instantiate the service synchronously or asynchronously. * The client can specify the name of a {{Secret}} with credentials. Currently users need to preconfigure their apps (to use the secret provided by the Catalog). There are plans to make it the other way around. * An {{Endpoints}} object contains a list of IP addresses and ports to desired Pods (or other type of services) * The Boker Pod can provide its own UI (it's just a running Pod). Things to clarify and other issues: * No UI for creating/deleting/editing ServicePlans. It is also worth to mention that OpenShift Origin (with {{oc cluster up}}) comes with one default plan (use {{oc edit ServiceClass infinispan-ephemeral}} to view it). * Shall we create separate separate service or one service with multiple plans? > Investigate Service Brokers > --------------------------- > > Key: ISPN-7973 > URL: https://issues.jboss.org/browse/ISPN-7973 > Project: Infinispan > Issue Type: Feature Request > Components: Cloud Integrations > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7973) Investigate Service Brokers

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-7973?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec edited comment on ISPN-7973 at 7/12/17 4:06 AM: -------------------------------------------------------------------- Based on [discussion between Marko Luksa and Emmanuel Bernard|https://bluejeans.com/s/uij6Y]: * Marko implemented En Masse. * The Broker controls instances it created. E.g. we might imagine having a JDG Broker which will add a cache to all living instances. * The {{ServicePlan}} is a resource incorporated into {{ServiceClass}}. It is not separate. * The Broker can instantiate the service synchronously or asynchronously. * The client can specify the name of a {{Secret}} with credentials. Currently users need to preconfigure their apps (to use the secret provided by the Catalog). There are plans to make it the other way around. * An {{Endpoints}} object contains a list of IP addresses and ports to desired Pods (or other type of services) * The Boker Pod can provide its own UI (it's just a running Pod). * Ideas: * We may use the Broker to instrument the deployed JDG instances * We may use the Broker to instantiate JDG instances outside of the cloud. During the Bind step we could provide credentials to connect to it. In addition to that we'd need to manually facilitate {{Endpoints}} objects pointing to the cluster. * During the bind operation we should provide {{hotrod-client.properties}}. * Things to clarify and other issues: * No UI for creating/deleting/editing ServicePlans. It is also worth to mention that OpenShift Origin (with {{oc cluster up}}) comes with one default plan (use {{oc edit ServiceClass infinispan-ephemeral}} to view it). * Shall we create separate separate service or one service with multiple plans? was (Author: sebastian.laskawiec): Based on [discussion between Marko Luksa and Emmanuel Bernard|https://bluejeans.com/s/uij6Y]: * Marko implemented En Masse. * The Broker controls instances it created. E.g. we might imagine having a JDG Broker which will add a cache to all living instances. * The {{ServicePlan}} is a resource incorporated into {{ServiceClass}}. It is not separate. * The Broker can instantiate the service synchronously or asynchronously. * The client can specify the name of a {{Secret}} with credentials. Currently users need to preconfigure their apps (to use the secret provided by the Catalog). There are plans to make it the other way around. * An {{Endpoints}} object contains a list of IP addresses and ports to desired Pods (or other type of services) * The Boker Pod can provide its own UI (it's just a running Pod). * Ideas: * We may use the Broker to instrument the deployed JDG instances * We may use the Broker to instantiate JDG instances outside of the cloud. During the Bind step we could provide credentials to connect to it. In addition to that we'd need to manually facilitate {{Endpoints}} objects pointing to the cluster. * During the bind operation we should provide {{hotrod-client.properties}}. * Potentially missing features: * No UI for creating/deleting/editing ServicePlans. It is also worth to mention that OpenShift Origin (with {{oc cluster up}}) comes with one default plan (use {{oc edit ServiceClass infinispan-ephemeral}} to view it). > Investigate Service Brokers > --------------------------- > > Key: ISPN-7973 > URL: https://issues.jboss.org/browse/ISPN-7973 > Project: Infinispan > Issue Type: Feature Request > Components: Cloud Integrations > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7973) Investigate Service Brokers

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-7973?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec edited comment on ISPN-7973 at 7/12/17 4:01 AM: -------------------------------------------------------------------- Based on [discussion between Marko Luksa and Emmanuel Bernard|https://bluejeans.com/s/uij6Y]: * Marko implemented En Masse. * The Broker controls instances it created. E.g. we might imagine having a JDG Broker which will add a cache to all living instances. * The {{ServicePlan}} is a resource incorporated into {{ServiceClass}}. It is not separate. * The Broker can instantiate the service synchronously or asynchronously. * The client can specify the name of a {{Secret}} with credentials. Currently users need to preconfigure their apps (to use the secret provided by the Catalog). There are plans to make it the other way around. * An {{Endpoints}} object contains a list of IP addresses and ports to desired Pods (or other type of services) * The Boker Pod can provide its own UI (it's just a running Pod). * Ideas: * We may use the Broker to instrument the deployed JDG instances * We may use the Broker to instantiate JDG instances outside of the cloud. During the Bind step we could provide credentials to connect to it. In addition to that we'd need to manually facilitate {{Endpoints}} objects pointing to the cluster. * During the bind operation we should provide {{hotrod-client.properties}}. * Potentially missing features: * No UI for creating/deleting/editing ServicePlans. It is also worth to mention that OpenShift Origin (with {{oc cluster up}}) comes with one default plan (use {{oc edit ServiceClass infinispan-ephemeral}} to view it). was (Author: sebastian.laskawiec): Based on [discussion between Marko Luksa and Emmanuel Bernard|https://bluejeans.com/s/uij6Y]: * Marko implemented En Masse Potentially missing features: * No UI for creating/deleting/editing ServicePlans. It is also worth to mention that OpenShift Origin (with {{oc cluster up}}) comes with one default plan (use {{oc edit ServiceClass infinispan-ephemeral}} to view it). > Investigate Service Brokers > --------------------------- > > Key: ISPN-7973 > URL: https://issues.jboss.org/browse/ISPN-7973 > Project: Infinispan > Issue Type: Feature Request > Components: Cloud Integrations > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2017