Date   
Re: Can a Bosh deployment be aborted when drain script returns non-zero exit code?

Carol Morneau
 

You're exactly right.

From /var/vcap/bosh/log:

2017-10-19_20:09:16.76704 [Cmd Runner] 2017/10/19 20:09:16 DEBUG - Stderr:
2017-10-19_20:09:16.76704 [Cmd Runner] 2017/10/19 20:09:16 DEBUG - Successful: false (1)
2017-10-19_20:09:16.76705 [ParallelScript] 2017/10/19 20:09:16 ERROR - '/var/vcap/jobs/containers/bin/drain' script has failed with error: Script did not return a signed integer: strconv.ParseInt: parsing "": invalid syntax
2017-10-19_20:09:16.76705 [Drain Action] 2017/10/19 20:09:16 DEBUG - Got a result
2017-10-19_20:09:16.76706 [Task Service] 2017/10/19 20:09:16 ERROR - Failed processing task #01b91a43-4f6e-4b52-5c65-0d7fd18d0b4d got: 1 of 1 drain scripts failed. Failed Jobs: containers.

Would you recommend a better way to fail a deployment?

Re: Can I clear /var/vcap/micro_bosh/data/cache?

Steffen Uhlig
 

Thanks, Adrian. I did that before, but I am not sure if I recently ran that.

Is that command supposed to clean up all unused cache entries?

Thanks.

Steffen.

Default user and password for bosh-lite vm

Arpit Sharma
 

Hi Team,

I have deployed bosh lite with followed link https://bosh.io/docs/bosh-lite.html
Can any one update me how i can login in this vm? What will be default user and password for the vm which is deployed in virtualbox?

Regards:
Arpit Sharma

Re: Default user and password for bosh-lite vm

Tyler Schultz
 

The Tips section of the page you linked to has instructions on how to ssh
into the director vm.

--Tyler

On Wed, Nov 1, 2017 at 9:24 AM, Arpit Sharma <arpitvipulsharma(a)gmail.com>
wrote:

Hi Team,

I have deployed bosh lite with followed link https://bosh.io/docs/bosh-
lite.html
Can any one update me how i can login in this vm? What will be default
user and password for the vm which is deployed in virtualbox?

Regards:
Arpit Sharma

Bosh compatible vSphere version

nitin padalia
 

Hi,
Is there any compatibility list of BOSH with vSphere version. Say I am upgrading my vSphere environment then how can I safely say that it won't impact my CF deployment or other deployments managed by BOSH.

CF mailing lists migration Tuesday at 9am PST

Chris Clark
 

Hello all,

CF-bosh, and all other Cloud Foundry Foundation mailing lists, will be
migrating from Mailman to Groups.io on Nov 7th, Tuesday morning, at 9am
PST. Migration should take an hour or two, and during this time there will
be a delay in any new posts. The archives will be still be available.

Groups.io should provide significant improvements in functionality and UI
over Mailman. For those of you interacting with this list solely through
email, you likely won't even notice the change. If you use the interface
at lists.cloudfoundry.org, you will soon see a nice new GUI to use... the
domain, and associated URLs, will remain the same. If you'd like to learn
more about Groups.io, please reference their documentation
<https://groups.io/static/help>.

I'll let you know Tuesday once migration is complete. Please reach out if
you have any questions, concerns, exultations.

Chris Clark

Access of cf from bosh lite

Arpit Sharma
 

Dear Team,

I have deployed cf on bosh lite. But cf is only able to accessable from that server because its based on boshlite. we installed bosh lite from the link https://bosh.io/docs/bosh-lite.html and cloud foundry from official http://docs.cloudfoundry.org/deploying/boshlite/index.html.Is there any way I can get access of this cf to on our lan?

Re: CF mailing lists migration Tuesday at 9am PST

Chris Clark
 

Migration is now complete and things seem fully functional (including search function).  Please let me know if you have any issues or concerns.  You can take a look at the new interface here, or just continue to use email.  

Links to the old lists have been redirected and should be working fine.  
However, if there are links out there (in documentation, stack overflow, wherever) pointing to specific posts on the lists, those links have broken.  Hopefully the search function will allow people to easily find old posts, so this shouldn't be a big inconvenience.  If it is, please let me know. 

- Chris Clark

On Fri, Nov 3, 2017 at 10:03 AM, Chris Clark <cclark@...> wrote:
Hello all, 

CF-bosh, and all other Cloud Foundry Foundation mailing lists, will be migrating from Mailman to Groups.io on Nov 7th, Tuesday morning, at 9am PST.  Migration should take an hour or two, and during this time there will be a delay in any new posts.  The archives will be still be available. 

Groups.io should provide significant improvements in functionality and UI over Mailman.  For those of you interacting with this list solely through email, you likely won't even notice the change.  If you use the interface at lists.cloudfoundry.org, you will soon see a nice new GUI to use... the domain, and associated URLs, will remain the same.  If you'd like to learn more about Groups.io, please reference their documentation.  

I'll let you know Tuesday once migration is complete.  Please reach out if you have any questions, concerns, exultations.  

Chris Clark

Nominations Open: CF Summit NA CFP Co-Chair

Swarna Podila
 

Hello!
For those of you that I haven't interacted with yet, I am Swarna Podila, and have been dubbed the Community Manager for CF community.  I will make sure we will have plenty of opportunities to meet virtually and face-to-face.

