Date   

Re: Cloud Foundry Diego v1.0.0 released, starting EOL schedule for DEAs

Tom S Lee
 

👍
Congrats!

On Wed, Nov 30, 2016 at 11:58 AM, Dieu Cao <dcao(a)pivotal.io> wrote:

Super excited about Diego reaching 1.0!
Congrats to the Diego team!

-Dieu

On Tue, Nov 29, 2016 at 9:53 AM, Eric Malm <emalm(a)pivotal.io> wrote:

Hi, all,

I'm extremely pleased to report that the Cloud Foundry Diego team has now
released version 1.0.0 of diego-release, after having successfully
validated its ambitious scaling targets in a full Cloud Foundry setting. If
you've been following in our public tracker at
https://www.pivotaltracker.com/n/projects/1003146, or joined the
Community Advisory Board discussion earlier this month, you'll have seen
that the Diego team has succeeded in running 200,000 CF apps with a total
of 250,000 instances on a large, Diego-backed CF deployment on GCP.

A key part of achieving this milestone has been replacing the etcd
key-value store with a relational data store, and from version 1.0.0
forward Diego officially supports only MySQL and Postgres databases.
Consequently, if you haven't done so already, please conduct your migration
to one of these two relational stores as soon as possible. Throughout major
version 1, Diego will support migrating data from existing etcd data stores
to MySQL or Postgres, but not standalone etcd deployments. We also
recommend that operators adopt a new set of more granular database
configuration properties introduced in Diego v0.1490.0 instead of the
original monolithic connection string.

As a reminder, the release of Diego v1.0.0 also officially starts the
six-month end-of-life schedule for the DEAs. Please see more details in the
earlier announcement at https://lists.cloudfoundry.org
/archives/list/cf-dev(a)lists.cloudfoundry.org/message/GMXXJ
TTM2Q6SIRGVXSQH4TPLHTVHKNNG/.

Finally, a tremendous thank-you to all of the past and present members of
the Diego team, stretching all the way back to January 2014!

Thanks,
Eric Malm, CF Runtime Diego PM
--
Cheers,

Tom Lee
Senior Manager, Technical Program Manager
Pivotal - Cloud Foundry


Proposed PMC: Open Service Broker API

Chip Childers <cchilders@...>
 

All,

We will be officially proposing the creation of a new PMC within the Cloud
Foundry Foundation to support the efforts of an informal working group that
has been looking to open up governance around the Service Broker API to
other interested ecosystems / projects / companies beyond the CF community.

For those interested, the proposal is here:

https://docs.google.com/document/d/1vT-MkqMUJFOshLEAAqUJSAVTPTIuZ_sHl919m1vKfJ0/edit#


For some background on the informal working group, and why this is good for
the CF ecosystem >
http://thenewstack.io/cloud-foundrys-service-broker-api-role-in-kubernetes-and-open-source-platforms/


-chip
--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815


2017 CF Summit Silicon Valley Contributor Code

Chip Childers <cchilders@...>
 

Hi all!

Some of you may have noticed that the registration is now open for the
upcoming CF Summit in Silicon Valley, and we are offering free passes for
contributors to the project again.

This code can be used by anyone that is a contributor to a Cloud Foundry or
BOSH project. We consider contributions to be project leads, dedicated
committers or even if you have sent in a pull request to one of the
projects.

Use of the code is on the honor system... ;-)

https://www.cloudfoundry.org/summit2017/?utm_source=flash&utm_campaign=summit_2017_sv&utm_medium=eml&utm_term=cloud%20foundry%20summit


Code: CFSV17CONT
Feel free to reach out to me or to events(a)cloudfoundry.org if you have any
questions.

See you there!
--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815


Re: Cloud Foundry Diego v1.0.0 released, starting EOL schedule for DEAs

Dieu Cao <dcao@...>
 

Super excited about Diego reaching 1.0!
Congrats to the Diego team!

-Dieu

On Tue, Nov 29, 2016 at 9:53 AM, Eric Malm <emalm(a)pivotal.io> wrote:

Hi, all,

I'm extremely pleased to report that the Cloud Foundry Diego team has now
released version 1.0.0 of diego-release, after having successfully
validated its ambitious scaling targets in a full Cloud Foundry setting. If
you've been following in our public tracker at https://www.pivotaltracker.
com/n/projects/1003146, or joined the Community Advisory Board discussion
earlier this month, you'll have seen that the Diego team has succeeded in
running 200,000 CF apps with a total of 250,000 instances on a large,
Diego-backed CF deployment on GCP.

A key part of achieving this milestone has been replacing the etcd
key-value store with a relational data store, and from version 1.0.0
forward Diego officially supports only MySQL and Postgres databases.
Consequently, if you haven't done so already, please conduct your migration
to one of these two relational stores as soon as possible. Throughout major
version 1, Diego will support migrating data from existing etcd data stores
to MySQL or Postgres, but not standalone etcd deployments. We also
recommend that operators adopt a new set of more granular database
configuration properties introduced in Diego v0.1490.0 instead of the
original monolithic connection string.

As a reminder, the release of Diego v1.0.0 also officially starts the
six-month end-of-life schedule for the DEAs. Please see more details in the
earlier announcement at https://lists.cloudfoundry.
org/archives/list/cf-dev(a)lists.cloudfoundry.org/message/
GMXXJTTM2Q6SIRGVXSQH4TPLHTVHKNNG/.

Finally, a tremendous thank-you to all of the past and present members of
the Diego team, stretching all the way back to January 2014!

Thanks,
Eric Malm, CF Runtime Diego PM


Re: FW: issue tracker permissions

Lisa Doan <ldoan@...>
 

Hi Marco -- there is a chance we can start this by the end of the year. It
has taken us a little while longer than expected to complete the features
that were ahead of it, but they should be releasing in the next few weeks,
and we then can start to focus on Viewers being able to follow. Due to the
holidays and other year-end distractions, we probably won't complete the
entire feature set by end of year. But it is still very high on our
priority list as we know it is important to you and many of our customers.
My apologies for the delay.

Thanks,
Lisa

On Wed, Nov 30, 2016 at 6:54 AM, Voelz, Marco <marco.voelz(a)sap.com> wrote:

Dear Lisa,



How is the "viewers can follow stories" feature coming along? Today is the
last day of November, I haven't seen it in Tracker's release notes or
received any update from your side since the two mails below. Any chance
that we get that feature by the end of the year?



Warm regards

Marco



*From: *Lisa Doan <ldoan(a)pivotal.io>
*Date: *Monday, 26 September 2016 at 18:26
*To: *"Voelz, Marco" <marco.voelz(a)sap.com>
*Cc: *Guillaume Berche <bercheg(a)gmail.com>, "Discussions about Cloud
Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org>,
Dan Podsedly <dpodsedly(a)pivotal.io>, Chip Childers <
cchilders(a)cloudfoundry.org>, "cholick(a)gmail.com" <cholick(a)gmail.com>

*Subject: *Re: [cf-dev] Re: FW: issue tracker permissions



Hi all -- a couple people reached out asking for a date for Viewers can
follow. We are currently targeting November of this year.


Thanks,

Lisa



