How stable Diego is?

324 views
Skip to first unread message

prys...@gmail.com

unread,
Apr 14, 2015, 5:47:32 AM4/14/15
to vcap...@cloudfoundry.org
Hi guys,

Well, we know that Diego still in beta... but what are current limitation to use it?
We see releases pretty often but can't use them because we unsure that it will work with current release of CF.
Are there any examples of docker images successfully pushed to Diego except well known cloudfoundry/diego-docker-app?
Could you please share your examples of images? May be you have an experience of adopting cool applications such as Jenkis CI, Wordpress etc?

What "Found no compatible cell" error means?
What is the good/bad signs of an image to run it in Diego (except 12 factors)?

Sorry, so many questions.

Alex Prysmakou / Altoros

Eric Malm

unread,
Apr 14, 2015, 2:56:36 PM4/14/15
to vcap...@cloudfoundry.org
Hi, Alex,

Thanks very much for inquiring about the current state of the Diego project. As Onsi mentioned in his Diego Update post a few weeks ago, we're continuing to make progress towards recommendation for production usage and eventual replacement of the DEAs in CF. I'll respond inline to some of your other questions below.

On Tue, Apr 14, 2015 at 2:47 AM, <prys...@gmail.com> wrote:
Hi guys,

Well, we know that Diego still in beta... but what are current limitation to use it?
We see releases pretty often but can't use them because we unsure that it will work with current release of CF.

The Diego continuous integration pipeline differs from the cf-release pipeline in that it cuts a new BOSH final release every time diego-release passes its unit tests, inter-component integration tests, and integration against a CF deployment on AWS. Consequently, the Diego team creates many more final releases of diego-release than there are of cf-release.

Dieu Cao from Runtime and the Diego team have been working together to provide recommended final Diego releases to accompany final CF releases when they are announced. For example, the announcement of cf v206 last week lists final release 0.1075.0 as the recommended compatible version of Diego. Additionally, the Diego team has a story coming up soon in our backlog to publish a more complete list of compatible cf-release and diego-release commits as an artifact of our CI pipeline.

Also, as Onsi mentioned, before Diego is declared production-ready, we may introduce backwards-incompatible changes for the sake of development expediency. We'll do our best to warn the community about any major such changes as they occur; in fact, I'll be posting about one of those incompatibilities shortly.
 
Are there any examples of docker images successfully pushed to Diego except well known cloudfoundry/diego-docker-app?
Could you please share your examples of images? May be you have an experience of adopting cool applications such as Jenkis CI, Wordpress etc?

The Diego team at present is focused mainly on ensuring basic compatibility with Docker images pushed through CF, and not with exercising the full range of capabilities of Docker images pushed to the Diego runtime. I believe that some users experimenting with the Lattice project (which uses Diego components internally) have tried running a broader range of Docker images. It would be great if some of them could comment here on vcap-dev about their experiences in getting different Docker images to run through CF, Lattice, or even the lower-level HTTP API that Diego exposes via its receptor component.
 

What "Found no compatible cell" error means?

If you see a "Found no compatible cell" error when staging or running, it typically means that the distributed auction algorithm running in Diego was unable to find a cell that matches the rootfs specifications on the Task or DesiredLRP, respectively. In the case of running a Docker image via CF, it may mean that no cell has declared it is capable of running docker images in its garden backend. What are the circumstances under which you're seeing this error? Also, please note that Diego final release 0.1046.0 introduced one of those backwards incompatibilities mentioned above that may result in this error for existing apps even if you're running compatible versions of CF and Diego. I'll provide more details about how to intervene manually to correct the system in a forthcoming post.
 
What is the good/bad signs of an image to run it in Diego (except 12 factors)?

