Which component knows about the runtime environments?

[florian...@googlemail.com]

Hi all,

in the last days I've read a lot about the CloudFoundry architecture, yet there is one thing that remains unclear for me: Which component does actually know about the runtime environments on which the cloud apps will run in the end?

DEAs are (as far as I got it) unaware of the application code and just use the start/stop buttons of the droplets. Yet, somewhere I read that DEAs tell the Cloud Controller which Runtime Environments they provide (or rather: they tell whether they could run a specific droplet, one parameter being the needed runtime environment). Now, how does it actually work?

And another question: What does the Stager exactly do? Which components are being packed to a droplet?


Thanks for your time. Best regards,
Florian

[kelby lee]

在 2012年11月5日星期一UTC+8下午10时40分25秒，florian...@googlemail.com写道：

Hi all,

in the last days I've read a lot about the CloudFoundry architecture, yet there is one thing that remains unclear for me: Which component does actually know about the runtime environments on which the cloud apps will run in the end?

What i know is: vmc have a detect process when you upload your app, then it clound know the runtime,framework,server info and other some environments. And Staging as so on more or less. Then you could ask app what it's environments.

DEAs are (as far as I got it) unaware of the application code and just use the start/stop buttons of the droplets. Yet, somewhere I read that DEAs tell the Cloud Controller which Runtime Environments they provide (or rather: they tell whether they could run a specific droplet, one parameter being the needed runtime environment). Now, how does it actually work?

DEA could calculate it's resources, then decide it's delay time when "process_dea_discover".

And another question: What does the Stager exactly do? Which components are being packed to a droplet?

Stager mainly do this things: Downloading app, which as a zip file in CC; Unpacking app and Staging app; Creating droplet, then uploading droplet.
The Stager do the common things, but the 'specific staging process' is by specific StagingPlugin.  

[florian...@googlemail.com]

On Friday, 9 November 2012 11:19:46 UTC+1, kelby lee wrote:

在 2012年11月5日星期一UTC+8下午10时40分25秒，florian...@googlemail.com写道：

Hi all,

in the last days I've read a lot about the CloudFoundry architecture, yet there is one thing that remains unclear for me: Which component does actually know about the runtime environments on which the cloud apps will run in the end?

What i know is: vmc have a detect process when you upload your app, then it clound know the runtime,framework,server info and other some environments. And Staging as so on more or less. Then you could ask app what it's environments.

Thank you. What I meant is: Do DEAs know about the runtime environments they can run? For example, does a DEA know that it can run Java applications but not Python applications, since it has a Java runtime environment installed but not a Python runtime environment? Or in other words: are runtime environments completely transparent to DEAs or not? I could for example imagine that the runtime environment comes inside the droplet, therefore being completely transparent to DEAs (altough I don't know whether this would make sense in practice.
 

DEAs are (as far as I got it) unaware of the application code and just use the start/stop buttons of the droplets. Yet, somewhere I read that DEAs tell the Cloud Controller which Runtime Environments they provide (or rather: they tell whether they could run a specific droplet, one parameter being the needed runtime environment). Now, how does it actually work?

DEA could calculate it's resources, then decide it's delay time when "process_dea_discover".

And another question: What does the Stager exactly do? Which components are being packed to a droplet?

Stager mainly do this things: Downloading app, which as a zip file in CC; Unpacking app and Staging app; Creating droplet, then uploading droplet.
The Stager do the common things, but the 'specific staging process' is by specific StagingPlugin.  

So if I understand correctly, each language/runtime comes with with a specific StagingPlugin. I didn't know this...