Date   

Re: Self-signed cert for registry failing on stager

Tom Sherrod <tom.sherrod@...>
 

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@...>
 

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
 

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.


Re: Generic data points for dropsonde

Benjamin Black
 

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

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





Re: Generic data points for dropsonde

Dwayne
 

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




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

CF Runtime
 

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


Singapore Company Offer

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

 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@...>
 

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.


Re: Announcing Experimental support for Asynchronous Service Operations

Dieu Cao <dcao@...>
 

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/

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


Re: Announcing Experimental support for Asynchronous Service Operations

Guillaume Berche
 

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


Re: Self-signed cert for registry failing on stager

Will Pragnell <wpragnell@...>
 

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


Re: Can't push app due to expired certificate

Christopher B Ferris <chrisfer@...>
 

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
 
 

----- 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
 

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
 

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


Re: Can't push app due to expired certificate

Mike Dalessio
 

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.


Re: Can't push app due to expired certificate

Kei YAMAZAKI
 


Re: Can't push app due to expired certificate

Mike Dalessio
 

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.


Re: Can't push app due to expired certificate

Quintessence Anx
 

Ah sorry - I wasn't able to see the image of the error on my phone. I
thought it was a different error.

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.


Re: Can't push app due to expired certificate

Daniel Mikusa
 

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.


Re: Can't push app due to expired certificate

Aleksey Zalesov
 

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 <http://www.altoros.com/> | blog.altoros.com <http://blog.altoros.com/> | twitter.com/altoros <http://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 <mailto: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.

7981 - 8000 of 9426