Date   

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.


Re: Can't push app due to expired certificate

Quintessence Anx
 

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

Sylvain Gibier
 

Yup - I can confirm as well. All buildpacks relying on
download.run.pivotal.io are failing now.

S.

On Mon, Aug 31, 2015 at 3:10 PM, 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
 

Hi all,

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


Can't push app due to expired certificate

Aleksey Zalesov
 

Hello! Today we can't push apps to CF due to expired SSL certificate of
download.run.pivotal.io

<http://cf-dev.70369.x6.nabble.com/file/n1404/Screen_Shot_2015-08-31_at_15.png>

Here are CF app logs:

2015-08-31T17:36:18.57+0530 [STG/0] ERR [DownloadCache]
WARN Unable to download
https://download.run.pivotal.io/memory-calculator/trusty/x86_64/index
.yml into cache /tmp: SSL_connect returned=1 errno=0 state=SSLv3 read server
certificate B: certificate verify failed

Please fix the cert.

P.S. This issue is for Open Source CF, not Pivotal CF!



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


www.lists.cloudfoundry.org

Yana | X-Factors Web Networks Ltd <yanarobbins20@...>
 

Hi,

I recently browsed through your business listing and wanted to highlight
some key points for consideration. I am sure it will complement your
SEOwork to help attract quality visitors and gradually scale high on the
search-engine result's page.

A few changes, aesthetically and/or-SEO-wise, can make your site convert
more visitors into leads and also get it placed higher in the organic
search results, for a few of the select terms.

Would you be interested in receiving some more details on the prospect at
absolutely-no-cost-involved?

Regards,

YANA

X-FACTOR WEB NETWORKS Ltd
Headquarters: 5859 Suite Canoga Ave, Woodland Hills, CA 91367
Other Offices: Hong Kong & China | Australia | New Zealand | UAE


www.lists.cloudfoundry.org

Hannah | Office Coffee Soltns <hannahquinn183@...>
 

Hi,

I represent providers of high quality office coffee. By choosing a
specialized coffee delivery service, you can cut your overhead noticeably
vs. using grocery delivery or even wholesale ordering services.

May I send some information about office coffee quotes?

Hannah

Business-Development-Manager

Office Coffee Solutions
2000 Yorkmont Rd, Charlotte, NC 28217, United States


Generic data points for dropsonde

Benjamin Black
 

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: SSH into a pushed Docker image

Matthew Sykes <matthew.sykes@...>
 

The diego ssh daemon is a statically linked binary so if you have a /bin/sh
or a /bin/bash in your docker image, it should work. The scp support is
also baked in so you don't need that binary at the target either.

On Fri, Aug 28, 2015 at 4:21 PM, James Bayer <jbayer(a)pivotal.io> wrote:

diego ssh support should work with docker images. there likely are some
minimal prerequisites for things in the image like a shell or whatever
executables you would try with ssh. here is my output from the
cloudfoundry/lattice-app docker image

lattice is about to have tcp router support included. it will take a
little while longer to get it into full CF.

$ cf ssh jbayer-lattice-app

BusyBox v1.21.1 (Ubuntu 1:1.21.0-1ubuntu1) built-in shell (ash)
Enter 'help' for a list of built-in commands.

~ # ls -al
total 6820
drwxr-xr-x 1 root root 84 Aug 28 20:18 .
drwxr-xr-x 1 root root 84 Aug 28 20:18 ..
drwxr-xr-x 1 root root 2336 Aug 28 20:18 bin
drwxr-xr-x 1 root root 122 Aug 28 20:18 dev
drwxr-xr-x 1 root root 108 Aug 28 20:18 etc
-rwxr-xr-x 1 root root 6971512 Aug 28 01:54 lattice-app
drwxr-xr-x 1 root root 400 May 22 2014 lib
lrwxrwxrwx 1 root root 3 May 22 2014 lib64 -> lib
dr-xr-xr-x 187 65534 65534 0 Aug 28 20:18 proc
lrwxrwxrwx 1 root root 3 May 22 2014 sbin -> bin
dr-xr-xr-x 13 65534 65534 0 Aug 28 20:18 sys
drwxrwxrwt 1 root root 40 Aug 28 20:18 tmp


On Fri, Aug 28, 2015 at 11:43 AM, Jack Cai <greensight(a)gmail.com> wrote:

The SSH support in Diego is awesome. I'm wondering whether it's possible
to SSH into a pushed Docker image as well? If yes, what need to be done in
the docker image in order to get it working?

Meanwhile, I suppose the tcp-routing support is still not available in
Diego, right?

Thanks in advance!

Jack


--
Thank you,

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

7961 - 7980 of 9398