On Mon, Sep 26, 2016 at 10:03 AM, Lisa Doan <ldoan(a)pivotal.io> wrote:

Hi all,



Just to re-iterate, we do have this feature prioritized on the Tracker
team. I'm sorry we haven't been able to deliver this yet, but there are a
number of other higher priority items that we must attend to before we can
begin this work. We will keep you posted as we get closer to implementing
this.



Thanks,

Lisa



On Sun, Sep 25, 2016 at 12:54 AM, Voelz, Marco <marco.voelz(a)sap.com>
wrote:

Dear Guillaume,

Thanks for your efforts in this direction. As I already stated before, it
is really a pain that you are not able to follow stories or comment when
not being a member in a Pivotaltracker project. However, github issues
aren’t more than a crutch, probably not even a good one.

For example, GH issues cannot be ordered. They are in the order of
creation, priorization is not visible. Therefore, if you look e.g. at the
BOSH mirror [1], there are a bunch of “unstarted” and “unscheduled” issues,
the first “started” one comes on page 2. For bugs, it gets more confusing.
Most people have the github bot activated, which creates a PT story for
each GH issue created. This is already confusing, because you have two
places where potentially updates to this bug could be located in, and
nobody knows where to look. Add in the mirroring, and now you have three
places, see an example for the buildpacks [2]. All of this is not your
fault, it is a restriction on how GH deals with issues and the fact that
we’re distributing information over more than one place.

While I appreciate your efforts and time spent on this: I strongly feel
that is an issue that can only be solved by one of two options:
• The Pivotaltracker team implementing the necessary functionality
• Migrating to a different tracker

I’m trying all I can to push for the first option by talking to Dan and
Lisa, but other features seem to be more important to the PT team. In
November, it has been a year since I asked for this, so my confidence isn’t
very high that it is going to happen at all. For me that just means option
two is getting more and more realistic every day.

Warm regards
Marco

[1] https://github.com/cf-tm-bot/bosh/issues
[2] https://github.com/cloudfoundry/staticfile-buildpack/issues/85



-----Original Message-----
From: Guillaume Berche <bercheg(a)gmail.com>
Date: Saturday, 24 September 2016 at 12:29
To: "Discussions about Cloud Foundry projects and the system overall." <
cf-dev(a)lists.cloudfoundry.org>
Cc: Chip Childers <cchilders(a)cloudfoundry.org>, "cholick(a)gmail.com" <
cholick(a)gmail.com>, Dan Podsedly <dpodsedly(a)pivotal.io>, Lisa Doan <
ldoan(a)pivotal.io>, "Voelz, Marco" <marco.voelz(a)sap.com>
Subject: Re: [cf-dev] Re: FW: issue tracker permissions

Hi,


The mirroring of foundation projects is around 60% complete. See [5]
for more detailed coverage. This should enable community members to watch
the most active foundation backlogs. I received no notifications of
negative side effects of this mirroring so
far. I'll proceed with mirroring the remaining projects in the next
days/weeks.

There are interesting next steps that could be tackled, such as
enabling commenting on the backlogs, or searching across all foundation
backlog history, see [3]. Let me know if you have interests in discussing
these next steps and current challenges faced by
the mirroring process. The upcoming Frankfurt cfsummit unconference
on monday might be a good place for this, I'd propose a subject if I
receive some interest.


Thanks,


Guillaume.






Guillaume.




On Mon, Sep 5, 2016 at 10:21 PM, Guillaume Berche
<bercheg(a)gmail.com> wrote:

Hi,


We have prototyped at Orange an automatic mirroring of Pivotal Tracker
(PT) stories into github issues. See pivotaltrackermirror at [1], and the
experimental mirror of the buildpack tracker at [2]. I'd like to thanks the
buildpacks team for accepting to join
this experiment and providing us with feedback in the past few weeks.

We hope this could bring the following benefits to the CF community:

1. allow use of the
watching notifications <https://help.github.com/
articles/about-notifications/#types-of-notifications> github feature to
track progress on public pivotal trackers projects: all stories or selected
stories of interest.
2. allow use of
github search features <https://help.github.com/
articles/searching-github> to search Pivotal Tracker content (e.g.
accross multiple mirrored PT projects, or along with other github
repositories hosting the associated code)
3. allow use of
github @mentions <https://help.github.com/articles/basic-writing-and-
formatting-syntax/#mentioning-users-and-teams> to contact github accounts
associated with PT public projects contributors, in the context with a
specific mirrored story
4. mirrored content becomes discoverable: search engines index it,
making it easier to find mirrored PT content such as a stack trace

This is still experimental work. We would like to hear community
feedback about this initiative (how is it useful?), as well as core
contributor teams (are there unexpected side-effects that need to be
handled beyond what we fixed so far [3]?) Do you have
suggestions for enhancements: can you comment/vote/improve in [3]?


Our plan is to progressively extend this experiment to more trackers
listed in [5] (in a rate of a few projects per week). Please report issues
on [3] if you observe negative side effects, or reply to this email if you
have concerns about this mirroring.



There still a fair amount of work ahead to convert this experiment
into a stable tool, and opportunities to provide some new cool features to
the community. Contributions are welcome :-)



Thanks,


Guillaume.



ps: I also recently noticed a PT slack integration [4] that would also
cover use-case #1 (get notifications for all stories in a tracker). I'm not
yet sure what it takes to add it to a given channel.


[1]
https://github.com/orange-cloudfoundry/pivotaltrackermirror <
https://github.com/orange-cloudfoundry/pivotaltrackermirror>
[2] https://github.com/cf-tm-bot/buildpacks
[3]
https://github.com/orange-cloudfoundry/pivotaltrackermirror/issues <
https://github.com/orange-cloudfoundry/pivotaltrackermirror/issues>
[4]
https://cloudfoundry.slack.com/apps/A0F82E7H8-pivotal-tracker <
https://cloudfoundry.slack.com/apps/A0F82E7H8-pivotal-tracker>
[5]
https://github.com/cloudfoundry-community/cf-docs-contrib/wiki <
https://github.com/cloudfoundry-community/cf-docs-contrib/wiki>






Guillaume.




On Sun, May 29, 2016 at 8:05 PM, John Wong
<gokoproject(a)gmail.com> wrote:

Just an idea... Is there a feature in Tracker to always cc
someone/some email address? For non security and non confidential stories
we can Cc this email address automatically which will post to a google
group and a thread will be built as comment is added.
This at least allow a read-only mirror.


Just a thought...


On Sunday, May 29, 2016, Voelz, Marco <marco.voelz(a)sap.com> wrote:

Dear Dan, dear Lisa, dear Chip, dear community,

sorry for digging out this old issue again and again. If you are just
tuning in, here is the situation
·
I like Pivotal Tracker as a product
·
I have to use Tracker for my daily work, as it is currently mandatory
for all CFF projects and all of them use it
·
The restrictions in pivotal tracker make it hard to impossible to do
the daily stuff you want to do within a large open-source community.

After initially bringing this up in November last year, here are a few
of the problems I addressed with Dan in a hangout session in February:
·
To follow stories in a project you need to be a member of that
project. Therefore, you cannot track progress on stories in other projects.
·
To comment on stories, the same restrictions as above apply

It has been 3 months since Dan and I talked, I’ve checked back every 4
weeks with him and what I’ve heard so far is ideas. I haven’t seen a
prototype, any specifics on the current state,
any planning details. It’s not like I’m demanding this feature should
be done by now – I just want to know what is going on.

I have to say I am very unhappy in how this topic is treated. From my
point of view, it seems like there is a huge lack of transparency and
feedback. Please, let me know what’s going on.
I don’t want to switch to a different tracker, such as e.g. trello,
but if the requirements of a large open-source community aren’t heard, then
I don’t know what else to do about this.

Warm regards
Marco

PS: What about a public tracker backlog in tracker, so people can
follow their favorite feature stories and see where they are in the
planning and when they’re done?


On 16/01/16 13:09, "Voelz, Marco" <marco.voelz(a)sap.com> wrote:





Dear all,



it has now been more than a month since I sent my feedback concerning
this feature to the tracker team – I haven't received any reaction to it.

@Chip:
Is there an option you could weigh in for this from the Foundation
perspective? That would be great!



Sorry for being so stubborn about this, but in my opinion this is a
crucial feature for a bug tracker/backlog which is used in an open-source
product. I know that all the people
working directly at pivotal don't feel the pain, because they can
either talk directly to everyone in person or have the necessary rights to
comment/follow in the other projects, but for everyone else this is really,
really a problem.



Warm regards

Marco



On 09/12/15 21:20, "Voelz, Marco" <marco.voelz(a)sap.com> wrote:




Thanks for pointing me to this link. However, we seem to have the same
problem here: This seems like a fire-and-forget solution. Where does this
item go? How can I send it to
other people and have them +1 it, like it, follow it, favorite it or
whatever is necessary to indicate that there is more than 1 person wanting
this feature?




Thanks and warm regards

Marco



On 09/12/15 20:01, "Amit Gupta" <agupta(a)pivotal.io> wrote:




If you're logged in to Tracker, there's a "Help & Updates" link at the
top, and one of the options is Provide Feedback.


On Wed, Dec 9, 2015 at 10:59 AM, Voelz, Marco <marco.voelz(a)sap.com>
wrote:

I'd happily submit a feature request to build up some visible demand
for this – could you point me to the right channel here?




Thanks and warm regards

Marco



On 08/12/15 23:01, "Dieu Cao" <dcao(a)pivotal.io> wrote:





Unfortunately in order to follow a story in tracker, the minimum
required level is "member" which allows you to create/comment/delete
stories in tracker.

I would suggest submitting a request to the pivotal tracker team to
help build up evidence that this is a feature that people want.



-Dieu



On Tue, Dec 8, 2015 at 12:49 PM, Matt Cholick <cholick(a)gmail.com>
wrote:

Sorry to resurrect an older thread, but I wanted to chime in that this
is a frustration I have too. There are several stories in the various CF
teams public backlogs that I'd
like to keep track of.


Is it possible for community members to get enough permissions on our
tracker accounts to add ourselves to the follow list?



-Matt



On Mon, Nov 23, 2015 at 3:10 AM, Koper, Dies <
diesk(a)fast.au.fujitsu.com> wrote:

Hi Marco, Jan,

I sent an email to Tracker support about that last week because we
were hoping to close CLI feature requests on GH and let people follow the
stories on Tracker. Support confirmed that people need to have R/W access
to a project to do that.
I have just replied to ask if they'd consider an enhancement. Not sure
what the proper channel would be to get such a story prioritized.
Will let you know if I get a reply.

Regards,
Dies Koper
Cloud Foundry CLI PM

-----Original Message-----
From: Voelz, Marco [mailto:marco.voelz(a)sap.com]
Sent: Monday, November 23, 2015 8:00 PM
To: Discussions about Cloud Foundry projects and the system overall.
Subject: [cf-dev] Re: FW: issue tracker permissions

Thanks Jan for bringing that up, I've had similar problems with that
as well. Any ideas on how to solve this? Is this a feature that the tracker
team actively works on?
Hitting cmd+r every few days on the same stories doesn't seem like the
best way to stay informed about your favorite features.

Warm regards
Marco



On 19/11/15 09:23, "Sievers, Jan" <jan.sievers(a)sap.com> wrote:

>>Hi,
>>
>>I was trying to watch a story I am interested in
>>https://www.pivotaltracker.com/n/projects/892938/stories/105493826
>>
>>
>>I do have an account but it seems I don't have permissions to watch
nor to comment.
>>
>>Is there something I missed?
>>
>>Regards
>>Jan
>>





































































--
Sent from Jeff Dean's printf() mobile console

















Re: FW: issue tracker permissions

Marco Voelz
 

Dear Lisa,

How is the "viewers can follow stories" feature coming along? Today is the last day of November, I haven't seen it in Tracker's release notes or received any update from your side since the two mails below. Any chance that we get that feature by the end of the year?

Warm regards
Marco

From: Lisa Doan <ldoan(a)pivotal.io>
Date: Monday, 26 September 2016 at 18:26
To: "Voelz, Marco" <marco.voelz(a)sap.com>
Cc: Guillaume Berche <bercheg(a)gmail.com>, "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org>, Dan Podsedly <dpodsedly(a)pivotal.io>, Chip Childers <cchilders(a)cloudfoundry.org>, "cholick(a)gmail.com" <cholick(a)gmail.com>
Subject: Re: [cf-dev] Re: FW: issue tracker permissions

Hi all -- a couple people reached out asking for a date for Viewers can follow. We are currently targeting November of this year.

Thanks,
Lisa

On Mon, Sep 26, 2016 at 10:03 AM, Lisa Doan <ldoan(a)pivotal.io<mailto:ldoan(a)pivotal.io>> wrote:
Hi all,

Just to re-iterate, we do have this feature prioritized on the Tracker team. I'm sorry we haven't been able to deliver this yet, but there are a number of other higher priority items that we must attend to before we can begin this work. We will keep you posted as we get closer to implementing this.

Thanks,
Lisa

On Sun, Sep 25, 2016 at 12:54 AM, Voelz, Marco <marco.voelz(a)sap.com<mailto:marco.voelz(a)sap.com>> wrote:
Dear Guillaume,

Thanks for your efforts in this direction. As I already stated before, it is really a pain that you are not able to follow stories or comment when not being a member in a Pivotaltracker project. However, github issues aren’t more than a crutch, probably not even a good one.

For example, GH issues cannot be ordered. They are in the order of creation, priorization is not visible. Therefore, if you look e.g. at the BOSH mirror [1], there are a bunch of “unstarted” and “unscheduled” issues, the first “started” one comes on page 2. For bugs, it gets more confusing. Most people have the github bot activated, which creates a PT story for each GH issue created. This is already confusing, because you have two places where potentially updates to this bug could be located in, and nobody knows where to look. Add in the mirroring, and now you have three places, see an example for the buildpacks [2]. All of this is not your fault, it is a restriction on how GH deals with issues and the fact that we’re distributing information over more than one place.

While I appreciate your efforts and time spent on this: I strongly feel that is an issue that can only be solved by one of two options:
• The Pivotaltracker team implementing the necessary functionality
• Migrating to a different tracker

