On Sep 16, 2016, at 3:50 AM, Jean-Francois Denise
<jdenise(a)redhat.com> wrote:
My reply inlined.
On 15/09/16 21:15, Brian Stansberry wrote:
>> On Sep 15, 2016, at 2:05 PM, Harald Pehl <hpehl(a)redhat.com> wrote:
>>
>>
>>
>> On Thu, Sep 15, 2016 at 2:21 PM, Brian Stansberry
<brian.stansberry(a)redhat.com> wrote:
>> I’m adding wildfly-dev in cc.
>>
>> Yes, the names of the parameters are ambiguous. And it’s not necessary for them
to be ambiguous, as the “alternatives”, “required” and “requires" stuff lets us use
clearly named params for different cases:
>>
>> “attribute” — required=true, alternatives=[parameter]
>> “parameter - required=true, alternatives=[attribute], requires=[operation]
>> “operation” - required=false
>>
>> An alternative is we could just drop all of those. The operation and attribute
params are not necessary if the client has already done a read-resource-description or
read-operation-description and already knows the value of the “capability-reference”
descriptor. Then it could simply be
>>
>>
/core-service=capability-registry:suggest-capabilities(address=[(subsystem=foo),(child=bar)],static-name=org.wildfly.network.socket-binding)
>> {
>> “outcome” => “success”,
>> “result” => [
>> “http”,
>> “https”
>> ]
>> }
>>
>> From the console's perspective that version would work best for us.
>>
> Ok thanks.
>
> And both variants are possible if Jeff wants the other one for the CLI. The
'static-name' param could just be an alternative to ‘attribute’ and
‘parameter’+’operation'.
I am not sure about the right syntax, We are possibly in the same case as HAL. If we
offer a proper completion for the :write-attribute name (there is a start for this), we
will have already accessed to the value-type and metadata for the deepest property. So we
should have the capability-reference and call the operation with the couple Resource
Address,Reference.
How about other operations?
The nice thing is if we just need static-name we can do that, and then if later we find we
need more it can be added in a compatible way.
>
>> However I see one issue using this approach: If there are multiple suggestions
having the same name while referring to different resources. This typically happens with
attributes which have a capability reference to
"org.wildfly.network.socket-binding" (for instance attribute
"socket-binding" in "/subsystem=remoting/connector=*").
>>
>> Using
/core-service=capability-registry:get-provider-points(name=org.wildfly.network.socket-binding)
returns "/socket-binding-group=*/socket-binding=*" which resolves to several
"http" socket-bindings in different socket-binding-groups.
>>
>> Just using the names as suggestions would end up in several "http"
suggestions. What we do in that case in the console is to show some context:
>>
>> standard-sockets / http
>> ha-sockets / http
>> full-sockets / http
>> …
> To account for this instead of returning a simple list we can return an object node
equivalent to a Map<String, Set<PathAddress>>.
What is the advantage to expose all possible http capabilities? At the end the attribute
value will only contain 'http' right? So do we really need to expose all the
possibilities although whatever the user choice, 'http' will be stored in the
value? For a given resource attribute value (eg: 'http') the server should be able
to compute scopes and identify the right path (one of the 3 possible paths to 'http’).
>
>>
>> When thinking about this we should remember the dot/bracket syntax we allow for
updating details of complex attributes via write-attribute:
>>
>> :write-attribute(name=complex.nested[2].field,value=http)
>>
>> For the CLI, just passing through “attribute”=>"complex.nested[2].field”
is easier as there is no need for it to unpack the ‘.’ and ‘[]' syntax and find the
description of ‘field’ and get the capabiity-reference.
>>
>> For the console, it may be easier to get the capability-reference and pass it
instead. Easier than going from some code backing a gui widget and synthesizing
"complex.nested[2].field” to pass to the server.
>>
>>
>>> On Sep 15, 2016, at 6:40 AM, Jean-Francois Denise <jdenise(a)redhat.com>
wrote:
>>>
>>> The operation argument is an optional argument that contains the resource
operation name. In case the operation is present, the attribute argument means operation
argument. Otherwise the attribute contains the name of an attribute. This is a draft of
operation, the operation naming could be reviewed.
>>> I don't think that this operation updates the capabilities registry, this
is a readonly operation to retrieve capabilities.
>>> JF
>>>
>>> On 15/09/16 12:41, Harald Pehl wrote:
>>>> That looks very promising. Having such an operation would also cover the
requirements of HAL. What's behind the "operation" parameter? Does it allow
add / modify?
>>>>
>>>> On Thu, Sep 15, 2016 at 12:04 PM, Jean-Francois Denise
<jdenise(a)redhat.com> wrote:
>>>> Hi,
>>>>
>>>> I have spent some time looking at the semantic of the capability scopes
(thanks to Brian help).
>>>> A client "could" try to base its capability resolution by
looking at capabilities present in the capabilities registry. Scope can be very complex,
are possibly not fully modeled yet, and semantic could evolve in the future. So difficult
for a client to rely on scopes to resolve the accessible capabilities.
>>>>
>>>> The server side has the logic to check the capabilities and could expose
part of its engine logic to clients for capabilities resolution. Brian is proposing that
the capabilities registry would expose a new operation:
>>>>
/core-service=capability-registry:suggest-capabilities(address=[(subsystem=foo),(child=bar)],operation=add,
>>>> attribute=socket-binding)
>>>> {
>>>> “outcome” => “success”,
>>>> “result” => [
>>>> “http”,
>>>> “https”
>>>> ]
>>>> }
>>>>
>>>> It seems that the CLI "completion requirements" would be
covered by this addition. I am wandering if it would also cover the HAL ones?
>>>>
>>>> Thanks.
>>>>
>>>> JF
>>>>
>>>>
>>>> On 13/09/16 21:50, Harald Pehl wrote:
>>>>> See my answers inline.
>>>>> On Tue, Sep 13, 2016 at 12:04 PM, Jean-Francois Denise
<jdenise(a)redhat.com> wrote:
>>>>> Hi Claudio and Harald, thank you for your reply. Some questions
in-lined. I am just discovering the capabilities topic ;-) On 12/09/16 19:47, Claudio
Miranda wrote:
>>>>> Your suggested approach looks similar to the way HAL does, however
there are some differences. 1) There are many attributes that doesn't declare the
capability-reference, (example: subsystem=transactions, attribute jdbc-store-datasource),
then we emulate it.
>>>>> How do you emulate this? You are hard coding the list of attributes
that are reference to capabilities? You can point me to some code? Harald, what is the
technical difficulty there? Are they real capabilities? If the referenced resource
can't register capabilities, are they actual capabilities?
>>>>> We have an internal registry [1] which is basically a map with the
capability name as key and a class holding information about the capability as value [2].
Most entries in our registry are taken from /core-service=capability-registry, but to
provide the capabilities also for WildFly < 11, we need to manually add entries to our
registry during startup [3].
>>>>>
>>>>> 2) The capabilities and addresses are associated at bootstrap, this
way HAL associates all capability-reference names to the target address it should lookup
on at runtime.
https://github.com/hal/core/blob/26bb90653f60cfad2f3c3aac5964c4f125e18777...
>>>>> This is the information that the capabilities registry contains?
Right? I should be able to retrieve all that from the registry?
>>>>> Yes we read everything from /core-service=capability-registry
>>>>> 3) For domain mode, the attributes that declares capabilities
resources out of profile, as socket-bindings, there is a small inconvenient, we need to
display the full resource address, as there is no way to associate the profile to the
socket-binding, we need to show all socket-binding of all socket-binding-groups, see
http://i.imgur.com/86VP1F9.png
>>>>> The /<profile>/subsystem=transactions/process-id-socket-binding
should be tagged with "capability-reference". Right? And it doesn't seem to
be. Do you now the rational?
>>>>> Right, the r-r-d result for /<profile>/subsystem=transactions
does not contain a "capabilities-reference" for the attribute
"process-id-socket-binding". This seems to be a bug in the transactions
subsystem. But actually it's a good example how we can still provide typeahead support
for attributes which do not have a "capability-reference" info [4]. This does
not involve the capabilities registry. It's just about adding typeahead support for
attributes which reference some other resources, but do not yet have a
"capabilities-reference"
>>>>> Once the user has chosen a value, what are you setting as the value
for the process-id-socket-binding attribute? Harald, you are saying that the resource name
is taken as form input. So it means that only the last part of the resource address is
stored? For example only "ajp"? Is it enough to fully identify the actual
resource? Don't you need (full capabilities name + scope)?
>>>>> Yes that's right, only the resource name is stored. Let's
take the server-group resource as an example. It has the attribute "profile"
which declares the "capability-reference"
"org.wildfly.domain.profile". When adding the resource, only the profile name is
stored. AIUI to identify / verify the profile the attribute value and the information from
the capabilities-regisrty are used.
>>>>>
>>>>> Thank-you.
>>>>> [1]
https://github.com/hal/hal.next/blob/develop/meta/src/main/java/org/jboss...
>>>>> [2]
https://github.com/hal/hal.next/blob/develop/meta/src/main/java/org/jboss...
>>>>> [3]
https://github.com/hal/hal.next/blob/develop/app/src/main/java/org/jboss/...
>>>>> [4]
https://github.com/hal/hal.next/blob/develop/app/src/main/resources/org/j...
>>>>> --- Harald Pehl JBoss by Red Hat
http://hpehl.info
>>>> --
>>>> --- Harald Pehl JBoss by Red Hat
http://hpehl.info
>> --
>> Brian Stansberry
>> Manager, Senior Principal Software Engineer
>> JBoss by Red Hat
>>
>>
>>
>>
>>
>>
>> --
>> ---
>> Harald Pehl
>> JBoss by Red Hat
>>
http://hpehl.info
--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat