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

[Brian Stansberry]

On 8/15/12 12:33 PM, Alexey Loubyansky wrote:
> 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 :)
>

Or both!

Guess which will happen first. ;-)

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