Date   

BOSH PMC refactoring part 2 – moving CPIs out of incubation

Marco Voelz
 

Dear friends of BOSH,
 
The BOSH project management committee (PMC) proposes to promote the most mature and widely used CPIs from incubation to full project status. Specifically, we want to promote these CPIs
  • AWS CPI [1]
  • OpenStack CPI [2]
  • VSphere CPI [3]
  • Google CPI [4]
  • Azure CPI [5]

Promoting the projects has some impact on their users, depending on how you consume the CPIs
  • We will move the repositories from the cloudfoundry-incubator to the cloudfoundry organization in github. Github takes care of redirecting from the old repository location to the new one, so all links and references to the old repositories should still work. 
  • References on bosh.io currently include the github organization name [6]. In the past, there have been issues with people consuming outdated releases from bosh.io after they had been renamed or moved – we might need a similar mechanism of redirecting that github provides to avoid that.

Please reach out to by replying to this mail or contacting me personally if you have questions, concerns, or comments.

Warm regards
Marco

PS: cross-posted on cf-developers for greater reach and potential experiences about previous promotions from incubator to full project.



Re: UAA required configuration #cf

williamnguyen167@...
 

Thank you for your reply.
I have fixed this problem by adding encryption into uaa.yml
Still having another exception but uncommment the SAML key configuration will solve it.


Notice: [Cloud Controller] capi-release is removing debian_nfs_server

Charles Hansen <chansen@...>
 

Hi all,

capi-release is removing the debian_nfs_server job and package. It was deprecated in January 2016 and replaced with webdav. We still support connecting to nfs, but we no longer provide an nfs server.

To follow the full extent of this work, you can see the tracker story here:

Please feel free to reach out on slack if you have any questions:

Thanks,
- CAPI team


Re: CFCR?

Oleksandr Slynko
 

Hi Mike,

Use this mailing list or go directly to the Slack #cfcr channel. https://cloudfoundry.slack.com/messages/C5SF37P8X

Sincerely,
Alex Slynko


Re: CFCR?

Chip Childers <cchilders@...>
 

This should work! Or if it's more BOSH related, the cf-bosh@... list might be better.


On Wed, Aug 22, 2018 at 3:39 PM Mike Lloyd <mike@...> wrote:

Hey folks,

 

Where is the best place to post topics/questions about CFCR? Would that be here or is there another mailing list specific to CFCR?

 

Respectfully,

 

Mike Lloyd

t: @mxplusc

g: @mxplusb
Professional Member, ACM

 

--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815


CFCR?

mike@...
 

Hey folks,

 

Where is the best place to post topics/questions about CFCR? Would that be here or is there another mailing list specific to CFCR?

 

Respectfully,

 

Mike Lloyd

t: @mxplusc

g: @mxplusb
Professional Member, ACM

 


Re: UAA required configuration #cf

Dr Nic Williams <drnicwilliams@...>
 

Try adding this encryption: section https://github.com/starkandwayne/quick-uaa-deployment-cf/blob/master/src/uaa.yml#L8

 

From: 30051024040n behalf of
Sent: Wednesday, August 22, 2018 6:02 pm
To: cf-dev@...
Subject: [cf-dev] UAA required configuration #cf
 
I'm trying to build UAA on localhost (Window 10 Home)
After running command "$ ./gradlew run"
And finished (I think so) execute at 97%
I running command: 
"$ curl -H "Accept: application/json" localhost:8080/uaa/login
{
  "timestamp":"2012-03-28T18:25:49+0100",
  "commit_id":"111274e",
  "prompts":{"username":["text","Username"],
    "password":["password","Password"]
  }
}"
Server return "FAILURE"
Take a look at log file
The exception threw as: "Invalid bean definition with name 'activeKeyService' defined in class path resource [spring/login-ui.xml]: Could not resolve placeholder 'encryption.active_key_label' in value "${encryption.active_key_label}"; nested exception is java.lang.IllegalArgumentException: Could not resolve placeholder 'encryption.active_key_label' in value "${encryption.active_key_label}"
How can I fix this problem?


UAA required configuration #cf

williamnguyen167@...
 

I'm trying to build UAA on localhost (Window 10 Home)
After running command "$ ./gradlew run"
And finished (I think so) execute at 97%
I running command: 
"$ curl -H "Accept: application/json" localhost:8080/uaa/login
{
  "timestamp":"2012-03-28T18:25:49+0100",
  "commit_id":"111274e",
  "prompts":{"username":["text","Username"],
    "password":["password","Password"]
  }
}"
Server return "FAILURE"
Take a look at log file
The exception threw as: "Invalid bean definition with name 'activeKeyService' defined in class path resource [spring/login-ui.xml]: Could not resolve placeholder 'encryption.active_key_label' in value "${encryption.active_key_label}"; nested exception is java.lang.IllegalArgumentException: Could not resolve placeholder 'encryption.active_key_label' in value "${encryption.active_key_label}"
How can I fix this problem?


