Date   

Diego as Default?

Leandro David Cacciagioni
 

guys is there any reason why Diego is not enabled by default in the
`generate_deployment_manifest` templates? AFAIK DEA arch is being
deprecated in a few months so I think it could be good to already have it
as default.

Then since Diego is not in the defaults which guide did I follow for AWS
diego deployment the ones in Diego docs(
https://github.com/cloudfoundry/diego-release/tree/develop/examples/aws),
the ones in the cf-release (
https://github.com/cloudfoundry/cf-release/tree/master/example_manifests)
or which ones?

Thanks,
Leandro.-


Asynchronous route-mapping and blue-green deployment

Anderer, Thomas
 

Hello everyone,

we already had an internal discussion on the topic and since we could not quite come to a solution, I'd like to ask in this list.

We're using a self-made blue-green-deployment-script which pretty much does what's explained on cloudfoundry.org (https://docs.cloudfoundry.org/devguide/deploy-apps/blue-green.html), and additionally checks (HTTP-GET) the application after push, map-route and unmap-route. This script has been working fine on an instance A of CF (DEA-based and relatively small), but has issues on instance B (Diego-based, larger). The aforementioned HTTP-GET sometimes fails with "404 Not Found: Requested route does not exist" directly after push or map-route. We never experienced this issue on instance A. This could of course mean that the instance is small enough that all router operation are handled faster than our script is able to react. On instance B it sometimes takes up to a 1 second or even longer until the route mapping is finally completed.

In our internal discussion with our CF operators, we found a couple of parts of documentation which at least hint to different, maybe even inconsistent inner workings of the route mapping:
1) https://docs.cloudfoundry.org/devguide/deploy-apps/blue-green.html: Step 3: Map-route - The CF Router immediately begins to load balance traffic for demo-time.example.com between Blue and Green.
- In my opinion this implies or at least strongly hints that the map-route call was supposed to be synchronous.
2) PUT to "/v2/apps/#{app_guid}/routes/#{route_guid}" returns 201 CREATED and not 202 ACCEPTED, which also implies that it is a synchronous operation. It also does not return an event or operation which could be pinged to wait for completion of route mapping.
3) Operations which show the state of the route, like for example 'cf routes' already shows the route as being successfully mapped, although 404 is still returned.
4) See https://docs.cloudfoundry.org/devguide/deploy-apps/routes-domains.html#map-route: Applications running on the DEA architecture must be restarted after routes for an app are mapped or unmapped. Applications running on Diego do not need to be restarted.
- This is contrary to what I experienced, since route mapping on our instance A always worked synchronously and without restart of the application. Furthermore, it contradicts what's explained in 1) at least for DEA.
5) https://github.com/cloudfoundry/diego-design-notes#routing-translation-components:
Routing Translation Components: Route-Emitter
a) monitors DesiredLRP state and ActualLRP state via the BBS. When a change is detected, the Route-Emitter emits route registration and unregistration messages to the gorouter via the NATS message bus,
b) periodically emits the entire routing table to the router,
c) maintains a lock in consul to ensure only one route-emitter handles route registration at a time.
- This hints that route mapping is an asynchronous task.

Some of the issues could be fixed by repeatedly pinging the application in order to wait until the route has been mapped. But what about blue-green-deployment, where I map the application to a route on which there is already a running application. Here, I cannot find out in a general way, if the route mapping is completed and when I can start unmapping the route from the old application. If route-mapping is indeed an asynchronous task, in my opinion the description on https://docs.cloudfoundry.org/devguide/deploy-apps/blue-green.html is misleading at best. And all blue-green-deployment-scripts which I've seen so far have this issue.

So, is the route mapping really supposed to be asynchronous? If so, is there any general way to find out when the route-mapping process has finished?

Thank you for your help and clarification,

Best regards,
--
Thomas Anderer
Agile Software Engineer
andrena objects ag
currently working at SAP


UAA 3.10.0 Release Announcement

Sree Tummidi
 

Hi All,

On behalf of the entire UAA team I am pleased to announce the release of *UAA
3.10.0*. This release truly has been community driven effort with major
feature contributions from *SAP* and *Microsoft*.

The release highlights include

Major FeaturesExternal User Claims via UserInfo Endpoint

