1. Cf-Dev
  2. Messages

Expanded

Topics Messages
   Date   
Re: Droplets and Stacks

Guillaume Berche
 

Thanks Dieu for your response and for considering these use-cases!

When updating a system buildpack, only the "updated_at" field changes and
no other versionning info is available. I therefore understand that the
"updated_at" field plays the role of the "sequence number" for updates and
the suggestion for an explicit sequence number integer is not currently
considered. While the updated_at field is generic to all CC entities, and
makes it appealing for filtering, I feel that dates are heavier and more
error prone for querying than integer sequence numbers.

Besides, as buildpacks updates have security implications, would'nt it make
sense to expose "buildpack events" when they are created/updated/deleted
including the regular actor, actee information (just like other system-wide
entities such as service brokers or service plans) ?

Last, would'nt it make sense to have the buildpack staging life cycle to
invoke the buildpack "detect" script and record its output even when the -b
option is specified in "cf push" command ? This way the detailed buildpack
internal versionning information returned in STDOUT would be available and
displayed with "cf app" command regardless of whether -b option was used to
constraint use of specific buildpack.

ps: Dieu, Mike, I'm not sure whether buildpack life cycle features now fall
into the CAPI team or the buildpacks team (which tracker should I watch
stories related to this discussion ?).

Thanks again,

Guillaume.


Initial buildpack uploading:
$ cf create-buildpack gbe-static-bp-test ./binary-bp1.zip 20
$ Cf_TRACE=true cf buildpacks
[...]
{
"metadata": {
"guid": "0b173bea-6b1b-4ec5-b1de-e8911c3d7cc4",
"url": "/v2/buildpacks/0b173bea-6b1b-4ec5-b1de-e8911c3d7cc4",
"created_at": "2015-10-27T17:46:49Z",
"updated_at": "2015-10-27T17:46:50Z"
},
"entity": {
"name": "gbe-static-bp-test",
"position": 13,
"enabled": true,
"locked": false,
"filename": "binary-bp1.zip"
}
}

Buildpack update:

$ cf update-buildpack gbe-static-bp-test -p ./binary-bp2.zip -i 20
$ Cf_TRACE=true cf buildpacks
[...]

{
"metadata": {
"guid": "0b173bea-6b1b-4ec5-b1de-e8911c3d7cc4",
"url": "/v2/buildpacks/0b173bea-6b1b-4ec5-b1de-e8911c3d7cc4",
"created_at": "2015-10-27T17:46:49Z",
"updated_at": "2015-10-27T17:48:28Z"
},
"entity": {
"name": "gbe-static-bp-test",
"position": 13,
"enabled": true,
"locked": false,
"filename": "binary-bp2.zip"
}
}

On Tue, Oct 27, 2015 at 10:13 AM, Dieu Cao <dcao(a)pivotal.io> wrote:

Hi Guillaume,

We could consider exposing on a droplet [1] the additional metadata that
you've mentioned, such as the buildpack guid for a system buildpack or the
git sha given a buildpack url.

I think it would make sense to consider adding an additional filter to
/v3/droplets to be able to query by creation date. Similarly, allowing
filters based on buildpack information sounds useful as well.

-Dieu



[1]
http://apidocs.cloudfoundry.org/222/droplets_(experimental)/get_a_droplet.html
[2]
http://apidocs.cloudfoundry.org/222/droplets_(experimental)/list_all_droplets.html


On Sun, Oct 25, 2015 at 2:40 PM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Thanks Mike for the additional details. Long due PR on buildpacks-docs at
[1]

Dieu, can you please comment on the suggestion above for more fine
grained buildpack versionning support ?

Thanks,

Guillaume.

[1] https://github.com/cloudfoundry/docs-buildpacks/pull/39

On Thu, Aug 6, 2015 at 8:02 PM, Mike Dalessio <mdalessio(a)pivotal.io>
wrote:





The /v2/buildpacks endpoint (used by the "cf buildpacks" command)
displays the last update date for a buildpack, e.g.