I’m trying all I can to push for the first option by talking to Dan and Lisa, but other features seem to be more important to the PT team. In November, it has been a year since I asked for this, so my confidence isn’t very high that it is going to happen at all. For me that just means option two is getting more and more realistic every day.

Warm regards
Marco

[1] https://github.com/cf-tm-bot/bosh/issues
[2] https://github.com/cloudfoundry/staticfile-buildpack/issues/85



-----Original Message-----
From: Guillaume Berche <bercheg(a)gmail.com<mailto:bercheg(a)gmail.com>>
Date: Saturday, 24 September 2016 at 12:29
To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>>
Cc: Chip Childers <cchilders(a)cloudfoundry.org<mailto:cchilders(a)cloudfoundry.org>>, "cholick(a)gmail.com<mailto:cholick(a)gmail.com>" <cholick(a)gmail.com<mailto:cholick(a)gmail.com>>, Dan Podsedly <dpodsedly(a)pivotal.io<mailto:dpodsedly(a)pivotal.io>>, Lisa Doan <ldoan(a)pivotal.io<mailto:ldoan(a)pivotal.io>>, "Voelz, Marco" <marco.voelz(a)sap.com<mailto:marco.voelz(a)sap.com>>
Subject: Re: [cf-dev] Re: FW: issue tracker permissions

Hi,


The mirroring of foundation projects is around 60% complete. See [5] for more detailed coverage. This should enable community members to watch the most active foundation backlogs. I received no notifications of negative side effects of this mirroring so
far. I'll proceed with mirroring the remaining projects in the next days/weeks.

There are interesting next steps that could be tackled, such as enabling commenting on the backlogs, or searching across all foundation backlog history, see [3]. Let me know if you have interests in discussing these next steps and current challenges faced by
the mirroring process. The upcoming Frankfurt cfsummit unconference on monday might be a good place for this, I'd propose a subject if I receive some interest.


Thanks,


Guillaume.






Guillaume.




On Mon, Sep 5, 2016 at 10:21 PM, Guillaume Berche
<bercheg(a)gmail.com<mailto:bercheg(a)gmail.com>> wrote:

Hi,


We have prototyped at Orange an automatic mirroring of Pivotal Tracker (PT) stories into github issues. See pivotaltrackermirror at [1], and the experimental mirror of the buildpack tracker at [2]. I'd like to thanks the buildpacks team for accepting to join
this experiment and providing us with feedback in the past few weeks.

We hope this could bring the following benefits to the CF community:

1. allow use of the
watching notifications <https://help.github.com/articles/about-notifications/#types-of-notifications> github feature to track progress on public pivotal trackers projects: all stories or selected stories of interest.
2. allow use of
github search features <https://help.github.com/articles/searching-github> to search Pivotal Tracker content (e.g. accross multiple mirrored PT projects, or along with other github repositories hosting the associated code)
3. allow use of
github @mentions <https://help.github.com/articles/basic-writing-and-formatting-syntax/#mentioning-users-and-teams> to contact github accounts associated with PT public projects contributors, in the context with a specific mirrored story
4. mirrored content becomes discoverable: search engines index it, making it easier to find mirrored PT content such as a stack trace

This is still experimental work. We would like to hear community feedback about this initiative (how is it useful?), as well as core contributor teams (are there unexpected side-effects that need to be handled beyond what we fixed so far [3]?) Do you have
suggestions for enhancements: can you comment/vote/improve in [3]?


Our plan is to progressively extend this experiment to more trackers listed in [5] (in a rate of a few projects per week). Please report issues on [3] if you observe negative side effects, or reply to this email if you have concerns about this mirroring.



There still a fair amount of work ahead to convert this experiment into a stable tool, and opportunities to provide some new cool features to the community. Contributions are welcome :-)



Thanks,


Guillaume.



ps: I also recently noticed a PT slack integration [4] that would also cover use-case #1 (get notifications for all stories in a tracker). I'm not yet sure what it takes to add it to a given channel.


[1]
https://github.com/orange-cloudfoundry/pivotaltrackermirror <https://github.com/orange-cloudfoundry/pivotaltrackermirror>
[2] https://github.com/cf-tm-bot/buildpacks
[3]
https://github.com/orange-cloudfoundry/pivotaltrackermirror/issues <https://github.com/orange-cloudfoundry/pivotaltrackermirror/issues>
[4]
https://cloudfoundry.slack.com/apps/A0F82E7H8-pivotal-tracker <https://cloudfoundry.slack.com/apps/A0F82E7H8-pivotal-tracker>
[5]
https://github.com/cloudfoundry-community/cf-docs-contrib/wiki <https://github.com/cloudfoundry-community/cf-docs-contrib/wiki>





Guillaume.




On Sun, May 29, 2016 at 8:05 PM, John Wong
<gokoproject(a)gmail.com<mailto:gokoproject(a)gmail.com>> wrote:

Just an idea... Is there a feature in Tracker to always cc someone/some email address? For non security and non confidential stories we can Cc this email address automatically which will post to a google group and a thread will be built as comment is added.
This at least allow a read-only mirror.


Just a thought...


On Sunday, May 29, 2016, Voelz, Marco <marco.voelz(a)sap.com<mailto:marco.voelz(a)sap.com>> wrote:

Dear Dan, dear Lisa, dear Chip, dear community,

sorry for digging out this old issue again and again. If you are just tuning in, here is the situation
·
I like Pivotal Tracker as a product
·
I have to use Tracker for my daily work, as it is currently mandatory for all CFF projects and all of them use it
·
The restrictions in pivotal tracker make it hard to impossible to do the daily stuff you want to do within a large open-source community.

After initially bringing this up in November last year, here are a few of the problems I addressed with Dan in a hangout session in February:
·
To follow stories in a project you need to be a member of that project. Therefore, you cannot track progress on stories in other projects.
·
To comment on stories, the same restrictions as above apply

It has been 3 months since Dan and I talked, I’ve checked back every 4 weeks with him and what I’ve heard so far is ideas. I haven’t seen a prototype, any specifics on the current state,
any planning details. It’s not like I’m demanding this feature should be done by now – I just want to know what is going on.

I have to say I am very unhappy in how this topic is treated. From my point of view, it seems like there is a huge lack of transparency and feedback. Please, let me know what’s going on.
I don’t want to switch to a different tracker, such as e.g. trello, but if the requirements of a large open-source community aren’t heard, then I don’t know what else to do about this.

Warm regards
Marco

PS: What about a public tracker backlog in tracker, so people can follow their favorite feature stories and see where they are in the planning and when they’re done?


On 16/01/16 13:09, "Voelz, Marco" <marco.voelz(a)sap.com<mailto:marco.voelz(a)sap.com>> wrote:





Dear all,



it has now been more than a month since I sent my feedback concerning this feature to the tracker team – I haven't received any reaction to it.

@Chip:
Is there an option you could weigh in for this from the Foundation perspective? That would be great!



Sorry for being so stubborn about this, but in my opinion this is a crucial feature for a bug tracker/backlog which is used in an open-source product. I know that all the people
working directly at pivotal don't feel the pain, because they can either talk directly to everyone in person or have the necessary rights to comment/follow in the other projects, but for everyone else this is really, really a problem.



