Page MenuHomePhabricator

Build a dependency graph resolver for deployment stages and tasks
Closed, DeclinedPublic

Description

Use a directed acyclic graph to control the order of execution within and among deployment stages.

Event Timeline

mmodell claimed this task.
mmodell raised the priority of this task from to Needs Triage.
mmodell updated the task description. (Show Details)
mmodell added a project: Scap.
mmodell added a subscriber: mmodell.

I agree that within stages a DAG would be awesome to have. What worries me here is to use one for defining the relationship between stages as well. What would be the rationale for that?

My fear is that we would end up with a Puppet-like system, which, precisely because of the extensive usage of DAGs, makes it quite hard to get right from the start and reason about since a lot of processes may happen in parallel.

@mobrovac:

This will be a lot simpler than puppet. And 'among stages' probably doesn't need to use a graph resolver.

You can see what I have so far in {D76}

mmodell lowered the priority of this task from High to Low.Jan 21 2016, 11:30 PM
mmodell changed the task status from Open to Stalled.Feb 15 2016, 3:22 PM
mmodell moved this task from Debt to Experiments on the Scap board.
mmodell set Security to None.
Aklapper changed the task status from Stalled to Open.May 10 2020, 3:49 PM

@mmodell: The previous comments don't explain what/who exactly this task is stalled on ("If a report is waiting for further input (e.g. from its reporter or a third party) and can currently not be acted on"). Hence resetting task status.

(Smallprint, as general orientation for task management: If work on this task is blocked by another task, then that other task should be added via Edit Related Tasks...Edit Subtasks. If this task is stalled on an upstream project, then the Upstream tag should be added. If this task requires info from the task reporter, then there should be instructions which info is needed. If you wanted to express that nobody is currently working on this task, then the assignee should be removed and/or priority could be lowered instead. If this task is out of scope and nobody should ever work on this, then task status should be "declined".)

this is obsolete, though it's still a good idea it's no longer relevant to current plans.