{
"metadata": {
"guid": "e000b78c-c898-419e-843c-2fd64175527e",
"url": "/v2/buildpacks/e000b78c-c898-419e-843c-2fd64175527e",
"created_at": "2014-04-08T22:05:34Z",
"updated_at": "2015-07-08T23:26:42Z"
},
"entity": {
"name": "java_buildpack",
"position": 3,
"enabled": true,
"locked": false,
"filename": "java-buildpack-v3.1.zip"
}
}

Would'nt it make sense to have the CC increment a version number for
each update so that it becomes easier to query than only relying on dates
comparison ?

While it's great to have buildpacks provide themselves detailed
versionning info for their code and their most important
dependencies/remote artifacts, I feel the cf platform should provide a bit
more support to help identify versions of buildpacks used by apps, such as:
- refine the app summary endpoint [g2]:
- for system buildpacks: include the buildpack guid (in addition to
the buildpack name) as to allow correlation to /v2/buildpacks endpoint
- for custom buildpacks (url): record and display the git hash
commit for a buildpack url
- refine the app listing endpoints [g4] or v3 [g5] to
- support querying app per system buildpack id
- support querying app by dates of "package_updated_at" or best a
version number as suggested above

I'm wondering whether the CAPI team working on API V3 is planning some
work in this area, and could comment the suggestions above.
I'll let Dieu respond to these suggestions, as she's the CAPI PM.

attachment.html

attachment.html

Re: When will dea be replaced by diego?

Amit Kumar Gupta
 

That's strange, just followed it, worked for me. You can search the
mailing list for the subject "Cloud Foundry DEA to Diego switch - when?"

On Tue, Oct 27, 2015 at 1:35 AM, Aleksey Zalesov <
aleksey.zalesov(a)altoros.com> wrote:

Hi Amit,

the link is broken.

Alex Zalesov

attachment.html

attachment.html

Ability to move a space between orgs

Mike Youngstrom <youngm@...>
 

We occasionally need to move spaces between orgs when our business
reorganizes. It would be great if we could atomically move spaces between
orgs.

It seems not difficult but when you look deeper things get stickier:
* Private Domains are owned by orgs
* Service access may be different between orgs
* New Organization scoped brokers may cause issues.

Thoughts on supporting moving a space between orgs? Could perhaps error
out if an issue like the ones above is detected?

Mike

attachment.html

attachment.html

Re: how does hm9000 actually determine application health?

Jesse T. Alford
 

If the app doesn't have a bound route, it's not health checked on DEAs. If
it fails without actually exiting, the system won't notice.

(On Diego, the health check has to be explicitly disabled.)

On Tue, Oct 27, 2015, 8:12 AM Eric Poelke <epoelke(a)gmail.com> wrote:

Thanks guys. So I thought that I had come across the bit of its healthy
if its listening on $PORT, but that got me thinking about the small worker
process I just deployed. Since it does not listen on a port is it just
assumed to be "ok"?

attachment.html

attachment.html

[abacus] Port numbers we use in local test environments

Jean-Sebastien Delfino
 

Hi all,

In preparation for our final 0.0.2 rc, I've started to look into setting up
local test environments with multiple instances of each Abacus app. I found
that we don't have a documented list of the port numbers we use for testing
each app locally outside of CF, and that the configuration of these ports
is distributed in multiple files and scripts, making it a bit difficult to
manage.

So, I'm planning to clean that up sometime today, hoping to make it easier
to configure test environments with multiple instances. As a heads up, I'm
probably going to reassign some of the test ports we use, but will keep the
ports for usage submission and reporting (our public APIs) unchanged to not
break the folks that may be testing with them.

I'm also going to add that list of default test ports to a doc/ports.md
file.

HTH

- Jean-Sebastien

attachment.html

attachment.html

Re: how does hm9000 actually determine application health?

Eric Poelke
 

