[jboss-jira] [JBoss JIRA] (WFCORE-919) Allow read-only data/content storage

[Brian Stansberry (JIRA)]

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

Brian Stansberry edited comment on WFCORE-919 at 8/26/15 11:43 AM:
-------------------------------------------------------------------

The content repository is an internal detail, not an end user API. So this is a proposal to change that. Particularly the "deployments are managed via another system (docker, puppet etc)" bit, would be  such a big change as to really require a separate issue altogether.

Without going to that point, but just sharing the repo, some kind of config setting that lets the user independently specify the location of the content repo would be needed. That itself somewhat exposes the internal detail (i.e. that the content repo is implemented via a FS location.) Any config for this would need to be done in such a way that it can become an alternative to some other approach (e.g. someday we pull content via the internet from Mars.)

If the step of making the repo sharable is worked out, then the "read-only" flag for a given host becomes a small thing.

I don't see a *direct* relationship to WFCORE-310, although it does touch on the same general use cases. The tangential relationship is a host that can be master cannot be configured with a r-o repo, as the master is the one who writes. Being configured with a r-o repo would be an issue with promoting a slave to master (as the config would have to be corrected) but the mechanics of promoting a slave are not the direct concern of 310. 310 deals with the fact that a slave that is ignoring parts of the domain-wide config/content is ineligible for promotion.

 




was (Author: brian.stansberry):
The content repository is an internal detail, not an end user API. So this is a proposal to change that. Particularly the "deployments are managed via another system (docker, puppet etc)" bit, would be  such a big change as to really require a separate issue altogether

Without going to that point, but just sharing the repo, some kind of config setting that lets the user independently specify the location of the content repo would be needed. That itself somewhat exposes the internal detail (i.e. that the content repo is implemented via a FS location.) Any config for this would need to be done in such a way that it can become an alternative to some other approach (e.g. someday we pull content via the internet from Mars.)

If the step of making the repo sharable is worked out, then the "read-only" flag for a given host becomes a small thing.

I don't see a *direct* relationship to WFCORE-310, although it does touch on the same general use cases. The tangential relationship is a host that can is master cannot be configured with a r-o repo, as the master is the one who writes. Being configured with a r-o repo would be an issue with promoting a slave to master (as the config would have to be corrected) but the mechanics of promoting a slave are not the direct concern of 310. 310 deals with the fact that a slave that is ignoring parts of the domain-wide config/content is ineligible for promotion.

 



> Allow read-only data/content storage
> ------------------------------------
>
>                 Key: WFCORE-919
>                 URL: https://issues.jboss.org/browse/WFCORE-919
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta4
>            Reporter: James Livingston
>            Assignee: Brian Stansberry
>
> It would be nice to allow the content repository to be read-only, if there was an external guarantee that all content should be there. This would be useful in situations where all HCs (including the DC) share that over NFS, or deployments are managed via another system (docker, puppet etc).
> It could be a ContentRepository implementation which does not make chances, and fails if attempted or content is missing. On read-only HCs the current writeability check would need to be disabled, along with the cleaner task, and the DC (if it could write) would need to ensure content was not removed prior to HCs performing undeployment.
> This would presumably have some interaction with WFCORE-310.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)