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

[Alexey Loubyansky]

Deployments are different because /deployment=xxx:add(...) accepts content.
Deployment overlays are created in two steps:
- :upload-deployment-stream
- read results of the above and use the checksums as arguments to the 
overlay/content:add(...)

Yes, a workaround would be to add operations to overlays that would 
combine these actions.

Or invest in transactions :)

On 08/15/2012 05:53 PM, Brian Stansberry wrote:
> I don't quite understand this one. How is this different from
> deployments? Is this just an issue of not having all the API options
> available for adding overlays that we have for deployments? If so we can
> solve that easily enough.
>
> On 8/15/12 9:57 AM, Alexey Loubyansky wrote:
>> Another issue related to this command and management of the overlay and
>> links is that this command can't be a part of a batch because actions
>> like create a new overlay with content and adding content to an existing
>> overlay can't translate into a single composite operation, which a batch
>> translates to.
>>
>> The problem is referencing results of one step in a composite operation
>> from arguments of another step in the same composite operation.
>>
>> Alexey
>>
>> On 08/15/2012 04:11 PM, 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
>>
>
>