[jboss-as7-dev] problems with deployment overlays and linking

[Brian Stansberry]

I don't quite understand this one. How is this different from 
deployments? Is this just an issue of not having all the API options 
available for adding overlays that we have for deployments? If so we can 
solve that easily enough.

On 8/15/12 9:57 AM, Alexey Loubyansky wrote:
> Another issue related to this command and management of the overlay and
> links is that this command can't be a part of a batch because actions
> like create a new overlay with content and adding content to an existing
> overlay can't translate into a single composite operation, which a batch
> translates to.
>
> The problem is referencing results of one step in a composite operation
> from arguments of another step in the same composite operation.
>
> Alexey
>
> On 08/15/2012 04:11 PM, Alexey Loubyansky wrote:
>> I've been prototyping a CLI command that manages deployment overlays and
>> got worried :)
>>
>> I think, the current representation (actually, the data structure, in
>> other words) of the overlays and their linking in the management model
>> will lead to a lot of issues related to consistency of the data and
>> complicate management of deployments in general.
>>
>> Basically, it's a many-to-many relationship between overlays and
>> deployments. Currently, overlays and deployments are defined separately
>> and linked using the "third table", each row of which consists of a link
>> name, overlay name and deployment name (or deployment name regex). (BTW,
>> I understand this design is not random, there were reasons to organize
>> it this way but I'd like to raise my concerns).
>>
>> Which is a common practice in a relational database design but our
>> management model is not as sophisticated, yet :) We don't have:
>> - foreign key constraints (again, yet, I know Brian is going to look
>> into that);
>> - no cascade-delete;
>> - no queries (e.g. by node attributes).
>>
>>
>> CREATING A LINK AND LOOKING FOR IT
>>
>> To create a link between an overlay and a deployment, I have to come up
>> with a name for it, which has to be unique, like a primary key. Well, I
>> chose the format overlay_name-deployment_name. Then, in CLI, I rely on
>> this format to search for the link(s), since searching by resource
>> attributes turns out to be much more complicated, although possible.
>> Actually, even searching using this naming format by deployment name or
>> an overlay name is not that smooth. So, the CLI now expects a specific
>> naming format. Taking into account that the CLI is not the only
>> management tool and that any application or user can manage things
>> "manually", it'd be good for all the users and tools to agree on the
>> naming format, which is not practical.
>>
>> REMOVING A DEPLOYMENT
>>
>> Until now it was about removing only the deployment. Now, not to run
>> into inconsistencies in the model, the "third table" has to be searched
>> for references and cleaned up if found.
>>
>> Removing an overlay leads to the same consequences, of course, which is
>> unavoidable anyway. But I think we could re-organize the model to
>> minimize the risks or running into inconsistencies and simplify management.
>>
>> ALTERNATIVE STRUCTURES
>>
>> I discussed these issues with Emanuel, who agreed and had in mind
>> another idea to represent this in the model, which I actually find more
>> logical and elaborate. I'll let him follow up and describe it in details.
>>
>> Thanks,
>> Alexey
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat