Polices and deployments

[Jose Carrasco]

Hello guys.

I have read the Brooklyn documentation and I do not understand how a entity is deployed.

A application is the responsible of provisioning start, configure and manage its child entities, but how?

For example, does a entity define a method to deploy it which is called for its parent? Which is the difference between this method and a police?

May I use a police to deploy (or provision) a entity, or a police allows managed a deployed entity only?

In summary, I do not understand how a entity es deployed.

Thanks a lot.

[Richard Downer]

Jose,

Each entity has a set of effectors - effectors are basically "methods" which do something[1]. An application is a special case of entity, so the application too has effectors (methods).

You will normally find that an entity has "start" and "stop" effectors. Invoking the "start" effector will normally also start any child entities.

Therefore, when you execute "start" on the application, the application will also start its child entities - for example, a database and a web cluster.

Then the web cluster will also start its child entities - a load balancer and a dynamic cluster. Then the dynamic cluster will start its child entities - a number of web servers. So the "start" instruction has propagated right the way through the hierarchy of entities.

Policies are a different thing. A policy will be examining an entity by reading its sensors. A policy will then take decisions, and will invoke effectors to make something happen.

Take the RestarterPolicy, for example. You attach this to an entity - a web server for example. This policy reads the entity "state" sensor - if the sensor says that the web server has stopped (crashed), it will invoke the entity's "start" effector, to try and restart the node.

As another example, AutoScalerPolicy is attached to a cluster. It will be connected to a sensor that measures the load on the cluster. The policy will decide if the cluster is too large or too small, and will invoke the cluster's "resize" effector.

Hope this clears things up a bit, but please post back if you've any more questions.

Richard.

[1]Effector has a specific meaning in autonomic computing, which is a big influence on Brooklyn and an area in which some Brooklyn contributors are experts. I'm not an expert in autonomic computing, so I'm probably hugely oversimplifying the case and horrifying our experts with that statement :-)

--
You received this message because you are subscribed to the Google Groups "brooklyn-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to brooklyn-user...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Richard Downer • Principal Engineer • Cloudsoft Corporation • http://www.cloudsoftcorp.com

GitHub richardcloudsoft • Twitter @FrontierTown

[Jose Carrasco]

Hello Richard.

Thanks a lot for your reply, and of course I was suspect that the policies  allow managed a entity and they do not allow create a new instance, but I was sure and I understand more Brooklyn now.

One more.

When a application is deployed you must indicate the location, a cloud provider (or localhost). So, when the application is launched then Brooklyn uses jclouds to deployed the child entities  (of the application)  in the indicated cloud provider. After, the polices are deployed which manage the application entities. 

Thus, for example if a police P1 detect a incorrect behavior of a entity E1 which is deployed in a cloud provide CP1. May it be possible this police P1 re-deployes this instance E1 in a new cloud provider CP2 ? or as you tell me the police have to call a effort to re-deploy the intance only. I konw Brooklyn is not create to this, however I hope understand more Brooklyn and its behavior.

Thanks a lot.

[Molnár Mihály László]

Hi Jose!

You can write a policy which deletes the entity at that provider and creates a new at another location if you want.

But I think restart and replace misbehaving entities is the supported by policies included in brooklyn in HA policy:
http://brooklyncentral.github.io/use/api/brooklyn/policy/ha/ServiceReplacer.html
http://brooklyncentral.github.io/use/api/brooklyn/policy/ha/ServiceRestarter.html

So for this you have to write your own, but Richard or others will fix me if I told something wrong :)

Rusty

[Richard Downer]

Jose,

I'm not sure if Brooklyn can do *today* what you are suggesting - perhaps another of the Brooklyn team can confirm if this is a feature that is implemented - but it is absolutely a feature that Brooklyn should have, and could have! It is not unknown for a cloud provider's zone to fail, and therefore a policy which can redeploy to another cloud provider is a worthwhile thing to have. Brooklyn's framework is certainly capable of providing this, even if that exact policy has not been written yet.

Rusty,

As you point out, this is a very similar case to the replacer policy, which stops and starts entities in one location. It's feasible to have a policy that stops in one location and starts in another.

Richard.

[Aled Sage]

Hi Jose,

When you re-deploy E1 in a new cloud provider CP2, is it stateless or is this a disaster recovery scenario?

DR is almost always more involved. It's something we've automated for customers but it requires things like datastore replication/configuration, human-in-the-loop to confirm the failover, and wiring up components in CP2 to the correct (replicated) datastore. It's therefore not really a reusable policy as it depends very much on the nature of the application. However, there are good patterns that can be followed.

If you just want to stop E1 and start another entity with an identical entity-spec (i.e. no application-level state being moved) then that's a lot easier. There's not an out-of-the-box policy for it. However, the entity brooklyn.entity.group.DynamicRegionsFabric with its addRegion/removeRegion effectors will get you a long way.

Very interested to hear more about your use-case.

Aled

On 11/12/2013 16:31, Richard Downer wrote:

Jose,

I'm not sure if Brooklyn can do *today* what you are suggesting - perhaps another of the Brooklyn team can confirm if this is a feature that is implemented - but it is absolutely a feature that Brooklyn should have, and could have! It is not unknown for a cloud provider's zone to fail, and therefore a policy which can redeploy to another cloud provider is a worthwhile thing to have. Brooklyn's framework is certainly capable of providing this, even if that exact policy has not been written yet.

Rusty,