Re: Polyglot Service Discovery is Generally Available

Mike Youngstrom
 

Wahoo!!!!


On Tue, Aug 21, 2018 at 5:32 PM Preethi Varambally <pvarambally@...> wrote:
Hello All,

Polyglot Service Discovery is now Generally Available in cf-deployment version 3.4.0. Here is the feature narrative that we had shared previously and contains the latest updates.

We made an enhancement to this feature to allow you to configure custom internal domains. Optionally you can still continue to use 'apps.internal' if you wish to. You can find instructions for this on our Github page.

Please reach out to us if you have any questions.

Thanks,
CF Networking Team



Re: Polyglot Service Discovery is Generally Available

Zach Robinson
 

Congrats CF Networking Team!


On Tue, Aug 21, 2018 at 4:34 PM Preethi Varambally <pvarambally@...> wrote:
Hello All,

Polyglot Service Discovery is now Generally Available in cf-deployment version 3.4.0. Here is the feature narrative that we had shared previously and contains the latest updates.

We made an enhancement to this feature to allow you to configure custom internal domains. Optionally you can still continue to use 'apps.internal' if you wish to. You can find instructions for this on our Github page.

Please reach out to us if you have any questions.

Thanks,
CF Networking Team



Polyglot Service Discovery is Generally Available

Preethi Varambally
 

Hello All,

Polyglot Service Discovery is now Generally Available in cf-deployment version 3.4.0. Here is the feature narrative that we had shared previously and contains the latest updates.

We made an enhancement to this feature to allow you to configure custom internal domains. Optionally you can still continue to use 'apps.internal' if you wish to. You can find instructions for this on our Github page.

Please reach out to us if you have any questions.

Thanks,
CF Networking Team



Re: Service Instance Sharing is now GA

Zach Robinson
 

Awesome feature.  Congrats Services API Team!


On Tue, Aug 21, 2018 at 3:17 AM Sam Gunaratne <rgunaratne@...> wrote:
Hello CF Devs,

We are happy to announce that Service Instance Sharing is now Generally Available starting from CF Deployment 3.4.0 (CAPI Release 1.66.0).

Sharing a service instance between spaces allows apps in different spaces to share databases, messaging queues, and other types of services. This eliminates the need for development teams to use service keys and user-provided services to bind their apps to the same service instance that was provisioned using the cf create-service command. Sharing service instances improves security, auditing, and provides a more intuitive user experience.
 
This functionality is turned off by default but can be enabled in CF using a feature flag.


We would like to thank for your feedback during the experimental phase.

Thanks,

Services API Team


Service Instance Sharing is now GA

Sam Gunaratne
 

Hello CF Devs,

We are happy to announce that Service Instance Sharing is now Generally Available starting from CF Deployment 3.4.0 (CAPI Release 1.66.0).

Sharing a service instance between spaces allows apps in different spaces to share databases, messaging queues, and other types of services. This eliminates the need for development teams to use service keys and user-provided services to bind their apps to the same service instance that was provisioned using the cf create-service command. Sharing service instances improves security, auditing, and provides a more intuitive user experience.
 
This functionality is turned off by default but can be enabled in CF using a feature flag.


We would like to thank for your feedback during the experimental phase.

Thanks,

Services API Team


Re: REQUEST for REVIEW - Proposed Scope for CF-Deployment v4.0

Marco Voelz
 

Dear Josh,


Thanks for starting this process for cf-deployment 4.0!


Announcing coming changes and also changes that didn't make it in 4.0 addresses some of the concerns I raised about cf-deployment 3.0 [1] and hopefully the next major releases will go a bit smoother. It is also great that you specifically mention where you got the team's sign-off to enable/disable certain things.


Warm regards

Marco


[1] https://lists.cloudfoundry.org/g/cf-dev/message/8191


From: cf-dev@... <cf-dev@...> on behalf of Josh Collins <jcollins@...>
Sent: Friday, August 17, 2018 8:49:28 PM
To: cf-dev@...
Subject: [cf-dev] REQUEST for REVIEW - Proposed Scope for CF-Deployment v4.0
 
Hello Fellow Cloud-Foundrians,

Based on the feedback generated during the cf-deployment v3.0 retro and observations of the impact of 3.0 on the CF development community CI's, I'd like to share and gather feedback on proposed scope of the next major release of cf-deployment.

