[teiid-issues] [JBoss JIRA] (TEIID-5007) Changes to reduce Teiid in the cloud footprint

[Steven Hawkins (JIRA)]

    [ https://issues.jboss.org/browse/TEIID-5007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491225#comment-13491225 ] 

Steven Hawkins commented on TEIID-5007:
---------------------------------------

I'm not finding good guidelines around ephemeral disk usage.  You can put limits based upon image and node usage, but there doesn't seem to be an a priori way of automatically determining a limit for a single container - https://docs.openshift.com/container-platform/3.6/admin_guide/out_of_resource_handling.html

As is things like the logs, temp files (buffer manager, deployment related), etc. just go to their default location.  For the server log the console is probably sufficient.  Concerns such locations for heap and other dumps should they be needed should be looked at (Burr has material on this and I'm not sure what we're planning on baking into the base java image).

Options:
- fully read-only image and manage all disk usage through volumes (seems unnecessary as we don't need persistence)
- add more parameters, in particular buffermanager disk consumption to the templates (or even useDisk=false)
- something else?




> Changes to reduce Teiid in the cloud footprint
> ----------------------------------------------
>
>                 Key: TEIID-5007
>                 URL: https://issues.jboss.org/browse/TEIID-5007
>             Project: Teiid
>          Issue Type: Quality Risk
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>             Fix For: 10.1
>
>
> A Teiid instance even as swarm or springboot needs additional considerations to minimize the runtime footprint.   This includes:
> * container aware auto-sizing.  Detection of the number of cpus and available memory need refined - there are experimental settings being considered for containerized vms to better report these values and there is logic in WildFly and other projects that attempts better auto-detection.  We also need to utilize the memory buffer space more and probably as off-heap space (and ideally direct operations on the serialized data)
> * Subsystems required include JTA, webserver, security, which could be satisfied by slimmer alternative versions - especially if we make new assumptions, such as not utilizing xa transactions.
> * Engine dependencies could be application specific - removing xml/xsl support, geometry support, etc.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)