Date   

Proposal for split deployments in cf-deployment

David Sabeti
 

Hi cf-dev,

One thing we're considering in the future for cf-deployment is providing a
way to break down the unified deployment manifest into smaller deployments.
Particularly, we want to split up deployments in a way that helps operators
manage the way updates are rolled out.

Take a look here for the proposal:
https://docs.google.com/document/d/1l4v7ocYph_Al20j6TVF6ylRrUKyFH9hSwxxSbIcZ0wM/edit?usp=sharing

Please comment on the document with any feedback you have. We'd love to
hear from you.

Thanks!
David Sabeti
CF Release Integration Project Lead


Re: CF deployment on BOSH-lite

David Sabeti
 

Subhankar,

If you have any questions about cf-deployment, feel free to jump in the
#cf-deployment channel on the Cloud Foundry slack, or open a Github issue
on the repo. The RelInt team (which maintains cf-deployment) can help you
out there.

David

On Thu, Aug 10, 2017 at 10:40 AM Subhankar Chattopadhyay <
subho.atg(a)gmail.com> wrote:

Hi,

Thanks to all for your prompt reply. Surely, cf-deployment eases lot of
deployment complexity!

Regards,
Subhankar

On Thu, 10 Aug 2017 at 9:39 PM, Eric Malm <emalm(a)pivotal.io> wrote:

Hi, Subhankar,

That's likely the result of the consul certificates in the canned
BOSH-Lite CF manifest expiring after 2 years.
https://github.com/cloudfoundry/cf-release/pull/1229 fixes that, has
been merged, and should be in a new cf-release release-candidate and then
final CF release soon. In the meantime, you can also use
./scripts/generate-consul-certs in the cf-release to generate a new set of
certificates and then copy them into the appropriate BOSH properties in
templates/cf-infrastructure-bosh-lite.yml.

I second Natalie's advice to try using cf-deployment (
https://github.com/cloudfoundry/cf-deployment) to deploy CF to BOSH-Lite
instead of the older manifest-generation systems in cf-release and
diego-release.

Best,
Eric, CF Diego PM

On Thu, Aug 10, 2017 at 9:01 AM, Natalie Bennett <nbennett(a)pivotal.io>
wrote:

You should 100% be using cf-deployment for local development at this
point. Release Integration is now working with Pivotal CloudOps to
transition Pivotal's production CF instance to cf-deployment.

Once there's a running production instance of cf-deployment, RelInt will
begin the process of deprecating cf-release. If you can avoid transitioning
yourself, or learning cf-r's manifest generation, you should.

Exactly what's going on with consul depends on why Bosh lite crashed. I
personally wouldn't spend much time debugging it since consul is also in
the process of being removed.

A couple of possible steps for the consul problem:

1. That error output looks like a problem with certs, so those certs
might just be wrong. You won't have that problem with cf-d since it
generates its own certs.

2. When in doubt and not in production, scale consul down to 1, delete
its data directory (I think /var/vcap/store but I'd expect the consul
release repo to have instructions) and scale back up

3. Though what I'd do is tear the whole thing down and start over.

- Natalie

On Thu, Aug 10, 2017 at 7:53 AM Subhankar Chattopadhyay <
subho.atg(a)gmail.com> wrote:

Hi,

I used to deploy CF using the
cf-release(https://github.com/cloudfoundry/cf-release) and following
the steps mentioned in
http://docs.cloudfoundry.org/deploying/boshlite/create_a_manifest.html.
It was working fine till my bosh-lite crashed and when I tried to re
install, consul_z1 was not running and I got the following error
inside the log

error during stop: dial tcp [::1]:8400: getsockopt: connection refused
error during start: timeout exceeded: "rpc error: failed to get conn:
x509: certificate has expired or is not yet valid"
2017/08/09 04:23:24 [ERR] agent.client: Failed to decode response
header: EOF
2017/08/09 04:23:24 [ERR] agent.client: Failed to decode response
header: EOF
error during start: timeout exceeded: "rpc error: failed to get conn:
x509: certificate has expired or is not yet valid"
2017/08/09 04:24:26 [ERR] agent.client: Failed to decode response
header: EOF
2017/08/09 04:24:26 [ERR] agent.client: Failed to decode response
header: EOF
error during start: timeout exceeded: "rpc error: failed to get conn:
x509: certificate has expired or is not yet valid"


Am I missing some steps here? Should I deploy with new certificates ?

I then deployed bosh and cf using
bosh-deployment(https://github.com/cloudfoundry/bosh-deployment) and
cf-deployment(https://github.com/cloudfoundry/cf-deployment). It
worked perfectly.

I am wondering if cf-deployment is the way to go for local bosh-lite
development or I should try with cf-release? Can someone help me with
this?



Regards,
Subhankar Chattopadhyay
Bangalore, India
--



Subhankar Chattopadhyay
Bangalore, India


Re: CF deployment on BOSH-lite

Subhankar Chattopadhyay <subho.atg@...>
 

Hi,

Thanks to all for your prompt reply. Surely, cf-deployment eases lot of
deployment complexity!

Regards,
Subhankar

On Thu, 10 Aug 2017 at 9:39 PM, Eric Malm <emalm(a)pivotal.io> wrote:

Hi, Subhankar,

That's likely the result of the consul certificates in the canned
BOSH-Lite CF manifest expiring after 2 years.
https://github.com/cloudfoundry/cf-release/pull/1229 fixes that, has been
merged, and should be in a new cf-release release-candidate and then final
CF release soon. In the meantime, you can also use
./scripts/generate-consul-certs in the cf-release to generate a new set of
certificates and then copy them into the appropriate BOSH properties in
templates/cf-infrastructure-bosh-lite.yml.

I second Natalie's advice to try using cf-deployment (
https://github.com/cloudfoundry/cf-deployment) to deploy CF to BOSH-Lite
instead of the older manifest-generation systems in cf-release and
diego-release.

Best,
Eric, CF Diego PM

On Thu, Aug 10, 2017 at 9:01 AM, Natalie Bennett <nbennett(a)pivotal.io>
wrote:

You should 100% be using cf-deployment for local development at this
point. Release Integration is now working with Pivotal CloudOps to
transition Pivotal's production CF instance to cf-deployment.

Once there's a running production instance of cf-deployment, RelInt will
begin the process of deprecating cf-release. If you can avoid transitioning
yourself, or learning cf-r's manifest generation, you should.

Exactly what's going on with consul depends on why Bosh lite crashed. I
personally wouldn't spend much time debugging it since consul is also in
the process of being removed.

A couple of possible steps for the consul problem:

1. That error output looks like a problem with certs, so those certs
might just be wrong. You won't have that problem with cf-d since it
generates its own certs.

2. When in doubt and not in production, scale consul down to 1, delete
its data directory (I think /var/vcap/store but I'd expect the consul
release repo to have instructions) and scale back up

3. Though what I'd do is tear the whole thing down and start over.

- Natalie

On Thu, Aug 10, 2017 at 7:53 AM Subhankar Chattopadhyay <
subho.atg(a)gmail.com> wrote:

Hi,

I used to deploy CF using the
cf-release(https://github.com/cloudfoundry/cf-release) and following
the steps mentioned in
http://docs.cloudfoundry.org/deploying/boshlite/create_a_manifest.html.
It was working fine till my bosh-lite crashed and when I tried to re
install, consul_z1 was not running and I got the following error
inside the log

error during stop: dial tcp [::1]:8400: getsockopt: connection refused
error during start: timeout exceeded: "rpc error: failed to get conn:
x509: certificate has expired or is not yet valid"
2017/08/09 04:23:24 [ERR] agent.client: Failed to decode response
header: EOF
2017/08/09 04:23:24 [ERR] agent.client: Failed to decode response
header: EOF
error during start: timeout exceeded: "rpc error: failed to get conn:
x509: certificate has expired or is not yet valid"
2017/08/09 04:24:26 [ERR] agent.client: Failed to decode response
header: EOF
2017/08/09 04:24:26 [ERR] agent.client: Failed to decode response
header: EOF
error during start: timeout exceeded: "rpc error: failed to get conn:
x509: certificate has expired or is not yet valid"


Am I missing some steps here? Should I deploy with new certificates ?

I then deployed bosh and cf using
bosh-deployment(https://github.com/cloudfoundry/bosh-deployment) and
cf-deployment(https://github.com/cloudfoundry/cf-deployment). It
worked perfectly.

I am wondering if cf-deployment is the way to go for local bosh-lite
development or I should try with cf-release? Can someone help me with
this?



Regards,
Subhankar Chattopadhyay
Bangalore, India
--



Subhankar Chattopadhyay
Bangalore, India


Re: CF deployment on BOSH-lite

Eric Malm <emalm@...>
 

Hi, Subhankar,

That's likely the result of the consul certificates in the canned BOSH-Lite
CF manifest expiring after 2 years. https://github.com/
cloudfoundry/cf-release/pull/1229 fixes that, has been merged, and should
be in a new cf-release release-candidate and then final CF release soon. In
the meantime, you can also use ./scripts/generate-consul-certs in the
cf-release to generate a new set of certificates and then copy them into
the appropriate BOSH properties in templates/cf-infrastructure-
bosh-lite.yml.

I second Natalie's advice to try using cf-deployment (https://github.com/
cloudfoundry/cf-deployment) to deploy CF to BOSH-Lite instead of the older
manifest-generation systems in cf-release and diego-release.

Best,
Eric, CF Diego PM

On Thu, Aug 10, 2017 at 9:01 AM, Natalie Bennett <nbennett(a)pivotal.io>
wrote:

You should 100% be using cf-deployment for local development at this
point. Release Integration is now working with Pivotal CloudOps to
transition Pivotal's production CF instance to cf-deployment.

Once there's a running production instance of cf-deployment, RelInt will
begin the process of deprecating cf-release. If you can avoid transitioning
yourself, or learning cf-r's manifest generation, you should.

Exactly what's going on with consul depends on why Bosh lite crashed. I
personally wouldn't spend much time debugging it since consul is also in
the process of being removed.

A couple of possible steps for the consul problem:

1. That error output looks like a problem with certs, so those certs might
just be wrong. You won't have that problem with cf-d since it generates its
own certs.

2. When in doubt and not in production, scale consul down to 1, delete its
data directory (I think /var/vcap/store but I'd expect the consul release
repo to have instructions) and scale back up

3. Though what I'd do is tear the whole thing down and start over.

- Natalie

On Thu, Aug 10, 2017 at 7:53 AM Subhankar Chattopadhyay <
subho.atg(a)gmail.com> wrote:

Hi,

I used to deploy CF using the
cf-release(https://github.com/cloudfoundry/cf-release) and following
the steps mentioned in
http://docs.cloudfoundry.org/deploying/boshlite/create_a_manifest.html.
It was working fine till my bosh-lite crashed and when I tried to re
install, consul_z1 was not running and I got the following error
inside the log

error during stop: dial tcp [::1]:8400: getsockopt: connection refused
error during start: timeout exceeded: "rpc error: failed to get conn:
x509: certificate has expired or is not yet valid"
2017/08/09 04:23:24 [ERR] agent.client: Failed to decode response header:
EOF
2017/08/09 04:23:24 [ERR] agent.client: Failed to decode response header:
EOF
error during start: timeout exceeded: "rpc error: failed to get conn:
x509: certificate has expired or is not yet valid"
2017/08/09 04:24:26 [ERR] agent.client: Failed to decode response header:
EOF
2017/08/09 04:24:26 [ERR] agent.client: Failed to decode response header:
EOF
error during start: timeout exceeded: "rpc error: failed to get conn:
x509: certificate has expired or is not yet valid"


Am I missing some steps here? Should I deploy with new certificates ?

I then deployed bosh and cf using
bosh-deployment(https://github.com/cloudfoundry/bosh-deployment) and
cf-deployment(https://github.com/cloudfoundry/cf-deployment). It
worked perfectly.

I am wondering if cf-deployment is the way to go for local bosh-lite
development or I should try with cf-release? Can someone help me with
this?



Regards,
Subhankar Chattopadhyay
Bangalore, India


Re: CF deployment on BOSH-lite

James Leavers
 

An issue was opened recently as the bosh-lite consul certs had expired:
https://github.com/cloudfoundry/cf-release/issues/1230

On 10 August 2017 at 15:53:52, Subhankar Chattopadhyay (subho.atg(a)gmail.com)
wrote:

Hi,

I used to deploy CF using the
cf-release(https://github.com/cloudfoundry/cf-release) and following
the steps mentioned in
http://docs.cloudfoundry.org/deploying/boshlite/create_a_manifest.html.
It was working fine till my bosh-lite crashed and when I tried to re
install, consul_z1 was not running and I got the following error
inside the log

error during stop: dial tcp [::1]:8400: getsockopt: connection refused
error during start: timeout exceeded: "rpc error: failed to get conn:
x509: certificate has expired or is not yet valid"
2017/08/09 04:23:24 [ERR] agent.client: Failed to decode response header:
EOF
2017/08/09 04:23:24 [ERR] agent.client: Failed to decode response header:
EOF
error during start: timeout exceeded: "rpc error: failed to get conn:
x509: certificate has expired or is not yet valid"
2017/08/09 04:24:26 [ERR] agent.client: Failed to decode response header:
EOF
2017/08/09 04:24:26 [ERR] agent.client: Failed to decode response header:
EOF
error during start: timeout exceeded: "rpc error: failed to get conn:
x509: certificate has expired or is not yet valid"


Am I missing some steps here? Should I deploy with new certificates ?

I then deployed bosh and cf using
bosh-deployment(https://github.com/cloudfoundry/bosh-deployment) and
cf-deployment(https://github.com/cloudfoundry/cf-deployment). It
worked perfectly.

I am wondering if cf-deployment is the way to go for local bosh-lite
development or I should try with cf-release? Can someone help me with
this?



Regards,
Subhankar Chattopadhyay
Bangalore, India


Re: CF deployment on BOSH-lite

Natalie Bennett
 

You should 100% be using cf-deployment for local development at this point.
Release Integration is now working with Pivotal CloudOps to transition
Pivotal's production CF instance to cf-deployment.

Once there's a running production instance of cf-deployment, RelInt will
begin the process of deprecating cf-release. If you can avoid transitioning
yourself, or learning cf-r's manifest generation, you should.

Exactly what's going on with consul depends on why Bosh lite crashed. I
personally wouldn't spend much time debugging it since consul is also in
the process of being removed.

A couple of possible steps for the consul problem:

1. That error output looks like a problem with certs, so those certs might
just be wrong. You won't have that problem with cf-d since it generates its
own certs.

2. When in doubt and not in production, scale consul down to 1, delete its
data directory (I think /var/vcap/store but I'd expect the consul release
repo to have instructions) and scale back up

3. Though what I'd do is tear the whole thing down and start over.

- Natalie
On Thu, Aug 10, 2017 at 7:53 AM Subhankar Chattopadhyay <subho.atg(a)gmail.com>
wrote:

Hi,

I used to deploy CF using the
cf-release(https://github.com/cloudfoundry/cf-release) and following
the steps mentioned in
http://docs.cloudfoundry.org/deploying/boshlite/create_a_manifest.html.
It was working fine till my bosh-lite crashed and when I tried to re
install, consul_z1 was not running and I got the following error
inside the log

error during stop: dial tcp [::1]:8400: getsockopt: connection refused
error during start: timeout exceeded: "rpc error: failed to get conn:
x509: certificate has expired or is not yet valid"
2017/08/09 04:23:24 [ERR] agent.client: Failed to decode response header:
EOF
2017/08/09 04:23:24 [ERR] agent.client: Failed to decode response header:
EOF
error during start: timeout exceeded: "rpc error: failed to get conn:
x509: certificate has expired or is not yet valid"
2017/08/09 04:24:26 [ERR] agent.client: Failed to decode response header:
EOF
2017/08/09 04:24:26 [ERR] agent.client: Failed to decode response header:
EOF
error during start: timeout exceeded: "rpc error: failed to get conn:
x509: certificate has expired or is not yet valid"


Am I missing some steps here? Should I deploy with new certificates ?

I then deployed bosh and cf using
bosh-deployment(https://github.com/cloudfoundry/bosh-deployment) and
cf-deployment(https://github.com/cloudfoundry/cf-deployment). It
worked perfectly.

I am wondering if cf-deployment is the way to go for local bosh-lite
development or I should try with cf-release? Can someone help me with
this?



Regards,
Subhankar Chattopadhyay
Bangalore, India


CF deployment on BOSH-lite

Subhankar Chattopadhyay <subho.atg@...>
 

Hi,

I used to deploy CF using the
cf-release(https://github.com/cloudfoundry/cf-release) and following
the steps mentioned in
http://docs.cloudfoundry.org/deploying/boshlite/create_a_manifest.html.
It was working fine till my bosh-lite crashed and when I tried to re
install, consul_z1 was not running and I got the following error
inside the log

error during stop: dial tcp [::1]:8400: getsockopt: connection refused
error during start: timeout exceeded: "rpc error: failed to get conn:
x509: certificate has expired or is not yet valid"
2017/08/09 04:23:24 [ERR] agent.client: Failed to decode response header: EOF
2017/08/09 04:23:24 [ERR] agent.client: Failed to decode response header: EOF
error during start: timeout exceeded: "rpc error: failed to get conn:
x509: certificate has expired or is not yet valid"
2017/08/09 04:24:26 [ERR] agent.client: Failed to decode response header: EOF
2017/08/09 04:24:26 [ERR] agent.client: Failed to decode response header: EOF
error during start: timeout exceeded: "rpc error: failed to get conn:
x509: certificate has expired or is not yet valid"


Am I missing some steps here? Should I deploy with new certificates ?

I then deployed bosh and cf using
bosh-deployment(https://github.com/cloudfoundry/bosh-deployment) and
cf-deployment(https://github.com/cloudfoundry/cf-deployment). It
worked perfectly.

I am wondering if cf-deployment is the way to go for local bosh-lite
development or I should try with cf-release? Can someone help me with
this?



Regards,
Subhankar Chattopadhyay
Bangalore, India


Re: Gorouter now supports SNI and multiple certs

Dieu Cao <dcao@...>
 

Woohoo!

On Aug 9, 2017 6:47 PM, "Shannon Coen" <scoen(a)pivotal.io> wrote:

On behalf of the CF Routing team, I'm pleased to announce routing-release
0.160.0:
https://github.com/cloudfoundry-incubator/routing-release/
releases/tag/0.160.0

This release includes a bunch of exciting features, including our most
requested one:
- SNI / Multiple Certificates

...as well as:
- Mutual TLS / Validation of Client Certificates
- Forwarding of Client Certificates to backends via the
X-Forwarded-Client-Cert HTTP header, enabling mutual TLS between client and
apps without forfeiting HTTP load balancing. The Java buildpack was
recently updated to support this header, transparently exposing certificate
metadata to apps.
- Max concurrent connections per backend, preventing slow apps from
impacting the availability of the rest of the platform
- 5 second frontend timeout on idle client connections, forcing load
balancers that time out silently to send their clients a TCP Reset.

These features will be included in an upcoming version of cf-release.

Note: this release removes support for properties router.ssl_cert and
router.ssl_key in favor of router.tls_pem, which is required if router.enable_ssl:
true.

Best,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.


Gorouter now supports SNI and multiple certs

Shannon Coen
 

On behalf of the CF Routing team, I'm pleased to announce routing-release
0.160.0:
https://github.com/cloudfoundry-incubator/routing-release/releases/tag/
0.160.0

This release includes a bunch of exciting features, including our most
requested one:
- SNI / Multiple Certificates

...as well as:
- Mutual TLS / Validation of Client Certificates
- Forwarding of Client Certificates to backends via the
X-Forwarded-Client-Cert HTTP header, enabling mutual TLS between client and
apps without forfeiting HTTP load balancing. The Java buildpack was
recently updated to support this header, transparently exposing certificate
metadata to apps.
- Max concurrent connections per backend, preventing slow apps from
impacting the availability of the rest of the platform
- 5 second frontend timeout on idle client connections, forcing load
balancers that time out silently to send their clients a TCP Reset.

These features will be included in an upcoming version of cf-release.

Note: this release removes support for properties router.ssl_cert and
router.ssl_key in favor of router.tls_pem, which is required if
router.enable_ssl:
true.

Best,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.


CF CAB call for August 2017 is next Wednesday, August 16th @ 8a PDT [15:00 UTC]

Michael Maximilien
 

Hi, all,

Quick reminder that the CAB call for August is next Wednesday, August 16th @ 8a PDT. All zoom info and agenda in link [1].

Remember, no more status update but rather discussions, so come ready with your questions. We will also have:

1. yours truly presenting about CF-Extensions PMC: projects, process, and tooling.

2. Open slot for anyone to present something OSS related to CF. Reply directly to me with proposals or suggestions or start discussion on the slack.cloudfoundry.org #CAB channel.

Zoom you all next week. I'll send one more reminder on this list next week.

Best,

dr.max

ibm cloud labs
sillicon valley, ca
usa
maximilien.org

Sent from my iPhone

[1] https://docs.google.com/document/d/1SCOlAquyUmNM-AQnekCOXiwhLs6gveTxAcduvDcW_xI/edit#heading=h.o44xhgvum2we


Re: Service broker authors: have you ever changed your service or plan names?

Sascha Matzke
 

We've refrained from renaming and extended the service catalog of affected
brokers with additional "new" entries with new names and UUIDs and actively
phased out the old ones (restricted access etc.).

There are so many delicate mechanisms bound to the names of marketplace
services (triggers in buildpacks, spring cloud magic) that renaming
existing services seemed to risky.

A clearer contract about how to handle service and service plan names would
definitely help (are the names just display names or is it ok to use them
otherwise).

Best,

Sascha

On Tue, Aug 8, 2017 at 11:58 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

The Service Broker API currently supports modifying the service name and
plan name fields, as a uuid is used as the unique identifier. These names
are used in CLI workflows, and are used by applications to parse the
VCAP_SERVICES environment variable to identify credentials. In practice, if
these names are changed it may require updating an application to use the
new service name to identify credentials.

The metadata field is often used to expose display names for services and
plans.

The Open Service Broker API working group is interested to know how often
these names actually change, and whether they could be considered immutable
in the future.

Best,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.
--
Through the darkness of future past
the magician longs to see
One chants out between two worlds
*Fire walk with me*.


Re: Service broker authors: have you ever changed your service or plan names?

Subhankar Chattopadhyay <subho.atg@...>
 

It would be good to have plan renaming feature, also would be good to
have it only as display name so that it can be changed without much of
dependency. We have also faced similar situations previously.

On Wed, Aug 9, 2017 at 3:40 AM, Mike Youngstrom <youngm(a)gmail.com> wrote:
We have renamed plans and services in the past. I would like to be able to
continue to update them in the future. But I wouldn't consider it a must
have feature but it does has come in handy in the past.

Mike

On Tue, Aug 8, 2017 at 3:58 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

The Service Broker API currently supports modifying the service name and
plan name fields, as a uuid is used as the unique identifier. These names
are used in CLI workflows, and are used by applications to parse the
VCAP_SERVICES environment variable to identify credentials. In practice, if
these names are changed it may require updating an application to use the
new service name to identify credentials.

The metadata field is often used to expose display names for services and
plans.

The Open Service Broker API working group is interested to know how often
these names actually change, and whether they could be considered immutable
in the future.

Best,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.
--




Subhankar Chattopadhyay
Bangalore, India


Re: Cloud foundry buildpack to support openJFX

Peter Dotchev <dotchev@...>
 

Hi,

Try the binary buildpack or a Docker image.
There you have most flexibility.

Best regards,
Petar


On Wed, Jul 26, 2017 at 5:48 PM, Raghuvamsi Uthpala <
Raghuvamsi.Uthpala(a)indegene.com> wrote:

Hi Team,



I’m new to cloud foundry and we are setting up CF for our organization.



We have a requirement for one of our apps that it needs openJFX with java
8 . I’ve tried creating some custom build packs but not successful.

Can some one help me out if there are some build packs which I can use
that support openJFX or some steps to add this to default java-buildpack.



Appreciate your help.



*Raghuvamsi Uthpala*

Office: +91-80-39204567 <+91%2080%203920%204567>

DevOps – Lead.

Software Engineering Services

Mobile: +91- 9492901250 <+91%2094929%2001250>

Email: raghuvamsi.uthpala(a)indegene.com

Web: www.indegene.com

[image: cid:image001.png(a)01D1006F.0E0455B0] <http://www.indegene.com/>

Follow us:

*[image: cid:image002.png(a)01D1006F.0E0455B0]*
<https://www.linkedin.com/company/68889?trk=tyah&trkInfo=clickedVertical:company,clickedEntityId:68889,idx:2-1-2,tarId:1438602556067,tas:indege>

*[image: cid:image003.png(a)01D1006F.0E0455B0]*
<https://www.facebook.com/Indegene>



[image: cid:image004.png(a)01D1006F.0E0455B0] <http://www.indegene.com/atom>



Disclaimer: This email (including any attachments) contains information,
which is confidential and may be subject to legal privilege. If you are not
the intended recipient, you must not use, distribute, or copy this email.
If you have received this email in error, please notify the sender
immediately and delete this. Any views expressed in this mail are not
necessarily the views of INDEGENE. Thank you.






Disclaimer : This message and any attachments are solely for the intended
recipient and may contain confidential or privileged information. If you
are not the intended recipient, any disclosure, copying, use, or
distribution of the information included in this message and any
attachments is prohibited. If you have received this communication in
error, please notify us by reply e-mail to IT(a)Indegene.com and
immediately and permanently delete this message and any attachments. Any
views expressed in this mail are not necessarily the views of INDEGENE.
Thank you.


Re: Service broker authors: have you ever changed your service or plan names?

Mike Youngstrom
 

We have renamed plans and services in the past. I would like to be able to
continue to update them in the future. But I wouldn't consider it a must
have feature but it does has come in handy in the past.

Mike

On Tue, Aug 8, 2017 at 3:58 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

The Service Broker API currently supports modifying the service name and
plan name fields, as a uuid is used as the unique identifier. These names
are used in CLI workflows, and are used by applications to parse the
VCAP_SERVICES environment variable to identify credentials. In practice, if
these names are changed it may require updating an application to use the
new service name to identify credentials.

The metadata field is often used to expose display names for services and
plans.

The Open Service Broker API working group is interested to know how often
these names actually change, and whether they could be considered immutable
in the future.

Best,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.


Service broker authors: have you ever changed your service or plan names?

Shannon Coen
 

The Service Broker API currently supports modifying the service name and
plan name fields, as a uuid is used as the unique identifier. These names
are used in CLI workflows, and are used by applications to parse the
VCAP_SERVICES environment variable to identify credentials. In practice, if
these names are changed it may require updating an application to use the
new service name to identify credentials.

The metadata field is often used to expose display names for services and
plans.

The Open Service Broker API working group is interested to know how often
these names actually change, and whether they could be considered immutable
in the future.

Best,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.


Re: Cloud foundry buildpack to support openJFX

Stephen Levine
 

Hi Raghuvamsi,

It may be worth opening an issue about this on the Java buildpack Github
issue tracker[1].

[1] https://github.com/cloudfoundry/java-buildpack/issues

Thanks,
Stephen

On Wed, Jul 26, 2017 at 10:48 AM, Raghuvamsi Uthpala <
Raghuvamsi.Uthpala(a)indegene.com> wrote:

Hi Team,



I’m new to cloud foundry and we are setting up CF for our organization.



We have a requirement for one of our apps that it needs openJFX with java
8 . I’ve tried creating some custom build packs but not successful.

Can some one help me out if there are some build packs which I can use
that support openJFX or some steps to add this to default java-buildpack.



Appreciate your help.



*Raghuvamsi Uthpala*

Office: +91-80-39204567 <+91%2080%203920%204567>

DevOps – Lead.

Software Engineering Services

Mobile: +91- 9492901250 <+91%2094929%2001250>

Email: raghuvamsi.uthpala(a)indegene.com

Web: www.indegene.com

[image: cid:image001.png(a)01D1006F.0E0455B0] <http://www.indegene.com/>

Follow us:

*[image: cid:image002.png(a)01D1006F.0E0455B0]*
<https://www.linkedin.com/company/68889?trk=tyah&trkInfo=clickedVertical:company,clickedEntityId:68889,idx:2-1-2,tarId:1438602556067,tas:indege>

*[image: cid:image003.png(a)01D1006F.0E0455B0]*
<https://www.facebook.com/Indegene>



[image: cid:image004.png(a)01D1006F.0E0455B0] <http://www.indegene.com/atom>



Disclaimer: This email (including any attachments) contains information,
which is confidential and may be subject to legal privilege. If you are not
the intended recipient, you must not use, distribute, or copy this email.
If you have received this email in error, please notify the sender
immediately and delete this. Any views expressed in this mail are not
necessarily the views of INDEGENE. Thank you.






Disclaimer : This message and any attachments are solely for the intended
recipient and may contain confidential or privileged information. If you
are not the intended recipient, any disclosure, copying, use, or
distribution of the information included in this message and any
attachments is prohibited. If you have received this communication in
error, please notify us by reply e-mail to IT(a)Indegene.com and
immediately and permanently delete this message and any attachments. Any
views expressed in this mail are not necessarily the views of INDEGENE.
Thank you.


Re: bosh lite v2

David Sabeti
 

Hi cf-dev,

To add to this, I wanted to clarify what the Release Integration team is
currently validating, and what we will plan to validate, in our pipelines.

*Currently*
We validate cf-release against the deprecated Vagrant workflow, and
cf-deployment against the new bosh-lite workflow that uses bosh-deployment
as described on bosh.io.

*In the near future -- about two weeks*
We're going to switch to using the bosh-deployment workflow for cf-release,
and support that for the remainder of cf-release's lifetime. cf-deployment
will continue to be validated on the bosh-deployment workflow as well.

*tl;dr - The Release Integration team will stop validating the Vagrant
workflow for bosh-lite in two weeks, so please switch to using the workflow
described on bosh.io <http://bosh.io>*

Thanks,
David Sabeti
CF Release Integration Project Lead

On Fri, Aug 4, 2017 at 3:05 PM Dmitriy Kalinin <dkalinin(a)pivotal.io> wrote:

+cf-dev

On Fri, Aug 4, 2017 at 2:49 PM, Dmitriy Kalinin <dkalinin(a)pivotal.io>
wrote:

hey all,

as some of you may know, we have been recently recommending to install
bosh lite via cli v2 instead of vagrant. we haven't found any serious
drawbacks to the new approach so i would like to recommend new approach to
everyone. i've updated cloudfoundry/bosh-lite repo to point to new
bosh.io docs about bosh-lite.

here are some advantages to the new approach:
- uses cli v2 standard create-env
- uses official vsphere stemcell as a host image for vbox
- allows to configure director with uaa and credhub
- "bosh lite" can be installed on any supported iaas (not just vbox)

we are happy to answer any questions on cloudfoundry #bosh slack.

cheers,
dmitriy


Re: Any simple stub file of cloud foundry deployment on openstack

Natalie Bennett
 

cf-deployment will be going GA over the next couple of months, and
production transitions between cf-release and cf-deployment will be
painful. (My team is working on the first one now.)

If you set up with cf-deployment and give David Sabeti (PM of the team
making it) feedback about any features you need, you'll save yourself a lot
of time and pain.

You'll also be able to use BOSH to generate all your certs automatically.

- Natalie
Pivotal Cloud Operations

On Mon, Aug 7, 2017 at 4:49 AM Arpit Sharma <arpitvipulsharma(a)gmail.com>
wrote:

Hi David McClure,

Right now I am preparing this for testing environment. But surely after
this proof of concept , It will be on production environment.


Re: Any simple stub file of cloud foundry deployment on openstack

Arpit Sharma
 

Hi David McClure,

I have tried above mentioned method, but I am getting error like this:

Task 101

07:35:43 | Preparing deployment: Preparing deployment (00:00:00)
L Error: Required property 'networks' was not specified in object ({})

07:35:44 | Error: Required property 'networks' was not specified in object ({})

Started Tue Aug 8 07:35:43 UTC 2017
Finished Tue Aug 8 07:35:44 UTC 2017
Duration 00:00:01

Task 101 error

Updating deployment:
Expected task '101' to succeed but state is 'error'

Exit code 1


Can you help me with this?


Re: Any simple stub file of cloud foundry deployment on openstack

Arpit Sharma
 

Hi David McClure,

Got the link. Thanks for your response. Let me check and try with this.

2301 - 2320 of 9425