Date   
Re: Building BOSH release for s390x platform

Rob Day-Reynolds <rdayreynolds@...>
 

You can package a bosh release by cloning the bosh repo from github.com/cloudfoundry/bosh and running `bosh create-release --tarball <path/to/bosh/release/tarball.tgz>` inside the repo.

Then, you can use that local bosh release when using bosh-deployment by adding a `-o bosh-deployment/local-bosh-release-tarball.yml -v local_bosh_release=<path/to/bosh/release/tarball.tgz`.

If you're seeing errors when trying to deploy at that point that's when you would have to make changes in the bosh repo to the jobs/packages/etc.

On Wed, Feb 21, 2018 at 11:59 AM, R M <rishi.investigate@...> wrote:
Hi there,

I am looking for some directions on building BOSH release for s390x arch.  I have successfully built CLI V2 on this platform and trying to create-env bosh-deployment/bosh.yml but yml file refers to pre-built bosh release from from S3.

I would like to build BOSH release for my platform by replacing x86 packages with s390x equivalent.  It seems that I will need to make major changes to jobs/config/packages etc. and then create a bosh release out of it.

Any pointers greatly appreciated. Tx.




--
Thanks,
RDR

Building BOSH release for s390x platform

R M
 

Hi there,

I am looking for some directions on building BOSH release for s390x arch.  I have successfully built CLI V2 on this platform and trying to create-env bosh-deployment/bosh.yml but yml file refers to pre-built bosh release from from S3.

I would like to build BOSH release for my platform by replacing x86 packages with s390x equivalent.  It seems that I will need to make major changes to jobs/config/packages etc. and then create a bosh release out of it.

Any pointers greatly appreciated. Tx.

Re: Canary Node Update

Tyler Schultz
 

Hi Ponraj,

Although it is likely to be the same instance, there is no guarantee that the same instance will be always chosen as the canary. There are many reasons BOSH director would choose a different instance to update first.

You may be interested to know about the `spec.bootstrap` property made available during template rendering. Before making deployment changes BOSH director will select a bootstrap instance and update that instance first. The `spec.bootstrap` property will be true for the given instance. If the bootstrap instance were to go away (eg. scaling the instance count down or switching AZs), director will select a new bootstrap instance.


--Tyler

On Wed, Feb 14, 2018 at 7:59 PM, Ponraj E <ponraj.e@...> wrote:
Hi Colleagues,

Is the canary node chosen by BOSH always the same on every update? Like for example, if we have a three node cluster in a deployment and our update section looks like this:
update:
    canaries: 1
    max_in_flight: 1
 
 i.e., one node at a time. 
 
We see that on every update, the canary node chosen, is always the same. Is there any chance that this behaviour can change, maybe in case, if the canary node is in "stopped" or "failing", will the other VM be picked up for update?


Canary Node Update

Ponraj E <ponraj.e@...>
 

Hi Colleagues,

Is the canary node chosen by BOSH always the same on every update? Like for example, if we have a three node cluster in a deployment and our update section looks like this:
update:
    canaries: 1
    max_in_flight: 1
 
 i.e., one node at a time. 
 
We see that on every update, the canary node chosen, is always the same. Is there any chance that this behaviour can change, maybe in case, if the canary node is in "stopped" or "failing", will the other VM be picked up for update?

CAB call for February is Wednesday 02/21 @ 8a PST

Michael Maximilien <maxim@...>
 

FYI...
 
First off, Happy Valentines Day! 
 
Second, reminder that the CAB call for February is scheduled for next Wednesday 02/21 @ 8a PST.
 
WIP agenda in [1] but summary:
 
  1. CFF updates.
  2. Highlights from different PMCs and teams.
  3. Community talks:
a. CF Documentation Process and How you can contribute? by Benjamin Tarnoff and team, Pivotal
b. CF Abacus Demo / Update by Hristo Lliev and team, SAP
 
I will send one more reminder next week on this list. Zoom soon.
 
Best,
 
