On Tue, Jan 10, 2017 at 5:09 AM, Galder Zamarreño <gal...@redhat.com> wrote:
> Hey Paul,
>
> Thanks for the quick answer.
>
> The motivation for ISPN-7326 is to reduce domain configuration needed to test
> xsite replication in the Javascript client. Without ISPN-7326 I'm having to
> duplicate profiles for each site where the changing values are minimal. It
> would be helpful to control the values I mentioned via system property to
> reduce the number of profiles required in the domain config.
>
> The reason I'm interested in reducing the number of changes I make the
> default domain config (e.g. by reducing number of profiles) is to make it
> easier in the future to migrate to newer domain configurations.
>
> To be more precise, domain.xml in [1] contains 3 clustered profiles:
> 'clustered', 'earth' and 'moon'. This makes the configuration for testing
> clustered and xsite capabilities quite verbose. Ideally, I'd like to have 1
> clustered profile, 'clustered', and using system properties select which
> transport to use and provide optional site names...etc where needed.
>
> So indeed, the motivation for this is not a real environment.
I see. So long as we go with approach #2, I think this is worthwhile.
> Your sugggestion for 2. doesn't sound too bad. Note that a similar approach
> would be required for remote-site's name.
Ah, you mean for the JGroups remote-site config in the RELAY2
protocol. Yeah, that shouldn't be too bad either.
e.g.
<relay site="local">
<remote-site name="local" site-name="${...}" channel=".."/>
<remote-site name="remote" site-name="${...}" channel=".."/>
</relay>
Here the site attribute of the relay resource must reference the
remote-site resource by it's name (because it is a model reference).
The relay resource's service handler currently stores the remote-sites
in a list. We'll want to change this to map them by name. Obtaining
the actual site-name (i.e. the value returned by
RelayConfiguration.getSiteName()) becomes a simple map lookup, now
that the site name is decoupled from the resource name. We can still
make site-name optional, and default it to the resource name if
undefined.
I've opened https://issues.jboss.org/browse/WFLY-7871
Paul
> Thoughts?
>
> [1]
> https://github.com/galderz/js-client/blob/16c985e0957c10f332c0dc9b561997c3f88c1c24/spec/configs/domain.xml
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
>> On 9 Jan 2017, at 17:47, Paul Ferraro <paul.ferr...@redhat.com> wrote:
>>
>> Hi Galder,
>>
>> The short answer: Attributes that are components of a resource path
>> address may not contain expressions.
>>
>> What is the motivation behind ISPN-7326?
>>
>> When the x-site domain model for Infinispan was originally designed,
>> the assumption was that a domain controller would never attempt to
>> manage a host residing in a remote data center. Typically a domain
>> controller doesn't manage hosts outside of its own network. Even an
>> architecture that uses multiple logical sites within the same physical
>> data center would still isolate each site to a separate network.
>>
>> Question aside, there are at least 2 ways we can do this:
>>
>> 1. Refactor the model. Remove the backup resource entirely. This
>> means that individual site configurations will no longer be
>> addressable. Instead, the parent resource would maintain a list of
>> backup objects, where "site" becomes a normal attribute that allows
>> expressions.
>>
>> Dealing with complex object types in the model isn't exactly a
>> pleasurable experience, so I would first make sure that the
>> requirement is legitimate/realistic and thus warrants the change. Of
>> course, the biggest headache will be the model transformations
>> required to support mixed domains (mixed domains are a reality of
>> upgrading), as well as translation of domain operations that reference
>> the legacy resources.
>>
>> 2. Decouple the logical backup name from the actual site name:
>>
>> <backups>
>> <backup name="remote" site="${...}" strategy="SYNC"/>
>> </backups>
>>
>> Here, each host has an addressable "remote" backup resource, where the
>> site name is an expression and resolves to a host-specific value.
>> Additionally, we can make this site attribute optional, and have it
>> default to the backup name if undefined.
>>
>> In conclusion, if this is confirmed to be a genuine feature request, I
>> would strongly encourage you to go with option #2.
>>
>> Paul
>>
>> On Mon, Jan 9, 2017 at 8:49 AM, Galder Zamarreño <gal...@redhat.com> wrote:
>>> Hey Paul,
>>>
>>> Re: https://issues.jboss.org/browse/ISPN-7326
>>>
>>> I have some doubts how to achieve what I'm trying to do in ^
>>>
>>> More specifically, backup's 'site' attribute and remote-site's name
>>> attributes are special in the sense that they're not represented as
>>> SimpleAttributeDefinition instances. Instead, it seems like they're
>>> expected to be fully resolved when the XML read since they are part of path
>>> addresses.
>>>
>>> Resolution when XML is read does not work since reading is done by the host
>>> controller and I'd want the resolution to happen when the particular server
>>> node starts up.
>>>
>>> So, what would be the best way to achieve what I'm after?
>>>
>>> One way I was thinking is maybe leaving the XML reading part as is, and
>>> only when the cache is added, do the resolution manually there. However,
>>> this does not seem to work as is, because the XML attribute is already
>>> resolved when I add the cache and it's resolved to the default value (cos
>>> process controller was not started with -D...), so I can't seem to get the
>>> original XML value. Moreover, even if this was resolved, would it be fine
>>> for the path address to have the default value for the property in it, and
>>> the actual cache configured with the name passed via system property?
>>> Doesn't sound right...
>>>
>>> Any other way? Maybe add separate SimpleAttributeDefinition instances for
>>> these XML attributes on top of their path address values?
>>>
>>> Cheers,
>>> --
>>> Galder Zamarreño
>>> Infinispan, Red Hat
>>>
>
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