Thanks guys. So I thought that I had come across the bit of its healthy if its listening on $PORT, but that got me thinking about the small worker process I just deployed. Since it does not listen on a port is it just assumed to be "ok"?
Re: How to get a new UAA guid by REST

Juan Antonio Breña Moral <bren at juanantonio.info...>
 

Re: Diego and Maven support

Daniel Mikusa
 

Krzysztof,

Passed some of this information along to engineering and they've got a
story to investigate this more.

https://www.pivotaltracker.com/story/show/106702544

From what I saw with some additional tests, this 503 error is not going to
prevent your app from deploying. It happens after the app has been
deployed, when the plugin is trying to monitor the progress of your app
while it stages and starts. The 503 will make Maven fail, but if you
ignore that and wait a bit you should see that the app stages and starts
successfully.

If it doesn't start, you could be hitting a different issue or there could
be some other problem with the app. You could try troubleshooting that by
using `cf` to push the app and by running `cf logs` in one terminal and
`mvn cf:push` from a second, which would let you see the full staging and
start up logs. Perhaps something in there would indicate the problem.

Dan

On Mon, Oct 26, 2015 at 10:23 AM, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:

Krzysztof,

Thanks for the follow up. I pushed a test app and I'm seeing the same
"503 Service Unavailable" from Maven. Is that what you're seeing?

Dan

On Sun, Oct 25, 2015 at 4:32 PM, Krzysztof Wilk <chris.m.wilk(a)gmail.com>
wrote:

Dan,

It seems to me that there is more than one cause of this problem.

I have done the following:
1. upgraded cf CLI from 6.12 to 6.13
2.cf set-health-check MY_APP_NAME none
3. set <healthCheckTimeout>180</healthCheckTimeout> (pom.xml)
4. removed env variables in order to allow Maven to set them again

Still no luck.

However, I have read that there is intensive development of Maven client
plugin 2.x happening now. I will give it a try as soon as first release is
available.

Best,
Krzysztof

attachment.html

attachment.html

Multiple ldap backend in UAA

Jakub Witkowski
 

I would like to create configuration that will work with more than one LDAP backend for users authentication.
I've read some Java code of UAA but it's not clear for my if configuration describe below is possible.

My configuration have users split over two AD domains controller. Desired configuration have only one UAA endpoints.
I don't want setup two UUA server or use multitenant configuration in UAA.
Desired configuration have one UAA server with database MariaDB as primary profile and multiple LDAP backends only user for authentication.
Mariadb will have all groups and there shouldn't be be any LDAP mappings between and UAA (but if it possible it would quite nice to create some kind of hybrid)

best regards
j.witkowski
Re: How to get a new UAA guid by REST

Juan Antonio Breña Moral <bren at juanantonio.info...>
 

Hi,

many thanks, Aleksey.

Now, I can create and get users from uaa.
https://github.com/cloudfoundry/uaa/issues/249

Now I am going to use guid-uaa to a create an users in CC API.
Re: How to get a new UAA guid by REST

Aleksey Zalesov
 

You should use GET request instead of POST. See this topic:

https://github.com/cloudfoundry/uaa/blob/master/docs/UAA-APIs.rst#query-for-information-get-users

Alex Zalesov
Re: json data and the cli

Matthew Sykes <matthew.sykes@...>
 

Given the scope and cross cutting nature of the issue, I think it's
something better handled by the CLI team via prioritized stories. Speaking
from experience, large PRs and PRs that involve refactors tend to be
painful for all involved.

