Date   

- Is it possible to create custom Roles

Kinjal Doshi
 

Hi,

In Pivotal CF, is it possible to create custom roles?

Thanks,
Kinjal


- About services w.r.t orgs and spaces

Kinjal Doshi
 

Hi,

I wanted to understand if orgs and spaces in Pivotal CF contribute towards
accessing services from:


1. Applications deployed in different spaces of same org and
2. Application deployed in different orgs altogether. (spaces would be
different here by default, right?)

Thanks for your help in advance.

Regards,

Kinjal


Re: Adding multiple users to user/auditor roles of an orgnization

Dieu Cao <dcao@...>
 

Hi Anil,

There is not an API to add multiple users to multiple roles of an
organization.

-Dieu
CF Runtime PM

On Tue, May 12, 2015 at 7:22 PM, Anil Ambati <aambati(a)hotmail.com> wrote:

Hi,
is there a CF API to add multiple users to multiple roles of an
organization? I have looked at the CF docs, but did not find any indication
that such API exists.

Thank you.

Regards,
Anil

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


Re: Recipe to install Diego?

Xianfeng Ye
 

Thanks all!

Xianfeng Ye

On Mon, May 11, 2015 at 9:17 PM, OzzOzz <ozzozz(a)gmail.com> wrote:

Hi,

I have posted a sample BOSH deployment manifest to Gist.
https://gist.github.com/ozzozz/4c08c37863b703a75afc
I could deploy cf-release v207 and diego-release 0.1099.0 to AWS Tokyo
region by MicroBOSH.

I could also deploy cf-release and diego-release to OpenStack(Juno).
The manifests differs only in 'networks', 'cloud_properties' and
'stemcell'.

Regards,
Ken

---
<ozzozz(a)gmail.com>
Mitaka, Tokyo Japan


On Sat, May 9, 2015 at 8:57 PM, Tom Sherrod <tom.sherrod(a)gmail.com> wrote:
Hi,

Are there any examples or docs on installing Diego with bosh/microbosh?
Using the bosh-lite as a template, I'm tripping up on various parts. Is
this
even a valid direction in installing?
Either AWS or Openstack..

Thanks,
Tom

_______________________________________________
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


Re: UAA, SAML, and LDAP questions

Aaron Huber
 

In our case we use email address as the username via LDAP as well (UPN actually, but same thing) so it would be the same. Is there a timeline for the ECP profile support?

Aaron

From: Filip Hanik [mailto:fhanik(a)pivotal.io]
Sent: Wednesday, May 13, 2015 3:54 PM
To: Mike Youngstrom
Cc: Sree Tummidi; Huber, Aaron M; CF Developers Mailing List
Subject: Re: [cf-dev] UAA, SAML, and LDAP questions

The problem with SAML is that we never see the username. We only receive the username in form of an email address from the SAML IDP. This would not correspond to the username you would log in to LDAP with.

The use case you describe would indicate we want two different authentication sources represent the same authentication source.
I believe the correct solution here is to implement the SAML ECP profile. At that point you'd have an option to go LDAP or SAML rather than trying to mix both.

Filip


On Wed, May 13, 2015 at 3:30 PM, Mike Youngstrom <youngm(a)gmail.com<mailto:youngm(a)gmail.com>> wrote:
Possibly, though I think regular user authentication would still be a concern for our users since security forces a rather short TTL for our access tokens. I'll have to take a look and try a few things. We may decide to just use LDAP and forget about the SSO integration for now.

Mike

On Wed, May 13, 2015 at 3:03 PM, Sree Tummidi <stummidi(a)pivotal.io<mailto:stummidi(a)pivotal.io>> wrote:
Hi Aaron,
You could potentially use the access token (similar to a personal access token used for GitHub API ) to achieve the CLI automation. The access token can either be retrieved via an authentication to the CLI itself or via UAAC.
Regular users would still continue to use the -sso option.


Thanks,
Sree Tummidi
Sr. Product Manager
Identity - Pivotal Cloud Foundry


On Wed, May 13, 2015 at 1:56 PM, Huber, Aaron M <aaron.m.huber(a)intel.com<mailto:aaron.m.huber(a)intel.com>> wrote:
That’s the main concern we have as well – we currently need LDAP for the CLI since SAML doesn’t work in that case, but we’d like SAML for web-based interactions (SSO in a portal, etc.). But at present it seems like that’s not possible without the user having to deal with effectively two separate accounts.

Aaron

From: Mike Youngstrom [mailto:youngm(a)gmail.com<mailto:youngm(a)gmail.com>]
Sent: Wednesday, May 13, 2015 1:34 PM
To: Filip Hanik
Cc: Huber, Aaron M; CF Developers Mailing List
Subject: Re: [cf-dev] UAA, SAML, and LDAP questions

Well, that's a bummer. Is there any way around that? Our SAML is backed by the same LDAP so they are the same user. We can provide a unique ID to correlate SAML with LDAP users.

Mike

On Wed, May 13, 2015 at 2:28 PM, Filip Hanik <fhanik(a)pivotal.io<mailto:fhanik(a)pivotal.io>> wrote:
yes, it would result in two different shadow accounts, differentiated by the value of the user's origin field



On Wed, May 13, 2015 at 2:08 PM, aaron_huber <aaron.m.huber(a)intel.com<mailto:aaron.m.huber(a)intel.com>> wrote:
Would the same user logging in via SAML and LDAP result in two different UAA
user objects with different sources, so that the user would have two
different sets of orgs/spaces/apps?

Aaron



--
View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-UAA-SAML-and-LDAP-questions-tp62p65.html
Sent from the CF Dev mailing list archive at Nabble.com.
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


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


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


Re: UAA, SAML, and LDAP questions

Filip Hanik
 

The problem with SAML is that we never see the username. We only receive
the username in form of an email address from the SAML IDP. This would not
correspond to the username you would log in to LDAP with.

The use case you describe would indicate we want two different
authentication sources represent the same authentication source.
I believe the correct solution here is to implement the SAML ECP profile.
At that point you'd have an option to go LDAP or SAML rather than trying to
mix both.

Filip

On Wed, May 13, 2015 at 3:30 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:

Possibly, though I think regular user authentication would still be a
concern for our users since security forces a rather short TTL for our
access tokens. I'll have to take a look and try a few things. We may
decide to just use LDAP and forget about the SSO integration for now.

Mike

On Wed, May 13, 2015 at 3:03 PM, Sree Tummidi <stummidi(a)pivotal.io> wrote:

Hi Aaron,
You could potentially use the access token (similar to a personal access
token used for GitHub API ) to achieve the CLI automation. The access token
can either be retrieved via an authentication to the CLI itself or via UAAC.
Regular users would still continue to use the -sso option.


Thanks,
Sree Tummidi
Sr. Product Manager
Identity - Pivotal Cloud Foundry


On Wed, May 13, 2015 at 1:56 PM, Huber, Aaron M <aaron.m.huber(a)intel.com>
wrote:

That’s the main concern we have as well – we currently need LDAP for
the CLI since SAML doesn’t work in that case, but we’d like SAML for
web-based interactions (SSO in a portal, etc.). But at present it seems
like that’s not possible without the user having to deal with effectively
two separate accounts.



Aaron



*From:* Mike Youngstrom [mailto:youngm(a)gmail.com]
*Sent:* Wednesday, May 13, 2015 1:34 PM
*To:* Filip Hanik
*Cc:* Huber, Aaron M; CF Developers Mailing List
*Subject:* Re: [cf-dev] UAA, SAML, and LDAP questions



Well, that's a bummer. Is there any way around that? Our SAML is
backed by the same LDAP so they are the same user. We can provide a unique
ID to correlate SAML with LDAP users.



Mike



On Wed, May 13, 2015 at 2:28 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

yes, it would result in two different shadow accounts, differentiated
by the value of the user's origin field







On Wed, May 13, 2015 at 2:08 PM, aaron_huber <aaron.m.huber(a)intel.com>
wrote:

Would the same user logging in via SAML and LDAP result in two different
UAA
user objects with different sources, so that the user would have two
different sets of orgs/spaces/apps?

Aaron



--
View this message in context:
http://cf-dev.70369.x6.nabble.com/cf-dev-UAA-SAML-and-LDAP-questions-tp62p65.html
Sent from the CF Dev mailing list archive at Nabble.com.

_______________________________________________
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


Re: UAA, SAML, and LDAP questions

Mike Youngstrom
 

Possibly, though I think regular user authentication would still be a
concern for our users since security forces a rather short TTL for our
access tokens. I'll have to take a look and try a few things. We may
decide to just use LDAP and forget about the SSO integration for now.

Mike

On Wed, May 13, 2015 at 3:03 PM, Sree Tummidi <stummidi(a)pivotal.io> wrote:

Hi Aaron,
You could potentially use the access token (similar to a personal access
token used for GitHub API ) to achieve the CLI automation. The access token
can either be retrieved via an authentication to the CLI itself or via UAAC.
Regular users would still continue to use the -sso option.


Thanks,
Sree Tummidi
Sr. Product Manager
Identity - Pivotal Cloud Foundry


On Wed, May 13, 2015 at 1:56 PM, Huber, Aaron M <aaron.m.huber(a)intel.com>
wrote:

That’s the main concern we have as well – we currently need LDAP for
the CLI since SAML doesn’t work in that case, but we’d like SAML for
web-based interactions (SSO in a portal, etc.). But at present it seems
like that’s not possible without the user having to deal with effectively
two separate accounts.



Aaron



*From:* Mike Youngstrom [mailto:youngm(a)gmail.com]
*Sent:* Wednesday, May 13, 2015 1:34 PM
*To:* Filip Hanik
*Cc:* Huber, Aaron M; CF Developers Mailing List
*Subject:* Re: [cf-dev] UAA, SAML, and LDAP questions



Well, that's a bummer. Is there any way around that? Our SAML is backed
by the same LDAP so they are the same user. We can provide a unique ID to
correlate SAML with LDAP users.



Mike



On Wed, May 13, 2015 at 2:28 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

yes, it would result in two different shadow accounts, differentiated
by the value of the user's origin field







On Wed, May 13, 2015 at 2:08 PM, aaron_huber <aaron.m.huber(a)intel.com>
wrote:

Would the same user logging in via SAML and LDAP result in two different
UAA
user objects with different sources, so that the user would have two
different sets of orgs/spaces/apps?

Aaron



--
View this message in context:
http://cf-dev.70369.x6.nabble.com/cf-dev-UAA-SAML-and-LDAP-questions-tp62p65.html
Sent from the CF Dev mailing list archive at Nabble.com.

_______________________________________________
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


Re: UAA, SAML, and LDAP questions

Sree Tummidi
 

Hi Aaron,
You could potentially use the access token (similar to a personal access
token used for GitHub API ) to achieve the CLI automation. The access token
can either be retrieved via an authentication to the CLI itself or via UAAC.
Regular users would still continue to use the -sso option.


Thanks,
Sree Tummidi
Sr. Product Manager
Identity - Pivotal Cloud Foundry


On Wed, May 13, 2015 at 1:56 PM, Huber, Aaron M <aaron.m.huber(a)intel.com>
wrote:

That’s the main concern we have as well – we currently need LDAP for the
CLI since SAML doesn’t work in that case, but we’d like SAML for web-based
interactions (SSO in a portal, etc.). But at present it seems like that’s
not possible without the user having to deal with effectively two separate
accounts.



Aaron



*From:* Mike Youngstrom [mailto:youngm(a)gmail.com]
*Sent:* Wednesday, May 13, 2015 1:34 PM
*To:* Filip Hanik
*Cc:* Huber, Aaron M; CF Developers Mailing List
*Subject:* Re: [cf-dev] UAA, SAML, and LDAP questions



Well, that's a bummer. Is there any way around that? Our SAML is backed
by the same LDAP so they are the same user. We can provide a unique ID to
correlate SAML with LDAP users.



Mike



On Wed, May 13, 2015 at 2:28 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

yes, it would result in two different shadow accounts, differentiated by
the value of the user's origin field







