I believe heat has its own dependency graph implementation but if that was 
switched to networkx[1] that library has a bunch of nice read/write 

See: https://github.com/networkx/networkx/tree/master/networkx/readwrite

And one made for sqlalchemy @ https://pypi.python.org/pypi/graph-alchemy/

Networkx has worked out pretty well for taskflow (and I believe mistral is also 
using it).

[1] https://networkx.github.io/

Something to think about...

On Sep 23, 2014, at 11:32 AM, Zane Bitter <zbit...@redhat.com> wrote:

> On 23/09/14 09:44, Anant Patil wrote:
>> On 23-Sep-14 09:42, Clint Byrum wrote:
>>> Excerpts from Angus Salkeld's message of 2014-09-22 20:15:43 -0700:
>>>> On Tue, Sep 23, 2014 at 1:09 AM, Anant Patil <anant.pa...@hp.com> wrote:
>>>>> Hi,
>>>>> One of the steps in the direction of convergence is to enable Heat
>>>>> engine to handle concurrent stack operations. The main convergence spec
>>>>> talks about it. Resource versioning would be needed to handle concurrent
>>>>> stack operations.
>>>>> As of now, while updating a stack, a backup stack is created with a new
>>>>> ID and only one update runs at a time. If we keep the raw_template
>>>>> linked to it's previous completed template, i.e. have a back up of
>>>>> template instead of stack, we avoid having backup of stack.
>>>>> Since there won't be a backup stack and only one stack_id to be dealt
>>>>> with, resources and their versions can be queried for a stack with that
>>>>> single ID. The idea is to identify resources for a stack by using stack
>>>>> id and version. Please let me know your thoughts.
>>>> Hi Anant,
>>>> This seems more complex than it needs to be.
>>>> I could be wrong, but I thought the aim was to simply update the goal 
>>>> state.
>>>> The backup stack is just the last working stack. So if you update and there
>>>> is already an update you don't need to touch the backup stack.
>>>> Anyone else that was at the meetup want to fill us in?
>>> The backup stack is a device used to collect items to operate on after
>>> the current action is complete. It is entirely an implementation detail.
>>> Resources that can be updated in place will have their resource record
>>> superseded, but retain their physical resource ID.
>>> This is one area where the resource plugin API is particularly sticky,
>>> as resources are allowed to raise the "replace me" exception if in-place
>>> updates fail. That is o-k though, at that point we will just comply by
>>> creating a replacement resource as if we never tried the in-place update.
>>> In order to facilitate this, we must expand the resource data model to
>>> include a version. Replacement resources will be marked as "current" and
>>> to-be-removed resources marked for deletion. We can also keep all current
>>> - 1 resources around to facilitate rollback until the stack reaches a
>>> "complete" state again. Once that is done, we can remove the backup stack.
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> Backup stack is a good way to take care of rollbacks or cleanups after
>> the stack action is complete. By cleanup I mean the deletion of
>> resources that are no longer needed after the new update. It works very
>> well when one engine is processing the stack request and the stacks are
>> in memory.
> It's actually a fairly terrible hack (I wrote it ;)
> It doesn't work very well because in practice during an update there are 
> dependencies that cross between the real stack and the backup stack (due to 
> some resources remaining the same or being updated in place, while others are 
> moved to the backup stack ready for replacement). So in the event of a 
> failure that we don't completely roll back on the spot, we lose some 
> dependency information.
>> As a step towards distributing the stack request processing and making
>> it fault-tolerant, we need to persist the dependency task graph. The
>> backup stack can also be persisted along with the new graph, but then
>> the engine has to traverse both the graphs to proceed with the operation
>> and later identify the resources to be cleaned-up or rolled back using
>> the stack id. There would be many resources for the same stack but
>> different stack ids.
> Right, yeah this would be a mistake because in reality there is only one 
> graph, so that's how we need to model it internally.
>> In contrast, when we store the current dependency task graph(from the
>> latest request) in DB, and version the resources, we can identify those
>> resources that need to be rolled-back or cleaned up after the stack
>> operations is done, by comparing their versions. With versioning of
>> resources and template, we can avoid creating a deep stack of backup
>> stacks. The processing of stack operation can happen from multiple
>> engines, and IMHO, it is simpler when all the engines just see one stack
>> and versions of resources, instead of seeing many stacks with many
>> resources for each stack.
> Bingo.
> I think all you need to do is record in the resource the particular template 
> and set of parameters it was tied to (maybe just generate a UUID for each 
> update... or perhaps a SHA hash of the actual data for better rollbacks?). 
> Then any resource that isn't part of the latest template should get deleted 
> during the cleanup phase of the dependency graph traversal.
> As you mentioned above, we'll also need to store the dependency graph of the 
> stack in the database somewhere. Right now we generate it afresh from the 
> template by assuming that each resource name corresponds to one entry in the 
> DB. Since that will no longer be true, we'll need it to be a graph of 
> resource IDs that we store.
> cheers,
> Zane.
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

OpenStack-dev mailing list

Reply via email to