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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>