On Wed, May 13, 2015 at 2:08 PM, aaron_huber <aaron.m.huber(a)intel.com>
wrote:

Would the same user logging in via SAML and LDAP result in two different
UAA
user objects with different sources, so that the user would have two
different sets of orgs/spaces/apps?

Aaron



--
View this message in context:
http://cf-dev.70369.x6.nabble.com/cf-dev-UAA-SAML-and-LDAP-questions-tp62p65.html
Sent from the CF Dev mailing list archive at Nabble.com.

_______________________________________________
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


Re: UAA, SAML, and LDAP questions

Aaron Huber
 

That’s the main concern we have as well – we currently need LDAP for the CLI since SAML doesn’t work in that case, but we’d like SAML for web-based interactions (SSO in a portal, etc.). But at present it seems like that’s not possible without the user having to deal with effectively two separate accounts.

Aaron

From: Mike Youngstrom [mailto:youngm(a)gmail.com]
Sent: Wednesday, May 13, 2015 1:34 PM
To: Filip Hanik
Cc: Huber, Aaron M; CF Developers Mailing List
Subject: Re: [cf-dev] UAA, SAML, and LDAP questions

Well, that's a bummer. Is there any way around that? Our SAML is backed by the same LDAP so they are the same user. We can provide a unique ID to correlate SAML with LDAP users.

Mike

On Wed, May 13, 2015 at 2:28 PM, Filip Hanik <fhanik(a)pivotal.io<mailto:fhanik(a)pivotal.io>> wrote:
yes, it would result in two different shadow accounts, differentiated by the value of the user's origin field



On Wed, May 13, 2015 at 2:08 PM, aaron_huber <aaron.m.huber(a)intel.com<mailto:aaron.m.huber(a)intel.com>> wrote:
Would the same user logging in via SAML and LDAP result in two different UAA
user objects with different sources, so that the user would have two
different sets of orgs/spaces/apps?

Aaron



--
View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-UAA-SAML-and-LDAP-questions-tp62p65.html
Sent from the CF Dev mailing list archive at Nabble.com.
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


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


Re: UAA, SAML, and LDAP questions

Mike Youngstrom
 

Well, that's a bummer. Is there any way around that? Our SAML is backed
by the same LDAP so they are the same user. We can provide a unique ID to
correlate SAML with LDAP users.

Mike

On Wed, May 13, 2015 at 2:28 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

yes, it would result in two different shadow accounts, differentiated by
the value of the user's origin field



On Wed, May 13, 2015 at 2:08 PM, aaron_huber <aaron.m.huber(a)intel.com>
wrote:

Would the same user logging in via SAML and LDAP result in two different
UAA
user objects with different sources, so that the user would have two
different sets of orgs/spaces/apps?

Aaron



--
View this message in context:
http://cf-dev.70369.x6.nabble.com/cf-dev-UAA-SAML-and-LDAP-questions-tp62p65.html
Sent from the CF Dev mailing list archive at Nabble.com.
_______________________________________________
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


Re: UAA, SAML, and LDAP questions

Filip Hanik
 

yes, it would result in two different shadow accounts, differentiated by
the value of the user's origin field



On Wed, May 13, 2015 at 2:08 PM, aaron_huber <aaron.m.huber(a)intel.com>
wrote:

Would the same user logging in via SAML and LDAP result in two different
UAA
user objects with different sources, so that the user would have two
different sets of orgs/spaces/apps?

Aaron



--
View this message in context:
http://cf-dev.70369.x6.nabble.com/cf-dev-UAA-SAML-and-LDAP-questions-tp62p65.html
Sent from the CF Dev mailing list archive at Nabble.com.
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: UAA, SAML, and LDAP questions

Aaron Huber
 

Would the same user logging in via SAML and LDAP result in two different UAA
user objects with different sources, so that the user would have two
different sets of orgs/spaces/apps?

Aaron



--
View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-UAA-SAML-and-LDAP-questions-tp62p65.html
Sent from the CF Dev mailing list archive at Nabble.com.


Re: UAA, SAML, and LDAP questions

Mike Youngstrom
 

Great! I'll dig in and give it a try then. Thanks Filip!

Mike

On Wed, May 13, 2015 at 1:36 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

yes, it is entirely possible to run both SAML (as many providers as you
need) and LDAP (single provider).

we are keeping an eye on the SAML ECP profile to make it easier to handle
password grants as well as the CLI itself.

Filip


On Wed, May 13, 2015 at 1:34 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:

We're investigating converting our UAA from a custom fork that integrates
with our organization's SSO to the stock UAA using SAML and/or LDAP. We
would like to maintain SSO functionalities for our web tools but after
doing some reading SAML for the CLI might not work the way we expect it.

In order to log into the CLI when using SAML does it require the user to
go to a web page and get a one time login token? cf login --sso? If so, I
don't think that will work for our and some CLI deployment automation we do.

Is it possible to configure UAA to use both SAML and LDAP? The CLI could
use LDAP and the web use SAML?

Thanks,
Mike

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


Re: UAA, SAML, and LDAP questions

Filip Hanik
 

yes, it is entirely possible to run both SAML (as many providers as you
need) and LDAP (single provider).

we are keeping an eye on the SAML ECP profile to make it easier to handle
password grants as well as the CLI itself.

Filip

On Wed, May 13, 2015 at 1:34 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:

We're investigating converting our UAA from a custom fork that integrates
with our organization's SSO to the stock UAA using SAML and/or LDAP. We
would like to maintain SSO functionalities for our web tools but after
doing some reading SAML for the CLI might not work the way we expect it.

In order to log into the CLI when using SAML does it require the user to
go to a web page and get a one time login token? cf login --sso? If so, I
don't think that will work for our and some CLI deployment automation we do.

Is it possible to configure UAA to use both SAML and LDAP? The CLI could
use LDAP and the web use SAML?

Thanks,
Mike

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


UAA, SAML, and LDAP questions

Mike Youngstrom
 

We're investigating converting our UAA from a custom fork that integrates
with our organization's SSO to the stock UAA using SAML and/or LDAP. We
would like to maintain SSO functionalities for our web tools but after
doing some reading SAML for the CLI might not work the way we expect it.

In order to log into the CLI when using SAML does it require the user to go
to a web page and get a one time login token? cf login --sso? If so, I
don't think that will work for our and some CLI deployment automation we do.

Is it possible to configure UAA to use both SAML and LDAP? The CLI could
use LDAP and the web use SAML?

Thanks,
Mike


Re: cf-release v208 is now available

Dieu Cao <dcao@...>
 

Regarding manifest templates, this means that the bosh director can now
look at the number of instances per job to calculate the resource pool
sizes so it does not need to be specified separately.
As of version 2862, BOSH can compute these sizes dynamically from the list
of jobs. Let's remove this data from the spiff templates in cf-release.
You will need at least this version of BOSH.
I'll update the release note to mention that.

Regarding ephemeral disk sizes, it's not required to use underscores. The
4GB specified in the template for c3.large is replacement of the ephemeral
disk used by default for c3.large.
Also, there was an additional commit [1] that adjusted the instances sizes
back up a bit as we were seeing flakiness in our environments when it was
too low.
I'll link that commit too on the release notes.

Thanks!

[1]
https://github.com/cloudfoundry/cf-release/commit/e09ccfbe95c5dffb200b033f761f04a603404881

On Tue, May 12, 2015 at 6:41 PM, John Wong <gokoproject(a)gmail.com> wrote:

Great release!!! Congrat.

Just a couple questions (but if this is the right thread to ask please
excuse me and let me know).


- Manifest templates no longer include resource pool sizes details
<https://github.com/cloudfoundry/cf-release/commit/fc26ee26443d79d765df490910ea0b4c9706d6ba>


https://github.com/cloudfoundry/cf-release/commit/fc26ee26443d79d765df490910ea0b4c9706d6ba

In a way I was "spoiled" and never really asked why we needed resource
pool but went alone with it, but what does the commit comment "bosh
director can figure this out automatically" mean?


- Adjusted ephemeral disk sizes on new instance types for AWS template
to be more realisticdetails
<https://www.pivotaltracker.com/story/show/91780134>

I just want to make sure I understand the underscore for each of the size
is just some syntax thing for the template, not something I would actually
write in my manifest. Also c3.large by default has 2x16SSD, so are we
taking 4Gb (from the template) from the ephemeral/instance?

And congratulation for merging UAA and Login server. So now all we need is
2 VMs minimally if we really want to have HA (aside from enabling
bosh resurrect).

Thanks in advance.

John Wong




On Tue, May 12, 2015 at 8:22 PM, Dieu Cao <dcao(a)pivotal.io> wrote:

The cf-release v208 was released on May 12th, 2015

- Please see note about merge of UAA/Login server jobs below to
maintain zero down time for CC and UAA for existing deployments.

Runtime

- [Experimental] Work continues on support for Asynchronous Service
Instance Operationsdetails
<https://www.pivotaltracker.com/epic/show/1561148>
- Completed Improvements to Recursive Deletion of Org and Space, in
support of Asynchronous Service Operations details
<https://www.pivotaltracker.com/epic/show/1751766>
- [Experimental] Work continues on /v3 and Application Process Types
details <https://www.pivotaltracker.com/epic/show/1334418>
- [Experimental] Work continues on Route API details
<https://www.pivotaltracker.com/epic/show/1590160>
- [Experimental] Work continues on Context Path Routes details
<https://www.pivotaltracker.com/epic/show/1808212>
- Work continues on support for Service Keys details
<https://www.pivotaltracker.com/epic/show/1743366>
- Work continues on support for Arbitrary Service Parameters details
<https://www.pivotaltracker.com/epic/show/1725984>
- Adjusted ephemeral disk sizes on new instance types for AWS
template to be more realisticdetails
<https://www.pivotaltracker.com/story/show/91780134>
- Including staticfile buildpack v1.0.0 details
<https://github.com/cloudfoundry/staticfile-buildpack/releases/tag/v1.0.0>
- Removed separate login job from minimal aws deployment details
<https://www.pivotaltracker.com/story/show/93505400>
- Allow acceptance test timeouts to be set via manifest details
<https://github.com/cloudfoundry/cf-release/commit/b6c1f33771213ded1cf7c982f5f6fafb3d900197>
- Update default cipher list for haproxy and gorouter details
<https://www.pivotaltracker.com/story/show/91129360>
- Addressed tcpdump CVE-2015-0261, CVE-2015-2153, CVE-2015-2154,
CVE-2015-2155details
<https://www.pivotaltracker.com/story/show/93371680>
- Upgrading php buildpack to v3.1.1 details
<https://github.com/cloudfoundry/php-buildpack/releases/tag/v3.1.1>
- Manifest templates no longer include resource pool sizes details
<https://github.com/cloudfoundry/cf-release/commit/fc26ee26443d79d765df490910ea0b4c9706d6ba>
- Upgrading ruby buildpack to v1.3.1 details
<https://github.com/cloudfoundry/ruby-buildpack/releases/tag/v1.3.1>
- Bump CLI to 6.11.1 for CATS and remove darwin CLI details
<https://www.pivotaltracker.com/story/show/92595438>
- Upgrade cf-release to use ruby 2.1.6 and remove ruby 2.1.4 for CC,
Collector, Warden, DEAdetails
<https://www.pivotaltracker.com/story/show/92547532>
- Addresses ruby CVE-2015-1855
- cloudfoundry/cf-release #660
<https://github.com/cloudfoundry/cf-release/pull/660>: Add security
group for cf-mysql subnets to bosh-lite details
<https://www.pivotaltracker.com/story/show/92658768>
- Adjust VCAP_ID as endpoint/sticky cookie changes details
<https://www.pivotaltracker.com/story/show/92796282>
- Disable compression when creating proxy connection details
<https://www.pivotaltracker.com/story/show/93362206>
- cleanup regex details
<https://github.com/cloudfoundry/cloud_controller_ng/commit/5257a8af6990e71cd1e34ae8978dfe4773b32826>
- A space developer can create a wildcard route for private domains
details <https://www.pivotaltracker.com/story/show/82612406>
- Allow commands to be reset to nothing details
<https://www.pivotaltracker.com/story/show/93406896>

UAA Updates

- Merged UAA & Login Server details
<https://github.com/cloudfoundry/uaa/releases/tag/2.0.0>
- Multi-tenant UAA details
<https://github.com/cloudfoundry/uaa/releases/tag/2.1.0>
- Registering wildcard routes for *.login and *.uaa details
<https://github.com/cloudfoundry/cf-release/commit/0260567d9761700dbccde3088165121d7933e058>
- Zero Downtime Upgrade Procedure
- Perform the cf-release upgrade and keep number of login server
of jobs the same as your existing deploy.
- Change the number of Login Server Job instances to 0 and
re-deploy after initial deploy completes.

Note: The combination of Older Login Server jobs and the newly merged
UAA/Login Server job is not supported. This should be done only for a short
duration to achieve the zero downtime. The Login Server instances should be
deleted via a bosh redeploy immediately after a successful upgrade
Used Configuration

- BOSH Version: 152
- Stemcell Version: 2889
- CC Api Version: 2.25.0

Commit summary
<http://htmlpreview.github.io/?https://github.com/cloudfoundry-community/cf-docs-contrib/blob/master/release_notes/cf-208-whats-in-the-deploy.html>
Compatible Diego Version

- final release 1198 commit
<https://github.com/cloudfoundry-incubator/diego-release/commit/f7b15f8da536eee7be696896890943dbc6202242>


https://github.com/cloudfoundry/cf-release/releases/tag/v208

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


Re: Is it possible to use git push to deploy applications on CF

Alexander Lomov <alexander.lomov@...>
 

Hey.

The simplest way to add this behaviour is to add `cf push` command to
`.git/hooks/pre-push` executable file. The detail you can find in git docs
[0]

In this article you can find the possible reasons not to use `cf push`
together with `git push` [1]

[0] http://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks
[1]
http://blog.pivotal.io/pivotal-labs/labs/deploying-jruby-rails-application-cloud-foundry


------------------------
Alex Lomov
*Altoros* — Cloud Foundry deployment, training and integration
*Twitter:* @code1n <https://twitter.com/code1n> *GitHub:* @allomov
<https://gist.github.com/allomov>

On Wed, May 13, 2015 at 10:04 AM, Alan Moran <bonzofenix(a)gmail.com> wrote:

Hi Kinjal,

CF push does not support git input afaik.
But It would be fairly simple to implement a cf-cli plugin that does that
from the client side to offer a heroku-like experience.

Regards,


Alan

On May 12, 2015, at 10:44 PM, Kinjal Doshi <kindoshi(a)gmail.com> wrote:

Hi,

I would like to know if it is possible to deploy applications on cloud
foundry using git push. Or is it that only CF CLI can be used for pushing
applications?

Thanks,
Kinjal
_______________________________________________
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


Re: Is it possible to use git push to deploy applications on CF

Alan Morán <bonzofenix at gmail.com...>
 

Hi Kinjal,

CF push does not support git input afaik.
But It would be fairly simple to implement a cf-cli plugin that does that from the client side to offer a heroku-like experience.

Regards,


Alan

On May 12, 2015, at 10:44 PM, Kinjal Doshi <kindoshi(a)gmail.com> wrote:

Hi,

I would like to know if it is possible to deploy applications on cloud foundry using git push. Or is it that only CF CLI can be used for pushing applications?

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


Is it possible to use git push to deploy applications on CF

Kinjal Doshi
 

Hi,

I would like to know if it is possible to deploy applications on cloud
foundry using git push. Or is it that only CF CLI can be used for pushing
applications?

Thanks,
Kinjal


Adding multiple users to user/auditor roles of an orgnization

Anil Ambati <aambati@...>
 

Hi,
is there a CF API to add multiple users to multiple roles of an organization? I have looked at the CF docs, but did not find any indication that such API exists.

Thank you.

Regards,
Anil

9301 - 9320 of 9409