Open Stack

----- Original Message -----
> Hi Clayton,
> 
> Thank you for creating these diagrams. They are a great starting point for
> discussions
> around the git deploy blueprint.
> 
> Some questions/comments:
> 
> In both the diagrams, what do the arrows indicate?
> Data flow, control-flow, or some kind of ordering relationship?

"Happens after" mostly.  It was intended to be less formal than a true sequence flow, just a vehicle iterate and discuss until we'd nailed down any mismatches in how each of us looks at the overall flow, then move on to more formal definitions.

> Especially, the arrow from 'respond to client' to 'HEAT' box in the top
> diagram
> is a bit confusing. Correct me if I am wrong, but my guess is that the
> meaning
> of that arrow is, 'stack create' will happen after responding to client has
> happened.
> Although, this may not be necessarily true (both those steps can happen in
> async manner).

You and Adrian are right - I'll go back and explicitly call out the asynchronicity.

> 
> Second, how do you envision tying together the two diagrams/high-level flows?
> Specifically, once we have a built artifact (second diagram), how do we go
> about deploying it?

I'll throw another one in that's really abstract and follow up in a response.  I think the easy answer is "make a change to the 'plan', turn the plan into a HOT template, call HEAT to update the stack".  Over time Heat stack update then is the natural boundary for versions of an app.

> 
> We could either have, build abstraction -> REST API -> deploy abstraction,
> or, build abstraction -> deploy abstraction. What are your thoughts on this?
> 

Working backwards, builds usually create resources somewhere and sometimes those resources are large (e.g Jenkins and a Glance image, for instance).  The builder needs a clean endpoint to notify Solum that a new deployment artifact is available that replaces one of the existing deployment artifacts.  There's a big gray area here because it depends on how strongly Solum specifies this flow - the less strongly the flow is specified the more flexibility there is to integrate complex systems (Gerritt, Jenkins, existing corporate build procesess), the more strongly the flow is specified the easier it is to provide valuable outcomes.  My guess is that there probably is a "new artifact available" API call that updates an existing artifact which triggers a redeploy.  An artifact might be a zip, a WAR, a docker image, a glance image, a VM img file, etc.  I think this is a good topic for the build subgroup.