[jboss-jira] [JBoss JIRA] (WFLY-1918) Introduce "version" to all operations

[Brian Stansberry (JIRA)]

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

Brian Stansberry commented on WFLY-1918:
----------------------------------------

Notes from a discussion with Jason:

1) Key question is what is the behavior when the request provides no version:

a) Server assumes the latest version
PRO: No headers required for the common case
CON: Existing clients break as the server advances and they don't.
CON: We have to introduce sending of these versions in a release *before* the first release where the server really needs them
b) Server assumes version prior to the one when version headers were introduced
PRO/CON: reverse of a)

I lean toward b) (as does Jason, I believe) but we need to mitigate the user effort involved in sending these headers.

2) We can control some clients (i.e. CLI / HAL) to help mitigate the user effort. For example a CLI could be compiled with a set of default headers that match what was latest when it was compiled.

a) For CLI, this doesn't help with subsystems that were unknown at CLI compile time.
a) i) an extensible CLI could know about more subsystems, but 1) we don't have that and 2) extensions are only needed if some subsystem wants to add new high level commands
b) There should be some configurability around this; e.g. turn it off so an old CLI binary can be made to not send old version data when the user isn't using it for old servers.

3) However, many clients (e.g. scripts using curl or similar to call the http interface) have no WF-provided code to help here; the headers are entirely a user responsibility.

4) These headers are quite analogous to rollout plans -- complex side information that effect operation execution. So handling them similarly makes sense.

a) store sets of version settings server side in the content repo
b) use a header to reference a named set instead of having to specify the details in each request

5) An ability to have such settings associated with a username instead of/in addition to a shared store may make sense

Possible server-side algorithm:

a) check for specific versions sent with the request
b) for anything missing, check for a header that names a mapping set in the content repo (like rollout plans)
c) for anything missing, check if there is a mapping set in the content repo associated with current user's username
d) if not present, use defaults

Another thing that could be involved is the core management API version. That is, if that is somehow determined, then that can help determine subsystem mappings.
                
> Introduce "version" to all operations
> -------------------------------------
>
>                 Key: WFLY-1918
>                 URL: https://issues.jboss.org/browse/WFLY-1918
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>             Fix For: 9.0.0.CR1
>
>
> To better support backward compatibility for upcoming version of AS/mgmt api
> For start we should probably just send mgmt version of subsystem/core 
> in future we could use this info to route operations properly 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira