cf-dev@lists.cloudfoundry.org

v3 cc api style guide feedback requested

Dieu Cao <dcao@...>

#1450

Hi All,

The CAPI team has created a style guide for v3 of the cloud controller api
and would like to share this again with the wider cf community for feedback
after initial review within the team. [1]
Issues/PRs are welcome and appreciated!

Thanks,
Dieu
CF CAPI PM

[1] https://github.com/cloudfoundry/cc-api-v3-style-guide

attachment.html

Re: How to set cc.info with cf-release spiff templates ?

Guillaume Berche

#1449

Thanks Joseph for your response. Any chance that the OSS build pipeline
would update the spiff template with the current version number of the cf
release being built, as to avoid each consummers of the release to manually
update version number when updating cc.info.version ? Ideally by having the
spiff templates override the default value (yet-to-be-specified in the
release's spec file, see [3]) by the current cf release number ?

I was trying to manually assign this value with meta.releases[0].version,
but I see that meta.releases[0].version seems to always specify 'latest'
[2]. One possibility would have to specify the current release number (e.g.
'215')

Thanks in advance,

Guillaume.

[2]
https://github.com/cloudfoundry/cf-release/blob/90d730a2d13d9e065a7f348e7fd31a1522074d02/templates/cf-deployment.yml#L10
[3] https://github.com/cloudfoundry/cf-release/issues/774

Show quoted text

On Tue, Sep 1, 2015 at 11:29 PM, CF Runtime <cfruntime(a)gmail.com> wrote:

Unfortunately those properties don't actually do what they say. A story
has been added to the CAPI backlog to clean those up, and possibly change
them: https://www.pivotaltracker.com/story/show/102523218

In the meantime, you can override `version` and `description`, they are
currently used to populate the info endpoint, but they may change in the
process of doing the above story.

After the story is done, we'll add the attributes to the template so they
are easy to override, but for now you'll need to manually edit your
manifest to add the `version` and `description` properties.

Joseph
OSS Release Integration Team

On Thu, Aug 27, 2015 at 1:07 PM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Hi,

I'm trying to assign cc.info.description and cc.info.version [1] (to
merge meta.releases[0].version if cf release version), as to be able to
describe to end users which cf version is currently deployed from a "cf
curl v2/info" command.

I'm however struggling with spiff syntax to do so. I trial-and-errored
around modifying cf-release/templates as to allow for the merge without
luck so far.

Anyone succeeded in doing so without forking standard spiff templates ?

Thanks in advance,

Guillaume.

[1]
https://github.com/cloudfoundry/cf-release/blob/9334295133435fa77767651030500d2b0de62611/jobs/cloud_controller_ng/spec#L140-L145

attachment.html

Re: Which kind of resources stored in cc-resources container?

Matt Reider

#1448

You can refer to this discussion for some understanding of what is stored
in the cc-resources container:

https://groups.google.com/a/cloudfoundry.org/forum/#!topic/vcap-dev/nTQSn8spBPE

It's basically stores larger files to speed up subsequent app push. An
initial push will be slow, as all files are uploaded. A second push will be
faster, as the larger files (over 64k by default, but can be adjusted up),
are stored in the cc-resources container for re-use.

On Tue, Sep 1, 2015 at 6:40 PM Guangcai Wang <guangcai.wang(a)gmail.com>
wrote:

Hi,

I am using Swift as Cloud Foundry blobstore. I noticed there are four
containers:
cc-buildpacks
cc-droplets
cc-packages
cc-resources

For the first three containers, I can find the relationship between the
object in containers and the records in postgres database. I also noticed
that some objects will be stored in cc-resources when I push applications.
They seem related to the type of application (ruby, java, etc). However, I
cannot find what should be stored in cc-resources container. Are they
uploaded automatically by buildpack?  Is it decided by buildpack or
application? How to configure them if it is decided by application?


Thanks.

attachment.html

Re: diego questions: default memory and passing env variables

Amit Kumar Gupta

#1447

Responses inline.

On Tue, Sep 1, 2015 at 7:13 PM, Tom Sherrod <tom.sherrod(a)gmail.com> wrote:

What is the default memory size of an app deployed in diego? cf apps
indicate 1GB.
Yes.  This isn't a diego thing, this is a CC thing.


cf set-env doesn't appear to be getting the environment variable
information to the running container. Is cf set-env the correct method to
use?
You likely need to restage the application for ENV var changes to take
effect.  Unless I'm mistaken, this too is not diego-specific, and applies
to DEA containers as well.


Thanks!
Tom
Best,
Amit

attachment.html

Re: Self-signed cert for registry failing on stager

Tom Sherrod <tom.sherrod@...>

#1446

Thank you. The pointer to the code is excellent. I was looking in the right place. An odd part was I actually added the CA to the machine itself and it still did not work. 
I finally opted for a mirror registry with a public cert. Now working.

diego questions: default memory and passing env variables

Tom Sherrod <tom.sherrod@...>

#1445

What is the default memory size of an app deployed in diego? cf apps indicate 1GB.

cf set-env doesn't appear to be getting the environment variable information to the running container. Is cf set-env the correct method to use?

Thanks!
Tom

Which kind of resources stored in cc-resources container?

iamflying

#1444

Hi,

I am using Swift as Cloud Foundry blobstore. I noticed there are four
containers:
cc-buildpacks
cc-droplets
cc-packages
cc-resources

For the first three containers, I can find the relationship between the
object in containers and the records in postgres database. I also noticed
that some objects will be stored in cc-resources when I push applications.
They seem related to the type of application (ruby, java, etc). However, I
cannot find what should be stored in cc-resources container. Are they
uploaded automatically by buildpack?  Is it decided by buildpack or
application? How to configure them if it is decided by application?


Thanks.

attachment.html

Re: Generic data points for dropsonde

Benjamin Black

#1443

great questions, dwayne.

1) the partition key is intended to be used in a similar manner to
partitioners in distributed systems like cassandra or kafka. the specific
behavior i would like to make part of the contract is two-fold: that all
data with the same key is routed to the same partition and that all data in
a partition is FIFO (meaning no ordering guarantees beyond arrival time).

this could help with the multi-line log problem by ensuring a single
consumer will receive all lines for a given log entry in order, allowing
simple reassembly. however, the lines might be interleaved with other lines
with the same key or even other keys that happen to map to the same
partition, so the consumer does require a bit of intelligence. this was
actually one of the driving scenarios for adding the key.

2) i expect typical points to be in the hundreds of bytes to a few KB. if
we find ourselves regularly needing much larger points, especially near
that 64KB limit, i'd look to the JSON representation as the hierarchical
structure is more efficiently managed there.


b

Show quoted text

On Tue, Sep 1, 2015 at 4:42 PM, <dschultz(a)pivotal.io> wrote:

Hi Ben,

I was wondering if you could give a concrete use case for the partition
key functionality.

In particular I am interested in how we solve multi line log entries. I
think it would be better to solve it by keeping all the data (the multiple
lines) together throughout the logging/metrics pipeline, but could see how
something like a partition key might help keep the data together as well.

Second question: how large do you see these point messages getting
(average and max)? There are still several stages of the logging/metrics
pipeline that use UDP with a standard 64K size limit.

Thanks,
Dwayne

On Aug 28, 2015, at 4:54 PM, Benjamin Black <bblack(a)pivotal.io> wrote:

All,

The existing dropsonde protocol uses a different message type for each
event type. HttpStart, HttpStop, ContainerMetrics, and so on are all
distinct types in the protocol definition. This requires protocol changes
to introduce any new event type, making such changes very expensive. We've
been working for the past few weeks on an addition to the dropsonde
protocol to support easier future extension to new types of events and to
make it easier for users to define their own events.

The document linked below [1] describes a generic data point message
capable of carrying multi-dimensional, multi-metric points as sets of
name/value pairs. This new message is expected to be added as an additional
entry in the existing dropsonde protocol metric type enum. Things are now
at a point where we'd like to get feedback from the community before moving
forward with implementation.

Please contribute your thoughts on the document in whichever way you are
most comfortable: comments on the document, email here, or email directly
to me. If you comment on the document, please make sure you are logged in
so we can keep track of who is asking for what. Your views are not just
appreciated, but critical to the continued health and success of the Cloud
Foundry community. Thank you!


b

[1]
https://docs.google.com/document/d/1SzvT1BjrBPqUw6zfSYYFfaW9vX_dTZZjn5sl2nxB6Bc/edit?usp=sharing

attachment.html

Re: Generic data points for dropsonde

Dwayne

#1442

Hi Ben,

I was wondering if you could give a concrete use case for the partition key functionality.

In particular I am interested in how we solve multi line log entries. I think it would be better to solve it by keeping all the data (the multiple lines) together throughout the logging/metrics pipeline, but could see how something like a partition key might help keep the data together as well.

Second question: how large do you see these point messages getting (average and max)? There are still several stages of the logging/metrics pipeline that use UDP with a standard 64K size limit.

Thanks,
Dwayne

Show quoted text

On Aug 28, 2015, at 4:54 PM, Benjamin Black <bblack(a)pivotal.io> wrote:

All,

The existing dropsonde protocol uses a different message type for each event type. HttpStart, HttpStop, ContainerMetrics, and so on are all distinct types in the protocol definition. This requires protocol changes to introduce any new event type, making such changes very expensive. We've been working for the past few weeks on an addition to the dropsonde protocol to support easier future extension to new types of events and to make it easier for users to define their own events. 

The document linked below [1] describes a generic data point message capable of carrying multi-dimensional, multi-metric points as sets of name/value pairs. This new message is expected to be added as an additional entry in the existing dropsonde protocol metric type enum. Things are now at a point where we'd like to get feedback from the community before moving forward with implementation.

Please contribute your thoughts on the document in whichever way you are most comfortable: comments on the document, email here, or email directly to me. If you comment on the document, please make sure you are logged in so we can keep track of who is asking for what. Your views are not just appreciated, but critical to the continued health and success of the Cloud Foundry community. Thank you!

b

[1] https://docs.google.com/document/d/1SzvT1BjrBPqUw6zfSYYFfaW9vX_dTZZjn5sl2nxB6Bc/edit?usp=sharing

attachment.html

Re: How to set cc.info with cf-release spiff templates ?

CF Runtime

#1441

Unfortunately those properties don't actually do what they say. A story has
been added to the CAPI backlog to clean those up, and possibly change them:
https://www.pivotaltracker.com/story/show/102523218

In the meantime, you can override `version` and `description`, they are
currently used to populate the info endpoint, but they may change in the
process of doing the above story.

After the story is done, we'll add the attributes to the template so they
are easy to override, but for now you'll need to manually edit your
manifest to add the `version` and `description` properties.

Joseph
OSS Release Integration Team

Show quoted text

On Thu, Aug 27, 2015 at 1:07 PM, Guillaume Berche <bercheg(a)gmail.com> wrote:

Hi,

I'm trying to assign cc.info.description and cc.info.version [1] (to merge
meta.releases[0].version if cf release version), as to be able to describe
to end users which cf version is currently deployed from a "cf curl
v2/info" command.

I'm however struggling with spiff syntax to do so. I trial-and-errored
around modifying cf-release/templates as to allow for the merge without
luck so far.

Anyone succeeded in doing so without forking standard spiff templates ?

Thanks in advance,

Guillaume.

[1]
https://github.com/cloudfoundry/cf-release/blob/9334295133435fa77767651030500d2b0de62611/jobs/cloud_controller_ng/spec#L140-L145

attachment.html

Singapore Company Offer

Kia Group - Miss Vicky <gegew@...>

