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

[Emanuel Muckenhuber]

We were mainly discussing the possibility of removing the 
deployment-overlay-links and "link" overlays directly from the 
deployment section of the model:

<deployment name="myapp.war"
    ...
  <overrides>
    <override path="WEB-INF/lib" link="override2" />
    <content path="WEB-INF/web.xml" content="83e4e22f3422267b" />
    <file path="downloads" relative-to="download.file.path" />
  </overrides>
</deployment>

So you would be able to configure overlays as part of the deployment as 
well as link to shared deployment-overlays. This obviously does not give 
you all the possibilities the deployment-overlay-links would, however it 
avoids a many-to-many relationship. From a tooling standpoint it should 
make it easier.

I know we talked about something similar the last time we discussed 
overlays, but perhaps it's worth re-evaluating this with an actual mgmt 
client trying to impelement overlays.

On 08/15/2012 05:51 PM, Brian Stansberry wrote:
> I want to hear Emanuel's ideas.
>
> But for sure we need to get rid of the requirement to give names to
> links. Not just the need for some of rule for how the names are
> constructed; we should get rid of the need for names altogether.
>
> On 8/15/12 9:11 AM, 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
>>
>
>