As you can imagine, we (at the Foundation) have begun planning for CF Summit, Boston in April 2018.  I would like to share with you that we are accepting nominations for CFP Co-Chairs to help curate content for Cloud Foundry Summit North America 2018.  Please nominate yourself or a fellow community member that would represent the greater Cloud Foundry community's interest and are leaders in the community.  And feel free to unicast or post your questions here. 

I am super psyched to be here and look forward to meeting y'all over the coming months.

Cheers,
Swarna.

1 of 3 pre-start scripts failed. Failed Jobs: cloud_controller_ng. Successful Jobs: route_registrar, consul_agent

Arpit Sharma
 

Dear Team,
We are deploying cloud foundry on vsphere using bosh. We are getting following error on deployment of cf. Can anyone help me with this? 

Task 56 | 16:37:14 | Updating instance api_z1: api_z1/da2b9778-64dd-444d-9b90-d22397ba83de (0) (canary) (00:00:33)

                   L Error: Action Failed get_task: Task 535ba5ee-07f6-4750-4ad2-f527d0e4126c result: 1 of 3 pre-start scripts failed. Failed Jobs: cloud_controller_ng. Successful Jobs: route_registrar, consul_agent.

Task 56 | 16:37:47 | Error: Action Failed get_task: Task 535ba5ee-07f6-4750-4ad2-f527d0e4126c result: 1 of 3 pre-start scripts failed. Failed Jobs: cloud_controller_ng. Successful Jobs: route_registrar, consul_agent.

 

Task 56 Started  Thu Nov  9 16:26:01 UTC 2017

Task 56 Finished Thu Nov  9 16:37:47 UTC 2017

Task 56 Duration 00:11:46

Task 56 error

 

Updating deployment:

  Expected task '56' to succeed but state is 'error'

 

Exit code 1 ​

 

Re: Default user and password for bosh-lite vm

Jain, Ashish
 

Tips section has details https://bosh.io/docs/bosh-lite.html

On 01/11/17, 10:02 PM, "Arpit Sharma" <arpitvipulsharma@...> wrote:

Hi Team,

I have deployed bosh lite with followed link https://bosh.io/docs/bosh-lite.html
Can any one update me how i can login in this vm? What will be default user and password for the vm which is deployed in virtualbox?

Regards:
Arpit Sharma

Is there a way to specify the filesystem format in BOSH v1 manifest schema

Ponraj E <ponraj.e@...>
 

Hi Colleagues,

Currently bosh uses ext4 filesystem format by default for the attached persistent disks. Is there a way to specify some other filesystem format (like XFS) in BOSH V1 manifest schema?
I am aware of this https://bosh.io/docs/persistent-disk-fs.html but looks like this is for V2 manifest schema.


Regards,
Ponraj

Re: Is there a way to specify the filesystem format in BOSH v1 manifest schema

Dr Nic Williams
 

One option is to use the multiple persistent disk feature of bosh - this creates disks and does not format them.

http://www.starkandwayne.com/blog/bosh-multiple-disks/


From: cf-bosh@... <cf-bosh@...> on behalf of Ponraj E <ponraj.e@...>
Sent: Friday, November 10, 2017 7:07:55 PM
To: cf-bosh@...
Subject: [cf-bosh] Is there a way to specify the filesystem format in BOSH v1 manifest schema
 
Hi Colleagues,

Currently bosh uses ext4 filesystem format by default for the attached persistent disks. Is there a way to specify some other filesystem format (like XFS) in BOSH V1 manifest schema?
I am aware of this https://bosh.io/docs/persistent-disk-fs.html but looks like this is for V2 manifest schema.


Regards,
Ponraj

Re: Is there a way to specify the filesystem format in BOSH v1 manifest schema

Dr Nic Williams
 

The version of the manifest isn’t the main issue - you will need to upgrade your bosh director. But it is highly encouraged for you to be regularly upgrading your bosh environments.

See bosh-deployment repo for a wonderful way to deploy your bosh environments.


From: Dr Nic Williams <drnicwilliams@...>
Sent: Friday, November 10, 2017 8:32:22 PM
To: cf-bosh@...; cf-bosh@...
Subject: Re: [cf-bosh] Is there a way to specify the filesystem format in BOSH v1 manifest schema
 
One option is to use the multiple persistent disk feature of bosh - this creates disks and does not format them.

http://www.starkandwayne.com/blog/bosh-multiple-disks/


From: cf-bosh@... <cf-bosh@...> on behalf of Ponraj E <ponraj.e@...>
Sent: Friday, November 10, 2017 7:07:55 PM
To: cf-bosh@...
Subject: [cf-bosh] Is there a way to specify the filesystem format in BOSH v1 manifest schema
 
Hi Colleagues,

Currently bosh uses ext4 filesystem format by default for the attached persistent disks. Is there a way to specify some other filesystem format (like XFS) in BOSH V1 manifest schema?
I am aware of this https://bosh.io/docs/persistent-disk-fs.html but looks like this is for V2 manifest schema.


Regards,
Ponraj

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

Arpit Sharma
 

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? 

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

Re: Default user and password for bosh-lite vm

Arpit Sharma
 

Thanks Tyler...

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

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.

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.