#1440

hello!
  启就少辛苦一点。就要走的前亚集活，你安心地读书吧”爷爷团推出特中午回来把一早上的柴和草价高考结束了，晓多也就回到优们不知道晓多在做什么，因惠:
  英的重任。王晓多是村中唯一国解，因为他有梦，一个支持公结束了，晓多比平时更加努司有一丝的暖意，晓多如果手年北方向敞开着，所以交通不审村是流水镇最穷的村子，村特煤油灯亮着，由于舍不得花惠记录下来，在课后自己练习价。没事，爷爷奶奶还能干活格1980因为家庭经济原因，很多原元
  提供英国公司名即可完成年审；
  年审内容：年审回执+休眠公司财务年报+法定秘书服务（地址，电话，传真等）
  支付宝担保交易，有保障；
  顺丰快递年审文件，快捷安全！
  超过10年的专业服务，最优惠的价格！
  联系，整个屋子没有一丝的暖意人: 肖，整个屋子里很暗，只有窗小姐，Q屋走来，望着晓多。奶奶，Q: 26253了，晓多也就回到了家里，82482, Email：admin@kiya得如此，不时有几只蝙蝠飞group.com，Mobile: 136514北方向敞开着，所以交通不64499

  UK company Annual Audit,preferential price ￥1980
  Only need to provide UK company name to finish Annual Audit.
  Service list: Annual Return+Dormant Account Report+Secretarial services( Registation address, telephone,fax)
  Over 10 years of professional service, preferential price!
  Miss Vicky，QQ: 2625382482,Email：admin@...，Mobile: 13651464499

Re: Update Dashboard URL with Asynchronous Provisioning

Dieu Cao <dcao@...>

#1439

Hi John,

I added a story for the upgrade use case [1].

I believe the use case of needing to move the dashboard_url end point that
does not correspond to a service lifecycle event is trickier and is tracked
as part of your github issue [2].  The matching tracker story hadn't been
carried over to the CAPI backlog in the team merge, so it's now back in the
CAPI icebox under consideration.

-Dieu
CF CAPI PM

[1] https://www.pivotaltracker.com/story/show/102485224
[2] https://www.pivotaltracker.com/story/show/94657436

On Thu, Aug 27, 2015 at 11:06 AM, john mcteague <john.mcteague(a)gmail.com>
wrote:

There are additional use cases should also be considered.

First, if I upgrade a service, that may come with a new management console
on a different url, I would want this to be reflected.

Additionally, all service instances for a given service  may share a
single dashboard, but again, at some point we may need to move the
dashboards endpoint (which may or may not correspond to another service
life cycle event).

John
On 27 Aug 2015 01:03, "shannon" <scoen(a)pivotal.io> wrote:

Hello Robert,

Unfortunately, your use use case is not currently supported. dashboard_url
is only supported in the initial response from the broker, even though the
service instance may be asynchronously provisioned. The only workaround I
can think of is to predict the url, though it may not be initially
accessible.

I recognize this as a valid use case, and have asked Dieu (PM for CAPI,
now
responsible for the broker API) to consider it for prioritization.

I suggest that we enhance the response to
/v2/service_instances/:guid/last_operation so that when
"state":"succeeded"
a header is returned that links to a new endpoint GET
/v2/service_instances/:guid. This endpoint could expose a value for
dashboard_url that wasn't returned in the initial response.

Best,
Shannon



--
View this message in context:
http://cf-dev.70369.x6.nabble.com/cf-dev-Update-Dashboard-URL-with-Asynchronous-Provisioning-tp1313p1377.html
Sent from the CF Dev mailing list archive at Nabble.com.

attachment.html

Re: Announcing Experimental support for Asynchronous Service Operations

Dieu Cao <dcao@...>

#1438

Hi Guillaume,

We are looking for a couple more pieces of feedback.  All feedback I've
received so far has been positive.

