1. Cf-Dev
  2. Messages

Expanded

Topics Messages
   Date   
Re: On SelfServiceLinksEnabled #uaa

Dan Beneke
 

Hi CG - 

It looks as if you've taken the right step to disable the create account and password reset links.  We'd expect selfServiceLinksEnabled to have the documented effect (determines if users are allowed to sign up or reset their passwords via the UI) and aren't aware of open issues with its function.  Keep in mind that this value isn't global as it can be set for each individual identity zone.  If you think you've found a bug/issue, I'd encourage you to open a github issue supplying content that will allow the team to recreate the situation.

As for suppressing just one of the two self service links, that feature isn't offered.  Currently, enablement or disablement occurs jointly.  If it's of any value, you do have the option to set the destination http link for the 'create an acct' experience using config.links.selfService.signup .  I've seen implementations wherein this link takes users to a joint self service page with the information they need to either create an account or reset their password.

Regards,
Dan Beneke 

On Mon, Feb 3, 2020 at 9:07 AM JohnG via Lists.Cloudfoundry.Org <ci_98yr=yahoo.com@...> wrote:
in the uaa.yml, when I set selfServiceLinksEnabled to false 
under 
login:
  selfServiceLinksEnabled: false

they (create an acc and password reset link) still appear. Any reliable way to disable them?

Further, is there a way to just suppress "create an acc" with selfServiceLinksEnabled: false ?
and still have self service password reset enabled?

Thanks in anticipation

best regards
-CG

Re: New CLA tool for Cloud Foundry

Chris Clark
 

Hi all,