Warm regards

Marco



On 09/12/15 21:20, "Voelz, Marco" <marco.voelz(a)sap.com<mailto:marco.voelz(a)sap.com>> wrote:




Thanks for pointing me to this link. However, we seem to have the same problem here: This seems like a fire-and-forget solution. Where does this item go? How can I send it to
other people and have them +1 it, like it, follow it, favorite it or whatever is necessary to indicate that there is more than 1 person wanting this feature?




Thanks and warm regards

Marco



On 09/12/15 20:01, "Amit Gupta" <agupta(a)pivotal.io<mailto:agupta(a)pivotal.io>> wrote:




If you're logged in to Tracker, there's a "Help & Updates" link at the top, and one of the options is Provide Feedback.


On Wed, Dec 9, 2015 at 10:59 AM, Voelz, Marco <marco.voelz(a)sap.com<mailto:marco.voelz(a)sap.com>> wrote:

I'd happily submit a feature request to build up some visible demand for this – could you point me to the right channel here?




Thanks and warm regards

Marco



On 08/12/15 23:01, "Dieu Cao" <dcao(a)pivotal.io<mailto:dcao(a)pivotal.io>> wrote:





Unfortunately in order to follow a story in tracker, the minimum required level is "member" which allows you to create/comment/delete stories in tracker.

I would suggest submitting a request to the pivotal tracker team to help build up evidence that this is a feature that people want.



-Dieu



On Tue, Dec 8, 2015 at 12:49 PM, Matt Cholick <cholick(a)gmail.com<mailto:cholick(a)gmail.com>> wrote:

Sorry to resurrect an older thread, but I wanted to chime in that this is a frustration I have too. There are several stories in the various CF teams public backlogs that I'd
like to keep track of.


Is it possible for community members to get enough permissions on our tracker accounts to add ourselves to the follow list?



-Matt



On Mon, Nov 23, 2015 at 3:10 AM, Koper, Dies <diesk(a)fast.au.fujitsu.com<mailto:diesk(a)fast.au.fujitsu.com>> wrote:

Hi Marco, Jan,

I sent an email to Tracker support about that last week because we were hoping to close CLI feature requests on GH and let people follow the stories on Tracker. Support confirmed that people need to have R/W access to a project to do that.
I have just replied to ask if they'd consider an enhancement. Not sure what the proper channel would be to get such a story prioritized.
Will let you know if I get a reply.

Regards,
Dies Koper
Cloud Foundry CLI PM

-----Original Message-----
From: Voelz, Marco [mailto:marco.voelz(a)sap.com<mailto:marco.voelz(a)sap.com>]
Sent: Monday, November 23, 2015 8:00 PM
To: Discussions about Cloud Foundry projects and the system overall.
Subject: [cf-dev] Re: FW: issue tracker permissions

Thanks Jan for bringing that up, I've had similar problems with that as well. Any ideas on how to solve this? Is this a feature that the tracker team actively works on?
Hitting cmd+r every few days on the same stories doesn't seem like the best way to stay informed about your favorite features.

Warm regards
Marco



On 19/11/15 09:23, "Sievers, Jan" <jan.sievers(a)sap.com<mailto:jan.sievers(a)sap.com>> wrote:

>>Hi,
>>
>>I was trying to watch a story I am interested in
>>https://www.pivotaltracker.com/n/projects/892938/stories/105493826
>>
>>
>>I do have an account but it seems I don't have permissions to watch nor to comment.
>>
>>Is there something I missed?
>>
>>Regards
>>Jan
>>





































































--
Sent from Jeff Dean's printf() mobile console


bosh-lite becoming unresponsive

Peter Goetz <peter.gtz@...>
 

Hi all,

Has anyone experienced the problem before that bosh-lite simply becomes
unresponsive and completely locked up?

It seems that it is somehow connected to high CPU load on the vagrant VM,
or using up all memory. We've noticed this, when misconfiguring the
deployment manifest and causing gnatsd to eat up all CPUs. Unfortunately,
sometimes they seem to die also without high load. They never die when no
CF is deployed.

When they die, neither any `bosh` commands that try to access the director
work, nor a `vagrant ssh` gets into the machine, which suggests that the
machine has completely stalled.

The only thing that works is a `vagrant reload` and a subsequent `bosh
cck` (or deleting deployment) which is extremely time-consuming.

Any help is appreciated.
Thanks,
Peter


[ CF-243 / Blobstore ] Troubleshooting errors in internal_error.log

Fabien Guichard
 

Hello,

we're currently dealing with a problem with cf push and cf restage actions, which result in this error message :

2016-11-29T17:37:11.51+0100 [STG/0] OUT Exit status 0
2016-11-29T17:37:11.51+0100 [STG/0] OUT Staging complete
2016-11-29T17:37:11.51+0100 [STG/0] OUT Uploading droplet, build artifacts cache...
2016-11-29T17:37:11.51+0100 [STG/0] OUT Uploading droplet...
2016-11-29T17:37:11.51+0100 [STG/0] OUT Uploading build artifacts cache...
2016-11-29T17:37:11.51+0100 [STG/0] ERR Uploading failed
2016-11-29T17:37:11.52+0100 [STG/0] OUT Destroying container
2016-11-29T17:37:11.57+0100 [API/1] ERR Failed to stage application: staging failed
2016-11-29T17:37:12.51+0100 [STG/0] OUT Successfully destroyed container

So, we decided to investigate this way : blobstore => cc => cc-bridge (stager + cc-uploader).

Here what we saw in internal_error.log of the blobstore job :

:2016/11/29 23:18:57 [error] 6000#0: *2148 open() "/var/vcap/store/shared/cc-droplets/buildpack_cache/69/95/69954a51-4882-4992-9370-528fbc21e8e6/cflinuxfs2" failed (2: No such file or directory), client: 10.X.Y.Z, server: blobstore.service.cf.internal, request: "HEAD /admin/cc-droplets/buildpack_cache/69/95/69954a51-4882-4992-9370-528fbc21e8e6/cflinuxfs2 HTTP/1.1", host: "blobstore.service.cf.internal:4443"

2016/11/29 23:19:18 [error] 6000#0: *2168 open() "/var/vcap/store/shared/cc-droplets/buildpack_cache/69/95/69954a51-4882-4992-9370-528fbc21e8e6/cflinuxfs2" failed (2: No such file or directory), client: 10.X.Y.Z, server: blobstore.service.cf.internal, request: "HEAD /admin/cc-droplets/buildpack_cache/69/95/69954a51-4882-4992-9370-528fbc21e8e6/cflinuxfs2 HTTP/1.1", host: "blobstore.service.cf.internal:4443"

Basically, nginx is being cheated by cc (client ip addresses in log file are those of cc vms), which provide wrong path.

We thought about trying to recreate all cc vms with bosh to solve this issue, but we wanted to understand where and how those http request we're built.

Before we go into some costly reverse-engineering on cc source code, cc schema and so on, we want to ask if :

1) this kind of pattern errors is already known to some of you
2) if you have some hints to provide to address effectively cc logic :)

Many thx if you're able to help us with an answer.

Thanks for having read this thread.

Regards,
Fabien Guichard.


Re: Cloud Foundry Environment Variable Validation