If you'd like, I can raise an issue in GH. If you want a PR to simply add
yaml support to cups (which is what's most painful for me), I can probably
do that.

On Tue, Oct 27, 2015 at 2:32 AM, Koper, Dies <diesk(a)fast.au.fujitsu.com>
wrote:

Hi Matthew,



The commands you listed were developed over a span of several years, and
their options have evolved.

There is no technical reason for the missing options not to be added now
and implemented reusing each other’s code.

I think it’s mostly because there haven’t been enough user requests so it
hasn’t been prioritised.



PEM credentials for a user provided service is a good example of a use
case that’s not well catered for with the current specification.

Please let us know if you’d like to submit a PR to address this!



Regards,

Dies Koper

PM Dojo’er CLI team





*From:* Matthew Sykes [mailto:matthew.sykes(a)gmail.com]
*Sent:* Monday, October 26, 2015 12:00 PM
*To:* Discussions about Cloud Foundry projects and the system overall.
*Subject:* [cf-dev] json data and the cli



There are a number of places in the cli where a user needs to provide a
json payload to the cli. For example:



create-service/update-service

bind-service

create-service-keys

create-security-group/update-security-group



Depending on the command, the user can provide list of keys to be prompted
for, inline json, a pointer to a file containing json, or some
indeterminate combination of those options. That list bit is the problem -
there's no consistency across all of these commands.



Is there a reason why all of these commands can't use the same basic
infrastructure in the cli to provide a consistent behavior?



Also, when dealing with json data that contains new lines, it's very
painful for a human. (Think PEM encoded certificate chains as credentials
in a user provided service.) Given yaml is a superset of json, is there a
reason why we shouldn't or can't support yaml in the file representation of
the data?



Thanks.



--

Matthew Sykes
matthew.sykes(a)gmail.com


--
Matthew Sykes
matthew.sykes(a)gmail.com

attachment.html

attachment.html

Re: How to get a new UAA guid by REST

Juan Antonio Breña Moral <bren at juanantonio.info...>
 

Hi I could retrieve the uses but using your clue, I receive the following error:

Error: the string "{\"message\":\"Content type 'application/octet-stream' n
ot supported\",\"error\":\"scim\"}" was thrown, throw an Error :)

I think that my code is OK using the info from Github, but I suppose that I need some additional stuff:

https://github.com/cloudfoundry/uaa/blob/master/docs/UAA-APIs.rst#create-a-user-post-users

Users.prototype.add = function (token_type, access_token) {
"use strict";

var url = this.UAA_API_URL + "/Users";

console.log(url);
var options = {
method: 'POST',
url: url,
headers: {
Accept: 'application/json',
Authorization: token_type + ' ' + access_token
}
};

return this.REST.request(options, "200", false);
};

Do you have if I need some additional parameter?

I add the user in UAA to retrieve the guid-uaa and after use this call:
http://apidocs.cloudfoundry.org/222/users/creating_a_user.html

Juan Antonio
Re: Droplets and Stacks

Dieu Cao <dcao@...>
 

Hi Guillaume,

We could consider exposing on a droplet [1] the additional metadata that
you've mentioned, such as the buildpack guid for a system buildpack or the
git sha given a buildpack url.

I think it would make sense to consider adding an additional filter to
/v3/droplets to be able to query by creation date. Similarly, allowing
filters based on buildpack information sounds useful as well.

-Dieu



[1]
http://apidocs.cloudfoundry.org/222/droplets_(experimental)/get_a_droplet.html
[2]
http://apidocs.cloudfoundry.org/222/droplets_(experimental)/list_all_droplets.html

On Sun, Oct 25, 2015 at 2:40 PM, Guillaume Berche <bercheg(a)gmail.com> wrote:

Thanks Mike for the additional details. Long due PR on buildpacks-docs at
[1]

Dieu, can you please comment on the suggestion above for more fine grained
buildpack versionning support ?

Thanks,

Guillaume.

[1] https://github.com/cloudfoundry/docs-buildpacks/pull/39

On Thu, Aug 6, 2015 at 8:02 PM, Mike Dalessio <mdalessio(a)pivotal.io>
wrote:





The /v2/buildpacks endpoint (used by the "cf buildpacks" command)
displays the last update date for a buildpack, e.g.