I’ve got a few updates to the EasyCLA migration, now a few months behind us:

 We’ve removed the prompt to click on “CFF Migration” for previously whitelisted contributors. We’ll be deprecating this shortly, as it was intended as a temporary bridge to minimize disruption to contributors and avoid having covered committers and companies re-sign a CLA. At this point we assume the vast majority of active committers has already signed up with EasyCLA (anyone who has a commit since October has, and that's over 500 committers). Going forward, we’ll ask everyone else to sign a new CLA, which should only take a minute or two. 

Previously, the cloudfoundry and cloudfoundry-incubator GitHub orgs had been whitelisted. This should not have been the case. While the majority of these orgs’ members are covered by an existing CCLA or ICLA, membership in those orgs alone should not exempt committers from being covered by a CLA. Going forward, these orgs will not be whitelisted… so, if you’ve authorized EasyCLA with "CFF Migration" and your whitelisting was based on membership in one of these orgs alone, you may need to re-authorize EasyCLA and select your employer's CCLA, or sign an ICLA. Either way, this should just take a couple minutes.

Bots: If you have an issue with a CI (or any other) bot that makes commits (and therefore will trigger the CLA check), please open a ticket with LF IT (the EasyCLA app will prompt this in the GitHubPR), and they should be able to take care of this for you.

Please reach out to me, or LF IT, if you have any questions, issues, or feedback. Thank you again for your patience with all this!  

 

 
Re: enable 2fa for UAA zone

Peter Burkholder
 

Sorry my response was so blunt. Product tradeoff decisions are always hard and you can't make everyone happy. Just wanted to let you know that there are consumers for this feature if you do revisit anytime soon.
Re: enable 2fa for UAA zone

Peter Burkholder
 

> We see the UAA more frequently used as an identity proxy than as an IdP

This may be true because UAA doesn't support MFA. 
cloud.gov runs its own IdP simply because MFA is not supported by UAA. To quote from Bret Mogilefsky from https://github.com/cloudfoundry/cf-deployment/pull/540

> This is a shocking disappointment. The cloud.gov team predicated a chunk of their roadmap on the understanding that MFA was staying.
Re: enable 2fa for UAA zone

Dan Beneke
 

Hi CG - 

The 2FA/MFA feature still exist in the most recent versions of UAA, but Dr. Nic is correct in suggesting that our intent is to remove it.  We see the UAA more frequently used as an identity proxy than as an IdP, and often the IdP feature is used to store service accounts over actual human users that would be able to interact with 2FA/MFA flows.  The predominance of this usage pattern has led us to consider viewing UAA on a path to become a stronger identity proxy tool wherein the user brings their own identity (IdP).  This suggests 2FA/MFA features would/could be applied to the external IdP and not to the UAA itself as it would only be acting as a proxy.

Regards,
Dan Beneke

On Sat, Feb 1, 2020 at 7:23 PM JohnG via Lists.Cloudfoundry.Org <ci_98yr=yahoo.com@...> wrote:
>I think the UAA team deprecated or removed 2FA/MFA features.

Not sure I am following the "why",  to remove 2FA for UAA zone?

Any documentation pointing to that would be much appreciated.

Thanks Dr Nic!

On SelfServiceLinksEnabled #uaa

JohnG
 

in the uaa.yml, when I set selfServiceLinksEnabled to false 
under 
login:
  selfServiceLinksEnabled: false

they (create an acc and password reset link) still appear. Any reliable way to disable them?

Further, is there a way to just suppress "create an acc" with selfServiceLinksEnabled: false ?
and still have self service password reset enabled?

Thanks in anticipation

best regards
-CG
Re: New lead for Community (CAB) meetings

Swarna Podila
 

Hi Everyone,
Bringing this to the top of your inboxes, y'all.  

Please send in your nominations by Wednesday, February 5th.

-- Swarna Podila (she/her)
Senior
 Director
, Community
 | Cloud Foundry Foundation

You can read more about pronouns here, or please ask if you'd like to find out more.


On Thu, Jan 23, 2020 at 7:54 AM Swarna Podila <spodila@...> wrote:
Dear CF Community,
Max (popularly known as "Dr. Max", cc'd here) has been running Cloud Foundry Community Advisory Board (CAB) meetings for the past 4-ish years now.  As he mentioned during the recent calls, 2020 is a great opportunity for any of you in the community to nominate yourself (or someone you know is interested) to take the baton from Max.  Max will continue being an active member of our community; we just think that other members may want to take an opportunity to step up and make their mark in our community.  

The responsibilities will be to host 
  • the monthly CAB calls by sourcing interesting topics/demos for the meetings
  • in-person CAB meetings at Cloud Foundry Summits (we, from the Foundation, can help you with that)
If you are unsure of the responsibilities or if you would like to talk to Max directly, please feel free to reach out to him.

Please send us your nominations no later than February 5th. 

-- Swarna Podila (she/her)
Senior
 Director
, Community
 | Cloud Foundry Foundation

You can read more about pronouns here, or please ask if you'd like to find out more.
Re: enable 2fa for UAA zone

JohnG
 

>I think the UAA team deprecated or removed 2FA/MFA features.

Not sure I am following the "why",  to remove 2FA for UAA zone?

Any documentation pointing to that would be much appreciated.

Thanks Dr Nic!
Re: enable 2fa for UAA zone

Dr Nic Williams <drnicwilliams@...>
 

I think the UAA team deprecated or removed 2FA/MFA features.

Nic
--
Dr Nic Williams
Stark & Wayne LLC
+61 437 276 076
twitter @drnic
enable 2fa for UAA zone

JohnG
 

Greetings.

I hope this mailing forum can give me pointers on the following

How to enable 2fa (but-in google-authenticator) for UAA (base and default
zone)?

After creating a 2fa provider, when I try to update UAA zone via curl/api
post with update setting mfaconfig etc. I don't see any response back (yes,
with right admin client access token)

Also when directly updated the database query on identity_zone, config, when
it reboots it restores mfaconfig enabled to false.

Is there something 'am missing ; appreciate any pointers on this

Thanks
CG



--
Sent from: http://cf-dev.70369.x6.nabble.com/
Re: Bi-weekly Round-Up: Technical + Ecosystem Updates

Dr Nic Williams <drnicwilliams@...>
 

Thanks Chris for compiling this!

Nic

On Wed, 29 Jan 2020 at 11:12 am, Chris Clark <cclark@...> wrote:

In 2020, we thought it would be beneficial to share more frequent updates on various happenings in the Cloud Foundry ecosystem: community news, projects, releases, demos, recordings of community meetings, must-read articles, and other interesting finds within the community. Expect brief round-ups like this every two weeks going forward. We hope you find this useful and interesting - feedback welcome!

From The Last Few Weeks:

Jan 7 –  https://www.youtube.com/watch?v=D2DZNetyV5U&feature=youtu.be

Jan 21 –  https://www.youtube.com/watch?v=hob5Qj8Gaso&amp=&feature=youtu.be

Dates To Remember (All times US Pacific):

  • CF for Kubernetes SIG call – 8:30 AM on Feb 4
  • Bi-Weekly CF App Runtime PMC meeting – 10:30 AM on Feb 4

Check the community calendar for updates and meeting details here: https://www.cloudfoundry.org/community-calendar/

Interesting Finds from Around the Web:

Who’s hiring?  

Check out the jobs board https://www.cloudfoundry.org/cf-jobs/

--
Dr Nic Williams
Stark & Wayne LLC
+61 437 276 076
twitter @drnic
Bi-weekly Round-Up: Technical + Ecosystem Updates

Chris Clark
 

In 2020, we thought it would be beneficial to share more frequent updates on various happenings in the Cloud Foundry ecosystem: community news, projects, releases, demos, recordings of community meetings, must-read articles, and other interesting finds within the community. Expect brief round-ups like this every two weeks going forward. We hope you find this useful and interesting - feedback welcome!

From The Last Few Weeks:

Jan 7 –  https://www.youtube.com/watch?v=D2DZNetyV5U&feature=youtu.be

Jan 21 –  https://www.youtube.com/watch?v=hob5Qj8Gaso&amp=&feature=youtu.be

Dates To Remember (All times US Pacific):

  • CF for Kubernetes SIG call – 8:30 AM on Feb 4
  • Bi-Weekly CF App Runtime PMC meeting – 10:30 AM on Feb 4

Check the community calendar for updates and meeting details here: https://www.cloudfoundry.org/community-calendar/

Interesting Finds from Around the Web:

Who’s hiring?  

Check out the jobs board https://www.cloudfoundry.org/cf-jobs/
Re: CF Application Runtime PMC: CLI Project Lead Call for Nominations

Eric Malm
 

Hi, everyone,
 
VMware is nominating Zach Robinson for the CLI Project Lead in the Application Runtime PMC.
 
Zach has worked at Pivotal and VMware as a core contributor to Cloud Foundry since 2013, most recently as the lead for the CAPI project team in the App Runtime PMC and as a product manager focused on the CF app-developer experience. Over the years, he has worked with the CF Services, Runtime, CAPI, and CLI teams including anchoring Runtime and PMing CAPI, with contributions to many Cloud Foundry components. His previous experience includes over 10 years of engineering, primarily in the financial sector.
 
Please send any other nominations directly to me or in reply to this message no later than 11:59 PM PST on Monday, February 10, 2020.
 
Thanks,
Eric Malm
CF Application Runtime PMC: CLI Project Lead Call for Nominations

Eric Malm <emalm@...>
 

Hi, everyone,

Abby Chau, the lead for the CLI project within the Application Runtime PMC, has stepped down from the project. We thank her for her service.

The CLI team, located in San Francisco, now has an opening for its project lead. Project leads must be nominated by a Cloud Foundry Foundation member. Please send nominations directly to me or in reply to this message no later than 11:59 PM PST on Monday, February 10, 2020.

Also, if you have any questions about the role or the nomination process, as described in the CFF governance documents (https://www.cloudfoundry.org/governance/cff_development_operations_policy/), please let me know.

Thanks,
Eric Malm, CF Application Runtime PMC Lead
Re: CF app that helps with self-healing

Hjortshoj, Julian <Julian.Hjortshoj@...>
 

To me this seems a lot like a health check.  Is there some reason that you couldn't add a health check endpoint to your app instances (either directly, or as a sidecar) and then let CF take care of restarting the app instances for you?

From: cf-dev@... <cf-dev@...> on behalf of Siva <mailsiva@...>
Sent: Monday, January 27, 2020 11:22 AM
To: Discussions about Cloud Foundry projects and the system overall. <cf-dev@...>
Subject: Re: [cf-dev] CF app that helps with self-healing
 

[EXTERNAL EMAIL]

Thanks Daniel J and Daniel M for your inputs.
Troy - We are also thinking something along those lines to see of we can use the App Autoscaler for the restarts.

-Siva

On Mon, Jan 27, 2020 at 10:05 AM Troy Topnik <troy.topnik@...> wrote:
Ideally you'd want to trace the application misbehavior to a root cause in the application itself, but I think we've all been in the situation where "turn it off and on again" is an easier solution. :)

I wonder if this could be a feature request for App-AutoScaler? It already has access to the metric types required for the operation, but it would need to be able to take a policy action based on those metrics other than scaling up or down (e.g. "adjustment" : "restart" ).

TT

--
Troy Topnik
Senior Product Manager, 
SUSE Cloud Application Platform 
 



--
http://www.twitter.com/sivabalans
Re: CF app that helps with self-healing

Siva <mailsiva@...>
 

Thanks Daniel J and Daniel M for your inputs.
Troy - We are also thinking something along those lines to see of we can use the App Autoscaler for the restarts.

-Siva


On Mon, Jan 27, 2020 at 10:05 AM Troy Topnik <troy.topnik@...> wrote:
Ideally you'd want to trace the application misbehavior to a root cause in the application itself, but I think we've all been in the situation where "turn it off and on again" is an easier solution. :)

