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

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.

This capability seems to be covered by Isolation Segments. You will be

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

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

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

*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

Begin forwarded message:

From: Sree Tummidi <stummidi(a)pivotal.io>
Subject: [cf-dev] IMPORTANT: Upcoming breaking changes in UAA V23/3.9.2/cf-release 248
Date: November 28, 2016 at 1:56:00 PM EST
To: "stummidi(a)pivotal.io" <stummidi(a)pivotal.io>
Reply-To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org>

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