This feature enables User Attributes (including custom attributes) and
Group Memberships from LDAP, SAML and OpenID Connect providers to be
exposed via the UserInfo endpoint of UAA in addition to propagating them
via OpenID Connect id_token. This is an optional feature per external
identity provider and is turned on by setting the
config.storeCustomAttributes flag in the Identity Provider json. The token
must contain user_attributes and/or roles scopes for retrieving the custom
attributes and roles from the /userinfo
<http://docs.cloudfoundry.org/api/uaa/#user-info> endpoint.

- Ability to retrieve the custom user attributes from the OpenID Connect
userinfo endpoint External OIDC
<https://www.pivotaltracker.com/story/show/130477291>
- Ability to retrieve the roles from the OpenID Connect userinfo
endpoint - All Providers
<https://www.pivotaltracker.com/story/show/137497509>

Force User Password Change for UAA Internal Users

This feature allows the administrator to force all users to change their
password at next login time. This can be enforced on an individual user
basis <http://docs.cloudfoundry.org/api/uaa/#force-user-password-to-expire>.
This feature is multi-tenant and can be enabled per Identity Zone
<http://docs.cloudfoundry.org/api/uaa/index.html#force-pasword-change-for-users>
.

- Add support for User Force Password Change at next login
<https://www.pivotaltracker.com/story/show/131105231>
- Provide ability to force password change for all users in the system
<https://www.pivotaltracker.com/story/show/131113425>
- Update the Login UI to honor Force Password Change
<https://www.pivotaltracker.com/story/show/132023123>

SAML Bearer Token support

This feature enables SAML assertions to be exchanged for access tokens.
This feature has been contributed by *SAP*. The documentation can be found
here. <http://docs.cloudfoundry.org/api/uaa/#saml2-bearer-grant>

- Feature: Add saml2 bearer grant
<https://www.pivotaltracker.com/story/show/134877121>

SQL Server Support

In addition to PostGres and MySQL , UAA now supports SQL Server as a
backend. This feature has been contributed by *Microsoft*.

- Microsoft SQL Server Support as a backend
<https://www.pivotaltracker.com/story/show/136315437>

Detailed release notes are available here
<https://github.com/cloudfoundry/uaa/releases/tag/3.10.0>


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


Re: Loggregator Architecture Change: Independently Scalable Syslog

Marco Voelz
 

Thanks Adam for the permissions. The linked “Inception notes” document [1] seems to also have problems with permissions. Could you please also take care of that?

Thanks and warm regards
Marco

[1] https://docs.google.com/document/d/1LZCiFSe785BceKg9AM5btrnKucNfL11r1zobRuNy7Bk/edit


From: Adam Hevenor <ahevenor(a)pivotal.io>
Reply-To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org>
Date: Wednesday, 1 February 2017 at 16:39
To: "cf-dev(a)lists.cloudfoundry.org" <cf-dev(a)lists.cloudfoundry.org>
Subject: [cf-dev] Re: Re: Loggregator Architecture Change: Independently Scalable Syslog

Hi All -

I have updated the sharing settings. Everyone should now be able to see and comment.

Thanks
Adam


Dropping support for old versions of SSL and TLS in HAProxy and Gorouter

Shannon Coen
 

When TLS is enabled on Gorouter (router.enable_ssl: true; false by
default), it will currently accept connections using SSLv3, TLSv1.0,
TLSv1.1, or TLSv1.2.

The HAProxy in cf-release always has TLS enabled and will accept
connections using TLSv1.0, TLSv1.1, or TLSv1.2.

For security reasons, we would like to drop support in these components for
all versions except TLSv1.2. Please let me know if you have a compelling
use case for maintaining support for older versions using a manifest
property. I recognize this could be an issue if apps on your deployments of
CF must continue supporting clients that do not use TLSv1.2.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.


Re: Routing for Isolation Segments

Carlo Alberto Ferraris
 

Shannon,
I agree with Mike - we're in a similar situation where we already have implemented all network ACLs and FW rules - so also for us access control would be the priority, and partitioning nice to have.

Thanks,
Carlo


Deprecation Notice: bosh-hm-forwarder is moving

Adam Hevenor
 

Hi All -

In our continued effort for a clean the Loggregator code base we are moving another repo outside of Loggregator. The bosh-hm-forwarder can now be found at the following locations.

New repo: https://github.com/cloudfoundry/bosh-hm-forwarder
Bosh Release: http://bosh.io/releases/github.com/cloudfoundry/bosh-hm-forwarder-release?all=1