I wonder if this could be a feature request for App-AutoScaler? It already has access to the metric types required for the operation, but it would need to be able to take a policy action based on those metrics other than scaling up or down (e.g. "adjustment" : "restart" ).

TT

--
Troy Topnik
Senior Product Manager, 
SUSE Cloud Application Platform 
 



--
http://www.twitter.com/sivabalans
Re: CF app that helps with self-healing

Troy Topnik
 

Ideally you'd want to trace the application misbehavior to a root cause in the application itself, but I think we've all been in the situation where "turn it off and on again" is an easier solution. :)

I wonder if this could be a feature request for App-AutoScaler? It already has access to the metric types required for the operation, but it would need to be able to take a policy action based on those metrics other than scaling up or down (e.g. "adjustment" : "restart" ).

TT

--
Troy Topnik
Senior Product Manager, 
SUSE Cloud Application Platform 
troy.topnik@...
 
Re: CF app that helps with self-healing

Daniel Mikusa
 



On Fri, Jan 24, 2020 at 5:28 PM Siva <mailsiva@...> wrote:
Hi Daniel,
Thanks for your response.
I am aware of all the options you are suggesting. But what we are looking for is a process to restart an app instance without human intervention from an alert policy in our monitoring system. This monitoring system is outside of CF and does not have access to CF CLI. But it can access REST endpoints.