PS: I will be at INDEXconf all week next week in San Francisco and want to personally invite you (if around) to CF Day @ INDEX on 02/20, the day before CAB call, at the Moscone Center. We have curated a great line up of CF community speakers on various topics (see agenda: https://goo.gl/p9tKmz) and register for FREE with code: CD1CFDAY here: https://goo.gl/KxuZcF
 
------
dr.max
ibm ☁ 
silicon valley, ca
maximilien.org
 
 

CF Summit Contributor Registration Time

Chip Childers
 

Hey all!

It's time again for contributors to get themselves registered for CF Summit North America in April! 

For those of you that have contributed to a CFF project (any repo in the cloudfoundry, cloudfoundry-incubator, cloudfoundry-attic or openservicebrokerapi GitHub orgs), we've got you covered with free registration. :)

CFNA18CONT

-chip
--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815

Re: Bosh create_env CLI error returning { openstack =\u003e { tenant =\u003e Missing key } }

Marco Voelz
 

Dear RJWS,

 

the error you're seeing is because the CPI assumes you're not using Keystone v3. Therefore, it tries to find the properties necessary for Keystone v2, which is e.g. 'tenant' instead of project. To figure out if Keystone v3 or v2 is used, the CPI parses the URL passed in as 'auth_url' [1]. In theory, this error should not have occurred when you passed in a URL which contains '/v3'.

 

You're saying, you've already tried passing in '-v auth_url=https://somenode-us-west-3.mynode.com:5000/v3' and   also -v auth_url=https://somenode-us-west-3.mynode.com:5000/v3/auth/tokens' which both should have worked to trigger the logic for Keystone v3 and should show different errors on failure. Can you  do the same call with `bosh int` instead of `bosh create-env` and look at the generated manifest? The property `openstack.auth_url` should contain your /v3 URL.

 

Warm regards

Marco

 

[1] https://github.com/cloudfoundry-incubator/bosh-openstack-cpi-release/blob/b1e0620a1658b40d8d224dbda371729409722de9/src/bosh_openstack_cpi/lib/cloud/openstack/cloud.rb#L556-L558

 

From: <cf-bosh@...> on behalf of "rjwswenson@..." <rjwswenson@...>
Reply-To: "cf-bosh@..." <cf-bosh@...>
Date: Saturday, 13. January 2018 at 19:46
To: "cf-bosh@..." <cf-bosh@...>
Subject: [cf-bosh] Bosh create_env CLI error returning { openstack =u003e { tenant =u003e Missing key } }

 

Hello,
I am getting an error of a missing tenant key when I try to execute the bosh create_env command:

./bosh create-env bosh-deployment/bosh.yml --state=state.json   --vars-store=creds.yml  -o bosh-deployment/openstack/cpi.yml  -v director_name=bosh-1    \
-v internal_cidr=172.16.0.0/12    \
-v internal_gw=172.16.0.1     \
-v internal_ip=172.16.0.12    \
-v auth_url=https://somenode-us-west-3.mynode.com:5000      \
-v az=us-west-3a      \
-v default_key_name=microbosh     \
-v default_security_groups=[bosh]   \
-v net_id=vnet    \
-v tenant=genomicsdev     \
-v private_key=microbosh.pem     \
-v region=us-west-3a     \
-v openstack_domain=vts000004    \
-v openstack_project=rjwsgenomics    \
-v openstack_password=somepassword    \
-v openstack_username=someusername   \

I have seen this topic posted before, but the thread was inconclusive in terms of what resolved the issue.   I have tried passing a -v tenant=rjwsgenomics,  a -v openstack_tenant=genomics.   I have tried specifying this with /v2.0/tokens and /v3/auth/tokens and /v3 in the URI of the auth URL.  I have also tried modifying the CPI and modifying the keystone-v2.yml in the openstack subdir.  None of these have helped me get passed the error shown below:

[CLI] 2018/01/13 18:31:32 ERROR - creating stemcell (bosh-openstack-kvm-ubuntu-trusty-go_agent 3468.13): CPI 'create_stemcell' method responded with error: CmdError{"type":"InvalidCall","message":"Arguments are not correct, details: 'Invalid OpenStack cloud properties: #\u003cMembrane::SchemaValidationError: { openstack =\u003e { tenant =\u003e Missing key } }\u003e'","ok_to_retry":false}


creating stemcell (bosh-openstack-kvm-ubuntu-trusty-go_agent 3468.13):
  CPI 'create_stemcell' method responded with error: CmdError{"type":"InvalidCall","message":"Arguments are not correct, details: 'Invalid OpenStack cloud properties: #\u003cMembrane::SchemaValidationError: { openstack =\u003e { tenant =\u003e Missing key } }\u003e'","ok_to_retry":false}

Exit code 1




Best Regards,
RJWS

Bosh create_env CLI error returning { openstack =\u003e { tenant =\u003e Missing key } }

rjwswenson@...
 

Hello,
I am getting an error of a missing tenant key when I try to execute the bosh create_env command:

./bosh create-env bosh-deployment/bosh.yml --state=state.json   --vars-store=creds.yml  -o bosh-deployment/openstack/cpi.yml  -v director_name=bosh-1    \
-v internal_cidr=172.16.0.0/12    \
-v internal_gw=172.16.0.1     \
-v internal_ip=172.16.0.12    \
-v auth_url=https://somenode-us-west-3.mynode.com:5000      \
-v az=us-west-3a      \
-v default_key_name=microbosh     \
-v default_security_groups=[bosh]   \
-v net_id=vnet    \
-v tenant=genomicsdev     \
-v private_key=microbosh.pem     \
-v region=us-west-3a     \
-v openstack_domain=vts000004    \
-v openstack_project=rjwsgenomics    \
-v openstack_password=somepassword    \
-v openstack_username=someusername   \

I have seen this topic posted before, but the thread was inconclusive in terms of what resolved the issue.   I have tried passing a -v tenant=rjwsgenomics,  a -v openstack_tenant=genomics.   I have tried specifying this with /v2.0/tokens and /v3/auth/tokens and /v3 in the URI of the auth URL.  I have also tried modifying the CPI and modifying the keystone-v2.yml in the openstack subdir.  None of these have helped me get passed the error shown below:

[CLI] 2018/01/13 18:31:32 ERROR - creating stemcell (bosh-openstack-kvm-ubuntu-trusty-go_agent 3468.13): CPI 'create_stemcell' method responded with error: CmdError{"type":"InvalidCall","message":"Arguments are not correct, details: 'Invalid OpenStack cloud properties: #\u003cMembrane::SchemaValidationError: { openstack =\u003e { tenant =\u003e Missing key } }\u003e'","ok_to_retry":false}


creating stemcell (bosh-openstack-kvm-ubuntu-trusty-go_agent 3468.13):
  CPI 'create_stemcell' method responded with error: CmdError{"type":"InvalidCall","message":"Arguments are not correct, details: 'Invalid OpenStack cloud properties: #\u003cMembrane::SchemaValidationError: { openstack =\u003e { tenant =\u003e Missing key } }\u003e'","ok_to_retry":false}

Exit code 1




Best Regards,
RJWS

Re: Stemcell Ubuntu 16?

Dmitriy Kalinin
 

we are actively working on xenial stemcells. hoping that we ll be cutting beta stemcell versions soon. getting them into pcf as a default is an additional matter of time.

dm me (@dkalinin) on cloudfoundry slack. we can chat more if you need more pcf details.

Sent from my iPhone

On Dec 18, 2017, at 2:16 AM, petergpls <petergpls@...> wrote:

Thanks for getting back to me.

The issue is that we are using a third party product from IBM that does not support UBUNTU TRUSTY as it is a very old version hence I am not sure what to do at this point since we need to use the IBM product and we want to use PCF

I do no have a PCF account manager.

Regards
Peter
Solution Architect 

On Mon, 18 Dec 2017 at 6:21 pm, Michal Kuratczyk <mkuratczyk@...> wrote:
Hi,

While Ubuntu Trusty is a relatively old version, it is still supported and BOSH stemcells based on it are actively maintained and quickly patched for security issues (just take a look at the release notes: https://github.com/cloudfoundry/bosh-linux-stemcell-builder/releases). Vast majority of BOSH/CF deployments uses these stemcells. Official BOSH stemcells based on Xenial are under development.

While other stemcells are available from the community, stemcells are a core part of PCF and you can't use a different stemcell than the one currently supported by PCF (which is Trusty-based right now).

Please reach out to your Pivotal account team to discuss your concerns.

Best regards,

On Mon, Dec 18, 2017 at 1:08 AM, petergpls <petergpls@...> wrote:
Hi All,

I am a newcomer to this group and m a bit confused about the latest version of Ubuntu that is supported for the stemcell as the list provided at https://bosh.io/stemcells shows Ubuntu Trusty available only which is a very old version. I have also seen several google snippets talking about support for Ubuntu 16 which is a llatest version. I will be using ESXi with vSphere.

We are stronly considering cloud foundry (PCF) but need support for a fairly recent release of Ubuntu and Trusty is not what we can use. Can anyone clear this up for me please.

Regards




--
Michal Kuratczyk | Solution Architect | Pivotal Inc.
Mobile +48602421588 | mkuratczyk@...

--
Sent from Gmail Mobile

Re: Stemcell Ubuntu 16?

petergpls <petergpls@...>
 

Thanks for getting back to me.

The issue is that we are using a third party product from IBM that does not support UBUNTU TRUSTY as it is a very old version hence I am not sure what to do at this point since we need to use the IBM product and we want to use PCF

I do no have a PCF account manager.

Regards
Peter
Solution Architect 


On Mon, 18 Dec 2017 at 6:21 pm, Michal Kuratczyk <mkuratczyk@...> wrote:
Hi,

While Ubuntu Trusty is a relatively old version, it is still supported and BOSH stemcells based on it are actively maintained and quickly patched for security issues (just take a look at the release notes: https://github.com/cloudfoundry/bosh-linux-stemcell-builder/releases). Vast majority of BOSH/CF deployments uses these stemcells. Official BOSH stemcells based on Xenial are under development.

While other stemcells are available from the community, stemcells are a core part of PCF and you can't use a different stemcell than the one currently supported by PCF (which is Trusty-based right now).

Please reach out to your Pivotal account team to discuss your concerns.

Best regards,

On Mon, Dec 18, 2017 at 1:08 AM, petergpls <petergpls@...> wrote:
Hi All,

I am a newcomer to this group and m a bit confused about the latest version of Ubuntu that is supported for the stemcell as the list provided at https://bosh.io/stemcells shows Ubuntu Trusty available only which is a very old version. I have also seen several google snippets talking about support for Ubuntu 16 which is a llatest version. I will be using ESXi with vSphere.

We are stronly considering cloud foundry (PCF) but need support for a fairly recent release of Ubuntu and Trusty is not what we can use. Can anyone clear this up for me please.

Regards




--
Michal Kuratczyk | Solution Architect | Pivotal Inc.
Mobile +48602421588 | mkuratczyk@...

--
Sent from Gmail Mobile

Re: Stemcell Ubuntu 16?

Michal Kuratczyk
 

Hi,

While Ubuntu Trusty is a relatively old version, it is still supported and BOSH stemcells based on it are actively maintained and quickly patched for security issues (just take a look at the release notes: https://github.com/cloudfoundry/bosh-linux-stemcell-builder/releases). Vast majority of BOSH/CF deployments uses these stemcells. Official BOSH stemcells based on Xenial are under development.

While other stemcells are available from the community, stemcells are a core part of PCF and you can't use a different stemcell than the one currently supported by PCF (which is Trusty-based right now).

Please reach out to your Pivotal account team to discuss your concerns.

Best regards,

On Mon, Dec 18, 2017 at 1:08 AM, petergpls <petergpls@...> wrote:
Hi All,

I am a newcomer to this group and m a bit confused about the latest version of Ubuntu that is supported for the stemcell as the list provided at https://bosh.io/stemcells shows Ubuntu Trusty available only which is a very old version. I have also seen several google snippets talking about support for Ubuntu 16 which is a llatest version. I will be using ESXi with vSphere.

We are stronly considering cloud foundry (PCF) but need support for a fairly recent release of Ubuntu and Trusty is not what we can use. Can anyone clear this up for me please.

Regards




--
Michal Kuratczyk | Solution Architect | Pivotal Inc.
Mobile +48602421588 | mkuratczyk@...

Stemcell Ubuntu 16?

petergpls <petergpls@...>
 

Hi All,

I am a newcomer to this group and m a bit confused about the latest version of Ubuntu that is supported for the stemcell as the list provided at https://bosh.io/stemcells shows Ubuntu Trusty available only which is a very old version. I have also seen several google snippets talking about support for Ubuntu 16 which is a llatest version. I will be using ESXi with vSphere.

We are stronly considering cloud foundry (PCF) but need support for a fairly recent release of Ubuntu and Trusty is not what we can use. Can anyone clear this up for me please.

Regards

Re: Cloud Foundry and Kubernetes Integration Efforts

Mike Youngstrom
 

This is great!  I've been wondering about these very question since the Container Runtime was announced.  Thanks for posting this here.

Mike

On Fri, Dec 15, 2017 at 2:00 AM, Krannich, Bernd <bernd.krannich@...> wrote:

Hello all,

 

During the Cloud Foundry board meeting which happened right after the European Cloud Foundry summit in Basel there was a request to the Cloud Foundry Technical Advisory Board (TAB) to come up with ideas around a closer integration of Cloud Foundry and Kubernetes.

 

While there is the well-established Kubo effort to manage Kubernetes clusters using BOSH, a group of Cloud Foundry platinum member companies comprising of (in alphabetical order) IBM, SAP, and SUSE felt that we as a community could do more with respect to integrating Cloud Foundry and Kubernetes. In the last few weeks, colleagues from these three companies have started creating ideas and project proposals which are now in a shape so that we can share them with the broader Cloud Foundry community to solicit feedback:

 

  1. Cloud Foundry/Kubernetes Integration Scenarios
    • Goal: Integrate a Cloud Foundry deployment and one/many Kubernetes clusters, no matter how they were created
    • Lead: Bernd Krannich (SAP)
    • On this document Swisscom also provided their inputs
    • Also, while above document lists potential projects there is already a first project proposal around an Open Service Broker Catalog for which we are also seeking feedback
  2. Cloud Foundry Orchestrator Provider Interface
    • Goal: Provide an API inside Cloud Foundry to allow switching the scheduling layer for Cloud Foundry Applications to be K8S
    • Lead: Simon Moser (IBM)
  3. Containerizing Cloud Foundry
    • Goal: With topic #2 completed, deploy the remaining Cloud Foundry control plane components (UAA, Cloud Controller, …) as Pods on Kubernetes
    • Lead: Vlad Iovanov (SUSE)

 

People from the three companies can jointly say that it was great to see a collaborative effort resulting in what we think is a promising direction for Cloud Foundry overall.

 

We’d love to hear your thoughts so please make sure to leave comments and feedback in the respective documents or send us general feedback over cf-dev.

 

Thanks in advance,

Simon Moser (IBM), Bernd Krannich (SAP), Vlad Iovanov (SUSE) in the name of the colleagues from these three companies who put effort into the topic

 

 

 

Bernd Krannich

SAP Cloud Platform

SAP SE

Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany

 

bernd.krannich@...

 

Pflichtangaben/Mandatory Disclosure Statement: www.sap.com/impressum

 

Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank.

 

This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.


Cloud Foundry and Kubernetes Integration Efforts

Krannich, Bernd <bernd.krannich@...>
 

Hello all,

 

During the Cloud Foundry board meeting which happened right after the European Cloud Foundry summit in Basel there was a request to the Cloud Foundry Technical Advisory Board (TAB) to come up with ideas around a closer integration of Cloud Foundry and Kubernetes.

 

While there is the well-established Kubo effort to manage Kubernetes clusters using BOSH, a group of Cloud Foundry platinum member companies comprising of (in alphabetical order) IBM, SAP, and SUSE felt that we as a community could do more with respect to integrating Cloud Foundry and Kubernetes. In the last few weeks, colleagues from these three companies have started creating ideas and project proposals which are now in a shape so that we can share them with the broader Cloud Foundry community to solicit feedback:

 

  1. Cloud Foundry/Kubernetes Integration Scenarios
    • Goal: Integrate a Cloud Foundry deployment and one/many Kubernetes clusters, no matter how they were created
    • Lead: Bernd Krannich (SAP)
    • On this document Swisscom also provided their inputs
    • Also, while above document lists potential projects there is already a first project proposal around an Open Service Broker Catalog for which we are also seeking feedback
  2. Cloud Foundry Orchestrator Provider Interface
    • Goal: Provide an API inside Cloud Foundry to allow switching the scheduling layer for Cloud Foundry Applications to be K8S
    • Lead: Simon Moser (IBM)
  3. Containerizing Cloud Foundry
    • Goal: With topic #2 completed, deploy the remaining Cloud Foundry control plane components (UAA, Cloud Controller, …) as Pods on Kubernetes
    • Lead: Vlad Iovanov (SUSE)

 

People from the three companies can jointly say that it was great to see a collaborative effort resulting in what we think is a promising direction for Cloud Foundry overall.

 

We’d love to hear your thoughts so please make sure to leave comments and feedback in the respective documents or send us general feedback over cf-dev.

 

Thanks in advance,

Simon Moser (IBM), Bernd Krannich (SAP), Vlad Iovanov (SUSE) in the name of the colleagues from these three companies who put effort into the topic

 

 

 

Bernd Krannich

SAP Cloud Platform

SAP SE

Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany

 

bernd.krannich@...

 

Pflichtangaben/Mandatory Disclosure Statement: www.sap.com/impressum

 

Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank.

 

This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.

Re: Change filesystem type in V2 manifest schema

Marco Voelz
 

Hi,

 

a change in filesystem format requires formatting the disk. Currently, the only way to trigger creating a new persistent disk and copying over the data is when changing the disk's size. Hope that helps.

 

Warm regards

Marco

From: <cf-bosh@...> on behalf of Ponraj E <ponraj.e@...>
Reply-To: "cf-bosh@..." <cf-bosh@...>
Date: Thursday, 7. December 2017 at 15:53
To: "cf-bosh@..." <cf-bosh@...>
Subject: [cf-bosh] Change filesystem type in V2 manifest schema

 

Hi,

 

Here in the bosh docs https://bosh.io/docs/persistent-disk-fs.html, it is mentioned that if we want to change the filesystem type, we have to change the persistent disk size.

Why is the disk size change mandatory for the filesystem change?

 

We have a use case where we want to migrate the deployment from ext4 filesystem to xfs filesystem. But as per the docs, this happens only when the disk size is also changed.

Appreciate the help.

Re: [project-leads] Proposal to change GH org permission structure for committers

Amit Kumar Gupta
 

Hi all,

1) People that aren't on the project teams have a hard time finding where work of that project team is actually happening.

Do you have any data on how significant a problem this is?  I assume 99% of a team's work happens in cf or cf-inc orgs, and forks are temporary in service of PR'ing to a repo in cf or cf-inc.  For teams I've worked on in the past, someone has forked into their personal account and given the rest of the team members collab access to that repo, then tore it down after the PR is merged.  Forking into a team account e.g. cf-routing also seems like it makes sense to solve this problem.  But the main point IMO is that almost all the team's work happens in a discoverable place (cf or cf-inc), and the work that happens on these forks is ephemeral and not meant to receive further upstream PRs, they exist to PR into something else downstream.

2) The team specific orgs are not typically setup to ensure CLA's for any inbound pull requests.

See prev comment about how these team-specific orgs are generally not used for long-lived work that should be receiving PRs.

3) Use of the cloudfoundry-incubator for these forks is confusing to observers, and completely different from what the incubator is supposed to be.

Agree that cf-inc shouldn't be used to house forks.  It's confusing, not the point of cf-inc, and doesn't scale (what happens when two teams want to fork nats into cf-inc?).

If there were a simple working agreement to do core work in cf or cf-inc, and use personal/team accounts/orgs for temporary forks for the purpose of PRs, would this solve the problems?

I would definitely be hesitant about wide-open push access across teams, I'd recommend allowing teams and people to organically choose the best cross-team collaboration workflow (cross-team pairing, PRs, direct commit) on a case-by-case basis.

Cheers,
Amit

On Wed, Dec 6, 2017 at 4:50 PM, Chip Childers <cchilders@...> wrote:
All (especially committers and project leads),

Some of the CFF project teams have been working in team specific GH orgs as a way to fork other project team repos that aren't core to their own efforts. Others have been using the cloudfoundry-incubator org for this same purpose. Largely, this seems to be happening inside of the Runtime PMC projects, but may be happening in other projects. Neither is optimal, for several reasons:

1) People that aren't on the project teams have a hard time finding where work of that project team is actually happening.
2) The team specific orgs are not typically setup to ensure CLA's for any inbound pull requests.
3) Use of the cloudfoundry-incubator for these forks is confusing to observers, and completely different from what the incubator is supposed to be.