There was one report recently from Robert Moss about being able to provide
the dashboard_url asynchronously instead of part of the original response
[1].
I'm also considering whether that needs to be addressed prior to marking
the feature complete, or if it should be a separate/additive change to the
service broker api.

If you've had success with the current implementation, I would be greatly
interested in hearing that.

-Dieu

[1]
https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/thread/LJ26K22WG7OJCAIXWYPTJQKELVAUBUZC/

Show quoted text

On Tue, Sep 1, 2015 at 5:20 AM, Guillaume Berche <bercheg(a)gmail.com> wrote:

Hi,

I'm wondering whether the experimental async service broker api is now
ready to become official, or whether the CAPI team and PMs are still
lacking feedback or have some outstanding issues that need to be addressed
before calling the spec official? I was not able to spot any async-related
stories in the CAPI backlog [1]

We have a pending PR in cf-java-client [2] which is waiting for the async
broker spec to be made official.

Thanks in advance,

Guillaume.

[1] https://www.pivotaltracker.com/n/projects/966314
[2]
https://github.com/cloudfoundry/cf-java-client/pull/282#issuecomment-115874984

On Fri, Jun 5, 2015 at 9:21 AM, James Bayer <jbayer(a)pivotal.io> wrote:

i'm very happy to see this work delivered as the 60 second limit has come
up so often as a pain point in the past. great job to all who contributed!

On Wed, Jun 3, 2015 at 5:05 PM, Onsi Fakhouri <ofakhouri(a)pivotal.io>
wrote:

Well done Services API!  This is an awesome milestone!

On Wed, Jun 3, 2015 at 5:04 PM, Chip Childers <
cchilders(a)cloudfoundry.org> wrote:

Awesome news! Long time coming, and it opens up a whole world of
additional capabilities for users.

Nice work everyone!



On Jun 4, 2015, at 9:00 AM, Shannon Coen <scoen(a)pivotal.io> wrote:

On behalf of the Services API team, including Dojo participants from
IBM and SAP, I'm pleased to announce experimental availability and
published documentation for this much-anticipated feature.

As of cf-release v208 and CLI v6.11.1, Cloud Foundry now supports an
enhanced service broker integration in support of long-running
provisioning, update, and delete operations. This significantly broadens
the supported use cases for Cloud Foundry Marketplace Services, and I can't
wait to hear what creative things the ecosystem does with it. Provision
VMs, orchestrate clusters, install software, move data... yes, your broker
can even open support tickets to have those things done manually!

This feature is currently considered experimental, as we'd like you all
to review our docs, try out the feature, and give us feedback. We very
interested to hear about any confusion in the docs or the UX, and any
sticky issues you encounter in implementation. Our goal is for our docs
enable a painless, intuitive (can we hope for joyful?) implementation
experience.

We have not bumped the broker API yet for this feature. You'll notice
that our documentation for the feature is separate from the stable API docs
at this point. Once we're confident in the design (we're relying on your
feedback!), we'll bump the broker API version, move the docs for
asynchronous operations into the stable docs, AND implement support for
asynchronous bind/create-key and unbind/delete-key.

Documentation:
- http://docs.cloudfoundry.org/services/asynchronous-operations.html
- http://docs.cloudfoundry.org/services/api.html
Example broker for AWS (contributed by IBM):
- http://docs.cloudfoundry.org/services/examples.html
- https://github.com/cloudfoundry-samples/go_service_broker
Demo of the feature presented at CF Summit 2015:
- https://youtu.be/Ij5KSKrAq9Q

tl;dr

Cloud Foundry expects broker responses within 60 seconds. Now a broker
can return an immediate response indicating that a provision, update, or
delete operation is in progress. Cloud Foundry then returns a similar
response to the client, and begins polling the broker for the status of the
operation. Users, via API clients, can discover the status of the operation
("in progress", "succeeded", or "failed"), and brokers can provide
user-facing messages in response to each poll which are exposed to users
(e.g. "VMs provisioned, installing software, 30% complete").

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

