On 14/11/13 12:26, Renat Akhmerov wrote:
On 14 Nov 2013, at 18:03, Zane Bitter <zbit...@redhat.com
<mailto:zbit...@redhat.com>> wrote:
What might be a downside is that sharing a back-end may not be
technically convenient - one thing we have been reminded of in Heat is
that a service with timed tasks has to be scaled out in a completely
different way to a service that avoids them. This may or may not be an
issue for Mistral, but it could be resolved by having different
back-end services that communicate over RPC. The front-end API can
remain shared though.
Not sure I’m 100% following here. Could you please provide more details
on this? Seems to be an important topic to me. Particularly, what did
you mean when you said “sharing a back-end”? Sharing by which components?
If you have a service that is stateless and only responds to user
requests, then scaling it out is easy (just stick it behind a load
balancer). If it has state (i.e. a database), things become a whole lot
more complicated to maintain consistency. And if the application has
timed tasks as well as incoming requests, that also adds another layer
of complexity.
Basically you need to ensure that a task is triggered exactly once, in a
highly-available distributed system (and, per a previous thread, you're
not allowed to use Zookeeper ;). Your scaling strategy will be more or
less dictated by this, possibly to the detriment of the rest of your
service - though in Mistral it may well be the case that you have this
constraint already. If not then one possible solution to this is to run
two binaries and have different scaling strategies for each.
None of this should take away from the fact that the two features should
be part of the same API (this is what I meant by "sharing a front-end").
Hopefully that clarifies things :)
cheers,
Zane.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