As per the action item generated in the 3.0 retro, I've created a Google Doc which describes the high-level changes under proposal.


Anyone with the link above can review and comment.
Please feel free to review and provide feedback in the document as soon as you're able.

We'll be locking the scope the middle of next week (Wednesday August 22nd).

For those interested in following, here's the v4.0 epic in our backlog.
 
Lastly, if you've got breaking changes that you'd like Release Integration to consider in the future please bring them to my and the team's attention:
Thanks very much for reading to the end and Happy Friday!

Josh Collins
PM - Release Integration
--
Josh Collins
PM - CF R&D Release Integration


REQUEST for REVIEW - Proposed Scope for CF-Deployment v4.0

Josh Collins
 

Hello Fellow Cloud-Foundrians,

Based on the feedback generated during the cf-deployment v3.0 retro and observations of the impact of 3.0 on the CF development community CI's, I'd like to share and gather feedback on proposed scope of the next major release of cf-deployment.

As per the action item generated in the 3.0 retro, I've created a Google Doc which describes the high-level changes under proposal.


Anyone with the link above can review and comment.
Please feel free to review and provide feedback in the document as soon as you're able.

We'll be locking the scope the middle of next week (Wednesday August 22nd).

For those interested in following, here's the v4.0 epic in our backlog.
 
Lastly, if you've got breaking changes that you'd like Release Integration to consider in the future please bring them to my and the team's attention:
Thanks very much for reading to the end and Happy Friday!

Josh Collins
PM - Release Integration
--
Josh Collins
PM - CF R&D Release Integration


NOTICE: [go-buildpack] Default Go version will change from 1.8.x to 1.10.x after 2018-09-17

Scott Sisil
 

The default version of Go will be updated to 1.10.x in the first release after 2018-09-17.


Per the Go release website, Go versions that are two releases behind the latest major release are not supported[1]. Therefore we are giving users a 30 day notice before we change the default version of Go to the latest major version 1.10.x and remove Go versions 1.6.x and 1.7.x as they are no longer supported. If you are using 1.6.x and 1.7.x, please make plans to migrate your applications to 1.10.x in the next 30 days.


[1] https://golang.org/doc/devel/release.html



Scott

CF Buildpacks PM



Re: Proposal: Improving Security for HTTP Ingress to CFAR Application Containers

Eric Malm <emalm@...>
 

On Thu, Aug 16, 2018 at 9:16 PM, Mike Youngstrom <youngm@...> wrote:
Oh man, after re-reading your email it now makes sense.  To be honest I didn't actually read the document you provided since it wasn't open for read to everyone so I just assumed what was in there instead.  Sorry.

Huh, something weird has been going on with the permissions on that document: this is the third time now that I've had to change them back to allowing global comments. If for some reason that reverts back to a more restricted mode (on this proposal document or any others I've posted here) please let me know via an access request or via email or Slack and I'll correct it again.
 
Typically in our environments we use network firewalls to force that ingress into the network zones holding CF instances only happen through Enterprise load balancers and only then to specific components, e.g. gorouter, ssh-proxy, tcp router, etc., and use security groups to stop apps talking directly to other containers.  Though I imagine in the future we may deploy to environments with less strict network firewall setups.  In such an environment this configuration option would be very useful and we probably would use it without TCP routing support if we had such a situation.  But we don't currently.

Thanks for helping me through this email. :)

Sure, thanks for the extra feedback, and for hanging in there!

Best,
Eric 


Re: Proposal: Improving Security for HTTP Ingress to CFAR Application Containers

Mike Youngstrom
 

We would probably not deploy the improved http ingress until tcp and ssh are both working.  Our priority from the improvements in http ingress have been more on the reliable side and less on the security side.  We haven't run into any NATS mis-routing requests issues for a while and we do have TCP customers.  So, we would probably prefer to keep riding our current NATS good luck streak than disrupt our TCP customers.

Great, thanks for letting me know. Just to clarify, route integrity on its own (enabled via https://github.com/cloudfoundry/cf-deployment/blob/master/operations/experimental/enable-routing-integrity.yml) is intended primarily to improve HTTP routing reliability in the face of NATS and other component failures, and is still compatible with both CF SSH and TCP routing. This proposed more secure mode is an opt-in configuration that depends on but is separate from that "basic" route integrity.

Also, we on the Diego team think that we've finally finished ironing out a minor edge case around making sure incoming requests are handled correctly when app instances are being shutdown gracefully, so we expect to work with Release Integration in the next month or so to promote that route-integrity ops file to be a stable one and then later to be the default configuration in cf-deployment.

Oh man, after re-reading your email it now makes sense.  To be honest I didn't actually read the document you provided since it wasn't open for read to everyone so I just assumed what was in there instead.  Sorry.

Typically in our environments we use network firewalls to force that ingress into the network zones holding CF instances only happen through Enterprise load balancers and only then to specific components, e.g. gorouter, ssh-proxy, tcp router, etc., and use security groups to stop apps talking directly to other containers.  Though I imagine in the future we may deploy to environments with less strict network firewall setups.  In such an environment this configuration option would be very useful and we probably would use it without TCP routing support if we had such a situation.  But we don't currently.

Thanks for helping me through this email. :)