attachment.html

Re: Announcing Experimental support for Asynchronous Service Operations

Guillaume Berche

#1437

Hi,

I'm wondering whether the experimental async service broker api is now
ready to become official, or whether the CAPI team and PMs are still
lacking feedback or have some outstanding issues that need to be addressed
before calling the spec official? I was not able to spot any async-related
stories in the CAPI backlog [1]

We have a pending PR in cf-java-client [2] which is waiting for the async
broker spec to be made official.

Thanks in advance,

Guillaume.

[1] https://www.pivotaltracker.com/n/projects/966314
[2]
https://github.com/cloudfoundry/cf-java-client/pull/282#issuecomment-115874984

Show quoted text

On Fri, Jun 5, 2015 at 9:21 AM, James Bayer <jbayer(a)pivotal.io> wrote:

i'm very happy to see this work delivered as the 60 second limit has come
up so often as a pain point in the past. great job to all who contributed!

On Wed, Jun 3, 2015 at 5:05 PM, Onsi Fakhouri <ofakhouri(a)pivotal.io>
wrote:

Well done Services API!  This is an awesome milestone!

On Wed, Jun 3, 2015 at 5:04 PM, Chip Childers <cchilders(a)cloudfoundry.org
wrote:Awesome news! Long time coming, and it opens up a whole world of
additional capabilities for users.

Nice work everyone!



On Jun 4, 2015, at 9:00 AM, Shannon Coen <scoen(a)pivotal.io> wrote:

On behalf of the Services API team, including Dojo participants from IBM
and SAP, I'm pleased to announce experimental availability and published
documentation for this much-anticipated feature.

As of cf-release v208 and CLI v6.11.1, Cloud Foundry now supports an
enhanced service broker integration in support of long-running
provisioning, update, and delete operations. This significantly broadens
the supported use cases for Cloud Foundry Marketplace Services, and I can't
wait to hear what creative things the ecosystem does with it. Provision
VMs, orchestrate clusters, install software, move data... yes, your broker
can even open support tickets to have those things done manually!

This feature is currently considered experimental, as we'd like you all
to review our docs, try out the feature, and give us feedback. We very
interested to hear about any confusion in the docs or the UX, and any
sticky issues you encounter in implementation. Our goal is for our docs
enable a painless, intuitive (can we hope for joyful?) implementation
experience.

We have not bumped the broker API yet for this feature. You'll notice
that our documentation for the feature is separate from the stable API docs
at this point. Once we're confident in the design (we're relying on your
feedback!), we'll bump the broker API version, move the docs for
asynchronous operations into the stable docs, AND implement support for
asynchronous bind/create-key and unbind/delete-key.

Documentation:
- http://docs.cloudfoundry.org/services/asynchronous-operations.html
- http://docs.cloudfoundry.org/services/api.html
Example broker for AWS (contributed by IBM):
- http://docs.cloudfoundry.org/services/examples.html
- https://github.com/cloudfoundry-samples/go_service_broker
Demo of the feature presented at CF Summit 2015:
- https://youtu.be/Ij5KSKrAq9Q

tl;dr

Cloud Foundry expects broker responses within 60 seconds. Now a broker
can return an immediate response indicating that a provision, update, or
delete operation is in progress. Cloud Foundry then returns a similar
response to the client, and begins polling the broker for the status of the
operation. Users, via API clients, can discover the status of the operation
("in progress", "succeeded", or "failed"), and brokers can provide
user-facing messages in response to each poll which are exposed to users
(e.g. "VMs provisioned, installing software, 30% complete").

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

attachment.html

Re: Self-signed cert for registry failing on stager

Will Pragnell <wpragnell@...>

#1436

On the stager, the stager process is running with -insecureDockerRegistry-logLevel=info. Shouldn't theregistryname also be in stager arguments?

No, that flag is simply a boolean switch [1].

