Date   

Re: Announcing cf-mysql-release v35

Marco Nicosia
 

Hi Juan Pablo,

At the time we chose to go with MariaDB, our goal was to provide a
"MySQL-compatible" relational DB for CF. Also at the time, MariaDB claimed
to be a drop-in replacement; and to some extent, it still is.

We chose to stick with the name MySQL for three reasons:

1. Our commitment was MySQL, not necessarily MariaDB. We wanted to reserve
the right to change our minds on which "engine" to include in the future.
2. Name recognition: people new to CF are usually looking for "what's a
good DB to start with," and not necessarily thinking about the about the
small differences in the MySQL community. Especially at the time, but still
today, MySQL is universally known. MariaDB, less so.
3. We weren't even sure we wanted to call it MySQL in the first place. We
were considering something even more generic, like "relational database for
Cloud Foundry." The reason for this is that cf-MySQL-release is more than
just a thin packaging of MySQL, it's most everything you need to run a DB
with CF. That was unrealistic - people need to know what kind of DB is
running. So we stuck with a generic MySQL as a compromise.

Love to chat more over a beer at CF Summit if you happen to be attending!

-- Marco N.

On Wed, May 10, 2017 at 05:54 Juan Pablo Genovese <juanpgenovese(a)gmail.com>
wrote:

Great news, and great work!

OTOH, was there ever a discussion about changing the name of the release?
I feel it is a little unfair (and can be even misleading technologically
speaking) to still be calling it a "MySQL" release when in fact is using
MariaDB.
Maybe that discussion already took place and I missed it.

Thank you!


2017-05-10 1:09 GMT-03:00 Marco Nicosia <mnicosia(a)pivotal.io>:

On behalf of the Core Services team, I'm happy to announce that we've
recently published cf-mysql-release v35
<https://github.com/cloudfoundry/cf-mysql-release/releases/tag/v35>.

The major motivation for this release is to switch the manifest to use
BOSH links. This supports the work going on in cf-deployment
<https://github.com/cloudfoundry/cf-deployment>. We've also swapped out
our fork of route-registrar, preferring instead the official one in
routing-release
<https://github.com/cloudfoundry-incubator/routing-release>. Due to the
nature of the cf-deployment integration work, we may need to spin a small
release or two as we tweak how to expose those links.

Based on the results of the poll included with v34, few of you are locked
into using spiff. As a result of that, we continued to update spiff
templates in v35, but will no longer include them in future releases. To
deploy v35, I recommend you try cf-mysql-deployment v35
<https://github.com/cloudfoundry/cf-mysql-deployment/tree/v35>. Like
cf-deployment, we're learning as we go. Please send us lots of feedback.

Stay tuned for coming epics which will include tightening security and
tuning tweaks!

--
Marco Nicosia
Product Manager
Pivotal Software, Inc.
mnicosia(a)pivotal.io


---------- Forwarded message ----------
Date: Wed, May 3, 2017 at 7:20 PM
Subject: [cloudfoundry/cf-mysql-release] v35
Cc: Subscribed <subscribed(a)noreply.github.com>


cf-mysql-release v35

*Notice:* Based on your responses to the v34 poll
<https://github.com/cloudfoundry/cf-mysql-release/releases/tag/v34>,
this will be the last release in which we include updated spiff templates.
That means that starting with v36, you'll want to check out
cf-mysql-deployment <https://github.com/cloudfoundry/cf-mysql-deployment>
or continue building your manifest by other means.

Also, using cf-mysql-deployment
<https://github.com/cloudfoundry/cf-mysql-deployment> just got easier
with the official GA
<https://lists.cloudfoundry.org/archives/list/cf-bosh(a)lists.cloudfoundry.org/message/L6GNJMAVZEJX7ZQFOINWBRO7NDG56Y5H/>
of the bosh v2 CLI <http://bosh.io/docs/cli-v2.html>!
Dependency Updates

-

cf-mysql-release should use MariaDB 10.1.22 [#141072891
<https://www.pivotaltracker.com/story/show/141072891>]
-

Use routing-release instead of our own fork of route-registrar [
#135377279 <https://www.pivotaltracker.com/story/show/135377279>]

For a long time, cf-mysql-release has used a fork of the
route-registrar library. To stay current, we now require
routing-release
<https://github.com/cloudfoundry-incubator/routing-release>. Please
note the README.md
<http:///cloudfoundry/cf-mysql-release/blob/v35/README.md> now covers
this prerequisite.

*Note:* When switching to the canonical distribution of
route-registrar, we had to change the URL of the proxy. Where once
you'd visit https://proxy-0-p-mysql.SYSTEM-DOMAIN/, now the instance
index is pre-pended: https://0-proxy-p-mysql.SYSTEM-DOMAIN/.
- As an operator I can navigate to a well-known URL to discover a
list of URLs to the proxy dashboards [#138180969
<https://www.pivotaltracker.com/story/show/138180969>]

If you use cf-mysql-deployment, and include the
register-proxy-route.yml
<https://github.com/cloudfoundry/cf-mysql-deployment/blob/v35/operations/register-proxy-route.yml>
operations file, the deployment will automatically include a proxy
aggregator: https://proxy-p-mysql.SYSTEM-DOMAIN/ which will include
links to the proxy dashboards, regardless of the naming scheme. This
feature is only available when using BOSH links.
- As an Operator, I'd like the docs to cover how to upgrade from v34
to v35 which uses routing-release [#144161787
<https://www.pivotaltracker.com/story/show/144161787>]
- cloudfoundry/cf-mysql-release #157
<https://github.com/cloudfoundry/cf-mysql-release/issues/157>:
Unused nats properties [#143997101
<https://www.pivotaltracker.com/story/show/143997101>]

Some nats properties are no longer used by our jobs directly, but
routing-release still uses the same properties so deployment manifests do
not need to change.

Providing and Consuming BOSH links

Using BOSH links <https://bosh.io/docs/links.html> simplifies manifests
and manifest generation - every time a BOSH release uses a link, that's
less copying and pasting via template.

- cloudfoundry/cf-mysql-release #154
<https://github.com/cloudfoundry/cf-mysql-release/pull/154>: Provide
database links for mysql and proxy jobs [#143086033
<https://www.pivotaltracker.com/story/show/143086033>]
- cloudfoundry/cf-mysql-release #149
<https://github.com/cloudfoundry/cf-mysql-release/pull/149>:
Optionally consume cc link for app_domains in smoke tests [#140458283
<https://www.pivotaltracker.com/story/show/140458283>]

Bug Fixes and Minor Improvements

- [BUG] Upgrading from older releases fails to start mariadb [
#139334661 <https://www.pivotaltracker.com/story/show/139334661>]
- [BUG] Logs not draining to syslog [#143069405
<https://www.pivotaltracker.com/story/show/143069405>]
- Fixes a regression in v34 that logs were not sent to syslog.
- [BUG] mysql_release fails to deploy to a BOSH director using
local_dns [#143221877
<https://www.pivotaltracker.com/story/show/143221877>]
- [BUG] pre-start hangs indefinitely when cluster is not healthy [
#141824537 <https://www.pivotaltracker.com/story/show/141824537>]
- [BUG] If a node is failing, mariadb_ctrl waits for mysql forever [
#140517205 <https://www.pivotaltracker.com/story/show/140517205>]
- [BUG] roadmin user doesn't have read privs for admin operations? [
#139594503 <https://www.pivotaltracker.com/story/show/139594503>]
- cloudfoundry/cf-mysql-release #155
<https://github.com/cloudfoundry/cf-mysql-release/pull/155>: Allow
innodb_flush_log_at_trx_commit to be configurable [#143693837
<https://www.pivotaltracker.com/story/show/143693837>]
- cloudfoundry/cf-mysql-release #158
<https://github.com/cloudfoundry/cf-mysql-release/pull/158>: Nil the
consul link in the example stub [#144138871
<https://www.pivotaltracker.com/story/show/144138871>]
- cloudfoundry/cf-mysql-release #159
<https://github.com/cloudfoundry/cf-mysql-release/pull/159>: add
private key option to download-logs script [#144411627
<https://www.pivotaltracker.com/story/show/144411627>]
- As an Operator, if an errand is a no-op, it's better to exit 0 than
error [#139054911
<https://www.pivotaltracker.com/story/show/139054911>]
- Stop attaching the tarball to the release notes of cf-mysql-release
[#139611695 <https://www.pivotaltracker.com/story/show/139611695>]

Documentation

- Proxy startup and shutdown delay descriptions are backwards in spec
[#139996733 <https://www.pivotaltracker.com/story/show/139996733>]
- NOTICE files on various repositories are out of date [#141360157
<https://www.pivotaltracker.com/story/show/141360157>]

Manifest Changes

- New: cf.mysql.innodb_flush_log_at_trx_commit, optional, defaults to
1.
- New: cf_mysql.proxy.api_aggregator_port: optional, defaults to 8082.
- New: cf_mysql.proxy.api_uri, required when deploying the proxy
aggregator.
- Removed: cf_mysql.external_host
- Removed: cf_mysql.standalone


You are receiving this because you are subscribed to this thread.
View it on GitHub
<https://github.com/cloudfoundry/cf-mysql-release/releases/tag/v35> or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AANPTP6bHbvSYOVHua_lQ-4QpNgV2dB-ks5r2TYAgaJpZM4NQKSp>
.


--
Mis mejores deseos,
Best wishes,
Meilleurs vœux,

Juan Pablo
------------------------------------------------------
http://www.jpgenovese.com
--
--
Marco Nicosia
Product Manager
Pivotal Software, Inc.
mnicosia(a)pivotal.io
c: 650-796-2948


Re: CF Summit Hackathon!

Chip Childers <cchilders@...>
 

We were really hoping to have done that, but were not able to get that
particular plan in place (due to a number of factors). So this is
different, but the other idea didn't materialize this time around. We'll
keep working to figure out for future events though!

On Wed, May 10, 2017 at 8:29 AM Daniel Jones <
daniel.jones(a)engineerbetter.com> wrote:

*cough *replacing droplets with layered filesystems *cough*

I recall there was some discussion about having an event with teenagers
from under-represented backgrounds who aspired to break into the industry.
Is this event the same thing, or something distinct?

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

On 9 May 2017 at 23:56, Chip Childers <cchilders(a)cloudfoundry.org> wrote:

Free robots for cool CF hacks... looking forward to seeing what people
make!

On Tue, May 9, 2017 at 12:37 PM Chris Clark <cclark(a)cloudfoundry.org>
wrote:

Hello all,

For the first time this year, we'll be a having a CF Hackathon at Cloud
Foundry Summit Silicon Valley (Jun 13-15). It's free, and will have
dedicated time from 9am-3pm Tuesday, with projects due Wednesday at 3pm.
Winners will be announced on stage during Thursday's keynotes, and top
three teams (max 4 people) will receive various awesome robots as prizes.

You can sign up for this while registering for Summit, but walk-ins will
be welcome Tuesday morning.

More details here
<https://www.cloudfoundry.org/event_subpages/events-sv-2017/>.

Please reach out if you have any questions and/or suggestions.
Hope to see you there!

Chris Clark
Technical Operations Manager
Cloud Foundry Foundation
--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815 <(267)%20250-0815>
--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815


Re: CF Summit Hackathon!

Daniel Jones
 

*cough *replacing droplets with layered filesystems *cough*

I recall there was some discussion about having an event with teenagers
from under-represented backgrounds who aspired to break into the industry.
Is this event the same thing, or something distinct?

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 9 May 2017 at 23:56, Chip Childers <cchilders(a)cloudfoundry.org> wrote:

Free robots for cool CF hacks... looking forward to seeing what people
make!

On Tue, May 9, 2017 at 12:37 PM Chris Clark <cclark(a)cloudfoundry.org>
wrote:

Hello all,

For the first time this year, we'll be a having a CF Hackathon at Cloud
Foundry Summit Silicon Valley (Jun 13-15). It's free, and will have
dedicated time from 9am-3pm Tuesday, with projects due Wednesday at 3pm.
Winners will be announced on stage during Thursday's keynotes, and top
three teams (max 4 people) will receive various awesome robots as prizes.

You can sign up for this while registering for Summit, but walk-ins will
be welcome Tuesday morning.

More details here
<https://www.cloudfoundry.org/event_subpages/events-sv-2017/>.

Please reach out if you have any questions and/or suggestions.
Hope to see you there!

Chris Clark
Technical Operations Manager
Cloud Foundry Foundation
--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815 <(267)%20250-0815>


Re: Announcing cf-mysql-release v35

Juan Pablo Genovese
 

Great news, and great work!

OTOH, was there ever a discussion about changing the name of the release? I
feel it is a little unfair (and can be even misleading technologically
speaking) to still be calling it a "MySQL" release when in fact is using
MariaDB.
Maybe that discussion already took place and I missed it.

Thank you!


2017-05-10 1:09 GMT-03:00 Marco Nicosia <mnicosia(a)pivotal.io>:

On behalf of the Core Services team, I'm happy to announce that we've
recently published cf-mysql-release v35
<https://github.com/cloudfoundry/cf-mysql-release/releases/tag/v35>.

The major motivation for this release is to switch the manifest to use
BOSH links. This supports the work going on in cf-deployment
<https://github.com/cloudfoundry/cf-deployment>. We've also swapped out
our fork of route-registrar, preferring instead the official one in
routing-release
<https://github.com/cloudfoundry-incubator/routing-release>. Due to the
nature of the cf-deployment integration work, we may need to spin a small
release or two as we tweak how to expose those links.

Based on the results of the poll included with v34, few of you are locked
into using spiff. As a result of that, we continued to update spiff
templates in v35, but will no longer include them in future releases. To
deploy v35, I recommend you try cf-mysql-deployment v35
<https://github.com/cloudfoundry/cf-mysql-deployment/tree/v35>. Like
cf-deployment, we're learning as we go. Please send us lots of feedback.

Stay tuned for coming epics which will include tightening security and
tuning tweaks!

--
Marco Nicosia
Product Manager
Pivotal Software, Inc.
mnicosia(a)pivotal.io


---------- Forwarded message ----------
Date: Wed, May 3, 2017 at 7:20 PM
Subject: [cloudfoundry/cf-mysql-release] v35
Cc: Subscribed <subscribed(a)noreply.github.com>


cf-mysql-release v35

*Notice:* Based on your responses to the v34 poll
<https://github.com/cloudfoundry/cf-mysql-release/releases/tag/v34>, this
will be the last release in which we include updated spiff templates. That
means that starting with v36, you'll want to check out cf-mysql-deployment
<https://github.com/cloudfoundry/cf-mysql-deployment> or continue
building your manifest by other means.

Also, using cf-mysql-deployment
<https://github.com/cloudfoundry/cf-mysql-deployment> just got easier
with the official GA
<https://lists.cloudfoundry.org/archives/list/cf-bosh(a)lists.cloudfoundry.org/message/L6GNJMAVZEJX7ZQFOINWBRO7NDG56Y5H/>
of the bosh v2 CLI <http://bosh.io/docs/cli-v2.html>!
Dependency Updates

-

cf-mysql-release should use MariaDB 10.1.22 [#141072891
<https://www.pivotaltracker.com/story/show/141072891>]
-

Use routing-release instead of our own fork of route-registrar [
#135377279 <https://www.pivotaltracker.com/story/show/135377279>]

For a long time, cf-mysql-release has used a fork of the
route-registrar library. To stay current, we now require
routing-release
<https://github.com/cloudfoundry-incubator/routing-release>. Please
note the README.md
<http:///cloudfoundry/cf-mysql-release/blob/v35/README.md> now covers
this prerequisite.

*Note:* When switching to the canonical distribution of route-registrar,
we had to change the URL of the proxy. Where once you'd visit
https://proxy-0-p-mysql.SYSTEM-DOMAIN/
<https://proxy-0-p-mysql.SYSTEM-DOMAIN/>, now the instance index is
pre-pended: https://0-proxy-p-mysql.SYSTEM-DOMAIN/.
- As an operator I can navigate to a well-known URL to discover a list
of URLs to the proxy dashboards [#138180969
<https://www.pivotaltracker.com/story/show/138180969>]

If you use cf-mysql-deployment, and include the
register-proxy-route.yml
<https://github.com/cloudfoundry/cf-mysql-deployment/blob/v35/operations/register-proxy-route.yml>
operations file, the deployment will automatically include a proxy
aggregator: https://proxy-p-mysql.SYSTEM-DOMAIN/ which will include
links to the proxy dashboards, regardless of the naming scheme. This
feature is only available when using BOSH links.
- As an Operator, I'd like the docs to cover how to upgrade from v34
to v35 which uses routing-release [#144161787
<https://www.pivotaltracker.com/story/show/144161787>]
- cloudfoundry/cf-mysql-release #157
<https://github.com/cloudfoundry/cf-mysql-release/issues/157>:
Unused nats properties [#143997101
<https://www.pivotaltracker.com/story/show/143997101>]

Some nats properties are no longer used by our jobs directly, but
routing-release still uses the same properties so deployment manifests do
not need to change.

Providing and Consuming BOSH links

Using BOSH links <https://bosh.io/docs/links.html> simplifies manifests
and manifest generation - every time a BOSH release uses a link, that's
less copying and pasting via template.

- cloudfoundry/cf-mysql-release #154
<https://github.com/cloudfoundry/cf-mysql-release/pull/154>: Provide
database links for mysql and proxy jobs [#143086033
<https://www.pivotaltracker.com/story/show/143086033>]
- cloudfoundry/cf-mysql-release #149
<https://github.com/cloudfoundry/cf-mysql-release/pull/149>:
Optionally consume cc link for app_domains in smoke tests [#140458283
<https://www.pivotaltracker.com/story/show/140458283>]

Bug Fixes and Minor Improvements

- [BUG] Upgrading from older releases fails to start mariadb [
#139334661 <https://www.pivotaltracker.com/story/show/139334661>]
- [BUG] Logs not draining to syslog [#143069405
<https://www.pivotaltracker.com/story/show/143069405>]
- Fixes a regression in v34 that logs were not sent to syslog.
- [BUG] mysql_release fails to deploy to a BOSH director using
local_dns [#143221877
<https://www.pivotaltracker.com/story/show/143221877>]
- [BUG] pre-start hangs indefinitely when cluster is not healthy [
#141824537 <https://www.pivotaltracker.com/story/show/141824537>]
- [BUG] If a node is failing, mariadb_ctrl waits for mysql forever [
#140517205 <https://www.pivotaltracker.com/story/show/140517205>]
- [BUG] roadmin user doesn't have read privs for admin operations? [
#139594503 <https://www.pivotaltracker.com/story/show/139594503>]
- cloudfoundry/cf-mysql-release #155
<https://github.com/cloudfoundry/cf-mysql-release/pull/155>: Allow
innodb_flush_log_at_trx_commit to be configurable [#143693837
<https://www.pivotaltracker.com/story/show/143693837>]
- cloudfoundry/cf-mysql-release #158
<https://github.com/cloudfoundry/cf-mysql-release/pull/158>: Nil the
consul link in the example stub [#144138871
<https://www.pivotaltracker.com/story/show/144138871>]
- cloudfoundry/cf-mysql-release #159
<https://github.com/cloudfoundry/cf-mysql-release/pull/159>: add
private key option to download-logs script [#144411627
<https://www.pivotaltracker.com/story/show/144411627>]
- As an Operator, if an errand is a no-op, it's better to exit 0 than
error [#139054911 <https://www.pivotaltracker.com/story/show/139054911>
]
- Stop attaching the tarball to the release notes of cf-mysql-release [
#139611695 <https://www.pivotaltracker.com/story/show/139611695>]

Documentation

- Proxy startup and shutdown delay descriptions are backwards in spec [
#139996733 <https://www.pivotaltracker.com/story/show/139996733>]
- NOTICE files on various repositories are out of date [#141360157
<https://www.pivotaltracker.com/story/show/141360157>]

Manifest Changes

- New: cf.mysql.innodb_flush_log_at_trx_commit, optional, defaults to
1.
- New: cf_mysql.proxy.api_aggregator_port: optional, defaults to 8082.
- New: cf_mysql.proxy.api_uri, required when deploying the proxy
aggregator.
- Removed: cf_mysql.external_host
- Removed: cf_mysql.standalone


You are receiving this because you are subscribed to this thread.
View it on GitHub
<https://github.com/cloudfoundry/cf-mysql-release/releases/tag/v35> or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AANPTP6bHbvSYOVHua_lQ-4QpNgV2dB-ks5r2TYAgaJpZM4NQKSp>
.

--
Mis mejores deseos,
Best wishes,
Meilleurs vœux,

Juan Pablo
------------------------------------------------------
http://www.jpgenovese.com


Re: Inconsistency in retrieval of service plans

John Feminella <jxf@...>
 

hi Roopali,
I think Benjamin meant https://apidocs.cloudfoundry.org.
Ordering doesn't seem to be part of the contract of `inline-relations-depth`:
https://apidocs.cloudfoundry.org/258/services/list_all_service_plans_for_the_service.html
So the ordering is likely to be arbitrary if you use that parameter; since it's
arbitrary, you probably shouldn't depend on it.From the documentation,
`inline-relations-depth` is deprecated, so I also wouldn't depend on it for that
reason either.
Not sure if this works for you, but maybe you can get what you want by using the
`?q=…` query to get the correct ordering, then including whatever data you'd
like from the arbitrarily-ordered `inline-relations-depth` query and merging the
two results.
best,~ jf--John Feminella
Advisory Platform Architect
✉ ·jxf(a)pivotal.io
t · @jxxf

On Wed, May 10, 2017 5:47 AM, Roopali Sharma roopali1193(a)gmail.com wrote:
Hello,




The given link , http://api.cloudfoundry.org/ , does not give any details as to
the implementation differences of the APIs wherein the discrepancy lies,




For my investigations, I deployed a sample broker with ten sample plans , with
the first call which is " /v2/service_plans?q=<service_guid> " the plan order of
broker is respected at all times but the second call does some sort using
plan_ids, plan name and plan types(free or paid, public or private) and responds
with a differently ordered list . Could you redirect me to some link where in
this difference is clarified...


Re: Inconsistency in retrieval of service plans

Roopali Sharma <roopali1193@...>
 

Hello,

The given link , http://api.cloudfoundry.org/ , does not give any details as to the implementation differences of the APIs wherein the discrepancy lies,

For my investigations, I deployed a sample broker with ten sample plans , with the first call which is " /v2/service_plans?q=<service_guid> " the plan order of broker is respected at all times but the second call does some sort using plan_ids, plan name and plan types(free or paid, public or private) and responds with a differently ordered list . Could you redirect me to some link where in this difference is clarified...


Announcing cf-mysql-release v35

Marco Nicosia
 

On behalf of the Core Services team, I'm happy to announce that we've
recently published cf-mysql-release v35
<https://github.com/cloudfoundry/cf-mysql-release/releases/tag/v35>.

The major motivation for this release is to switch the manifest to use BOSH
links. This supports the work going on in cf-deployment
<https://github.com/cloudfoundry/cf-deployment>. We've also swapped out our
fork of route-registrar, preferring instead the official one in
routing-release <https://github.com/cloudfoundry-incubator/routing-release>.
Due to the nature of the cf-deployment integration work, we may need to
spin a small release or two as we tweak how to expose those links.

Based on the results of the poll included with v34, few of you are locked
into using spiff. As a result of that, we continued to update spiff
templates in v35, but will no longer include them in future releases. To
deploy v35, I recommend you try cf-mysql-deployment v35
<https://github.com/cloudfoundry/cf-mysql-deployment/tree/v35>. Like
cf-deployment, we're learning as we go. Please send us lots of feedback.

Stay tuned for coming epics which will include tightening security and
tuning tweaks!

--
Marco Nicosia
Product Manager
Pivotal Software, Inc.
mnicosia(a)pivotal.io


---------- Forwarded message ----------
Date: Wed, May 3, 2017 at 7:20 PM
Subject: [cloudfoundry/cf-mysql-release] v35
Cc: Subscribed <subscribed(a)noreply.github.com>


cf-mysql-release v35

*Notice:* Based on your responses to the v34 poll
<https://github.com/cloudfoundry/cf-mysql-release/releases/tag/v34>, this
will be the last release in which we include updated spiff templates. That
means that starting with v36, you'll want to check out cf-mysql-deployment
<https://github.com/cloudfoundry/cf-mysql-deployment> or continue building
your manifest by other means.

Also, using cf-mysql-deployment
<https://github.com/cloudfoundry/cf-mysql-deployment> just got easier with
the official GA
<https://lists.cloudfoundry.org/archives/list/cf-bosh(a)lists.cloudfoundry.org/message/L6GNJMAVZEJX7ZQFOINWBRO7NDG56Y5H/>
of the bosh v2 CLI <http://bosh.io/docs/cli-v2.html>!
Dependency Updates

-

cf-mysql-release should use MariaDB 10.1.22 [#141072891
<https://www.pivotaltracker.com/story/show/141072891>]
-

Use routing-release instead of our own fork of route-registrar [
#135377279 <https://www.pivotaltracker.com/story/show/135377279>]

For a long time, cf-mysql-release has used a fork of the route-registrar
library. To stay current, we now require routing-release
<https://github.com/cloudfoundry-incubator/routing-release>. Please note
the README.md <http:///cloudfoundry/cf-mysql-release/blob/v35/README.md>
now covers this prerequisite.

*Note:* When switching to the canonical distribution of route-registrar,
we had to change the URL of the proxy. Where once you'd visit
https://proxy-0-p-mysql.SYSTEM-DOMAIN/
<https://proxy-0-p-mysql.SYSTEM-DOMAIN/>, now the instance index is
pre-pended: https://0-proxy-p-mysql.SYSTEM-DOMAIN/.
- As an operator I can navigate to a well-known URL to discover a list
of URLs to the proxy dashboards [#138180969
<https://www.pivotaltracker.com/story/show/138180969>]

If you use cf-mysql-deployment, and include the register-proxy-route.yml
<https://github.com/cloudfoundry/cf-mysql-deployment/blob/v35/operations/register-proxy-route.yml>
operations file, the deployment will automatically include a proxy
aggregator: https://proxy-p-mysql.SYSTEM-DOMAIN/ which will include
links to the proxy dashboards, regardless of the naming scheme. This
feature is only available when using BOSH links.
- As an Operator, I'd like the docs to cover how to upgrade from v34 to
v35 which uses routing-release [#144161787
<https://www.pivotaltracker.com/story/show/144161787>]
- cloudfoundry/cf-mysql-release #157
<https://github.com/cloudfoundry/cf-mysql-release/issues/157>: Unused
nats properties [#143997101
<https://www.pivotaltracker.com/story/show/143997101>]

Some nats properties are no longer used by our jobs directly, but
routing-release still uses the same properties so deployment manifests do
not need to change.

Providing and Consuming BOSH links

Using BOSH links <https://bosh.io/docs/links.html> simplifies manifests and
manifest generation - every time a BOSH release uses a link, that's less
copying and pasting via template.

- cloudfoundry/cf-mysql-release #154
<https://github.com/cloudfoundry/cf-mysql-release/pull/154>: Provide
database links for mysql and proxy jobs [#143086033
<https://www.pivotaltracker.com/story/show/143086033>]
- cloudfoundry/cf-mysql-release #149
<https://github.com/cloudfoundry/cf-mysql-release/pull/149>: Optionally
consume cc link for app_domains in smoke tests [#140458283
<https://www.pivotaltracker.com/story/show/140458283>]

Bug Fixes and Minor Improvements

- [BUG] Upgrading from older releases fails to start mariadb [#139334661
<https://www.pivotaltracker.com/story/show/139334661>]
- [BUG] Logs not draining to syslog [#143069405
<https://www.pivotaltracker.com/story/show/143069405>]
- Fixes a regression in v34 that logs were not sent to syslog.
- [BUG] mysql_release fails to deploy to a BOSH director using local_dns
[#143221877 <https://www.pivotaltracker.com/story/show/143221877>]
- [BUG] pre-start hangs indefinitely when cluster is not healthy [
#141824537 <https://www.pivotaltracker.com/story/show/141824537>]
- [BUG] If a node is failing, mariadb_ctrl waits for mysql forever [
#140517205 <https://www.pivotaltracker.com/story/show/140517205>]
- [BUG] roadmin user doesn't have read privs for admin operations? [
#139594503 <https://www.pivotaltracker.com/story/show/139594503>]
- cloudfoundry/cf-mysql-release #155
<https://github.com/cloudfoundry/cf-mysql-release/pull/155>: Allow
innodb_flush_log_at_trx_commit to be configurable [#143693837
<https://www.pivotaltracker.com/story/show/143693837>]
- cloudfoundry/cf-mysql-release #158
<https://github.com/cloudfoundry/cf-mysql-release/pull/158>: Nil the
consul link in the example stub [#144138871
<https://www.pivotaltracker.com/story/show/144138871>]
- cloudfoundry/cf-mysql-release #159
<https://github.com/cloudfoundry/cf-mysql-release/pull/159>: add private
key option to download-logs script [#144411627
<https://www.pivotaltracker.com/story/show/144411627>]
- As an Operator, if an errand is a no-op, it's better to exit 0 than
error [#139054911 <https://www.pivotaltracker.com/story/show/139054911>]
- Stop attaching the tarball to the release notes of cf-mysql-release [
#139611695 <https://www.pivotaltracker.com/story/show/139611695>]

Documentation

- Proxy startup and shutdown delay descriptions are backwards in spec [
#139996733 <https://www.pivotaltracker.com/story/show/139996733>]
- NOTICE files on various repositories are out of date [#141360157
<https://www.pivotaltracker.com/story/show/141360157>]

Manifest Changes

- New: cf.mysql.innodb_flush_log_at_trx_commit, optional, defaults to 1.
- New: cf_mysql.proxy.api_aggregator_port: optional, defaults to 8082.
- New: cf_mysql.proxy.api_uri, required when deploying the proxy
aggregator.
- Removed: cf_mysql.external_host
- Removed: cf_mysql.standalone


You are receiving this because you are subscribed to this thread.
View it on GitHub
<https://github.com/cloudfoundry/cf-mysql-release/releases/tag/v35> or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AANPTP6bHbvSYOVHua_lQ-4QpNgV2dB-ks5r2TYAgaJpZM4NQKSp>
.


Re: CF Summit Hackathon!

Chip Childers <cchilders@...>
 

Free robots for cool CF hacks... looking forward to seeing what people make!

On Tue, May 9, 2017 at 12:37 PM Chris Clark <cclark(a)cloudfoundry.org> wrote:

Hello all,

For the first time this year, we'll be a having a CF Hackathon at Cloud
Foundry Summit Silicon Valley (Jun 13-15). It's free, and will have
dedicated time from 9am-3pm Tuesday, with projects due Wednesday at 3pm.
Winners will be announced on stage during Thursday's keynotes, and top
three teams (max 4 people) will receive various awesome robots as prizes.

You can sign up for this while registering for Summit, but walk-ins will
be welcome Tuesday morning.

More details here
<https://www.cloudfoundry.org/event_subpages/events-sv-2017/>.

Please reach out if you have any questions and/or suggestions.
Hope to see you there!

Chris Clark
Technical Operations Manager
Cloud Foundry Foundation
--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815


CF Summit Hackathon!

Chris Clark
 

Hello all,

For the first time this year, we'll be a having a CF Hackathon at Cloud
Foundry Summit Silicon Valley (Jun 13-15). It's free, and will have
dedicated time from 9am-3pm Tuesday, with projects due Wednesday at 3pm.
Winners will be announced on stage during Thursday's keynotes, and top
three teams (max 4 people) will receive various awesome robots as prizes.

You can sign up for this while registering for Summit, but walk-ins will be
welcome Tuesday morning.

More details here
<https://www.cloudfoundry.org/event_subpages/events-sv-2017/>.

Please reach out if you have any questions and/or suggestions.
Hope to see you there!

Chris Clark
Technical Operations Manager
Cloud Foundry Foundation


NOTICE: Undocumented support for io.js will be removed from the Node.js buildpack after 2017-06-09

Stephen Levine
 

Hi All,

The Node.js buildpack has undocumented support for downloading unmaintained
versions of io.js. This support will be removed after June 9, 2017. If you
happen to rely on this undocumented behavior, please switch to a supported
version of Node.js before that date. For more information, refer to the
buildpack documentation: http://docs.cloudfoundry.org/buildpacks/node/

Thanks,
Stephen Levine
CF Buildpacks PM


NOTICE: Deprecated versions of NGINX will be removed from the PHP buildpack after 2017-06-09

Stephen Levine
 

Hi All,

NGINX versions 1.10.3 and 1.11.13 are no longer supported upstream and will
be removed from the PHP buildpack after June 9, 2017. NGINX versions 1.12.x
and 1.13.x are already included in the latest release of the buildpack. For
more information, refer to the buildpack documentation:
http://docs.cloudfoundry.org/buildpacks/php/

Thanks,
Stephen Levine
CF Buildpacks PM


NOTICE: Version of NGINX in the Staticfile buildpack will change to 1.13.x after 2017-06-09

Stephen Levine
 

Hi All,

The version of NGINX in the Staticfile buildpack will change from the
latest 1.11.x version (currently 1.11.13) to the latest 1.13.x version
(currently 1.13.0) in the first release of the Staticfile buildpack after
June 9, 2017. For more information, refer to the buildpack documentation:
http://docs.cloudfoundry.org/buildpacks/staticfile/

Thanks,
Stephen Levine
CF Buildpacks PM


Re: Issues on upgrading UAA 3.6.0 to 3.12.0?

Filip Hanik
 

We recommend that you upgrade to 3.16.0 to make sure you get all security
fixes included.

The UAA you are upgrading to supports multiple keys.
Here is an example

https://github.com/cloudfoundry/uaa/blob/develop/uaa/src/test/resources/test/bootstrap/all-properties-set.yml#L72-L82

add both your new and old keys into the configuration. Then set the
activeKeyId to be the new key.

The old key will be used to verify existing tokens only. The new key will
be used to sign new tokens.
When you believe the time is right, you can remove the old key from the
configuration. any tokens still signed with the old key will then be
considered invalid.

Filip

On Mon, May 8, 2017 at 4:23 PM, Sam Leong <sam.leong(a)quicken.com> wrote:

Hi,

We've been running UAA 3.6 on production and need to upgrade to 3.12. One
requirement is that we will need to retain the validity of the token that
was issued by UAA 3.6 after the upgrade.

We used the default key for token signing in 3.6, in the upgrade we will
use a new key, so I like to know the way how the client be able to verify
the signature of the old valid tokens while the new tokens will be signed
by a new key after upgrade to 3.12?

Thanks, Sam


Issues on upgrading UAA 3.6.0 to 3.12.0?

Sam Leong
 

Hi,

We've been running UAA 3.6 on production and need to upgrade to 3.12. One requirement is that we will need to retain the validity of the token that was issued by UAA 3.6 after the upgrade.

We used the default key for token signing in 3.6, in the upgrade we will use a new key, so I like to know the way how the client be able to verify the signature of the old valid tokens while the new tokens will be signed by a new key after upgrade to 3.12?

Thanks, Sam


Re: Proposal for named service bindings

Mike Youngstrom
 

This looks great! Thanks Zach.

Mike

On Mon, May 8, 2017 at 12:05 PM, Zach Robinson <zrobinson(a)pivotal.io> wrote:

Hey all,

Here's the implementation proposal: https://docs.google.com/
document/d/1PjcEx5_w383AKI9WyJHI4gGDkhIS9mhqwUK5nvmOWUc/edit?usp=sharing

And here's the tracker epic: https://www.pivotaltracker.
com/epic/show/3472063

-Zach


Re: Proposal for named service bindings

Zach Robinson
 


Get RTT with MessageInterceptor

Felipe Roca Blaya <felipe.rocablaya13@...>
 

Hi,
I'm working with eclipse-leshan and I found troubles trying to retrieve the rtt between a Coap request and response.
I've created a new MessageInterceptor but I've saw that CoapEndpoint calculates and sets the RTT value after notify the different MessageInterceptor.
This seems strange for me because the RTT by definition excludes the overhead in the requester. My first reaction has been if you change the order it should works. But I'm sure this has been made for a good reason. So if someone could explain it to me or tell me some other way to retrieve the rtt I'll be grateful.
Thanks in advance


Re: CF Diego Apps logging on stdout

Prashant Ghorpade
 

Hi,

Any updates? I am not getting application staging logs for CF v259 as well. Same observations for CF v255/256 and 257.

Thanks,
Prashant

From: Prashant Ghorpade
Sent: Wednesday, April 26, 2017 3:14 PM
To: Discussions about Cloud Foundry projects and the system overall. <cf-dev(a)lists.cloudfoundry.org>
Subject: RE: [cf-dev] Re: CF Diego Apps logging on stdout

Hi,

Yes you right! I really mean to say application staging logs and following are sample output which I am not able to see for CF v255/256/257 for Diego as a default backend. It’s working for me for CF v254.

----------------------------------------------------------------------------------------------------------------------------
2017-04-24T13:00:31.67-0400 [STG/0] OUT Successfully created container
2017-04-24T13:00:31.67-0400 [STG/0] OUT Downloading app package...
2017-04-24T13:00:33.68-0400 [STG/0] OUT Staging...
2017-04-24T13:00:33.68-0400 [STG/0] OUT Downloaded app package (43.8M)
2017-04-24T13:00:35.32-0400 [STG/0] OUT -----> Java Buildpack Version: v3.14 (offline) | https://github.com/cloudfoundry/java-buildpack.git#d5d58c6
2017-04-24T13:00:35.51-0400 [STG/0] OUT -----> Downloading Open Jdk JRE 1.8.0_121 from https://java-buildpack.cloudfoundry.org/openjdk/trusty/x86_64/openjdk-1.8.0_121.tar.gz (found in cache)
2017-04-24T13:00:36.84-0400 [STG/0] OUT Expanding Open Jdk JRE to .java-buildpack/open_jdk_jre (1.3s)
2017-04-24T13:00:36.84-0400 [STG/0] OUT -----> Downloading Open JDK Like Memory Calculator 2.0.2_RELEASE from https://java-buildpack.cloudfoundry.org/memory-calculator/trusty/x86_64/memory-calculator-2.0.2_RELEASE.tar.gz (found in cache)
2017-04-24T13:00:36.87-0400 [STG/0] OUT Memory Settings: -Xms1363148K -XX:MetaspaceSize=209715K -Xmx1363148K -XX:MaxMetaspaceSize=209715K -Xss699K
2017-04-24T13:00:36.87-0400 [STG/0] OUT -----> Downloading Container Certificate Trust Store 2.0.0_RELEASE from https://java-buildpack.cloudfoundry.org/container-certificate-trust-store/container-certificate-trust-store-2.0.0_RELEASE.jar (found in cache)
2017-04-24T13:00:37.24-0400 [STG/0] OUT Adding certificates to .java-buildpack/container_certificate_trust_store/truststore.jks (0.3s)
2017-04-24T13:00:37.24-0400 [STG/0] OUT -----> Downloading Spring Auto Reconfiguration 1.10.0_RELEASE from https://java-buildpack.cloudfoundry.org/auto-reconfiguration/auto-reconfiguration-1.10.0_RELEASE.jar (found in cache)
2017-04-24T13:00:48.25-0400 [STG/0] OUT Uploading droplet...
2017-04-24T13:00:48.25-0400 [STG/0] OUT Exit status 0
2017-04-24T13:00:48.25-0400 [STG/0] OUT Staging complete
2017-04-24T13:00:48.25-0400 [STG/0] OUT Uploading droplet, build artifacts cache...
2017-04-24T13:00:48.25-0400 [STG/0] OUT Uploading build artifacts cache...
2017-04-24T13:00:48.32-0400 [STG/0] OUT Uploaded build artifacts cache (109B)
2017-04-24T13:00:53.13-0400 [STG/0] OUT Uploaded droplet (89.1M)
2017-04-24T13:00:53.16-0400 [STG/0] OUT Uploading complete
2017-04-24T13:00:53.19-0400 [STG/0] OUT Destroying container
2017-04-24T13:00:53.49-0400 [CELL/0] OUT Creating container
2017-04-24T13:00:54.04-0400 [CELL/0] OUT Successfully created container
2017-04-24T13:00:54.09-0400 [STG/0] OUT Successfully destroyed container
2017-04-24T13:00:57.49-0400 [CELL/0] OUT Starting health monitoring of container
----------------------------------------------------------------------------------------------------------------------------
Thanks,
Prashant

From: ronak banka [mailto:ronakbanka.cse(a)gmail.com]
Sent: Wednesday, April 26, 2017 2:54 PM
To: Discussions about Cloud Foundry projects and the system overall. <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>>
Subject: [cf-dev] Re: CF Diego Apps logging on stdout

Hello,

By "application startup logs", do you mean application staging logs??

Can you paste log lines which are missing?

Thanks
Ronak

On Wed, Apr 26, 2017 at 14:25 Prashant Ghorpade <prashant.ghorpade(a)sas.com<mailto:prashant.ghorpade(a)sas.com>> wrote:
Hello,

I have seen some changes related to “cf logs app_name” command from CF v255 onwards on Openstack using Diego as a default container. CF v254 is working for me.

I am not getting application startup logs after running “cf logs app_name” command on stdout.

I am able to see logs when I try to access the sample application from browser but I am more interested in application startup logs.

Kindly let me know in case any additional details are required for the same.

Thanks,
Prashant


Re: Update: Locks & Service Discovery in CF Runtime

Benjamin Gandon
 

The road off Consul looks like it is long but necessary. Consul looks like a spof in CF, when you know how much the platform needs it, and when you read that sometimes plain upgrades break it badly.

Plus, the myriad of logic in the confab wrapper around Consul is an example of how much Consul is hard to manage and keep up properly.

Don't forget that recently PCF benefitted a CRE (SRE-tye) shared review from Google.
Don't forget that we have converging evidences that let us think Google stays away from etcd for their hosted K8s on GCP.

My guess is that internally, Google SREs might have evidences at scale that systems like etcd or consul should be avoided, and this understanding is being ported to CF through the CRE program.


Also, moving away from Consul is like choosing to build Diego instead of building on top of K8s. Controlling the agenda is important. I mean not being forced to run after a project that has its own. Ensuring which value is put into the product, and that this value is consistent with the rest of the platform, is also important.


These are just thoughts. I would love to read more precise info about the Why, for this "away-from-Consul" move. Guys?

Le 26 avr. 2017 à 18:48, Voelz, Marco <marco.voelz(a)sap.com> a écrit :

Dear Luan,

Maybe that's a stupid question which has already been answered, but doesn't consul release 0.8 address most of the criticism from the CF community?

I see now big efforts on all sides (CF and BOSH teams) invested in building our own solution to a problem which seems to be pretty generic.

Do we think that's something we should spend engineering resources on and that others (e.g. HashiCorp in this case) cannot solve the problem to se be our needs? At least to me it seems that they try to move in the right direction.

Maybe my perspective on this is just too generic and I'm not deep enough in the technical details.

What do you think?

Thanks and warm regards
Marco



On 24. Apr 2017, at 20:35, Luan Santos <lsantos(a)pivotal.io> wrote:

Hi all,

We have been working on the milestones proposed before in order to lessen and remove our dependencies on Consul.

Please see the updated Locks & Service Discovery in CF Runtime document for more details and discussion.

Thanks,

Luan
Software Engineer, Cloud Foundry @ Pivotal


Re: Inconsistency in retrieval of service plans

Benjamin Gandon
 

Did you look at the doc on api.cloudfoundry.org about any ordering contract for those API calls?

Le 5 mai 2017 à 12:16, Roopali Sharma <roopali1193(a)gmail.com> a écrit :

Hello All,



While listing service plans for any given service , if we use /v2/service_plans?q=<service_guid> , the plans appear in the same order as defined in the service catalog. However, call to /v2/services/<service_guid>?inline-relations-depth=1 returns the service plans in some random ordering which does not respect the order of catalog. The ordering however does not change with every call and also does not seem to take into account unique plan_id or the plan_name itself. Hence , it is unclear as to what sorting paradigm is in use.



Can someone comment if this is a bug with controller API or if not, some clarity regarding the ranking order.



With regards,

Roopali Sharma

2621 - 2640 of 9414