----- Original Message -----
> So while I have been on vacation, I've been thinking about Solum and Heat.
> And I have some lingering questions in my mind that make me question
> whether a new server project is actually necessary at all, and whether
> we really should just be targeting innovation and resources towards the
> Heat project.
> What exactly is Solum's API going to control that is not already
> represented in Heat's API and the HOT templating language? At this
> point, I'm really not sure, and I'm hoping that we can discuss this
> important topic before going any further with Solum. Right now, I see so
> much overlap that I'm questioning where the differences really are.
> Thoughts?
> -jay

A few interesting scenarios that I assume heat would not cover, for discussion 
(trying to keep in mind what Georgy and others have said)

1) Find all of the applications using PHP 5.4.xxxx in their stack and update 
them to PHP 5.4.xxxx+1
   a) test that the application still works using its built in test suites
   b) if the PHP 5.4.xxxx+1 upgrade fails, go back to using PHP 5.4.xxxx for 
only the affected applications

2) Allow developers to deploy versions of a heat stack for testing, and then 
allow a release engineer to easily convert that heat stack to a production 
   a) Do that 3 times a day for 100 apps
   b) run the integration test suites on the stack to verify that the 
production version is not bugged

3) Generate a deployable glance image automatically and a new heat template 
when a developer pushes a change to a source repository
   a) Do that for 10k developers pushing changes 10x a day
   d) Keep 3 glance images referenced in 90% of stacks, 10 glance images 
referenced in 9% of stacks, and all glance images referenced by 1% of stacks

A lot of Solum's precepts are based on the observation that there are patterns 
in application development and lifecycle that work well for 90% of developers 
90% of the time.  It is certainly possible to build custom tooling around 
OpenStack that handle each of these scenarios... but each of those are slightly 
different in ways that are typically historical rather than technological.  
HEAT/HOT is orchestration of components - should it attempt to define the 
*when* and *why* of when stack changes occur?  Solum I see as providing a basis 
for the *when* and *why*, and relying on HEAT for the *how*.

OpenStack-dev mailing list

Reply via email to