As you point out, this is a very similar case to the replacer policy, which stops and starts entities in one location. It's feasible to have a policy that stops in one location and starts in another.

Richard.

On 11 December 2013 14:15, Moln�r Mih�ly L�szl� <laci...@gmail.com> wrote:

Hi Jose!

You can write a policy which deletes the entity at that provider and creates a new at another location if you want.

But I think restart and replace misbehaving entities is the supported by policies included in brooklyn in HA policy:
http://brooklyncentral.github.io/use/api/brooklyn/policy/ha/ServiceReplacer.html
http://brooklyncentral.github.io/use/api/brooklyn/policy/ha/ServiceRestarter.html

So for this you have to write your own, but Richard or others will fix me if I told something wrong :)

Rusty

On Wed, Dec 11, 2013 at 2:44 PM, Jose Carrasco <kiu...@gmail.com> wrote:

Hello Richard.

Thanks a lot for your reply, and of course I was suspect that the policies �allow managed a entity and they do not allow create a new instance, but I was sure and I understand more Brooklyn now.

One more.

When a application is deployed you must indicate the location, a cloud provider (or localhost). So, when the application is launched then Brooklyn uses jclouds to deployed the child entities �(of the application) �in the indicated cloud provider. After, the polices are deployed which manage the application entities.�

Thus, for example if a police P1 detect a incorrect behavior of a entity E1 which is deployed in a cloud provide CP1.�May it be possible this police P1 re-deployes this instance E1 in a new cloud provider CP2 ? or as you tell me the police have to call a effort to re-deploy the intance only. I konw Brooklyn is not create to this, however I hope understand more Brooklyn and its behavior.

Thanks a lot.

El mi�rcoles, 11 de diciembre de 2013 12:36:08 UTC+1, Richard Downer escribi�:

Jose,

Each entity has a set of effectors - effectors are basically "methods" which do something[1]. An application is a special case of entity, so the application too has effectors (methods).

You will normally find that an entity has "start" and "stop" effectors. Invoking the "start" effector will normally also start any child entities.

Therefore, when you execute "start" on the application, the application will also start its child entities - for example, a database and a web cluster.

Then the web cluster will also start its child entities - a load balancer and a dynamic cluster. Then the dynamic cluster will start its child entities - a number of web servers. So the "start" instruction has propagated right the way through the hierarchy of entities.

Policies are a different thing. A policy will be examining an entity by reading its sensors. A policy will then take decisions, and will invoke effectors to make something happen.

Take the RestarterPolicy, for example. You attach this to an entity - a web server for example. This policy reads the entity "state" sensor - if the sensor says that the web server has stopped (crashed), it will invoke the entity's "start" effector, to try and restart the node.

As another example, AutoScalerPolicy is attached to a cluster. It will be connected to a sensor that measures the load on the cluster. The policy will decide if the cluster is too large or too small, and will invoke the cluster's "resize" effector.

Hope this clears things up a bit, but please post back if you've any more questions.

Richard.

[1]Effector has a specific meaning in autonomic computing, which is a big influence on Brooklyn and an area in which some Brooklyn contributors are experts. I'm not an expert in autonomic computing, so I'm probably hugely oversimplifying the case and horrifying our experts with that statement :-)

On 11 December 2013 09:14, Jose Carrasco <kiu...@gmail.com> wrote:

Hello guys.

I have read the Brooklyn documentation and I do not understand how a entity is deployed.

A application is the responsible of provisioning start, configure and manage its�child entities, but how?

For example, does a entity define a method to deploy it which is called for its parent? Which is the difference between this method and a police?

May I use a police to deploy (or provision) a entity, or a police allows managed a deployed entity only?

In summary, I do not understand how a entity es deployed.

Thanks a lot.

--
You received this message because you are subscribed to the Google Groups "brooklyn-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to brooklyn-user...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--

Richard Downer � Principal Engineer � Cloudsoft Corporation � http://www.cloudsoftcorp.com

GitHub richardcloudsoft � Twitter @FrontierTown

--
You received this message because you are subscribed to the Google Groups "brooklyn-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to brooklyn-user...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "brooklyn-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to brooklyn-user...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Richard Downer � Principal Engineer � Cloudsoft Corporation � http://www.cloudsoftcorp.com

GitHub richardcloudsoft � Twitter @FrontierTown

[Jose Carrasco]

Hello all.

Thanks for your replies, they are very usefull for me.

Aled, the reason which launchs the change of the location (and provider) should be something event. I think that such as a entity and a application should change because a application is a entity too (I am sorry if I told something wrong), so this challenge will be complicate.

Now, I am going to study how Brooklyn use the application descriptor to deploy the entities of the application. Thus, I will ask a lot about Brooklyn :-) 

I am going to inspect the policies mencioned too,  and I will tell you about the results.

Thanks a lot.

Jose

[Aled Sage]

Hi Jose,

Triggering the change of location with an event makes sense. Policies normally subscribe to events (attribute-changes or other notifications) to decide when to perform actions, so that fits well.

However, what to do when that event is triggered depends on the nature of the entity: is it stateless (so easy to just create a new one in the new location); or is it stateful (so need to hook up to data residing in the second location or even connecting back to some entities running remaining in the first location). These are all things we've done in brooklyn, with increasing levels of complexity.

You're right that an application is an entity. But I'm guessing you want to keep the application entity as-is, and have the policy create new entities (in the new location) that are in the somewhere under application (in its entity hierarchy).

Aled