Today, permissions are established for specific teams to access specific repos. In most cases they are limited to the repos owned by their project. In some cases, teams are already sharing commit rights to repos from other projects. The theory of locked down permissions is tied to the assumption of code ownership by one specific team.

I propose we change both the technical aspects of how permissions are handled, and the social / community aspect of how committers work with other project teams.

Specifically, I propose that we change our permission model to a much simpler one:

1) A single team for all committers in each PMC. That team would be given write permission across all repos that are part of projects in that PMC in both the cloudfoundry-incubator and cloudfoundry GH organizations.
2) All repos would also have a default branch selected and set as "protected" (disabling deletion and things like forced push).

This would both simplify some of the administrative work (much of which is handled by the awesome admin team at Pivotal today), and allow us to change our community's approach to cross project collaboration. Specifically, teams that want to make changes to another project's repo would create a branch in that repo to do their work in (and from which to do a PR). Project teams would still "own" their repos (and default branches), but this would be convention not enforced via permissions.

I welcome your thoughts and feedback on the proposal!

-chip
--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815

--
You received this message because you are subscribed to the Google Groups "project-leads" group.
To unsubscribe from this group and stop receiving emails from it, send an email to project-leads+unsubscribe@cloudfoundry.org.
To post to this group, send email to project-leads@....
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/project-leads/CAD1Pwce90BMAZO1%3DdRES3gzAxvvT1onpw4uf%2BVQR-VqHRFpYAA%40mail.gmail.com.

Change filesystem type in V2 manifest schema

Ponraj E <ponraj.e@...>
 

Hi,
 
Here in the bosh docs https://bosh.io/docs/persistent-disk-fs.html, it is mentioned that if we want to change the filesystem type, we have to change the persistent disk size.
Why is the disk size change mandatory for the filesystem change?
 
We have a use case where we want to migrate the deployment from ext4 filesystem to xfs filesystem. But as per the docs, this happens only when the disk size is also changed.

Appreciate the help.

Proposal to change GH org permission structure for committers

Chip Childers
 

All (especially committers and project leads),

Some of the CFF project teams have been working in team specific GH orgs as a way to fork other project team repos that aren't core to their own efforts. Others have been using the cloudfoundry-incubator org for this same purpose. Largely, this seems to be happening inside of the Runtime PMC projects, but may be happening in other projects. Neither is optimal, for several reasons:

1) People that aren't on the project teams have a hard time finding where work of that project team is actually happening.
2) The team specific orgs are not typically setup to ensure CLA's for any inbound pull requests.
3) Use of the cloudfoundry-incubator for these forks is confusing to observers, and completely different from what the incubator is supposed to be.

Today, permissions are established for specific teams to access specific repos. In most cases they are limited to the repos owned by their project. In some cases, teams are already sharing commit rights to repos from other projects. The theory of locked down permissions is tied to the assumption of code ownership by one specific team.

