Open Stack

On 01/13/2016 10:41 AM, Tzu-Mainn Chen wrote:
> Hey all,
>
> I realize now from the title of the other TripleO/Mistral thread [1] that
> the discussion there may have gotten confused.  I think using Mistral for
> TripleO processes that are obviously workflows - stack deployment, node
> registration - makes perfect sense.  That thread is exploring practicalities
> for doing that, and I think that's great work.
>
> What I inappropriately started to address in that thread was a somewhat
> orthogonal point that Dan asked in his original email, namely:
>
> "what it might look like if we were to use Mistral as a replacement for the
> TripleO API entirely"
>
> I'd like to create this thread to talk about that; more of a 'should we'
> than 'can we'.  And to do that, I want to indulge in a thought exercise
> stemming from an IRC discussion with Dan and others.  All, please correct me
> if I've misstated anything.
>
> The IRC discussion revolved around one use case: deploying a Heat stack
> directly from a Swift container.  With an updated patch, the Heat CLI can
> support this functionality natively.  Then we don't need a TripleO API; we
> can use Mistral to access that functionality, and we're done, with no need
> for additional code within TripleO.  And, as I understand it, that's the
> true motivation for using Mistral instead of a TripleO API: avoiding custom
> code within TripleO.
>
> That's definitely a worthy goal... except from my perspective, the story
> doesn't quite end there.  A GUI needs additional functionality, which boils
> down to: understanding the Heat deployment templates in order to provide
> options for a user; and persisting those options within a Heat environment
> file.

We also have things like profile matching (on review now), which don't 
fall into any other project..

>
> Right away I think we hit a problem.  Where does the code for 'understanding
> options' go?  Much of that understanding comes from the capabilities map
> in tripleo-heat-templates [2]; it would make sense to me that responsibility
> for that would fall to a TripleO library.
>
> Still, perhaps we can limit the amount of TripleO code.  So to give API
> access to 'getDeploymentOptions', we can create a Mistral workflow.
>
>    Retrieve Heat templates from Swift -> Parse capabilities map
>
> Which is fine-ish, except from an architectural perspective
> 'getDeploymentOptions' violates the abstraction layer between storage and
> business logic, a problem that is compounded because 'getDeploymentOptions'
> is not the only functionality that accesses the Heat templates and needs
> exposure through an API.  And, as has been discussed on a separate TripleO
> thread, we're not even sure Swift is sufficient for our needs; one possible
> consideration right now is allowing deployment from templates stored in
> multiple places, such as the file system or git.
>
> Are we going to have duplicate 'getDeploymentOptions' workflows for each
> storage mechanism?  If we consolidate the storage code within a TripleO
> library, do we really need a *workflow* to call a single function?  Is a
> thin TripleO API that contains no additional business logic really so bad
> at that point?
>
> My gut reaction is to say that proposing Mistral in place of a TripleO API
> is to look at the engineering concerns from the wrong direction.  The
> Mistral alternative comes from a desire to limit custom TripleO code at all
> costs.  I think that is an extremely dangerous attitude that leads to
> compromises and workarounds that will quickly lead to a shaky code base
> full of design flaws that make it difficult to implement or extend any
> functionality cleanly.
>
> I think the correct attitude is to simply look at the problem we're
> trying to solve and find the correct architecture.  For these get/set
> methods that the API needs, it's pretty simple: storage -> some logic ->
> a REST API.  Adding a workflow engine on top of that is unneeded, and I
> believe that means it's an incorrect solution.
>
>
> Thanks,
> Tzu-Mainn Chen
>
>
>
> [1] http://lists.openstack.org/pipermail/openstack-dev/2016-January/083757.html
> [2] https://github.com/openstack/tripleo-heat-templates/blob/master/capabilities_map.yaml
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>