Tim Lawrence <tim.lawrence1984@...>
 

CF seems like it could be used as a prefix for a number of apps outside the
ecosystem. Would it be better to specifically exclude the full CF strings
in question rather than a CF_* wildcard?

Tim

On Tue, Nov 29, 2016 at 8:40 PM, Nicholas Calugar <ncalugar(a)pivotal.io>
wrote:

Hi CF,

CAPI would like to introduce a validation where we disallow environment
variables that begin with “CF_”. For context, we already [1] have several
validations for environment variables, e.g. “VCAP_”. We would like to
prohibit “CF_” for a couple reasons:

1. There are several environment variables with the prefix “CF_” that
are already set in containers running on the platform. Currently, without
this validation, users can override these with app environment variables.
2. VCAP_APPLICATION doesn’t quite fit for the V3 API world where apps
can be made up of multiple processes and tasks. See [2] original discussion
and [3] proposed environment variables we will introduce as we roll out the
V3 API.


If this is acceptable, we’d like to propose adding this validation in an
upcoming version of Cloud Foundry. The plan might look something like this:

1. Announce that the validation would be added in a certain version of
Cloud Foundry.
2. Complete the [3] story for the new “CF_” environment variables.
3. Announce the version where we will remove VCAP_APPLICATION, say
completion of above story + 5 versions.



Please let us know if you have any feedback for the validation itself or
the plan to roll this out.

Thanks!

Nick


[1] https://github.com/cloudfoundry/cloud_controller_
ng/blob/master/app/messages/validators.rb#L41-L47
[2] https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.
cloudfoundry.org/thread/LTF4NAKWF56SEER57ZNBO5SLM72NPTQJ/#
LTF4NAKWF56SEER57ZNBO5SLM72NPTQJ
[3] https://www.pivotaltracker.com/story/show/126180869

--
Nicholas Calugar
Product Manager - Cloud Foundry API
Pivotal Software, Inc.


Re: Cloud Foundry Environment Variable Validation

Michael Fraenkel <michael.fraenkel@...>
 

I vote that VCAP_APPLICATION not be removed.
While it is nice that we want to replace certain environment variables,
these have been there since day one. Asking people to rewrite their
applications is just wrong.

I do not see how we are tying a programming model discussion with an API
version. If we want to change the programming model of CF, then document
what the programming model is currently, and provide a way for people to
opt in to this new model. But I would certainly hope it is more than
just twiddling environment variables. A silly change will cause a lot of
pain.

- Michael

On 11/29/16 4:11 PM, Mike Youngstrom wrote:
That plan sounds good to me. I'd only ask that we attempt to lock
down how long we are going to keep VCAP_APPLICATION around sooner than
later. It will take time for our customers to transition their
application to the new variable and our customers work off of time
schedules not X number of CF releases. I'd like to see
VCAP_APPLICATION stay around for at least 3 months after the new
variable is available.

Mike

On Tue, Nov 29, 2016 at 1:40 PM, Nicholas Calugar <ncalugar(a)pivotal.io
<mailto:ncalugar(a)pivotal.io>> wrote:

Hi CF,

CAPI would like to introduce a validation where we disallow
environment variables that begin with “CF_”. For context, we
already [1] have several validations for environment variables,
e.g. “VCAP_”. We would like to prohibit “CF_” for a couple reasons:

1. There are several environment variables with the prefix “CF_”
that are already set in containers running on the platform.
Currently, without this validation, users can override these
with app environment variables.
2. VCAP_APPLICATION doesn’t quite fit for the V3 API world where
apps can be made up of multiple processes and tasks. See [2]
original discussion and [3] proposed environment variables we
will introduce as we roll out the V3 API.


If this is acceptable, we’d like to propose adding this validation
in an upcoming version of Cloud Foundry. The plan might look
something like this:

1. Announce that the validation would be added in a certain
version of Cloud Foundry.
2. Complete the [3] story for the new “CF_” environment variables.
3. Announce the version where we will remove VCAP_APPLICATION,
say completion of above story + 5 versions.



Please let us know if you have any feedback for the validation
itself or the plan to roll this out.

Thanks!

Nick


[1]
https://github.com/cloudfoundry/cloud_controller_ng/blob/master/app/messages/validators.rb#L41-L47
<https://github.com/cloudfoundry/cloud_controller_ng/blob/master/app/messages/validators.rb#L41-L47>

[2]
https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/thread/LTF4NAKWF56SEER57ZNBO5SLM72NPTQJ/#LTF4NAKWF56SEER57ZNBO5SLM72NPTQJ
<https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/thread/LTF4NAKWF56SEER57ZNBO5SLM72NPTQJ/#LTF4NAKWF56SEER57ZNBO5SLM72NPTQJ>
[3] https://www.pivotaltracker.com/story/show/126180869
<https://www.pivotaltracker.com/story/show/126180869>

--
Nicholas Calugar
Product Manager - Cloud Foundry API
Pivotal Software, Inc.


Re: Cloud Foundry Environment Variable Validation

Mike Youngstrom
 

That plan sounds good to me. I'd only ask that we attempt to lock down how
long we are going to keep VCAP_APPLICATION around sooner than later. It
will take time for our customers to transition their application to the new
variable and our customers work off of time schedules not X number of CF
releases. I'd like to see VCAP_APPLICATION stay around for at least 3
months after the new variable is available.

Mike

On Tue, Nov 29, 2016 at 1:40 PM, Nicholas Calugar <ncalugar(a)pivotal.io>
wrote:

Hi CF,

CAPI would like to introduce a validation where we disallow environment
variables that begin with “CF_”. For context, we already [1] have several
validations for environment variables, e.g. “VCAP_”. We would like to
prohibit “CF_” for a couple reasons:

1. There are several environment variables with the prefix “CF_” that
are already set in containers running on the platform. Currently, without
this validation, users can override these with app environment variables.
2. VCAP_APPLICATION doesn’t quite fit for the V3 API world where apps
can be made up of multiple processes and tasks. See [2] original discussion
and [3] proposed environment variables we will introduce as we roll out the
V3 API.


If this is acceptable, we’d like to propose adding this validation in an
upcoming version of Cloud Foundry. The plan might look something like this:

1. Announce that the validation would be added in a certain version of
Cloud Foundry.
2. Complete the [3] story for the new “CF_” environment variables.
3. Announce the version where we will remove VCAP_APPLICATION, say
completion of above story + 5 versions.



Please let us know if you have any feedback for the validation itself or
the plan to roll this out.

Thanks!

Nick


[1] https://github.com/cloudfoundry/cloud_controller_
ng/blob/master/app/messages/validators.rb#L41-L47
[2] https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.
cloudfoundry.org/thread/LTF4NAKWF56SEER57ZNBO5SLM72NPTQJ/#
LTF4NAKWF56SEER57ZNBO5SLM72NPTQJ
[3] https://www.pivotaltracker.com/story/show/126180869

--
Nicholas Calugar
Product Manager - Cloud Foundry API
Pivotal Software, Inc.


Cloud Foundry Environment Variable Validation

Nicholas Calugar
 

Hi CF,

CAPI would like to introduce a validation where we disallow environment
variables that begin with “CF_”. For context, we already [1] have several
validations for environment variables, e.g. “VCAP_”. We would like to
prohibit “CF_” for a couple reasons:

1. There are several environment variables with the prefix “CF_” that
are already set in containers running on the platform. Currently, without
this validation, users can override these with app environment variables.
2. VCAP_APPLICATION doesn’t quite fit for the V3 API world where apps
can be made up of multiple processes and tasks. See [2] original discussion
and [3] proposed environment variables we will introduce as we roll out the
V3 API.


If this is acceptable, we’d like to propose adding this validation in an
upcoming version of Cloud Foundry. The plan might look something like this:

1. Announce that the validation would be added in a certain version of
Cloud Foundry.
2. Complete the [3] story for the new “CF_” environment variables.
3. Announce the version where we will remove VCAP_APPLICATION, say
completion of above story + 5 versions.



Please let us know if you have any feedback for the validation itself or
the plan to roll this out.

Thanks!

Nick


[1]
https://github.com/cloudfoundry/cloud_controller_ng/blob/master/app/messages/validators.rb#L41-L47
[2]
https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/thread/LTF4NAKWF56SEER57ZNBO5SLM72NPTQJ/#LTF4NAKWF56SEER57ZNBO5SLM72NPTQJ
[3] https://www.pivotaltracker.com/story/show/126180869

--
Nicholas Calugar
Product Manager - Cloud Foundry API
Pivotal Software, Inc.


Cloud Foundry Diego v1.0.0 released, starting EOL schedule for DEAs

Eric Malm <emalm@...>
 

Hi, all,

I'm extremely pleased to report that the Cloud Foundry Diego team has now
released version 1.0.0 of diego-release, after having successfully
validated its ambitious scaling targets in a full Cloud Foundry setting. If
you've been following in our public tracker at
https://www.pivotaltracker.com/n/projects/1003146, or joined the Community
Advisory Board discussion earlier this month, you'll have seen that the
Diego team has succeeded in running 200,000 CF apps with a total of 250,000
instances on a large, Diego-backed CF deployment on GCP.

A key part of achieving this milestone has been replacing the etcd
key-value store with a relational data store, and from version 1.0.0
forward Diego officially supports only MySQL and Postgres databases.
Consequently, if you haven't done so already, please conduct your migration
to one of these two relational stores as soon as possible. Throughout major
version 1, Diego will support migrating data from existing etcd data stores
to MySQL or Postgres, but not standalone etcd deployments. We also
recommend that operators adopt a new set of more granular database
configuration properties introduced in Diego v0.1490.0 instead of the
original monolithic connection string.

As a reminder, the release of Diego v1.0.0 also officially starts the
six-month end-of-life schedule for the DEAs. Please see more details in the
earlier announcement at
https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/message/GMXXJTTM2Q6SIRGVXSQH4TPLHTVHKNNG/
.

Finally, a tremendous thank-you to all of the past and present members of
the Diego team, stretching all the way back to January 2014!

Thanks,
Eric Malm, CF Runtime Diego PM


Re: Proposal of Private Stacks ( Stacks for limited users ) (Re: Private Stacks ( Stacks for limited users ))

Nicholas Calugar
 

Hi,

Without more evidence of other operators needing this feature, I’m hesitant
to introduce a new API resource. I’ll add this to our someday / maybe list
for now.


Thanks,

Nick

--
Nicholas Calugar

On November 29, 2016 at 8:51:46 AM, Takahito SEYAMA (t.seyama20(a)gmail.com)
wrote:

Hi Nick,

Thanks for you reply.

This capability seems to be covered by Isolation Segments. You will be
able to assign a space to have access to an Isolation Segment where the
“private” stack is available. Other spaces, while able to see the “private”
stack with `cf stacks`, won’t be able to deploy apps to that Isolation
Segment and will have to use the default stack.

We agree that Isolation Segments seems to be able to address similar use
cases. However, as described above, Isolation Segment can not hide
existence of the stack. We think there are cases that users (especially
using stacks that contains proprietary resources, referred in Design
Document[1]) want to hide even existence of their stacks from public.
Private Stack can address such cases.

In addition, Private Stacks allows different stacks to coexist on the same
Cell. For example, cflinuxfs2 and centos can be delivered on in one Cell,
while Private Stacks can provide centos stack for the limited users. This
will contribute reducing both resource cost and management cost because
Isolation Segments requires different cells for each different stack.

[1]
https://docs.google.com/document/d/1_540iCJlMWQw7q4-JZHKYY_Pk3fmhcJk-vurAM4DcZQ/edit#heading=h.v0o3dngekgnu

Regards,
t.seyama

2016-11-01 1:42 GMT+09:00 Nicholas Calugar <ncalugar(a)pivotal.io>:

Hi,

This capability seems to be covered by Isolation Segments. You will be
able to assign a space to have access to an Isolation Segment where the
“private” stack is available. Other spaces, while able to see the “private”
stack with `cf stacks`, won’t be able to deploy apps to that Isolation
Segment and will have to use the default stack.

Does this cover your use case?


Thanks,

Nick

--
Nicholas Calugar
Product Manager - Cloud Foundry API
Pivotal Software, Inc.

On October 31, 2016 at 8:55:39 AM, 瀬山貴仁 (t.seyama20(a)gmail.com) wrote:

Hi all,

We want "Stacks" for limited number of users. Stacks are Cloud Foundry
structure, which provides base runtime environment of applications. In the
current implementation of Cloud Foundry, all Stacks are public and shared
by all users.
However, there should be situations to use (or provide) Stack for limited
number of users. It is possible to provide a special Stack which require
additional supports, to use proprietary resource and so on.

We named these "Private Stacks". Private Stacks's Design Document is here(
https://docs.google.com/document/d/1_540iCJlMWQw7q4-
JZHKYY_Pk3fmhcJk-vurAM4DcZQ/edit?usp=sharing ). In addition, We have
already made Minimal Viable Feature and sent Pull Request(
https://github.com/cloudfoundry/cloud_controller_ng/pull/707 ).
* This Pull Request is not for merge but for discussion.

Please comment for feature to Design Document and for implementation to
Pull Request if you have any.

Regards,
t.seyama


Runtime PMC - Greenhouse/BOSH on Windows Project Lead Call for Nominations

Dieu Cao <dcao@...>
 

Hello all,

David Morhovich, the Project Lead for the Greenhouse/BOSH on Windows team
within the Runtime PMC, will be transitioning back to an engineering role
in the new year. We wish him well in his future endeavors and thank him for
his time serving as the Greenhouse/BOSH on Windows Project Lead. The
Greenhouse/BOSH on Windows team, primarily located in New York, New York,
now has an opening for its project lead. Project leads must be nominated by
a Cloud Foundry Foundation member. Please send nominations to me/in reply
to this posting by end of day December 6th, 2016. If you have any questions
about the role/process, please let me know. These are described in the CFF
governance documents. [1] -Dieu Cao Runtime PMC Lead [1]
https://www.cloudfoundry.org/wp-content/uploads/2015/
09/CFF_Development_Operations_Policy.pdf


Logging JSON to disk

Jason Keene
 

I've noticed quite a few CF components log JSON to disk. Is there a
rational for why this is the case? As an operator debugging issues, trying
to manually parse JSON is brutal. This is only compounded with not having
something like jq installed in our stemcells.

Does anyone know why this is the case, or is this just something that got
cargo culted?


consul_z1 not running after updating

fang <fang_cloud@...>
 

I am deploying cloudfoundry on aws.

Failed: 'consul_z1/0 (411b0812-c3c2-4bec-8114-1eacb53b2dd5)' is not running
after update. Review logs for failed jobs: consul_agent, metron_agent



logs in metron_agent:

2016/11/28 11:08:40 RuntimeStats: failed to emit: EventWriter: No envelope
writer set (see SetWriter)
{"timestamp":1480330660.615530491,"process_id":7989,"source":"metron","log_level":"warn","message":"Failed
to connect to etcd. Number of tries: 5. Backing off for
15.662ms.","data":{"error":"sync cluster

consul logs:
error during start: timeout exceeded: "Get
http://127.0.0.1:8500/v1/agent/self: dial tcp 127.0.0.1:8500: getsockopt:
connection refused"

==> Error starting agent: Failed to start Consul server: Failed to parse any
CA certificates


Could anybody help?

-xiaoshan



--
View this message in context: http://cf-dev.70369.x6.nabble.com/consul-z1-not-running-after-updating-tp6165.html
Sent from the CF Dev mailing list archive at Nabble.com.


Re: Memory/Disk usage information -MB vs MiB

Ponraj E
 

Hi Nicholas,

There are so many API endpoints that returns response in MB. One such example is: http://apidocs.cloudfoundry.org/234/organizations/retrieving_organization_memory_usage.html

Do you need all of them?

--
Ponraj


Re: Memory/Disk usage information -MB vs MiB

Nicholas Calugar
 

Hi Ponraj and Daniel,

Could you point me at documentation or API endpoints you are looking at the
use MB?


Thanks,

Nick

--
Nicholas Calugar
Product Manager - Cloud Foundry API
Pivotal Software, Inc.

On November 28, 2016 at 2:42:07 PM, Daniel Jones (
daniel.jones(a)engineerbetter.com) wrote:

+1 for proper units (KiB, MiB)

Regards,
Daniel Jones - CTO
+44 (0)79 8000 9153
@DanielJonesEB <https://twitter.com/DanielJonesEB>
*EngineerBetter* Ltd <http://www.engineerbetter.com> - UK Cloud Foundry
Specialists

On Thu, Nov 24, 2016 at 7:00 AM, Ponraj E <ponraj.e(a)gmail.com> wrote:

Hi Colleagues,

I see CF using base 2 (1024 * 1024) for all the memory/disk quota/usage
information, but base 10's unit at the end(MB). For ex, CF returns app
instance memory as 1024 MB [using base 2 defintion (1024) and base 10's
unit (MB)].

The problem arises when we have a client which does the
conversion/formatting rightly and the values tend to differ from CF and the
client. Though this confusion has been in varied existence still (for ex:
Disk size of HDD), does CF have any plans of using one particular defintion
throughout, like either 1024 MiB or 1000 MB?

P.S :
base 2 definition: 1 Kibibyte = 1024 Byte
base 10 defintion: 1 Kilobyte = 1000 Byte

------
Ponraj


Re: IMPORTANT: Upcoming breaking changes in UAA V23/3.9.2/cf-release 248

Sree Tummidi
 

I have been informed by the CAPI team that the changes in Cloud Controller
to use the new rotatable signing key format is not yet in place and is
blocked on some fixes for CF-UAA-LIB
<https://www.pivotaltracker.com/n/projects/997278/stories/133947925>

For *CF-Release ONLY*, please continue to use the deprecated way of setting
the UAA JWT Signing and Verification key as mentioned below.
We will be sending out a separate notification on when we are ready to make
the switch to rotatable signing key format.

*uaa.jwt.signing_key:*
description: "The key used to sign the JWT-based OAuth2 tokens"
*uaa.jwt.verification_key:*
description: "The key used to verify JWT-based OAuth2 tokens"



Thanks,
Sree Tummidi
Staff Product Manager
Identity - Pivotal Cloud Foundry

On Mon, Nov 28, 2016 at 11:41 AM, Sree Tummidi <stummidi(a)pivotal.io> wrote:

Hi Michael,

This is the new way to specify the signing key used by UAA for signing the
JWT tokens. This format allows for rotation of the keys.
bosh-lite is currently using the deprecated properties mentioned below. We
will be changing these use the new rotatable properties in a subsequent
version.

Thank you bringing this up as I should have been clear in my
communication. UAA is no longer shipped with a default signing key. There
are two ways to set this key. I mentioned moving to the new format in my
previous email.

*Deprecated Format*

*uaa.jwt.signing_key:*
description: "Deprecated. Use uaa.jwt.policy.keys. The key used to sign
the JWT-based OAuth2 tokens"
*uaa.jwt.verification_key:*
description: "Deprecated. Use uaa.jwt.policy.keys. The key used to verify
JWT-based OAuth2 tokens"


*New Format (verification key needn't be set as we derive it from the
Private Key)*

*uaa.jwt.policy.keys:*
description: "Map of key IDs and signing keys, each defined with a
property `signingKey`"
example:
key-1:
signingKey: |
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----

* uaa.jwt.policy.active_key_id:*
description: "The ID of the JWT signing key to be used when signing
tokens."
example: "key-1"



Thanks,
Sree Tummidi
Staff Product Manager
Identity - Pivotal Cloud Foundry


On Mon, Nov 28, 2016 at 11:29 AM, Michael Fraenkel <
michael.fraenkel(a)gmail.com> wrote:

How are the following required when they aren't used in bosh-lite?


*uaa.jwt.policy.keys: *
* uaa.jwt.policy.active_key_id:*

How does one migrate from what we have to these?

- Michael


On 11/28/16 1:56 PM, Sree Tummidi wrote:

*Please read carefully if you are using UAA as standalone or as a bosh
release or part of cf-release*


Starting with UAA bosh release V23
<http://bosh.io/releases/github.com/cloudfoundry/uaa-release?version=23> which
packages UAA 3.9.2
<https://github.com/cloudfoundry/uaa/releases/tag/3.9.2> and *cf-release
248 (in works)* the following *properties have been made required.*

These are standard artifacts which can be generated using openssl. Please
refer the topic here
<https://github.com/cloudfoundry/uaa-release#generating-a-self-signed-certificate> on
how to generate a self signed cert.


*login.saml.serviceProviderCertificate:*
description: "UAA SAML Service provider certificate. This is used for
signing outgoing SAML Authentication Requests"
example: |
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE----

*login.saml.serviceProviderKey:*
description: "Private key for the service provider certificate."
example: |
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----


*uaa.jwt.policy.keys:*
description: "Map of key IDs and signing keys, each defined with a
property `signingKey`"
example:
key-1:
signingKey: |
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----

* uaa.jwt.policy.active_key_id:*
description: "The ID of the JWT signing key to be used when signing
tokens."
example: "key-1"


Thanks,
Sree Tummidi
Staff Product Manager
Identity - Pivotal Cloud Foundry



3301 - 3320 of 9425