Open Stack

Hi,

>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

Actually I think Heat can do this. Software components in HOT templates can
use Chef, puppet, SaltStack, so as these tools can do this Heat also is
capable to do this. As soon as you can use stack update and supply new
software component with all necessary automation scripts, you can upgrade
the whole stack. That perfectly fits to Heat and I believe Solum is
intended to use this Heat feature for upgrades and application roll-out.

>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 version
>   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

 That is a good example of Solum usage. I think that was mentioned in
yesterday discussion in Solum IRC chat, that there will be probably a
concept of "promotion". So you can promote image to different stages and
environments and Solum will have an API to describe these flows. That is
where Solum adds a huge value as it introduces concepts which are absent in
Heat. Ideas of "code", "build", "test" and "gates" are common in developers
world of CI\CD rather then in DevOps world where Heat plays great role.


>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*.

I am not sure that Heat should add "why" and "when" into the syntax. I
think it will overcomplicate HOT syntax. Currently there are dependencies
and waitconditions available in HOT and this should be enough to describe
deployments.

Thanks
Georgy


On Thu, Nov 14, 2013 at 11:46 AM, Clayton Coleman <ccoleman at redhat.com>wrote:

> ----- 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 version
>    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
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Georgy Okrokvertskhov
Technical Program Manager,
Cloud and Infrastructure Services,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131114/ffc6d4a6/attachment.html>