The error:2015-08-27T18:43:00.50-0400 [STG/0]      ERR builder exited with error:
failed to fetch metadata from [theregistryname/tom/diegotest] with tag
[latest] and insecure registries [] due to Invalid registry endpoint
https://theregistryname/v1/: Gethttps://theregistryname/v1/_ping: x509:
certificate signed by unknown authority. If this private registry supports
only HTTP or HTTPS with an unknown CA certificate, please add
`--insecure-registry theregistryname` to the daemon's arguments. In the
case of HTTPS, if you have access to the registry's CA certificate, no need
for the flag; simply place the CA certificate at /etc/docker/certs.d/
theregistryname/ca.crt

This message comes from `docker_app_lifecycle` [2]. It looks like that's
called by the stager, but for some reason the stager isn't passing the
right args through to it in your case. I'm afraid I don't know the Diego
code well enough to speculate as to why, but if you want to continue
tracing it through, you might want to start at [3], which is where the
stager works out what args it will pass to `docker_app_lifecycle`.

Hope that helps!

[1]:
https://github.com/cloudfoundry-incubator/stager/blob/master/cmd/stager/main.go#L82
[2]: https://github.com/cloudfoundry-incubator/docker_app_lifecycle
[3]:
https://github.com/cloudfoundry-incubator/stager/blob/master/backend/docker_backend.go#L321

On 28 August 2015 at 03:46, James Bayer <jbayer(a)pivotal.io> wrote:

perhaps see if the lattice instructions for private registries have any
hints for you: http://lattice.cf/docs/private-docker-registry/

On Thu, Aug 27, 2015 at 4:50 PM, Tom Sherrod <tom.sherrod(a)gmail.com>
wrote:

Successfully deployed from a registry with a public cert.
A registry with a private/self-signed cert fails at the stager.
I've got the name of the registry in insecure_docker_registry_list and
insecure_docker_registry: true in the manifest.
On the cell, the garden-linux process is running with
-insecureDockerRegistryList=theregistryname.
On the stager, the stager process is running with -insecureDockerRegistry
-logLevel=info
Shouldn't theregistryname also be in stager arguments?

The error:
2015-08-27T18:43:00.50-0400 [STG/0]      ERR builder exited with error:
failed to fetch metadata from [theregistryname/tom/diegotest] with tag
[latest] and insecure registries [] due to Invalid registry endpoint
https://theregistryname/v1/: Get https://theregistryname/v1/_ping: x509:
certificate signed by unknown authority. If this private registry supports
only HTTP or HTTPS with an unknown CA certificate, please add
`--insecure-registry theregistryname` to the daemon's arguments. In the
case of HTTPS, if you have access to the registry's CA certificate, no need
for the flag; simply place the CA certificate at
/etc/docker/certs.d/theregistryname/ca.crt

(change the hostname to "theregistryname" in this message...the real
hostname can be resolved and reached on each machine)


--
Thank you,

James Bayer

attachment.html

Re: Can't push app due to expired certificate

Christopher B Ferris <chrisfer@...>

#1435

Thanks for the quick response, guys!

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Cloud
IBM Software Group, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: http://thoughtsoncloud.com/index.php/author/cferris/
phone: +1 508 667 0402

Show quoted text

----- Original message -----
From: James Bayer <jbayer@...>
To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev@...>
Cc:
Subject: [cf-dev] Re: Re: Re: Can't push app due to expired certificate
Date: Mon, Aug 31, 2015 12:02 PM

i was just able to use the online version of the buildpack again after the new cert started propagating.

thanks to all who helped report and work on this so quickly!

we're going to do a post-mortem on the issue to see why the certification expiration was missed.

On Mon, Aug 31, 2015 at 8:33 AM, Kei YAMAZAKI <daydream.yamazaki@...> wrote:
Disable ssl verification workaround works.
https://github.com/kei-yamazaki/java-buildpack/commit/6b0551ce62f3be3b60e687775554f6f5b126cd0c

