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

[Stuart Douglas]

On 16/08/2012, at 7:29 PM, Emanuel Muckenhuber <emuckenh at redhat.com> wrote:

> 
> 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.

The big problem with this is that it does not work with the deployment scanner. 

It also has to be specified on every re-deploy. I think the simplest solution here 
is to just move the links under the deployment-overlays element and loose the 
flexibility to link at different levels. e.g:

/deployment-overlay=myOverlay/deployment=test.war
/deployment-overlay=myOverlay/deployment=*.jar

Stuart


> 
> 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
>>> 
>> 
>> 
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev