|
REQUEST for REVIEW - Proposed Scope for CF-Deployment 6.0
Josh Collins
Hello Fellow Cloud-Founderians, I'd like to share and gather feedback on proposed scope of the next major release of cf-deployment. I've created a Google Doc which describes the high-level changes under proposal. Anyone with the link above can review and comment. Please feel free to review and provide feedback in the document as soon as you're able. We'll be locking the scope Monday October 29th. For those interested in following, here's the v6.0 epic in our backlog. Lastly, if you've got breaking changes that you'd like Release Integration to consider in the future please bring them to my and the team's attention: Thanks very much for reading to the end and Happy Friday! -- Josh Collins PM - CF R&D Release Integration Josh Collins |
|
|
|
REQUEST for REVIEW - Proposed Scope for CF-Deployment 5.0
Josh Collins
Hello Fellow Cloud-Founderians, I'd like to share and gather feedback on proposed scope of the next major release of cf-deployment. I've created a Google Doc which describes the high-level changes under proposal. Anyone with the link above can review and comment. Please feel free to review and provide feedback in the document as soon as you're able. We'll be locking the scope Monday October 29th. For those interested in following, here's the v6.0 epic in our backlog. Lastly, if you've got breaking changes that you'd like Release Integration to consider in the future please bring them to my and the team's attention: Thanks very much for reading to the end and Happy Friday! -- Josh Collins PM - CF R&D Release Integration |
|
|
|
FYI: CF CAB calls for October and November
Michael Maximilien
Hi, all,
Just to be clear, no CF CAB call today as we did it live last week during CF Summit in Basel. Altoros already published their post with brief review. See link here: https://twitter.com/altoros/status/1051901952169320449?s=21 For next month, since the normal schedule would fall the day before US Thanksgiving we discussed in Basel to reschedule the week before, so Wednesday November 14th. Zoom with you then. Best, dr.max ibm ☁ silicon valley, ca |
|
|
|
Re: Cloud Foundry in Edinburgh
Caitlyn O'Connell <coconnell@...>
Hi all, It was so great getting to see so many of you at Cloud Foundry Summit in Basel this week! I'll be in Edinburgh week after next for Open Source Summit and am looking for volunteers to help Chris Clark and me at the booth. Sign up here. Major shoutout to the folks at Armakuni who've signed up for a slot! Please consider giving an hour or two of your time to talk about Cloud Foundry and meet folks in the community. It's a perfect opportunity to share what you're doing with CF. Thanks and see you in Scotland! Caitlyn ---------- Forwarded message --------- From: Naomi Washington <nwashington@...> Date: Fri, Oct 5, 2018 at 9:37 PM Subject: Re: Cloud Foundry at OSS EU 2018 | Call for Booth Staff Volunteers To: <marketing-workgroup@...> Hello - Just a reminder to sign up for the Cloud Foundry booth at Open Source Summit Europe 2018, October 22 - 24, 2018, in Edinburgh, United Kingdom. Cloud Foundry’s members are critical to the success of our participation at OSS EU, and we are requesting that anyone who is attending the event or are in the Edinburgh area, sign up for a shift to staff the booth. Please sign-up for a 2-hour time slot. Thank you again and have a wonderful weekend! Regards, Naomi Naomi Washington Meeting and Event Coordinator The Linux Foundation T: 1.913.426.3148 (Time Zone: Central) On Wed, Sep 19, 2018 at 10:00 AM Naomi Washington <nwashington@...> wrote:
You received this message because you are subscribed to the Google Groups "Marketing Workgroup" group. To unsubscribe from this group and stop receiving emails from it, send an email to marketing-workgroup+unsubscribe@.... To post to this group, send email to marketing-workgroup@.... Caitlyn O'Connell Marketing Communications Manager Cloud Foundry Foundation 818 439 5079 | @caitlyncaleah Want to contribute to our blog? Email content@.... Interested in how you can try out Cloud Foundry? Read about 2018 certified platforms. |
|
|
|
Re: Changing IP addresses in deployed CF
Hjortshoj, Julian <Julian.Hjortshoj@...>
Hi Jo,
I hope all is well with you. I didn't see a response to this, so I thought I'd take a swing at it.
This use case (moving all the state to another CF deployment for DR) is exactly what BBR is meant for (https://docs.cloudfoundry.org/bbr/). Did you consider to use that instead? To me, using scripting to patch the persistent disks seems like a pretty
sketchy idea and will be fragile at best. Even if you do get it to work, you will probably find that it is unreliable and requires a lot of maintenance when up upgrade to new cf-d versions that do stuff like replacing consul dns with bosh DNS or replacing
gorouter with istio.
BBR was fairly new in the 1.15 time frame, but there is an experimental ops file for it in that version.
HTH,
-Julian From: cf-dev@... [cf-dev@...] on behalf of Jonathan Stockley [jstockle@...]
Sent: Tuesday, October 9, 2018 11:49 AM To: cf-dev@... Subject: [cf-dev] Changing IP addresses in deployed CF [EXTERNAL EMAIL] Hi, We are using cf-deployment release 1.15.0 in a vSphere environment and are looking at DR strategies. Up until now, we have implemented DR by replicating the persistent disks to another vSphere configured with the same datastores and network config (i.e. IP addresses in both DCs are the same).
We now have to deploy into datacenters that have different IP networks. It has been suggested that we can update the IP addresses in the persistent disks when bringing up the DR site.
Is there any information as to where CF stores IP addresses of various components (config files, db tables, etc.) that I could use to determine the effort required to patch everything to use IP addresses in DR environment?
Thanks, Jo |
|
|
|
Changing IP addresses in deployed CF
Jonathan Stockley
Hi, We are using cf-deployment release 1.15.0 in a vSphere environment and are looking at DR strategies. Up until now, we have implemented DR by replicating the persistent disks to another vSphere configured with the same datastores and network config (i.e. IP addresses in both DCs are the same).
We now have to deploy into datacenters that have different IP networks. It has been suggested that we can update the IP addresses in the persistent disks when bringing up the DR site.
Is there any information as to where CF stores IP addresses of various components (config files, db tables, etc.) that I could use to determine the effort required to patch everything to use IP addresses in DR environment?
Thanks, Jo |
|
|
|
REMINDER: CF CAB call for October live @ CF Summit in Basel, Switzerland on Thursday 3p local time
Michael Maximilien
FYI...
No planned agenda. Just chit chat, recap, QAs, and discussions. Grab a drink and join us. We’ll try to broadcast it live if there is a remote audience. Tune to #cab slack channel for details. Best, dr.max ibm ☁ silicon valley, ca |
|
|
|
How plugin updates are handled in cloud foundry?
Sigal, Maya
Hi, I went through the following documentation: https://github.com/cloudfoundry/cli/tree/master/plugin/plugin_examples, however it couldn’t help. I would like to know how are a plugin updates are handled in cloud foundry? For example, if I have some hot fix, and I would like to have my plugin to be updated by all users ? Do they have to issue the command cf plugins –outdated, are they at least informed about available updates or can the updates be forced? I couldn’t find this information.
Thanks in advance, Maya Sigal |
|
|
|
Handing over the cf-resource and autopilot projects
Christopher Brown
Hi all, We (Alex Suraci & Christopher Brown) would like to propose handing the cf-resource and the underlying autopilot CF CLI plugin over to the CF Foundation and the community. The cf-resource is too specialized for the core Concourse distribution and I don’t have time to effectively and responsibly maintain the autopilot plugin anymore. Both projects could do with some love and a vision for their future. We’d like to move them into one of the Cloud Foundry GitHub organizations (I’m not sure which one makes sense) and find maintainer(s) for them. Would anyone who has made contributions to these projects in the past or relies on them heavily be interested in becoming a maintainer? Thanks, Alex & Christopher |
|
|
|
Re: Propose removing --no-start from cf push in CLI v7
Zach Robinson
Hi Norm,
That's an interesting possible UX. Part of this process is to gather feedback before making a change and to potentially alter the proposal to better fit everybody's needs. Thanks for sharing this. |
|
|
|
Re: Propose removing --no-start from cf push in CLI v7
Zach Robinson
Hi Dr Nic,
Yes this is a proposal to maintain that workflow, but with a slightly different command set. The title is bad. Should have called it Proposal to replace --no-start. -Zach |
|
|
|
Re: [cf-bosh] BOSH Stemcell Support Policy
Marco Voelz
Dear Morgan,
I don't have the rights to comment in the attached document, so I guess I'll leave my comments here.
We should specifically mention how we're dealing with the case of switching operating systems. We're doing it now by switching from Trusty to Xenial, and we will do it again when we switch from Xenial to Bionic or 20.04 (whatever it will be called).
In cases like this, will ne do N and N-1 per operating system version (i.e. N and N-1 on Trusty as well as N and N-1 on Xenial) – at least for some grace period?
Thanks and warm regards Marco
From: <cf-bosh@...> on behalf of Morgan Fine <mfine@...>
Hi CF Community,
The BOSH team is working to formalize a policy for Linux stemcell support. Up until now, the team has not had a policy on which stemcell lines are officially supported. We'll also be working to make this information available on bosh.io.
Please find the details in the attached document.
Best, Morgan Fine CF BOSH |
|
|
|
Re: Propose removing --no-start from cf push in CLI v7
Norm Abramovitz
Hi It seems to me that you are making the developer experience more painful with your new interface I wondering why you did not consider using parameters to cf push instead. The first parameter would be a stop after parameter to stop after a phase. --stop-after build|droplet|staging|start If you want to start at a particular phase versus starting with a build, then have a parameter starting at a phase. --start-at build|droplet|staging|start Most developers would still use cf push as it is now and only those people that need the new features will use them. Also, you maintain the readability of the cli interface. Now the no-start parameter can be maintained for backward compatibility. On Thu, Oct 4, 2018 at 1:29 PM Zach Robinson <zrobinson@...> wrote: Hey all, --
Norman Abramovitz Technical Director Stark & Wayne, LLC  |
|
|
|
Re: Propose removing --no-start from cf push in CLI v7
Dr Nic Williams <drnicwilliams@...>
I’ve used —no-start to create an new app so I can bind services, then push to start. Is there a different way to do this without —no-start (and before you’ve started creating an optional manifest)
Nic
From: 20002216260n behalf of
Hey all,Sent: Friday, October 5, 2018 4:29 am To: cf-dev@... Subject: [cf-dev] Propose removing --no-start from cf push in CLI v7 We asked for some feedback regarding the use of the --no-start flag some time ago. As a result, we're proposing a change to push in the upcoming CLI v7. In the linked doc we've described what the change is and why we want to make it. We'd love to hear any feedback in comments on the doc. https://docs.google.com/document/d/1OPJSUYXMQMtzZmVdnvwI4NiXE0xp4tuLxO3fhhXtGwI/edit?usp=sharing Thanks, Zach Robinson CAPI Project Lead and Abby Chau CLI Project Lead |
|
|
|
Propose removing --no-start from cf push in CLI v7
Zach Robinson
Hey all,
We asked for some feedback regarding the use of the --no-start flag some time ago. As a result, we're proposing a change to push in the upcoming CLI v7. In the linked doc we've described what the change is and why we want to make it. We'd love to hear any feedback in comments on the doc. https://docs.google.com/document/d/1OPJSUYXMQMtzZmVdnvwI4NiXE0xp4tuLxO3fhhXtGwI/edit?usp=sharing Thanks, Zach Robinson CAPI Project Lead and Abby Chau CLI Project Lead |
|
|
|
Future usage of instance identity credentials
matthias.winzeler@...
Hi all
I was quite excited when I found out about instance identity credentials (https://docs.cloudfoundry.org/devguide/deploy-apps/instance-identity.html): Each app gets its own x509 keypair that can be used for mTLS - and it’s even rotated automatically! This looks like a powerful enabler for all kind of future mTLS scenarios.
However, it looked like this keypair is currently limited to three use cases:
Why I’m interested about this:
But: the app does not notice when the keypair is rotated, causing the connection to break after the first rotation.
Are there any plans to add support (i.e. automatic watching and insertion) for other buildpacks so that CF_INSTANCE_CERT/CF_INSTANCE_KEY becomes a first class resource for all kind of apps?
If someone of the Credhub team is at CF Summit Basel next week I’d be very happy to chat about this!
Best regards Matthias
Matthias Winzeler Application Cloud https://developer.swisscom.com ___________________________________________________________________________ matthias.winzeler@... |
|
|
|
Re: CC API V3 and CLI v7 Initiative
Abby Chau
Hi Guillaume, Thanks for your email. Please feel free to drop by the CF CLI office hours at Summit. Looking forward to speaking. Best, Abby On Wed, Oct 3, 2018 at 10:28 AM Guillaume Berche <bercheg@...> wrote:
|
|
|
|
A new approach to forwarding application logs to syslog drains
Johannes Tuchscherer
Hi there, the loggregator team has come across a few cases where in a big cf deployment with over 9k application-bound syslog drains the scalable syslog adapter is reaching its scaling limits (pun intended). We spent some time rethinking the problem regarding the forwarding of application logs to syslog drains. We came to the conclusion that the forwarding best happens as close to the origin of the logs as possible. To implement that strategy, we want to introduce some process on the diego cell (maybe integrated in the loggregator agent aka metron agent), that will forward each application log line directly to the configured syslog endpoint. You can read more details in this document: Please let us know if you have any questions or concerns about this approach. Thanks, Johannes |
|
|
|
Re: CC API V3 and CLI v7 Initiative
Hi Zach, Some feedback related to the deprecation of the CC API V2 in favor of V3: there are many tooling out there that currently rely on the CC API V2 (such as UIs, service brokers, provisionning tools such as terraform-provider-cf or SAP MTA...). These tooling usually leverage CC API clients [2]. Ways to reduce impacts for such tooling would be to work with client maintainers (both official, experimental and unsupported) so sync the CC API V2 support policy with availability of CC API V3 support in clients is most widely used programming languages. The terraform-provider-cf [1] in particular is quite interested in having the CF CLI CC API client being extracted into a distinct repo, and be more developer friendly, see related discussions in [3][4]. Part of the terraform-provider-team will be at basel summit (see related talk at [1b]) and would be eager to exchange with the CF CLI team on this topic, possibly during the CF CLI office hours. Thanks, Guillaume. On Tue, Oct 2, 2018 at 6:46 PM Zach Robinson <zrobinson@...> wrote:
|
|
|
|
403 Forbidden Nginx
mjana@...
Hi,
I am getting 403 Forbidden Nginx when I type URL: https://preonboarding.apps.eu1.mindsphere.io/ What should I do now? |
|
|