If you happen to reference the bosh-hm-forwarder in the loggregator repo you have until March 1st to update your references. I'll bump this thread again on March 1st when we delete this from our repo.

Thanks
Adam


Recurring CAB and CF-extensions meetings

Michael Maximilien
 

fyi...
 
Since I got access to the CF Public Calendar (thanks Chip!) I moved the two recurring meetings (CAB and CF-extensions) to that calendar.
 
 
 
In theory, if you subscribed to the CF Public Calendar you should get these updates ASAP. If you added my calendar entry to yours then it should transfer. If not, delete the old and subscribe to the CF Public Calendar as that should give you everything CF related.
 
Sorry about this mishap. Hopefully, everyone now has the entries in their calendar. Just reminder, next CAB on Wed 02/15 @ 8a and next CF-extensions on Mon 02/27 @ 11a.
 
Talk to you then. Best,

------
dr.max
ibm cloud labs
silicon valley, ca
maximilien.org


Re: Deprecation Notice: loggregator statsd-injector is moving

Adam Hevenor
 

Hi All -

Just a reminder. Today is the last day to update your reference to the statds-injector. We'll be deleting the version in the Loggregator repo today. You need to use this repo instead:

https://github.com/cloudfoundry/statsd-injector-release

Thanks
Adam


Re: Loggregator Architecture Change: Independently Scalable Syslog

Adam Hevenor
 

Hi All -

I have updated the sharing settings. Everyone should now be able to see and comment.

Thanks
Adam


CF-extensions PMC proposal process - DRAFT

Michael Maximilien
 

Hi, all,

In order to streamline, expedite, and control the quality of extensions proposal, we have created a process by which all proposal must adhere.

I am asking your feedback on this process so we can make it official. Please find link below and please comment directly in Google Docs or reply to this email or ping me on Slack. It's short two pages so easy read.

https://docs.google.com/document/d/1KaYuqNbPrr23d3OsAhi0NTwBNy-LRZK-FbN3LfBgqjw

I would like to close the review on this by the next CAB call in third week of Feb (or before). All current proposals can opt to be grandfathered into this new process or not. Once official, please contact me with your decision if you are a proposal owner.

I hope this small process addition to CF-extensions will result in more submissions and eventually more incubation into CF.

All the best,

dr.max

ibm cloud labs
sillicon valley, ca
usa
maximilien.org

Sent from my iPhone


Re: Loggregator Architecture Change: Independently Scalable Syslog

Marco Voelz
 

Dear Adam,

thanks for sharing the document. Could you please make it accessible for everyone? All I currently get is

"You need permission
Want in? Ask for access, or switch to an account with permission. Learn more<https://support.google.com/drive?p=requesting_access&hl=en>"

Thanks and warm regards
Marco


From: Adam Hevenor <ahevenor(a)pivotal.io>
Reply-To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org>
Date: Tuesday, 31 January 2017 at 23:41
To: "cf-dev(a)lists.cloudfoundry.org" <cf-dev(a)lists.cloudfoundry.org>
Subject: [cf-dev] Loggregator Architecture Change: Independently Scalable Syslog

Hi All -

The loggregator team is planning a track of work that results in some architectural changes to how syslog drains are implemented. I wanted to share our plans and solicit any feedback about this new approach.

Brief: Developers and operators can use syslog drains to bind the logs of a specific app to a third party tool, but doing so puts additional strain on logs delivered through the firehose. These changes eliminate this burden and pave the way for more developer features related to syslog while keeping the same user experience.

For more details please see: https://docs.google.com/document/d/1B31BWuPVGYIbQaEVfFhmTmp8_5t8RwGGHY_4q4unojI/edit#<https://docs.google.com/document/d/1B31BWuPVGYIbQaEVfFhmTmp8_5t8RwGGHY_4q4unojI/edit>

Please let me know your comments, feedback or ideas about the proposal.
Thanks!
Adam


CF-extensions monthly meeting notes - January 2017

Michael Maximilien
 

FYI...

Find summary of meeting here:

https://docs.google.com/document/d/1RCMHYFQaB1oqdEKev-cVF2Rrr6qqCT9C6RmFFKmUxnI

Best,

dr.max

ibm cloud labs
sillicon valley, ca
usa
maximilien.org

Sent from my iPhone


Re: Loggregator Architecture Change: Independently Scalable Syslog

Vlad Iovanov
 

Cancel

On Jan 31, 2017 14:42, "Adam Hevenor" <ahevenor(a)pivotal.io> wrote:

Hi All -

The loggregator team is planning a track of work that results in some
architectural changes to how syslog drains are implemented. I wanted to
share our plans and solicit any feedback about this new approach.

Brief: Developers and operators can use syslog drains to bind the logs of
a specific app to a third party tool, but doing so puts additional strain
on logs delivered through the firehose. These changes eliminate this burden
and pave the way for more developer features related to syslog while
keeping the same user experience.

For more details please see: https://docs.google.com/document/d/
1B31BWuPVGYIbQaEVfFhmTmp8_5t8RwGGHY_4q4unojI/edit#

Please let me know your comments, feedback or ideas about the proposal.
Thanks!
Adam


Loggregator Architecture Change: Independently Scalable Syslog

Adam Hevenor
 

Hi All -

The loggregator team is planning a track of work that results in some architectural changes to how syslog drains are implemented. I wanted to share our plans and solicit any feedback about this new approach.

Brief: Developers and operators can use syslog drains to bind the logs of a specific app to a third party tool, but doing so puts additional strain on logs delivered through the firehose. These changes eliminate this burden and pave the way for more developer features related to syslog while keeping the same user experience.

For more details please see: https://docs.google.com/document/d/1B31BWuPVGYIbQaEVfFhmTmp8_5t8RwGGHY_4q4unojI/edit#

Please let me know your comments, feedback or ideas about the proposal.
Thanks!
Adam


Re: cf-release 252 - Upcoming mutual TLS changes

Aakash Shah
 

Quick followup, we may have spoken too soon about the changes to the TPS
job. Those changes are not slated to be in cf-release v252, but rather the
release following it. Please leave "basic_auth_username" and
"basic_auth_password"
in your manifest until cf-release v253.

Sorry if this caused any inconvenience,
CAPI Team

On Tue, Jan 31, 2017 at 11:56 AM, Aakash Shah <ashah(a)pivotal.io> wrote:

In the upcoming cf-release (v252), some components communicating with CC
via its internal API (for example: Loggregator, BBS, and TPS) will do so
over mutual TLS. This is part of an effort to have all Cloud Foundry
internal traffic be done over mutual TLS in lieu of basic auth. The CC and
other components must now be configured with several new certificates to
establish these mTLS connections. For most deployments, *use a shared CA
between CF and Diego deployments*.

Properties changes

For a cf-release deployment manifest, the following properties are
*required* for cloud_controller_ng and cloud_controller_worker jobs:

properties:
cc:
mutual_tls:
ca_cert:
public_cert:
private_key:

Within your diego-release deployment manifest, the following properties
are *required* for the tps job:

properties:
capi:
tps:
cc:
ca_cert:
client_cert:
client_key:

We have *removed* the following properties from the tps job:


- properties.capi.tps.cc.basic_auth_username
- properties.capi.tps.cc.basic_auth_password

Generating certificates

For instructions on how to generate the certificates for these properties,
please see this doc: https://github.com/cloudfoundry/capi-release/blob/
develop/docs/tls-configuration.md

We hope these changes are clear. If you run into trouble or have
questions, please feel free to reach out to us on slack
<https://cloudfoundry.slack.com/messages/capi/>!

- CAPI team


cf-release 252 - Upcoming mutual TLS changes

Aakash Shah
 

In the upcoming cf-release (v252), some components communicating with CC
via its internal API (for example: Loggregator, BBS, and TPS) will do so
over mutual TLS. This is part of an effort to have all Cloud Foundry
internal traffic be done over mutual TLS in lieu of basic auth. The CC and
other components must now be configured with several new certificates to
establish these mTLS connections. For most deployments, *use a shared CA
between CF and Diego deployments*.

Properties changes

For a cf-release deployment manifest, the following properties are
*required* for cloud_controller_ng and cloud_controller_worker jobs:

properties:
cc:
mutual_tls:
ca_cert:
public_cert:
private_key:

Within your diego-release deployment manifest, the following properties are
*required* for the tps job:

properties:
capi:
tps:
cc:
ca_cert:
client_cert:
client_key:

We have *removed* the following properties from the tps job:


- properties.capi.tps.cc.basic_auth_username
- properties.capi.tps.cc.basic_auth_password

Generating certificates

For instructions on how to generate the certificates for these properties,
please see this doc: https://github.com/cloudfoundry/capi-release/
blob/develop/docs/tls-configuration.md

We hope these changes are clear. If you run into trouble or have questions,
please feel free to reach out to us on slack
<https://cloudfoundry.slack.com/messages/capi/>!

- CAPI team


Re: Incubation proposal: Abacus Service Broker

Hristo Iliev
 

Hi,

Anyone that wants to join me & Max is more than welcome. Just use one of
the ways below.

Online meeting: https://apear.in/cf-abacus
Slack channel: abacusdev.slack.com

Phones:
Participant Passcode: 362 314 3907

Country Number Mobile/Lync
Bulgaria: 00 800 118 4451 tel:008001184451,,,3623143907# number
not accessible from mobile
Canada, Montreal: +1 514 669 5883 tel:+15146695883,,,3623143907#
Canada, Toronto: +1 416 915 3225 tel:+14169153225,,,3623143907#
Canada, Vancouver: +1 604 909 2086 tel:+16049092086,,,3623143907#
Canada: 1 877 252 4916 tel:18772524916,,,3623143907#
Germany, Frankfurt: +4969222210764 tel:+4969222210764,,,3623143907#
Germany, Munich: +4989710424682 tel:+4989710424682,,,3623143907#
Germany Mobile: 0800588 9331 tel:08005889331,,,3623143907#
India, Bangalore: +91 80 6127 5055 tel:+918061275055,,,3623143907#
India, Chennai: +91 44 6688 6114 tel:+914466886114,,,,3623143907#
India, Delhi: +91 11 6641 1356 tel:+911166411356,,,3623143907#
India, Gurgaon: +91 124 712 7900 tel:+911247127900,,,3623143907#
India, Mumbai: +91 22 6150 1743 tel:+912261501743,,,3623143907#
India: 1800 266 0327 tel:18002660327,,,,3623143907#
UK,03: +44 330 336 6043 tel:+443303366043,,,3623143907#
UK: 0800 368 0635 tel:08003680635,,,3623143907#
UK (lo-call): 0845 545 0012 tel:08455450012,,,3623143907#
US and Canada: 1-866-312-7353 tel:+18663127353,,,3623143907#
US and Canada: 1-646-434-0499 tel:+16464340499,,,3623143907#
US and Canada: 1-720-897-6637 tel:+17208976637,,,3623143907#
US and Canada: 1-484-427-2544 tel:+14844272544,,,3623143907#

Phone Type: Countries listed with a city are local access, all others are
International Toll Free. Please use local access numbers whenever possible.

Regards,
Hristo Iliev

2017-01-25 11:33 GMT+02:00 Hristo Iliev <hsiliev(a)gmail.com>:

Thanks Max.

Using the opportunity to remind of the Abacus Broker inception on January
31st @ 10a PST

Use the following link to add it to your calendar:
https://calendar.google.com/calendar/event?action=TEMPLATE&
tmeid=dDJwNmg5Z3ViN2NpOGozdGxoZ3Y0b3ZpamMgaHNpbGlldkBt&
tmsrc=hsiliev%40gmail.com

All connection details are on the Google Calendar invite link.

Regards,
Hristo Iliev


2017-01-21 0:15 GMT+02:00 Michael Maximilien <mmaximilien(a)gmail.com>:

Hi,

As discussed today, I will be happy to help you run the inception.

If anyone else (with more experience) was interested in helping, please
ping me and Hristo.

See you all (virtually) online on the 31st.

Best,

Max

On Mon, Nov 28, 2016 at 1:29 PM, Michael Maximilien <
mmaximilien(a)gmail.com> wrote:

Hi, all,

Thanks to SAP and Hristo for moving this forward.

Since I don't see any questions nor comments on this proposal, other
than mine. As such, I propose to include this into the CF-Extensions PMC.

Next step is to do an inception and start the project.

Hristo, happy to help you. Please let's connect offline or during
CF-Abacus weekly meetings von Friday. You can then announce details here
afterwards.

Welcome. Best,

Max

On Wed, Nov 16, 2016 at 3:51 PM, Michael Maximilien <
mmaximilien(a)gmail.com> wrote:

Thank you Hirsto and SAP for submitting this proposal. A nice extension
for CF.

Made some minor editorial changes but overall proposal looks great.
Looking forward to see feedback (if any) from community.

Best,

Max

On Tue, Nov 15, 2016 at 8:03 AM, Iliev, Hristo <hristo.iliev(a)sap.com>
wrote:

Hello,

I would like to propose to the Extensions PMC a new incubation project
around Abacus.

Project name: Abacus Service Broker
Project proposal: https://docs.google.com/docume
nt/d/1zGYi0jGRX9kodn8WR8OHn6CSjo3BTorfuza121aIeuU/edit?usp=sharing
Proposed Project Lead: Hristo Iliev (SAP)
Proposed Scope: See the "Goals" and "Non-goals" sections in the
proposal
Development Operating Model: Distributed Committer Model
Technical Approach: Refer to "Programming language" and "Deliverables"
in the proposal
Initial team committed: 3 engineers from SAP

I look forward to any questions or comments.

Regards,
Hristo Iliev, SAP




--
max
http://maximilien.org
http://blog.maximilien.com


--
max
http://maximilien.org
http://blog.maximilien.com


--
max
http://maximilien.org
http://blog.maximilien.com


Re: Pending Proposals for CF-Extensions for 2017

Michael Maximilien
 

Here is the other docs link. Previous was the CF-extensions notes.

https://docs.google.com/document/d/1aKmxFdGC4GnXBIZMx0qdIawHrEIRSjBOzB-spoPlbM8/edit?usp=sharing

And you are correct Guillaume, this was not setup for allowing comments. It
does not so fire away.

Best,

Max

On Mon, Jan 30, 2017 at 2:58 PM, Michael Maximilien <mmaximilien(a)gmail.com>
wrote:

Thanks odd. See attached picture.

Here is link again, just in case: https://docs.google.com/
document/d/1RCMHYFQaB1oqdEKev-cVF2Rrr6qqCT9C6RmFFKmUxnI/edit?usp=sharing

[image: Inline image 1]

On Fri, Jan 27, 2017 at 10:49 PM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Hi

The doc seems to not allow for comments nor suggestions. Max, can you
please allow this, would be easier to make suggestions.

Thanks,

Guillaume.

Le 20 janv. 2017 23:55, "Michael Maximilien" <maxim(a)us.ibm.com> a écrit :

Hi, all,

I am trying to get a handle on all pending proposals to CF-Extensions as
well as anything proposed to CF that is now orphaned or would like to be
considered in the CF-Extensions PMC. I have a list [1], however, I am sure
it is not complete.

Please, if you have a proposal pending fitting above and it's not listed
please add it or respond here or to me directly so I add and start tracking.

Thanks,

[1] https://docs.google.com/document/d/1aKmxFdGC4GnXBIZMx0qd
IawHrEIRSjBOzB-spoPlbM8/edit?usp=sharing

------
dr.max
ibm cloud labs
silicon valley, ca
maximilien.org


--
max
http://maximilien.org
http://blog.maximilien.com


--
max
http://maximilien.org
http://blog.maximilien.com


Re: Pending Proposals for CF-Extensions for 2017

Michael Maximilien
 

Thanks odd. See attached picture.

Here is link again, just in case:
https://docs.google.com/document/d/1RCMHYFQaB1oqdEKev-cVF2Rrr6qqCT9C6RmFFKmUxnI/edit?usp=sharing

[image: Inline image 1]

On Fri, Jan 27, 2017 at 10:49 PM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Hi

The doc seems to not allow for comments nor suggestions. Max, can you
please allow this, would be easier to make suggestions.

Thanks,

Guillaume.

Le 20 janv. 2017 23:55, "Michael Maximilien" <maxim(a)us.ibm.com> a écrit :

Hi, all,

I am trying to get a handle on all pending proposals to CF-Extensions as
well as anything proposed to CF that is now orphaned or would like to be
considered in the CF-Extensions PMC. I have a list [1], however, I am sure
it is not complete.

Please, if you have a proposal pending fitting above and it's not listed
please add it or respond here or to me directly so I add and start tracking.

Thanks,

[1] https://docs.google.com/document/d/1aKmxFdGC4GnXBIZMx0qd
IawHrEIRSjBOzB-spoPlbM8/edit?usp=sharing

------
dr.max
ibm cloud labs
silicon valley, ca
maximilien.org


--
max
http://maximilien.org
http://blog.maximilien.com

3061 - 3080 of 9429