<div dir="ltr">Hi,<div><br></div><div><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>1) Find all of the applications using PHP 5.4.xxxx in their stack and update them to PHP 5.4.xxxx+1</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px">
<span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>   a) test that the application still works using its built in test suites</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px">
<span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>  b) if the PHP 5.4.xxxx+1 upgrade fails, go back to using PHP 5.4.xxxx for only the affected applications</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px">
<br>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.<br>
<br style="font-family:arial,sans-serif;font-size:12.800000190734863px"><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>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</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px">
<span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>   a) Do that 3 times a day for 100 apps</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px"><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>   b) run the integration test suites on the stack to verify that the production version is not bugged</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px">
<br> 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.</div>
<div><br></div><div><br></div><div><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>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*.</span><br>
</div><div><span style="font-family:arial,sans-serif;font-size:12.800000190734863px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">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.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:12.800000190734863px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">Thanks</span></div><div><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">Georgy</span></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Nov 14, 2013 at 11:46 AM, Clayton Coleman <span dir="ltr"><<a href="mailto:ccoleman@redhat.com" target="_blank">ccoleman@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">----- Original Message -----<br>
> So while I have been on vacation, I've been thinking about Solum and Heat.<br>
><br>
> And I have some lingering questions in my mind that make me question<br>
> whether a new server project is actually necessary at all, and whether<br>
> we really should just be targeting innovation and resources towards the<br>
> Heat project.<br>
><br>
> What exactly is Solum's API going to control that is not already<br>
> represented in Heat's API and the HOT templating language? At this<br>
> point, I'm really not sure, and I'm hoping that we can discuss this<br>
> important topic before going any further with Solum. Right now, I see so<br>
> much overlap that I'm questioning where the differences really are.<br>
><br>
> Thoughts?<br>
> -jay<br>
<br>
</div>A few interesting scenarios that I assume heat would not cover, for discussion (trying to keep in mind what Georgy and others have said)<br>
<br>
1) Find all of the applications using PHP 5.4.xxxx in their stack and update them to PHP 5.4.xxxx+1<br>
   a) test that the application still works using its built in test suites<br>
   b) if the PHP 5.4.xxxx+1 upgrade fails, go back to using PHP 5.4.xxxx for only the affected applications<br>
<br>
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<br>
   a) Do that 3 times a day for 100 apps<br>
   b) run the integration test suites on the stack to verify that the production version is not bugged<br>
<br>
3) Generate a deployable glance image automatically and a new heat template when a developer pushes a change to a source repository<br>
   a) Do that for 10k developers pushing changes 10x a day<br>
   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<br>
<br>
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*.<br>

<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Georgy Okrokvertskhov<br>
Technical Program Manager,<br>Cloud and Infrastructure Services,<br>
Mirantis<br>
<a href="http://www.mirantis.com/" target="_blank">http://www.mirantis.com</a><br>
Tel. +1 650 963 9828<br>
Mob. +1 650 996 3284<br>
</div>