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

[Alexey Loubyansky]

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