Mike


Re: Proposal: Improving Security for HTTP Ingress to CFAR Application Containers

Eric Malm <emalm@...>
 

We would probably not deploy the improved http ingress until tcp and ssh are both working.  Our priority from the improvements in http ingress have been more on the reliable side and less on the security side.  We haven't run into any NATS mis-routing requests issues for a while and we do have TCP customers.  So, we would probably prefer to keep riding our current NATS good luck streak than disrupt our TCP customers.

Great, thanks for letting me know. Just to clarify, route integrity on its own (enabled via https://github.com/cloudfoundry/cf-deployment/blob/master/operations/experimental/enable-routing-integrity.yml) is intended primarily to improve HTTP routing reliability in the face of NATS and other component failures, and is still compatible with both CF SSH and TCP routing. This proposed more secure mode is an opt-in configuration that depends on but is separate from that "basic" route integrity.

Also, we on the Diego team think that we've finally finished ironing out a minor edge case around making sure incoming requests are handled correctly when app instances are being shutdown gracefully, so we expect to work with Release Integration in the next month or so to promote that route-integrity ops file to be a stable one and then later to be the default configuration in cf-deployment.
 
That's perfect.  We don't use the port.

Some examples where cell ip address has come in handy:
* Mostly firewall debugging.  Our firewall situation is a mess.  Lots of manual work and issues to debug where sometimes knowing the specific cell ip address can help in debugging a problem.
* Occasionally customers want to do tcpdumps from a destination server.  The ip of the cell hosting the source app instance helps reduce the tcpdump scope.  Unfortunately, in tcpdump situations the CF operations team usually gets involved anyway to grab a tcpdump from the cell side since last time I checked we couldn't take tcpdumps from in a container.  So, these scenarios are usually not very self service anyway.

Hope that helps.

Certainly, thanks for the details!

Best,
Eric


Re: Proposal: Improving Security for HTTP Ingress to CFAR Application Containers

Mike Youngstrom
 

Got it.
 
Not quite: in the initial form of this more secured configuration, neither CF SSH nor TCP routing will work at all, as their gateway/front/edge routers would not have the network pathway into the container that they currently recognize. The Diego team is actually done at this point with the diego-release features required to enable that initial secured configuration, and will soon contribute an experimental operations file to opt into it to cf-deployment shortly and then focus on our approach to make CF SSH work again in this secure mode. We don't expect the current TCP routing tier ever to work with this configuration, though, as the Routing team is instead focused on the Istio integration effort as a longer-term plan to replace both the HTTP and TCP routing tiers. So I'm interested in knowing whether you'd be able to enable this extra security in any of your CF environments if either (a) CF SSH doesn't work as a result (short-term obstacle, resolved in a month or so) or (b) TCP routing doesn't work (longer-term obstacle, resolved only with Istio integration).

We would probably not deploy the improved http ingress until tcp and ssh are both working.  Our priority from the improvements in http ingress have been more on the reliable side and less on the security side.  We haven't run into any NATS mis-routing requests issues for a while and we do have TCP customers.  So, we would probably prefer to keep riding our current NATS good luck streak than disrupt our TCP customers.
 
Great, thanks for the feedback! The CF_INSTANCE_IP environment variable will continue to contain the cell VM's IP inside the container environment, and it'll likewise still be present in the response from the CC stats endpoint, so it sounds like those network-debugging activities would be unaffected. It'd of course be great to hear the specifics of how having that cell VM IP has been useful to your developers or to you as the platform operators in resolving those network-related issues, though.

That's perfect.  We don't use the port.

Some examples where cell ip address has come in handy:
* Mostly firewall debugging.  Our firewall situation is a mess.  Lots of manual work and issues to debug where sometimes knowing the specific cell ip address can help in debugging a problem.
* Occasionally customers want to do tcpdumps from a destination server.  The ip of the cell hosting the source app instance helps reduce the tcpdump scope.  Unfortunately, in tcpdump situations the CF operations team usually gets involved anyway to grab a tcpdump from the cell side since last time I checked we couldn't take tcpdumps from in a container.  So, these scenarios are usually not very self service anyway.

Hope that helps.

Mike

1201 - 1220 of 9426