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

[Brian Stansberry]

On 8/16/12 7:52 PM, Stuart Douglas wrote:
>
> 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
>

It doesn't *have to* rule out different levels; i.e. this could be 
supported:

/server-group=x/deployment-overlay=myOverlay/deployment=test.war

That would be unintuitive though. A deployment-overlay resource in a 
server-group IMO would be unintuitive if it didn' work like 
/server-group=x/deployment=y -- i.e. it's a mapping of a global resource 
to the server group. And if we do that there's no reason to have the 
links in the top level /deployment-overlay=myOverlay.

I don't know if there's a great use case for different linking at 
different levels though. The things that come to mind are different JNDI 
references for different environments, things like that, and it seems 
like those can be solved via expressions in the deployment descriptors 
with different system property values in different levels.

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