I propose we change both the technical aspects of how permissions are handled, and the social / community aspect of how committers work with other project teams.

Specifically, I propose that we change our permission model to a much simpler one:

1) A single team for all committers in each PMC. That team would be given write permission across all repos that are part of projects in that PMC in both the cloudfoundry-incubator and cloudfoundry GH organizations.
2) All repos would also have a default branch selected and set as "protected" (disabling deletion and things like forced push).

This would both simplify some of the administrative work (much of which is handled by the awesome admin team at Pivotal today), and allow us to change our community's approach to cross project collaboration. Specifically, teams that want to make changes to another project's repo would create a branch in that repo to do their work in (and from which to do a PR). Project teams would still "own" their repos (and default branches), but this would be convention not enforced via permissions.

I welcome your thoughts and feedback on the proposal!

-chip
--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815

Re: Default user and password for bosh-lite vm

Arpit Sharma
 

Thanks Tyler...

Re: Server error, status code: 500, error code: 170011, message: Stager error: Failed to open TCP connection to stager.service.cf.internal:8888

Danny Berger
 

Hi Arpit - this message is fairly specific to the Cloud Foundry releases, so you might have better luck emailing the cf-dev@... where there's more experience deploying CF and seeing these particular error messages. A cursory suggestion to investigate might be that cells are not correctly running or reporting in. I think cf-dev will be able to help out more, or feel free to join the channels at http://slack.cloudfoundry.org.

Danny

On Mon, Nov 13, 2017 at 10:53 PM, Arpit Sharma <arpitvipulsharma@...> wrote:
Dear Team,
 
I have deployed CF as per official doc from cloudfoundry site on vsphere. When I am pushing an app, I am getting below mentioned error
 
Server error, status code: 500, error code: 170011, message: Stager error: Failed to open TCP connection to stager.service.cf.internal:8888
 
Can anyone help me with this? 




--
Danny Berger