The cf cli is just a glorified rest client. If you can access the cloud controller API for your foundation, you can do everything I mentioned w/out the cf cli & by using raw rest commands.


+1 to everything Daniel Jones said in his response.

Hope that helps!

Dan

 
For eg - The monitoring system will detect a high CPU utilization on one of the app instance. It will raise an alert which will trigger a policy that will call a REST endpoint of this self healing app. Based on the parameters passed in the request, the self-healing app will restart the requested app instance.
This is required when the app does not know that it is in a bad state but some metrics we are tracking are indicating that the app instance need to be restarted.
Hope that makes sense.

Thanks
Siva

On Fri, Jan 24, 2020 at 9:55 AM Daniel Mikusa <dmikusa@...> wrote:
Not sure I totally get what you are asking, but `cf restart-app-instance` will restart an instance, so if you have an alert trigger a script, you could script the restart.

Or you could just have the app itself know when it gets into a bad state, presumably it would if it's emitting the metrics to indicate this, and exit. When it exits the platform will just restart the app.

Dan


On Fri, Jan 24, 2020 at 12:30 PM Siva <mailsiva@...> wrote:
Dear CF community,
We are trying to find a way to selectively restart some instances of apps or to restart a specific app on an as needed basis based on some alerts that we receive from our monitoring solution. One option we are considering is to have a self-healing app deployed in CF which will have some REST endpoints exposed which we can call from our alert policies that will perform those actions for us. This self-healing app will essentially have the capabilities of CF CLI for stopping and starting services and instances. This app will also be protected by UAA.
Before we go off and start developing this app, I wanted to check if anyone in the CF community has thought about this approach before and have a solution in place or any ideas to consider.

Thanks,
Siva Balan



--

Re: CF app that helps with self-healing

Daniel Jones
 

Hi Siva,

