[wildfly-dev] [jboss-as7-dev] WFLY-1396 - File upload/manipulation through management API - modules, config files

[Brian Stansberry]

On 9/3/13 4:34 PM, Ondrej Zizka wrote:
>
> On 3.9.2013 18:36, Brian Stansberry wrote:
>> This would be something for after WF 8. The odds of it happening after
>> that will be much higher a contributor does it. It will need to be
>> thoroughly discussed though.
>>
>> For provisioning modules, I'm reluctant to add a lot of details to the
>> management API. That is, stuff like dependencies=["org.jboss.bar"],
>> imports=[...] exports=[...]. Besides being more work, it limits what can
>> be done to whatever jboss-modules config elements WF exposes. All that
>> stuff can be declared in a provided modules.xml.
> Right, if that structure is likely to change, then keeping it in XML is
> better.
>
>> The main thing that needs to be worked out are the managed domain
>> semantics.
>>
>> 1) For a "config file" where does it end up on the host? How is it made
>> visible to the servers? Does it need to be visible to all servers, or
>> should that vary depending on server group? Note that filesystem
>> permissions may result in the server processes not having visibility to
>> the host controller process' configuration dir.
> Perhaps the user could define an extra value for "relative-to" through
> mgmt API to point to an arbitrary dir in the FS, and use that.
> Or perhaps the server process could ask for the file in a form of a
> read-only hex-encoded property and store it.
>> 2) When a new host is started, how is this content made available? For
>> deployments their existence is tracked in domain.xml, so a new host
>> knows to pull down that content. Do we do that for these items? Or is
>> this just out of scope and it's up to the user to use admin-only mode
>> and use the /host=newhost:add... variant of these ops before bringing
>> the new host into the domain?
> Again, reusing the channel between host controller and the new server,
> for transfering additional config files?

Yes, that's how it would have to happen if supported.

Both this and solving the question of how the file gets provided to 
servers means information about these files becomes part of the domain 
configuration, just like deployments are.

> That would IMO be most transparent to the user. Not sure how to deal
> with exceptional situations.
>
>> On 9/3/13 7:40 AM, Tomaž Cerar wrote:
>>> This should be discussed on wildfly-dev mailing list....
>>> ----
>>> In any case, this is useful feature that many people / projects could
>>> use.
>>> I know that gatein team would love to have this to address their
>>> deployment scenario in domain mode.
>>>
>>> But given time constraints / features list for WF8 I cannot see this
>>> happening before WF9/10
>>> Unless someone sends PR with this implemented :-)
>>>
>>> --
>>> tomaz
>>>
>>>
>>> On Tue, Sep 3, 2013 at 1:58 PM, Ondrej Zizka <ozizka at redhat.com
>>> <mailto:ozizka at redhat.com>> wrote:
>>>
>>>      Hi everyone,
>>>
>>>      I'd like to bring some attention to an issue which would greatly
>>> improve
>>>      remote manageability of WildFly / EAP:
>>>      https://issues.jboss.org/browse/WFLY-1396
>>>
>>>      The thing is, for some management tasks, you need to have SSH
>>> access (or
>>>      similar) in addition to management API - to upload e.g. modules
>>> or SSH
>>>      related files.
>>>      To make the server completely manageable through the API, one of
>>> the
>>>      things needed is ability to upload files.
>>>      Is there some progress on this? Is it planned?
>>>
>>>      In the issue, there are some ideas how it could look. If you have a
>>>      minute, please comment on the issue or here.
>>>
>>>      Thanks,
>>>      Ondra
>>>
>>>      _______________________________________________
>>>      jboss-as7-dev mailing list
>>>      jboss-as7-dev at lists.jboss.org
>>> <mailto:jboss-as7-dev at lists.jboss.org>
>>>      https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat