|
Re: Maximum size limitation of Diego apps' routes
Tim Lawrence <tim.lawrence1984@...>
Wouldn't it be better to use a single URL and implement the auth and separation in the app via token or something rather than by host URL? Or if you need to do that maybe have a micro proxy app per customer which has the main app registered as a service? It seems a lot of overhead to have that many routes per app
Sent from my iPhone
toggle quoted messageShow quoted text
On 12 May 2017, at 16:48, Jason Huang <jasonxs.huang(a)gmail.com> wrote:
Daniel,
Our apps support multi-tenancy and our customers are enterprise customers. For each subscription, there is unique ur which is mapped to the same app. Therefore for 500 subscriptions there are 500 routes. This new limitation introduced in Diego would break our production.
Can someone share the reason for introducing the limitation?
Thanks,
Jason
On Fri, May 12, 2017 at 6:25 AM, Daniel Jones <daniel.jones(a)engineerbetter.com> wrote:
Hi Maggie,
That's an unusual number of routes for a single app. Could you explain the use case please, so we can attempt to think of other solutions to the problem?
Regards,
Daniel Jones - CTO
+44 (0)79 8000 9153
@DanielJonesEB
EngineerBetter Ltd - UK Cloud Foundry Specialists
On 12 May 2017 at 03:21, Meng, Xiangyi <Xiangyi.Meng(a)dell.com> wrote:
Hi,
We have one application with over 200 routes and one application with over 400 routes. And we expect more routes will be created with more subscriptions coming.
But those applications can’t run in Diego container due to the maximum size limitation of 4KB as mentioned in https://discuss.pivotal.io/hc/en-us/articles/230433388-Migrating-Applications-from-DEAs-to-Diego
Diego imposes a 4KB limit on the maximum size of an application's routes. While this doesn't translate to a specific number of routes, as it would depend on how many characters are in each routes, we are estimating that gives you space for 40 to 50 medium sized (50 character) routes. If you have too many routes bound to your application, you'll see the error Runner error: desire app failed: 503. In some cases you can work around this by using a wildcard route (i.e. *.my-domain.com) instead of mapping individual routes. When that is not possible, the only other option is to run multiple applications mapping 40 to 50 routes to each application.
Apparently wildcard is not an option and we don’t want to split applications just because we can’t add more routes. Is there any other solution? And would anyone help to explain why this limitation is necessary? I don’t remember same issue existed in DEA.
Thanks,
Maggie
|
|
|
Re: Incubation Proposal: Kubo (Kubernetes on BOSH)
Ditto. Have a great weekend all. Cheers, Max On Fri, May 12, 2017 at 7:54 AM Chip Childers <cchilders(a)cloudfoundry.org> wrote: Super exciting to see this!
On Fri, May 12, 2017 at 7:40 AM Alejandro Goyen <agoyen(a)pivotal.io> wrote:
Hello,
Pivotal and Google would like to propose to the CF Extensions PMC a new
incubation project , “KuBo”, focusing on BOSH-managed Kubernetes clusters.
This project may be used in a BOSH environment to deploy and manage
Kubernetes clusters.
Project name: KuBo (Kubernetes on Bosh)
Project proposal:
https://docs.google.com/document/d/1ZOFD5nBQC_vh9CmKHOGT7ugtNaJQ1t03jkLVsyDOH6k/edit#
Project overview presentation:
https://docs.google.com/presentation/d/1z-qGCcHLlPpz5LtS0TOcvBZIK4hUQ4GhB-jjQyHEF3c/edit#slide=id.g1d413a0051_0_13
Proposed Project Lead: Alejandro Goyen (Pivotal)
Proposed Scope: See “Proposed Scope” in the proposal
Development Operating Model: Pairing Model
Technical Approach: See “Architecture” and "Examples" in the proposal
Initial team committed: 4 engineers from Pivotal, 2 engineers from Google
Please let us know if you have any questions.
Thanks,
Alejandro Goyen, Pivotal
Eric Johnson, Google
--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815
-- dr.max Sent from my iPhone http://maximilien.org
|
|
|
Re: Maximum size limitation of Diego apps' routes
Daniel, Our apps support multi-tenancy and our customers are enterprise customers. For each subscription, there is unique ur which is mapped to the same app. Therefore for 500 subscriptions there are 500 routes. This new limitation introduced in Diego would break our production. Can someone share the reason for introducing the limitation? Thanks, Jason On Fri, May 12, 2017 at 6:25 AM, Daniel Jones < daniel.jones(a)engineerbetter.com> wrote: Hi Maggie,
That's an unusual number of routes for a single app. Could you explain the
use case please, so we can attempt to think of other solutions to the
problem?
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 12 May 2017 at 03:21, Meng, Xiangyi <Xiangyi.Meng(a)dell.com> wrote:
Hi,
We have one application with over 200 routes and one application with
over 400 routes. And we expect more routes will be created with more
subscriptions coming.
But those applications can’t run in Diego container due to the maximum
size limitation of 4KB as mentioned in https://discuss.pivotal.io/hc/
en-us/articles/230433388-Migrating-Applications-from-DEAs-to-Diego
Diego imposes a 4KB limit on the maximum size of an application's routes.
While this doesn't translate to a specific number of routes, as it would
depend on how many characters are in each routes, we are estimating that
gives you space for 40 to 50 medium sized (50 character) routes. If you
have too many routes bound to your application, you'll see the error *Runner
error: desire app failed: 503.* In some cases you can work around this
by using a wildcard route (i.e. *.my-domain.com) instead of mapping
individual routes. When that is not possible, the only other option is to
run multiple applications mapping 40 to 50 routes to each application.
Apparently wildcard is not an option and we don’t want to split
applications just because we can’t add more routes. Is there any other
solution? And would anyone help to explain why this limitation is
necessary? I don’t remember same issue existed in DEA.
Thanks,
Maggie
|
|
|
Re: Incubation Proposal: Kubo (Kubernetes on BOSH)
Chip Childers <cchilders@...>
Super exciting to see this!
toggle quoted messageShow quoted text
--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815
|
|
|
[Important] Breaking changes in UAA Release v35
Hi All, Starting with UAA bosh release v35 < http://bosh.io/releases/github.com/cloudfoundry/uaa-release?version=35> the following ERB validations have been added for OAuth Clients: 1. *redirect-uri* is required if authorized-grant-types contains "authorization_code" or "implicit" 2. *secret* is required if authorized-grant-types contains "authorization_code", "implicit" or "password". 3. *scope* is required if authorized-grant-types contains "authorization_code", "implicit" or "password" 4. *authorities* is required if authorized-grant-types contains "client_credentials" 5. *authorized-grant-types* should contain at least one of the following values : "authorization_code", "implicit", "password" , "client_credentials" Please ensure that your UAA bosh release yml is set up properly *as deployment will not proceed* without these changes. Thanks, Sree Tummidi Staff Product Manager Identity - Pivotal Cloud Foundry
|
|
|
Re: Maximum size limitation of Diego apps' routes
Hi Maggie, That's an unusual number of routes for a single app. Could you explain the use case please, so we can attempt to think of other solutions to the problem? 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 12 May 2017 at 03:21, Meng, Xiangyi <Xiangyi.Meng(a)dell.com> wrote: Hi,
We have one application with over 200 routes and one application with over
400 routes. And we expect more routes will be created with more
subscriptions coming.
But those applications can’t run in Diego container due to the maximum
size limitation of 4KB as mentioned in https://discuss.pivotal.io/hc/
en-us/articles/230433388-Migrating-Applications-from-DEAs-to-Diego
Diego imposes a 4KB limit on the maximum size of an application's routes.
While this doesn't translate to a specific number of routes, as it would
depend on how many characters are in each routes, we are estimating that
gives you space for 40 to 50 medium sized (50 character) routes. If you
have too many routes bound to your application, you'll see the error *Runner
error: desire app failed: 503.* In some cases you can work around this
by using a wildcard route (i.e. *.my-domain.com) instead of mapping
individual routes. When that is not possible, the only other option is to
run multiple applications mapping 40 to 50 routes to each application.
Apparently wildcard is not an option and we don’t want to split
applications just because we can’t add more routes. Is there any other
solution? And would anyone help to explain why this limitation is
necessary? I don’t remember same issue existed in DEA.
Thanks,
Maggie
|
|
|
Incubation Proposal: Kubo (Kubernetes on BOSH)
Hello, Pivotal and Google would like to propose to the CF Extensions PMC a new incubation project , “KuBo”, focusing on BOSH-managed Kubernetes clusters. This project may be used in a BOSH environment to deploy and manage Kubernetes clusters. Project name: KuBo (Kubernetes on Bosh) Project proposal: https://docs.google.com/document/d/1ZOFD5nBQC_vh9CmKHOGT7ugtNaJQ1t03jkLVsyDOH6k/edit# Project overview presentation: https://docs.google.com/presentation/d/1z-qGCcHLlPpz5LtS0TOcvBZIK4hUQ4GhB-jjQyHEF3c/edit#slide=id.g1d413a0051_0_13 Proposed Project Lead: Alejandro Goyen (Pivotal) Proposed Scope: See “Proposed Scope” in the proposal Development Operating Model: Pairing Model Technical Approach: See “Architecture” and "Examples" in the proposal Initial team committed: 4 engineers from Pivotal, 2 engineers from Google Please let us know if you have any questions. Thanks, Alejandro Goyen, Pivotal Eric Johnson, Google
|
|
|
Sylvain Goulmy <sygoulmy@...>
Hi all,
I see in the security configuration for consul that there is a specific procedure to
change existing certificates if you want to rotate to a new set.
I was wondering if that also applies for the other cf component (cc, etcd, loggregator) or
if this is only specific for the consul component ?
If this is consul specific, does it mean that for the other components you just have to
change the certs in your stub and deploy ?
Thanks in advance for your feedback.
Sylvain
|
|
|
Maximum size limitation of Diego apps' routes
Meng, Xiangyi <Xiangyi.Meng@...>
Hi, We have one application with over 200 routes and one application with over 400 routes. And we expect more routes will be created with more subscriptions coming. But those applications can't run in Diego container due to the maximum size limitation of 4KB as mentioned in https://discuss.pivotal.io/hc/en-us/articles/230433388-Migrating-Applications-from-DEAs-to-DiegoDiego imposes a 4KB limit on the maximum size of an application's routes. While this doesn't translate to a specific number of routes, as it would depend on how many characters are in each routes, we are estimating that gives you space for 40 to 50 medium sized (50 character) routes. If you have too many routes bound to your application, you'll see the error Runner error: desire app failed: 503. In some cases you can work around this by using a wildcard route (i.e. *.my-domain.com) instead of mapping individual routes. When that is not possible, the only other option is to run multiple applications mapping 40 to 50 routes to each application. Apparently wildcard is not an option and we don't want to split applications just because we can't add more routes. Is there any other solution? And would anyone help to explain why this limitation is necessary? I don't remember same issue existed in DEA. Thanks, Maggie
|
|
|
CF CAB call next week Wednesday May 17th @ 8a PDT (UTC -7)
Hi, all, Quick reminder of the CloudFoundry Community Advisory Board (CAB) call next Wednesday, May 17th @ 8a PDT (UTC -7). All info in link [1]. Remember, no more status updates but rather project highlights, open discussions, and community presentations. For this month we have two confirm presentations and perhaps a third---will confirm before reminder next week: 1. Idit Levine (formerly EMC) on the Unik project [2]. 2. Therese Stowell (Pivotal) on BOSH Backup/Restore (BBR) project [link in next email]. Please go to the slack.cloudfoundry.org and join the #CAB channel for previous and future discussions. Zoom you all next week. I'll send one more reminder on this list and Slack. Best, dr.max ibm cloud labs sillicon valley, ca Sent from my iPhone [1] https://docs.google.com/document/d/1SCOlAquyUmNM-AQnekCOXiwhLs6gveTxAcduvDcW_xI/edit#heading=h.o44xhgvum2we[2] https://github.com/cf-unik/unikdr.max ibm cloud labs sillicon valley, ca usa maximilien.org Sent from my iPhone
|
|
|
Chip Childers <cchilders@...>
toggle quoted messageShow quoted text
On Wed, May 10, 2017 at 3:06 PM Duncan Winn <dwinn(a)pivotal.io> wrote: Mr EngineerBetter,
*"cough *replacing droplets with layered filesystems *cough"*
And there I was thinking you were going to propose something easy like a
mainframe emulator buildpack :-)
On Wed, May 10, 2017 at 6:38 AM Chip Childers <cchilders(a)cloudfoundry.org>
wrote:
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
--
Duncan Winn
Cloud Foundry PCF Services
--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815
|
|
|
Mr EngineerBetter, *"cough *replacing droplets with layered filesystems *cough"* And there I was thinking you were going to propose something easy like a mainframe emulator buildpack :-) On Wed, May 10, 2017 at 6:38 AM Chip Childers <cchilders(a)cloudfoundry.org> wrote: 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
-- Duncan Winn Cloud Foundry PCF Services
|
|
|
Re: Proposal: Using OCI Images for Droplets and RootFS in CF
GREAT idea and proposal!
2017-05-10 14:53 GMT-03:00 Jamie OMeara <jomeara(a)pivotal.io>:
toggle quoted messageShow quoted text
+ 2,000 John, love the proposal
*Jamie O'Meara*
Platform Architect
303.898.5437
jomeara(a)pivotal.io
www.pivotal.io
On Wed, Mar 22, 2017 at 11:18 AM, John Feminella <jxf(a)pivotal.io> wrote:
+1,000! This is a fantastic proposal.
On Wed, Mar 22, 2017, 06:48 Julz Friedman <julz.friedman(a)gmail.com>
wrote:
Hi CF-Devs!
A few of us have been working on a proposal to explore using OCI Images
(a standardised format for container images) to allow more standard, more
flexible and potentially more performant management of root filesystems and
droplets in Cloud Foundry.
This is based on the talk Will Pragnell, Gareth Smith and I gave at CF
Summit EU [0] - which may be a better bet if you don't fancy a terrifyingly
long proposal doc [1]!
The proposal [1] and video [0] are below and feedback is very welcome!
[0]: https://www.youtube.com/watch?v=DSTT0przx4g
[1]: https://docs.google.com/document/d/16_dnhUW3CmM4KV6HDJlGuBfT
l-RL2oUee7n028Lhojs/edit?usp=sharing
Thanks,
Julz
Garden PM
--
John Feminella
Advisory Platform Architect
✉ · jxf(a)pivotal.io
t · @jxxf
-- Mis mejores deseos, Best wishes, Meilleurs vœux, Juan Pablo ------------------------------------------------------ http://www.jpgenovese.com
|
|
|
Re: Proposal: Using OCI Images for Droplets and RootFS in CF
+ 2,000 John, love the proposal
*Jamie O'Meara*
Platform Architect
303.898.5437
jomeara(a)pivotal.io
www.pivotal.io
toggle quoted messageShow quoted text
On Wed, Mar 22, 2017 at 11:18 AM, John Feminella <jxf(a)pivotal.io> wrote: +1,000! This is a fantastic proposal.
On Wed, Mar 22, 2017, 06:48 Julz Friedman <julz.friedman(a)gmail.com> wrote:
Hi CF-Devs!
A few of us have been working on a proposal to explore using OCI Images
(a standardised format for container images) to allow more standard, more
flexible and potentially more performant management of root filesystems and
droplets in Cloud Foundry.
This is based on the talk Will Pragnell, Gareth Smith and I gave at CF
Summit EU [0] - which may be a better bet if you don't fancy a terrifyingly
long proposal doc [1]!
The proposal [1] and video [0] are below and feedback is very welcome!
[0]: https://www.youtube.com/watch?v=DSTT0przx4g
[1]: https://docs.google.com/document/d/16_dnhUW3CmM4KV6HDJlGuBfTl-
RL2oUee7n028Lhojs/edit?usp=sharing
Thanks,
Julz
Garden PM
--
John Feminella
Advisory Platform Architect
✉ · jxf(a)pivotal.io
t · @jxxf
|
|
|
Re: Announcing cf-mysql-release v35
Marco,
I think I'll be there, and sure! Let me buy you a beer and discuss this.
Thank you! :)
2017-05-10 11:28 GMT-03:00 Marco Nicosia <mnicosia(a)pivotal.io>:
toggle quoted messageShow quoted text
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
-- Mis mejores deseos, Best wishes, Meilleurs vœux, Juan Pablo ------------------------------------------------------ http://www.jpgenovese.com
|
|
|
Re: Announcing cf-mysql-release v35
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
|
|
|
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
|
|
|
*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
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>:
toggle quoted messageShow quoted text
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
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.htmlSo 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...
|
|
|