I'm not aware of a similar solution that already exists. A couple of thoughts:
  • Could you use HTTP healthchecks, and have the endpoint return a non-200 status code if the app detects high CPU usage itself?
  • Be mindful of how CPU usage is reported. Whilst current containerisation tech can limit how many CPU shares a process gets, it can't control the system calls that report how much CPU is available. Hence things like `top` will appear inaccurate, and you should ensure the CPU usage statistics come from the metrics that feed into the cpu-entitlement-plugin. If you want to double-check this, there's a blog post (https://www.cloudfoundry.org/blog/better-way-split-cake-cpu-entitlements/) and the folks in the #garden channel are awfully helpful.
  • Having an endpoint that allows remote termination of an app sounds like a bit of a security risk, but I'm sure you'll manage that appropriately.

Regards,
Daniel 'Deejay' Jones - CTO
+44 (0)79 8000 9153
EngineerBetter Ltd - More than cloud platform specialists


On Fri, 24 Jan 2020 at 22:27, Siva <mailsiva@...> wrote:
Hi Daniel,
Thanks for your response.
I am aware of all the options you are suggesting. But what we are looking for is a process to restart an app instance without human intervention from an alert policy in our monitoring system. This monitoring system is outside of CF and does not have access to CF CLI. But it can access REST endpoints.
For eg - The monitoring system will detect a high CPU utilization on one of the app instance. It will raise an alert which will trigger a policy that will call a REST endpoint of this self healing app. Based on the parameters passed in the request, the self-healing app will restart the requested app instance.
This is required when the app does not know that it is in a bad state but some metrics we are tracking are indicating that the app instance need to be restarted.
Hope that makes sense.

Thanks
Siva

On Fri, Jan 24, 2020 at 9:55 AM Daniel Mikusa <dmikusa@...> wrote:
Not sure I totally get what you are asking, but `cf restart-app-instance` will restart an instance, so if you have an alert trigger a script, you could script the restart.

Or you could just have the app itself know when it gets into a bad state, presumably it would if it's emitting the metrics to indicate this, and exit. When it exits the platform will just restart the app.

Dan


On Fri, Jan 24, 2020 at 12:30 PM Siva <mailsiva@...> wrote:
Dear CF community,
We are trying to find a way to selectively restart some instances of apps or to restart a specific app on an as needed basis based on some alerts that we receive from our monitoring solution. One option we are considering is to have a self-healing app deployed in CF which will have some REST endpoints exposed which we can call from our alert policies that will perform those actions for us. This self-healing app will essentially have the capabilities of CF CLI for stopping and starting services and instances. This app will also be protected by UAA.
Before we go off and start developing this app, I wanted to check if anyone in the CF community has thought about this approach before and have a solution in place or any ideas to consider.

Thanks,
Siva Balan



--

Re: CF app that helps with self-healing

Siva <mailsiva@...>
 

Hi Daniel,
Thanks for your response.
I am aware of all the options you are suggesting. But what we are looking for is a process to restart an app instance without human intervention from an alert policy in our monitoring system. This monitoring system is outside of CF and does not have access to CF CLI. But it can access REST endpoints.
For eg - The monitoring system will detect a high CPU utilization on one of the app instance. It will raise an alert which will trigger a policy that will call a REST endpoint of this self healing app. Based on the parameters passed in the request, the self-healing app will restart the requested app instance.
This is required when the app does not know that it is in a bad state but some metrics we are tracking are indicating that the app instance need to be restarted.
Hope that makes sense.

Thanks
Siva


On Fri, Jan 24, 2020 at 9:55 AM Daniel Mikusa <dmikusa@...> wrote:
Not sure I totally get what you are asking, but `cf restart-app-instance` will restart an instance, so if you have an alert trigger a script, you could script the restart.

Or you could just have the app itself know when it gets into a bad state, presumably it would if it's emitting the metrics to indicate this, and exit. When it exits the platform will just restart the app.

Dan


On Fri, Jan 24, 2020 at 12:30 PM Siva <mailsiva@...> wrote:
Dear CF community,
We are trying to find a way to selectively restart some instances of apps or to restart a specific app on an as needed basis based on some alerts that we receive from our monitoring solution. One option we are considering is to have a self-healing app deployed in CF which will have some REST endpoints exposed which we can call from our alert policies that will perform those actions for us. This self-healing app will essentially have the capabilities of CF CLI for stopping and starting services and instances. This app will also be protected by UAA.
Before we go off and start developing this app, I wanted to check if anyone in the CF community has thought about this approach before and have a solution in place or any ideas to consider.

Thanks,
Siva Balan



--
http://www.twitter.com/sivabalans
581 - 600 of 9441