[wildfly-dev] Management Model: Squatter Resources
Brian Stansberry
brian.stansberry at redhat.com
Fri Oct 31 12:48:47 EDT 2014
On 10/30/14, 6:55 AM, Heiko Braun wrote:
>
>
> Thanks for the update Jeff. Yes, it's true that singleton resources impose problem when attempting to further automate (read data binding) the UI components we have in the console. But currently I don't believe we can do without them, as they provide a valid and reasonable way to model certain resources. So, with regard to your proposal, I think the way you approach the new hornetq resources is fine.
>
> The specific problems we are facing with the UI need to be tackled in general way and breaks down into these questions:
>
> - how do we (programmatically) identify singleton resources?
> - how do we access their resource meta data (:read-resource-desciption)?
>
> The fundamental problem (as described in my previous email) is that you cannot tell which resources are singletons when walking the tree using any of the child related operations (read-child-types(), read-children-names()). Currently the only way to go about that is to read child resource recursively and compare their structures. For regular, non-singleton resources the address token key (/<key>=<value>/...) denotes the type.
>
> We would need an equivalent way to identify the types for singleton resources as well. This for instance would work for us:
>
> /subsystem=messaging/hornetq-sever=*:read-children-types()
> {
> "outcome" => "success",
> "result" => [
> ...,
> "ha-policy=live-only",
> "ha-policy=replicated-master",
> "ha-policy=replicated-slave",
> ...
> ]
> }
>
I haven't taken action on this specific request before because this
general area is a really broad topic and I wanted to let thinking play
out. But we've been thinking about it quite a while now and there's a
consensus that these singleton resource types exist and there's no
reason not to improve the API in this way.
I opened https://issues.jboss.org/browse/WFCORE-208 and we'll be sure
it's resolved for the WF 9 Beta1.
Please have a look at the description of that JIRA, where I'm quite
precise about the semantics.
>
> On 30 Oct 2014, at 11:40, Jeff Mesnil <jmesnil at redhat.com> wrote:
>
>> I’m integrating HornetQ 2.5 in WildFly and I have a new use case for resources that is related to singleton/squatter resources.
>>
>> In HornetQ 2.5 they have completely rewritten the HA configuration. Basically, a server can be configured as live-only, replicated (master, slave, or colocated) or using shared-store (again as a master, slave or colocated).
>>
>> To represent this in the management model, I have added several resources under hornetq-server:
>>
>> /subsystem=messaging/
>> hornetq-server=*/
>> ha-policy=live-only
>> ha-policy=replicated-master
>> ha-policy=replicated-slave
>> ha-policy=replicated-colocated
>> ha-policy=shared-store-master
>> ha-policy=shared-store-slave
>> ha-policy=shared-store-colocated
>>
>> I have constraints for this ha-policy resource:
>> * There can at most one child for this type of resource (no child means no HA). This is enforces during the MODEL stage.
>> * The child can only be named using one of the 7 values above (i.e. there is no resource definition for ha-policy=*, using any other name would fail)
>>
>> Each ha-policy definition has a different set of attributes. Using an attribute group to represent the HA policy does not seem a good fit as some of them have subresources too.
>>
>> I wonder if that representation fits with our roadmap and whether it can be considered as a singleton (as there can only be one resource of that type among). I have the additional constraints of having only one chile for that type that is not covered by your proposal though.
>>
>> I especially wonder how the console (and to a lesser extent the cli) can deal with this resource.
>>
>> Heiko, is it something that would make sense for the console based on this resource description:
>>
>> [standalone at localhost:9990 hornetq-server=default] ./ha-policy=*:read-resource-description(recursive-depth=1)
>> {
>> "outcome" => "success",
>> "result" => [
>> {
>> "address" => [
>> ("subsystem" => "messaging"),
>> ("hornetq-server" => "default"),
>> ("ha-policy" => "replication-colocated")
>> ],
>> "outcome" => "success",
>> "result" => {
>> ...
>> }
>> },
>> {
>> "address" => [
>> ("subsystem" => "messaging"),
>> ("hornetq-server" => "default"),
>> ("ha-policy" => "replication-master")
>> ],
>> "outcome" => "success",
>> "result" => {
>> ...
>> }
>> },
>> {
>> "address" => [
>> ("subsystem" => "messaging"),
>> ("hornetq-server" => "default"),
>> ("ha-policy" => "shared-store-slave")
>> ],
>> "outcome" => "success",
>> "result" => {
>> ...
>> }
>> },
>> {
>> "address" => [
>> ("subsystem" => "messaging"),
>> ("hornetq-server" => "default"),
>> ("ha-policy" => "live-only")
>> ],
>> "outcome" => "success",
>> "result" => {
>> ...
>> }
>> },
>> {
>> "address" => [
>> ("subsystem" => "messaging"),
>> ("hornetq-server" => "default"),
>> ("ha-policy" => "shared-store-master")
>> ],
>> "outcome" => "success",
>> "result" => {
>> ...
>> }
>> },
>> {
>> "address" => [
>> ("subsystem" => "messaging"),
>> ("hornetq-server" => "default"),
>> ("ha-policy" => "replication-slave")
>> ],
>> "outcome" => "success",
>> "result" => {
>> ...
>> }
>> },
>> {
>> "address" => [
>> ("subsystem" => "messaging"),
>> ("hornetq-server" => "default"),
>> ("ha-policy" => "shared-store-colocated")
>> ],
>> "outcome" => "success",
>> "result" => {
>> ...
>> }
>> }
>> ]
>> }
>>
>> jeff
>>
>> --
>> Jeff Mesnil
>> JBoss, a division of Red Hat
>> http://jmesnil.net/
>>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
More information about the wildfly-dev
mailing list