[JBoss JIRA] (ISPN-9620) Rolling Upgrade Marshaller Changes
by Ryan Emerson (Jira)
[ https://issues.jboss.org/browse/ISPN-9620?page=com.atlassian.jira.plugin.... ]
Ryan Emerson updated ISPN-9620:
-------------------------------
Sprint: Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 10.0.0.Beta1, DataGrid Sprint #29, DataGrid Sprint #30 (was: Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 10.0.0.Beta1, DataGrid Sprint #29)
> Rolling Upgrade Marshaller Changes
> ----------------------------------
>
> Key: ISPN-9620
> URL: https://issues.jboss.org/browse/ISPN-9620
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core, Loaders and Stores
> Affects Versions: 9.4.0.Final
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 10.0.0.Beta4
>
>
> In order to allow for compatibility between infinispan versions it is necessary for us to utilise a marshalling implementation at both the cluster (internal node-to-node communication) and persistence layer that is strictly defined but allows for future changes. This is necessary in order to facilitate both rolling and start/stop upgrades. Protocol buffers should be utilised as the wire/storage format, with protostream providing the implementation.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (ISPN-8535) Rest API redesign
by Pedro Zapata Fernandez (Jira)
[ https://issues.jboss.org/browse/ISPN-8535?page=com.atlassian.jira.plugin.... ]
Pedro Zapata Fernandez updated ISPN-8535:
-----------------------------------------
Sprint: Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 10.0.0.Beta1, DataGrid Sprint #30 (was: Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 10.0.0.Beta1, DataGrid Sprint #31)
> Rest API redesign
> -----------------
>
> Key: ISPN-8535
> URL: https://issues.jboss.org/browse/ISPN-8535
> Project: Infinispan
> Issue Type: Feature Request
> Components: Server
> Affects Versions: 9.2.0.Final
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Priority: Major
> Fix For: 10.0.0.Final
>
>
> Infinispan REST API deals with only one resource, (the cache) and maps all operations on the cache using HTTP verbs and request parameters. The API assumes the URI is related to the cache making it hard to add new kinds of resources without causing ambiguous references.
> Since we now have other types of entities, such as counters, scripts, templates, etc, and each one of them can involve different operations, we should make the API more "Restful" by using more than one resource and collections of resources, plus HTTP verbs and operations on them. Examples:
> * Create a cache: POST /rest/caches
> * Delete a cache: DELETE /rest/caches/myCache
> * Create a template: POST /rest/templates
> * Delete a template: DELETE /rest/templates/myTemplate
> * Create an entry: POST /rest/caches/myCache/1
> * Create a counter: POST /rest/counters
> * Get a counter value: GET /rest/counters/mycounter
> * Increment a counter: GET /rest/counters/mycounter?action=increment
> * Search a cache: GET /rest/caches/myCache?action=search
> * Create a script: POST /rest/scripts/
> * Get a script source: GET /rest/scritps/myScript
> * Execute a script: GET /rest/scripts/myScript?action=execute¶m1=foo
> * Stop individual servers and the full cluster
>
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (ISPN-10352) Externalize all code and config samples in docs
by Donald Naro (Jira)
Donald Naro created ISPN-10352:
----------------------------------
Summary: Externalize all code and config samples in docs
Key: ISPN-10352
URL: https://issues.jboss.org/browse/ISPN-10352
Project: Infinispan
Issue Type: Enhancement
Components: Documentation-Core
Affects Versions: 10.0.0.Beta4
Reporter: Donald Naro
Assignee: Donald Naro
All code samples in docs should be run and tested at build time. Externalize all code samples to a separate directory and include them. Do the same for all config samples in any format, yaml, xml, and so on.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (ISPN-10350) Reduce operator product image size
by Galder Zamarreño (Jira)
Galder Zamarreño created ISPN-10350:
---------------------------------------
Summary: Reduce operator product image size
Key: ISPN-10350
URL: https://issues.jboss.org/browse/ISPN-10350
Project: Infinispan
Issue Type: Task
Components: Operator
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
So far with the work of JDG-2976, the operator product image is around ~350mb.
The reason this is so big is cos the image where the operator lives when the operator is built is the same image that builds the operator itself. There's a couple of reasons that would explain the big size: base image and leftover from build.
The base image right now is the standard UBI image. I tried to use UBI-minimal, but the tooling available there is not as advanced (e.g. yum vs microdnf), and as a result of that, after building the operator you're not able to do cleanup in the same way (microdnf does not have autoremove option). Without digging into the details, the resulting image with UBI minimal was ~700mb.
So, the aim of this JIRA is to reduce the image to only have the bare minimal plus the operator binary. This is not urgent but needs some deeper understanding.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months