{
"metadata": {
"guid": "e000b78c-c898-419e-843c-2fd64175527e",
"url": "/v2/buildpacks/e000b78c-c898-419e-843c-2fd64175527e",
"created_at": "2014-04-08T22:05:34Z",
"updated_at": "2015-07-08T23:26:42Z"
},
"entity": {
"name": "java_buildpack",
"position": 3,
"enabled": true,
"locked": false,
"filename": "java-buildpack-v3.1.zip"
}
}

Would'nt it make sense to have the CC increment a version number for
each update so that it becomes easier to query than only relying on dates
comparison ?

While it's great to have buildpacks provide themselves detailed
versionning info for their code and their most important
dependencies/remote artifacts, I feel the cf platform should provide a bit
more support to help identify versions of buildpacks used by apps, such as:
- refine the app summary endpoint [g2]:
- for system buildpacks: include the buildpack guid (in addition to
the buildpack name) as to allow correlation to /v2/buildpacks endpoint
- for custom buildpacks (url): record and display the git hash
commit for a buildpack url
- refine the app listing endpoints [g4] or v3 [g5] to
- support querying app per system buildpack id
- support querying app by dates of "package_updated_at" or best a
version number as suggested above

I'm wondering whether the CAPI team working on API V3 is planning some
work in this area, and could comment the suggestions above.
I'll let Dieu respond to these suggestions, as she's the CAPI PM.

attachment.html

attachment.html

Re: how does hm9000 actually determine application health?

Alexander Lomov <alexander.lomov@...>
 

You can take a look on this article https://blog.starkandwayne.com/2014/12/17/introduction-to-cloud-foundrys-health-monitor/

On Oct 24, 2015, at 1:41 AM, Eric Poelke <epoelke(a)gmail.com<mailto:epoelke(a)gmail.com>> wrote:

Can anyone tell me or point me to some documentation about how hm9k actually determines application health?

attachment.html

attachment.html

Re: How to get a new UAA guid by REST

Juan Antonio Breña Moral <bren at juanantonio.info...>
 

Hi Aleksey,

do you know where is the documentation for UAA REST API?
For CC API is this address:
http://apidocs.cloudfoundry.org/222/

Juan Antonio
Re: how does hm9000 actually determine application health?

Aleksey Zalesov
 

Short answer is app is healthy when it listens to $PORT. I think this check is done by DEA, though.

HM9000 listens to NATs for actual state and polls CC to grab desired state. Than it compares both states and issues start/stop commands through the NATs.

Alex Zalesov
Re: When will dea be replaced by diego?

Aleksey Zalesov
 

Hi Amit,

the link is broken.

Alex Zalesov
Re: mono apps are failed to start in CF

Aleksey Zalesov
 

OK, could you verify that your app works on both stacks in your local instance?

$ cf push app_name -s lucid64
$ cf push app_name -s cflinuxfs2

Alex Zalesov
Re: mono apps are failed to start in CF

Juan Antonio Breña Moral <bren at juanantonio.info...>
 

Using a local instance, the stacks installed are:

mocha test --config=LOCAL_INSTANCE_1
Environment: LOCAL_INSTANCE_1

Cloud foundry Stacks
{ metadata:
{ guid: '8898aa08-0d82-4c0b-9009-5d5989b56a95',
url: '/v2/stacks/8898aa08-0d82-4c0b-9009-5d5989b56a95',
created_at: '2015-07-15T12:32:30Z',
updated_at: null },
entity: { name: 'lucid64', description: 'Ubuntu 10.04 on x86-64' } }
{ metadata:
{ guid: '4dc22bc6-e7f3-4cb5-b1d0-da53723c65df',
url: '/v2/stacks/4dc22bc6-e7f3-4cb5-b1d0-da53723c65df',
created_at: '2015-07-15T12:32:30Z',
updated_at: null },
entity:
{ name: 'cflinuxfs2',
description: 'Cloud Foundry Linux-based filesystem' } }
√ The platform returns Stacks installed (190ms)


1 passing (850ms)

Juan Antonio
6961 - 6980 of 9441