<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 8, 2013 at 8:21 PM, Gustavo Niemeyer <span dir="ltr"><<a href="mailto:gustavo.niemeyer@canonical.com" target="_blank">gustavo.niemeyer@canonical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Apr 8, 2013 at 9:00 PM, Mark Ramm<br>
<<a href="mailto:mark.ramm-christensen@canonical.com">mark.ramm-christensen@canonical.com</a>> wrote:<br>
(...)<br>
<div class="im">> I think it is very fair to say that proper placement/co-location is a<br>
> prerequisite for that portion of the stacks feature, and that it would be<br>
> incompatable with the "force-machine" style co-location contemplated here.<br>
<br>
</div>Right, you understand it properly.<br>
<div class="im"><br></div></blockquote><div><br></div><div style>co-location is distinct from the real world use case that users want to achieve via force-machine. that use case is not a request for co-location its about density for cost. its not a request for co-located units as additional units to services are deployed. Its not clear though that service level constraints properly capture this except as a transient state with the added value that its recorded on the unit level, which is where william was going i think with the disconnect of historical constraints with current constraints. In the same way that such historical information is effectively wasted, because its not captured except at individual resource level, its not clear why its so important to capture the historical value of force-machine. The current constraints of the service are the state of the user intent and the model.</div>
<div style><br></div><div style>cheers,</div><div style><br></div><div style>Kapil</div><div style><br></div><div> </div></div></div></div>