Right now, Diego is still focused on running stateless long-running-processes such as 12-factor apps and relatively short-lived one-off tasks that also do not need to persist state on an attached filesystem. The Docker Support document in the Diego design notes repo contains more information about how Diego and CF run Docker images and what the present limitations are. In particular, not every directive in the Docker image metadata is supported yet, so for example Docker images that perform operations as specific users may not operate as intended when Garden run commands in them as the non-privileged 'vcap' user. We understand the importance of that functionality, though, and we'll be working with the Garden team to provide appropriately comprehensive support for users declared in the Docker image metadata at some future date.

Thanks,
Eric, for the CF Runtime Diego team
 

Sorry, so many questions.

Alex Prysmakou / Altoros

--
You received this message because you are subscribed to the Google Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/7f7f7a16-7dbb-4cec-b868-7ab96dc8ded8%40cloudfoundry.org.

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.

Aliaksandr Prysmakou

unread,
Apr 15, 2015, 8:07:03 AM4/15/15
to vcap...@cloudfoundry.org
Eric, 

thank you very much for the answer. It really helps us.

Marco Nicosia

unread,
Apr 21, 2015, 2:03:28 PM4/21/15
to vcap...@cloudfoundry.org
Following up on Eric's post of a week ago...


On Tuesday, April 14, 2015 at 11:56:36 AM UTC-7, Eric Malm wrote:
Are there any examples of docker images successfully pushed to Diego except well known cloudfoundry/diego-docker-app?
Could you please share your examples of images? May be you have an experience of adopting cool applications such as Jenkis CI, Wordpress etc?

The Diego team at present is focused mainly on ensuring basic compatibility with Docker images pushed through CF, and not with exercising the full range of capabilities of Docker images pushed to the Diego runtime. I believe that some users experimenting with the Lattice project (which uses Diego components internally) have tried running a broader range of Docker images. It would be great if some of them could comment here on vcap-dev about their experiences in getting different Docker images to run through CF, Lattice, or even the lower-level HTTP API that Diego exposes via its receptor component.

Happy to update that we published a new page, "Docker Image Examples" on the Lattice website today:


In it, we demonstrate a bunch of popular packages (Redis, Rabbit, MySQL, Postgres, and more!) on top of Lattice. It's a first pass, so I'm sure a bug or two has slipped through. Please feel free to proactively report bugs in the documentation. For now, it'd be best to post issues on the core Lattice github repo: https://github.com/cloudfoundry-incubator/lattice

Alex Prysmakou

unread,
Apr 22, 2015, 8:34:22 AM4/22/15
to vcap...@cloudfoundry.org

Cool,  if an image runs well in Latice does it have to run in Diego as well? Is there any difference?

--
You received this message because you are subscribed to a topic in the Google Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/9a152fb0-b2ea-40f9-a2de-52c7b46241b0%40cloudfoundry.org.

Marco Nicosia

unread,
Apr 22, 2015, 9:44:27 AM4/22/15
to vcap...@cloudfoundry.org
On Wednesday, April 22, 2015 at 5:34:22 AM UTC-7, Aliaksandr Prysmakou wrote:

Cool,  if an image runs well in Latice does it have to run in Diego as well? Is there any difference?

No difference! Lattice's execution engine is Diego, the same that will ultimately power Cloud Foundry.
 

21 kwi 2015 20:03 "Marco Nicosia" <mnic...@pivotal.io> napisał(a):
Following up on Eric's post of a week ago...

On Tuesday, April 14, 2015 at 11:56:36 AM UTC-7, Eric Malm wrote:
Are there any examples of docker images successfully pushed to Diego except well known cloudfoundry/diego-docker-app?
Could you please share your examples of images? May be you have an experience of adopting cool applications such as Jenkis CI, Wordpress etc?

The Diego team at present is focused mainly on ensuring basic compatibility with Docker images pushed through CF, and not with exercising the full range of capabilities of Docker images pushed to the Diego runtime. I believe that some users experimenting with the Lattice project (which uses Diego components internally) have tried running a broader range of Docker images. It would be great if some of them could comment here on vcap-dev about their experiences in getting different Docker images to run through CF, Lattice, or even the lower-level HTTP API that Diego exposes via its receptor component.