It can push with -b option.
cf push <APP-NAME> -b https://github.com/kei-yamazaki/java-buildpack.git\#disable-ssl-verification

--
Thank you,

James Bayer

Re: Can't push app due to expired certificate

Aleksey Zalesov

#1434

Thank you guys for fixing this issue!

I am able to push java apps again.

--
View this message in context: http://cf-dev.70369.x6.nabble.com/Can-t-push-app-due-to-expired-certificate-tp1404p1415.html
Sent from the CF Dev mailing list archive at Nabble.com.

Re: Can't push app due to expired certificate

James Bayer

#1433

i was just able to use the online version of the buildpack again after the
new cert started propagating.

thanks to all who helped report and work on this so quickly!

we're going to do a post-mortem on the issue to see why the certification
expiration was missed.

On Mon, Aug 31, 2015 at 8:33 AM, Kei YAMAZAKI <daydream.yamazaki(a)gmail.com>
wrote:

Disable ssl verification workaround works.

https://github.com/kei-yamazaki/java-buildpack/commit/6b0551ce62f3be3b60e687775554f6f5b126cd0c

It can push with -b option.
cf push <APP-NAME> -b
https://github.com/kei-yamazaki/java-buildpack.git\#disable-ssl-verification


-- 
Thank you,

James Bayer

attachment.html

Re: Can't push app due to expired certificate

Mike Dalessio

#1432

Hi all,

A new cert has been pushed, and it looks like this issue is resolved.
Please let me know if you're still experiencing SSL issues when downloading
java-buildpack artifacts.


On Mon, Aug 31, 2015 at 11:29 AM, Mike Dalessio <mdalessio(a)pivotal.io>
wrote:

Hi all,

Just an update: This affects:

* users of the "online" a.k.a. "uncached" java-buildpack,
* users of the "online/uncached" ruby-buildpack 1.5.0 and later who haved
opted-in to JRuby.

We're currently waiting for a new cert to be installed.

I'll obviously follow up with the java-buildpack team to make sure all the
buildpacks are using the same domain for downloading artifacts.


On Mon, Aug 31, 2015 at 10:33 AM, Daniel Mikusa <dmikusa(a)pivotal.io>
wrote:

I've reported this and we're working on it.

For what it's worth, this should only affect the Java build pack.  I
don't believe the other ones are using that URL.  If you're seeing the
message with other build packs, it might be because you aren't setting a
specific build pack for your app (i.e. you are relying on the detect
behavior of the build packs). For non-Java apps if you set a build pack
with `-b` or the `buildpacks` attribute, I believe it should clear up the
message.

Dan

On Mon, Aug 31, 2015 at 9:42 AM, Aleksey Zalesov <
aleksey.zalesov(a)altoros.com> wrote:

Can you clarify how can I do this?

It is not problem of our installation SSL cert that can be skipped with
—skip-ssl-validation.

Aleksey Zalesov | CloudFoundry Engineer | Altoros
Tel: (617) 841-2121 ext. 5707 | Toll free: 855-ALTOROS
Fax: (866) 201-3646 | Skype: aleksey_zalesov
www.altoros.com | blog.altoros.com | twitter.com/altoros

On 31 Aug 2015, at 16:18, Quintessence Anx <qanx(a)starkandwayne.com>
wrote:

Are you able to work around the issue by skipping SSL validation?
On Aug 31, 2015 9:10 AM, "Kei YAMAZAKI" <daydream.yamazaki(a)gmail.com>
wrote:

Hi all,

I encountered the same problem.
The same problem has occurred even PWS.
Please fix as soon as possible.

attachment.html

Re: Can't push app due to expired certificate

Kei YAMAZAKI

#1431

Disable ssl verification workaround works.
https://github.com/kei-yamazaki/java-buildpack/commit/6b0551ce62f3be3b60e687775554f6f5b126cd0c

It can push with -b option.
cf push <APP-NAME> -b https://github.com/kei-yamazaki/java-buildpack.git\#disable-ssl-verification