Happy to update that we published a new page, "Docker Image Examples" on the Lattice website today:


In it, we demonstrate a bunch of popular packages (Redis, Rabbit, MySQL, Postgres, and more!) on top of Lattice. It's a first pass, so I'm sure a bug or two has slipped through. Please feel free to proactively report bugs in the documentation. For now, it'd be best to post issues on the core Lattice github repo: https://github.com/cloudfoundry-incubator/lattice


Thanks,
Eric, for the CF Runtime Diego team
 

Sorry, so many questions.

Alex Prysmakou / Altoros

--
  Marco Nicosia
  Product Manager
  Pivotal Software, Inc.
 

Alex Prysmakou

unread,
Apr 23, 2015, 2:05:19 AM4/23/15
to vcap...@cloudfoundry.org

I understand that there is one execution engine in both systems, but I got different results in Latice and Diego. May be it was specific to my deployment, but CC in Diego may also affect on application deployment?

--
You received this message because you are subscribed to a topic in the Google Groups "Cloud Foundry Developers" group.

James Bayer

unread,
Apr 23, 2015, 2:07:30 AM4/23/15
to vcap...@cloudfoundry.org
can you tell us more about what was different?

--
You received this message because you are subscribed to the Google Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAAKp27DZQB13xvW0Zp-A-vU%3DTrFa1OUuEfKUb%2BOpDLG9T-NNjg%40mail.gmail.com.

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.



--
Thank you,

James Bayer

Alex Prysmakou

unread,
Apr 23, 2015, 7:27:16 AM4/23/15
to vcap...@cloudfoundry.org

James,
I'm on vacation this week. Will try to reproduce it on Monday. In general, some applications run well on Latice but fails on Diego.

Harry Zhang

unread,
Apr 27, 2015, 1:50:58 AM4/27/15
to vcap...@cloudfoundry.org
Glad to hear about that, I noticed the images including rabbitmq and mysql, does that mean that gorouter has already implemented TCP routing now?

James Bayer

unread,
Apr 27, 2015, 3:18:10 AM4/27/15
to vcap...@cloudfoundry.org
no, tcp routing is not implemented in gorouter w/o the custom connection upgrade. to reach the data services in diego you would need to be able to connect directly to the diego cells network interface and discover the appropriate ports, which are currently available with the diego receptor api.

--
You received this message because you are subscribed to the Google Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/f970e02f-19e3-4032-855d-813a0d490096%40cloudfoundry.org.

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.

Lev

unread,
Apr 29, 2015, 6:46:34 AM4/29/15
to vcap...@cloudfoundry.org

I've tried to push Redis image to Diego and only managed to get the app working after creating my own image with some Dockerfile modifications. The problems I've encountered are:

* The healthcheck script from the docker_app_lifecycle always checks the 8080 port. Am I right assuming this can't be configured yet?
* "chown -R redis ."  command fails with "Invalid argument" error. For my image I fixed it by running redis from vcap user.

How are this issues addressed in Lattice?

Lev Berman

Altoros - CloudFoundry deployment, training and integration

James Bayer

unread,
May 3, 2015, 8:08:17 AM5/3/15
to vcap...@cloudfoundry.org
lattice configures diego to use a configurable port check. if you don't map a route (cf push --no-route) then the port check should be turned off.

there are stories in the garden tracker that enables running as other users like this one that is in-flight: https://www.pivotaltracker.com/story/show/91955652

in lattice, you can get around the user issue with the --run-as-root command, but that's not exposed in cf / diego integration. the arbitrary user work should close many gaps here.

--
You received this message because you are subscribed to the Google Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/384e6205-4d8b-444a-9c57-14f43d97e859%40cloudfoundry.org.

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.
Reply all
Reply to author
Forward
0 new messages