Date   
GCP 3586.18 Stemcell Issues

Michael Xu <mxu@...>
 

Hello Cloud Foundry!

The BOSH team is currently investigating an issue when using  Google Cloud Platform 3586.18 light and full stemcells. BOSH deployments on GCP using either of these stemcells will fail, and result in a timeout with unresponsive agents. In the meantime, please use the 3586.16 version. 

Currently this `unresponsive agent` issue seems to only manifest when deploying to GCP and using this specific version, but if you are experiencing similar deployment failures in other cases, please let us know! Feel free to join us at the #bosh CF Slack channel, we are happy to help.

Thanks,
Michael Xu && BOSH team

post hook into bosh delete vm command

estein@...
 

Hi,

We are interested in deploying a zabbix agent via a bosh package.  We want the package to automatically add the VM once created to the Zabbix monitor, which can be done via post-start or post-deployment I believe.  However, I can't figure out how to do the opposite: namely in the case where a VM is deleted, we need it's entry in the Zabbix monitor to be deleted.  I know the APIs that allows the deletion and we have a Java application that can do it, but is there a way to hook into that delete mechanism?  Drain/post-stop is called regardless of whether the VM is stopped or deleted, so I don't think that will work.

Hoping someone knows.  Thanks.

Re: post hook into bosh delete vm command

adrian.kurt@...
 

Hi

 

First of all I suggest adding your Zabbix integration as a regular bosh-release instead of a package. You can use the runtime-config to add it to all deployed vms.

 

If I remember correctly there are two parameters passed to the drain script and based on those you should be able to find out if the vm is about to be deleted.

 

Kind regards

Adrian

 

From: cf-bosh@... [mailto:cf-bosh@...] On Behalf Of estein@...
Sent: Mittwoch, 20. Juni 2018 22:18
To: cf-bosh@...
Subject: [cf-bosh] post hook into bosh delete vm command

 

Hi,

We are interested in deploying a zabbix agent via a bosh package.  We want the package to automatically add the VM once created to the Zabbix monitor, which can be done via post-start or post-deployment I believe.  However, I can't figure out how to do the opposite: namely in the case where a VM is deleted, we need it's entry in the Zabbix monitor to be deleted.  I know the APIs that allows the deletion and we have a Java application that can do it, but is there a way to hook into that delete mechanism?  Drain/post-stop is called regardless of whether the VM is stopped or deleted, so I don't think that will work.

Hoping someone knows.  Thanks.

Re: post hook into bosh delete vm command

Benjamin Gandon
 

Hi,

I contributed recently the details about this « cluster scale-in » condition in the BOSH documentation:

And there are example here:
and here:

But for detecting BOSH-manged nodes showing up and going, maybe you should see how the prometheus team solves this problem. Especially, look how the node_exporter list all nodes that are managed by the BOSH server in order to feed the Prometheus system with the accurate list.

Best,
/Benjamin GANDON

Le 21 juin 2018 à 07:54, adrian.kurt@... a écrit :

Hi
 
First of all I suggest adding your Zabbix integration as a regular bosh-release instead of a package. You can use the runtime-config to add it to all deployed vms.
 
If I remember correctly there are two parameters passed to the drain script and based on those you should be able to find out if the vm is about to be deleted.
 
Kind regards
Adrian
 
From: cf-bosh@... [mailto:cf-bosh@...] On Behalf Of estein@...
Sent: Mittwoch, 20. Juni 2018 22:18
To: cf-bosh@...
Subject: [cf-bosh] post hook into bosh delete vm command
 
Hi,

We are interested in deploying a zabbix agent via a bosh package.  We want the package to automatically add the VM once created to the Zabbix monitor, which can be done via post-start or post-deployment I believe.  However, I can't figure out how to do the opposite: namely in the case where a VM is deleted, we need it's entry in the Zabbix monitor to be deleted.  I know the APIs that allows the deletion and we have a Java application that can do it, but is there a way to hook into that delete mechanism?  Drain/post-stop is called regardless of whether the VM is stopped or deleted, so I don't think that will work.

Hoping someone knows.  Thanks. 


Re: post hook into bosh delete vm command

estein@...
 

That actually does sound perfect.  I'll check it out.

Re: post hook into bosh delete vm command

estein@...
 

Sorry, yes, I meant as a bosh release.  I'm still getting used to the nomenclature. 

Re: post hook into bosh delete vm command

Marco Voelz
 

Hi,


Please note that all of the things Benjamin mentioned are mere workarounds rather than a desireable solution. We're looking for feedback for the proposal at https://github.com/cloudfoundry/bosh-notes/blob/master/proposals/drain-actions.md which would introduce a way for scripts to detect state changes in a drain script.


Warm regards

Marco



From: cf-bosh@... <cf-bosh@...> on behalf of estein@... <estein@...>
Sent: Thursday, June 21, 2018 5:20:56 PM
To: cf-bosh@...
Subject: Re: [cf-bosh] post hook into bosh delete vm command
 
Sorry, yes, I meant as a bosh release.  I'm still getting used to the nomenclature. 

Incubation proposal: CF Containerization

Cornelius Schumacher <cschum@...>
 

Hi all,

We would like to propose the CF Containerization effort for incubation in the
BOSH PMC.

The full proposal can be found here:
https://docs.google.com/document/d/1_IvFf-cCR4_Hxg-L7Z_R51EKhZfBqlprrs5NgC2iO2w/edit

As a first step towards this, we are proposing the Fissile code base as a
starting point, with the goal of transforming it in the direction of the above
proposal. Fissile is a tool that allows developers to convert existing BOSH
releases to docker images and deploy them to Kubernetes. Fissile is currently
used in SUSE CAP (https://www.suse.com/products/cloud-application-platform)
and IBM Cloud Foundry Enterprise Environment (https://console.bluemix.net/
docs/cloud-foundry/).

Fissile is fully open source and can currently be found on GitHub at
https://github.com/SUSE/fissile

The project would follow a distributed committer model.

Project Lead: Vlad Iovanov
Initial Committers:
- Jan Dubois (SUSE)
- Mark Yen (SUSE)
- Mario Manno (SUSE)
- Enrique Encalada (IBM)
- Matthias Diester (IBM)
- Gong (Grace) Zhang (IBM)

SAP is also currently evaluating additional staffing.

We are looking forward to your questions and comments.

Best Regards,
Cornelius

--
Cornelius Schumacher <cschum@...>

variable blob package name?

estein@...
 

All,

We have the scenario where a bosh package will be deployed to two different servers, and those servers require a different version of the package.  Everything else is the same save for the version of the package.  Is there a way to dynamically choose the package version required via a parameter in the manifest file?  Or do I simply have to copy the job and package and update the associated packing/spec file and/or create two separate releases (one for version 1 and another for version 2)?

For example:

server 1 requires mytar-1.2.2.tar.gz
server 2 requires mytar-2.2.2.tar.gz

Ideally there would be a single package file like:

tar -xvf mytar/mytar-${VERSION}.tar.gz

Is what I'm trying to do possible or again does it require simply having a duplicate of the jobs/packages and each one labeled accordingly in the release (or two separate releases)?

Forgot password

mounika.k@...
 

Hi, 
     We are unable to find API end points for the "forgot password" in UAA server. Can anyone suggest me? 

Thank you

Re: Forgot password

Ronak Banka
 

On Fri, 6 Jul 2018 at 7:07 PM, <mounika.k@...> wrote:
Hi, 
     We are unable to find API end points for the "forgot password" in UAA server. Can anyone suggest me? 

Thank you

Re: Forgot password

mounika.k@...
 

But I was asked about forgot password not change password. Thanks

Re: Forgot password

Ronak Banka
 

Mounika, Forgot password is a functionality which can be implemented in different ways. 

On backend it will use change password API call to make the changes.

Thanks

On Fri, 6 Jul 2018 at 9:56 PM, <mounika.k@...> wrote:
But I was asked about forgot password not change password. Thanks

Xenial stemcells now available: migration plan

Frédéric Desbiens
 

Hi everyone.


My name is Frédéric. I joined the BOSH team as a product manager recently, and work from Pivotal's Toronto office. Nice to meet you all!


A few weeks ago, the BOSH team introduced a new stemcell line based on Ubuntu 16.04 (Xenial Xerus) on bosh.io. For the time being, this line will be maintained in parallel with the previous ones, based on Ubuntu 14.04 (Trusty Tahr).


Canonical will provide security updates for Trusty until April 2019 per their official support lifecycle policy. Because Canonical will no longer provide security updates for Trusty after April 2019, we strongly recommend users start migrating towards the Xenial-based stemcell line now.


The BOSH team will continue to support the current 3586.x line of Trusty-based stemcells with upstream security patches until the CFAR migration to Xenial is complete. We do not plan on releasing any new major versions of Trusty-based stemcells, unless consumers have a specific request for a new major, and instead will focus on Xenial going forward.


We are currently evaluating when we will retire the Trusty-based stemcells, and are looking for feedback from the community about technical blockers that could impede the adoption of Xenial stemcells. If you are a release author, please take the time to verify your software on Xenial-based stemcells at the earliest opportunity. As a reminder, operators using cf-deployment must keep in mind that the repository will switch to Xenial-based stemcells well before April 2019 and should plan accordingly (more details on this can be found here).


    Frédéric Desbiens
    Product Manager | Pivotal Cloud Foundry BOSH

Re: Xenial stemcells now available: migration plan

Dr Nic Williams
 

Frédéric, when will Xenial stemcells move from X to X.Y version numbering with less regular updates of the major version X? This will help compiled releases to not have to update as often.

Nic

 


From: 30461002200n behalf of
Sent: Wednesday, July 11, 2018 7:02 am
To: cf-bosh@...; cf-dev@...
Subject: [cf-bosh] Xenial stemcells now available: migration plan
 

Hi everyone.


My name is Frédéric. I joined the BOSH team as a product manager recently, and work from Pivotal's Toronto office. Nice to meet you all!


A few weeks ago, the BOSH team introduced a new stemcell line based on Ubuntu 16.04 (Xenial Xerus) on bosh.io. For the time being, this line will be maintained in parallel with the previous ones, based on Ubuntu 14.04 (Trusty Tahr).


Canonical will provide security updates for Trusty until April 2019 per their official support lifecycle policy. Because Canonical will no longer provide security updates for Trusty after April 2019, we strongly recommend users start migrating towards the Xenial-based stemcell line now.


The BOSH team will continue to support the current 3586.x line of Trusty-based stemcells with upstream security patches until the CFAR migration to Xenial is complete. We do not plan on releasing any new major versions of Trusty-based stemcells, unless consumers have a specific request for a new major, and instead will focus on Xenial going forward.


We are currently evaluating when we will retire the Trusty-based stemcells, and are looking for feedback from the community about technical blockers that could impede the adoption of Xenial stemcells. If you are a release author, please take the time to verify your software on Xenial-based stemcells at the earliest opportunity. As a reminder, operators using cf-deployment must keep in mind that the repository will switch to Xenial-based stemcells well before April 2019 and should plan accordingly (more details on this can be found here).


    Frédéric Desbiens
    Product Manager | Pivotal Cloud Foundry BOSH

Re: Xenial stemcells now available: migration plan

Frédéric Desbiens
 

Hi Nic.

I expect this will happen in the near future. However, we still have some things to figure out and cannot commit to a date just yet. We will post an announcement to the list as soon as we will have come to a decision.

Best,

    Frédéric Desbiens
    Product Manager | Cloud Foundry BOSH
    email: fdesbiens@...



On Tue, Jul 10, 2018 at 2:42 PM Dr Nic Williams <drnicwilliams@...> wrote:
Frédéric, when will Xenial stemcells move from X to X.Y version numbering with less regular updates of the major version X? This will help compiled releases to not have to update as often.

Nic

 

From: 30461002200n behalf of
Sent: Wednesday, July 11, 2018 7:02 am
To: cf-bosh@...; cf-dev@...
Subject: [cf-bosh] Xenial stemcells now available: migration plan
 

Hi everyone.


My name is Frédéric. I joined the BOSH team as a product manager recently, and work from Pivotal's Toronto office. Nice to meet you all!


A few weeks ago, the BOSH team introduced a new stemcell line based on Ubuntu 16.04 (Xenial Xerus) on bosh.io. For the time being, this line will be maintained in parallel with the previous ones, based on Ubuntu 14.04 (Trusty Tahr).


Canonical will provide security updates for Trusty until April 2019 per their official support lifecycle policy. Because Canonical will no longer provide security updates for Trusty after April 2019, we strongly recommend users start migrating towards the Xenial-based stemcell line now.


The BOSH team will continue to support the current 3586.x line of Trusty-based stemcells with upstream security patches until the CFAR migration to Xenial is complete. We do not plan on releasing any new major versions of Trusty-based stemcells, unless consumers have a specific request for a new major, and instead will focus on Xenial going forward.


We are currently evaluating when we will retire the Trusty-based stemcells, and are looking for feedback from the community about technical blockers that could impede the adoption of Xenial stemcells. If you are a release author, please take the time to verify your software on Xenial-based stemcells at the earliest opportunity. As a reminder, operators using cf-deployment must keep in mind that the repository will switch to Xenial-based stemcells well before April 2019 and should plan accordingly (more details on this can be found here).


    Frédéric Desbiens
    Product Manager | Pivotal Cloud Foundry BOSH

Re: post hook into bosh delete vm command

Benjamin Gandon
 

Indeed, thank you for mentioning it Marco!

I was focused towards providing a working solution in my answer, not broadening the problem too much.

I definitely support this proposal. From the very start I found the {"persistent_disk":0} solution very workaround-ish indeed. For in-memory database, or anything stateless that needs draining, this currenty-state-of-the-art-workaround would not work.

In which form are you expecting feedback or support?

Best,
Benjamin GANDON



Le 28 juin 2018 à 14:34, Marco Voelz <marco.voelz@...> a écrit :

Hi,

Please note that all of the things Benjamin mentioned are mere workarounds rather than a desireable solution. We're looking for feedback for the proposal at https://github.com/cloudfoundry/bosh-notes/blob/master/proposals/drain-actions.md which would introduce a way for scripts to detect state changes in a drain script.

Warm regards
Marco


From: cf-bosh@... <cf-bosh@...> on behalf of estein@...<estein@...>
Sent: Thursday, June 21, 2018 5:20:56 PM
To: cf-bosh@...
Subject: Re: [cf-bosh] post hook into bosh delete vm command
 
Sorry, yes, I meant as a bosh release.  I'm still getting used to the nomenclature. 

Re: Incubation proposal: CF Containerization

Dmitriy Kalinin
 

Thank you for submitting this proposal. Let's shoot for collecting and resolving most of the comments in the next month by Aug 10th and voting at that time to incubate it in BOSH PMC.

On Tue, Jul 3, 2018 at 2:25 AM, Cornelius Schumacher <cschum@...> wrote:
Hi all,

We would like to propose the CF Containerization effort for incubation in the
BOSH PMC.

The full proposal can be found here:
https://docs.google.com/document/d/1_IvFf-cCR4_Hxg-L7Z_R51EKhZfBqlprrs5NgC2iO2w/edit

As a first step towards this, we are proposing the Fissile code base as a
starting point, with the goal of transforming it in the direction of the above
proposal. Fissile is a tool that allows developers to convert existing BOSH
releases to docker images and deploy them to Kubernetes. Fissile is currently
used in SUSE CAP (https://www.suse.com/products/cloud-application-platform)
and IBM Cloud Foundry Enterprise Environment (https://console.bluemix.net/
docs/cloud-foundry/
).

Fissile is fully open  source and can currently be found on GitHub at
https://github.com/SUSE/fissile

The project would follow a distributed committer model.

Project Lead: Vlad Iovanov
Initial Committers:
- Jan Dubois (SUSE)
- Mark Yen (SUSE)
- Mario Manno (SUSE)
- Enrique Encalada (IBM)
- Matthias Diester (IBM)
- Gong (Grace) Zhang (IBM)

SAP is also currently evaluating additional staffing.

We are looking forward to your questions and comments.

Best Regards,
Cornelius

--
Cornelius Schumacher <cschum@...>




BOSH PMC Lead - Call for Nominations

Chip Childers
 

All,

Dmitry Kalinin has decided to step down from his formal role in the CFF as the PMC Lead for the BOSH PMC. As such, nominations are now open for that roll.

Dmitry has nominated Marco Voelz (from SAP) to take on this roll (and Marco has acknowledged his interest).

If any CFF member participating in a BOSH PMC project wishes to nominate someone else, please do so by the end of the week by contacting me directly. Nominations will close by Monday July 23. After the nomination window, we will hold a vote of the BOSH PMC to select the new lead.

Thanks, and please let me know if you have any questions about this.

For reference, the PMC lead is defined in the CFF's Dev Governance Policy here > https://www.cloudfoundry.org/wp-content/uploads/2017/01/CFF_Development_Governance.pdf 

Relevant text here:
"The PMC Lead is responsible for coordinating the activities of their respective PMCs, assisting in prioritizing that PMC’s Projects’ Backlog, assisting in resolving disputes within that PMC, and meeting with their respective PMC members. [snip] (PMC Leads) shall be either (1) a Project Lead participating in one of the PMC’s Projects or (2) a participant from a Member that has at least one Dedicated Committer in that PMC’s Active Projects. PMC Leads should generally be the most qualified Project Lead in that PMC. [snip] the PMC Lead/s may be nominated by any PMC Member, and elected by the PMC members using Governance by Contribution within that PMC. "

-chip


--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815

Re: BOSH PMC Lead - Call for Nominations

Mike Youngstrom
 

Wow!  This is a big change!  Thanks Dimitry for all you've done over the years guiding and maturing Bosh.

Mike

On Mon, Jul 16, 2018 at 1:33 PM Chip Childers <cchilders@...> wrote:
All,

Dmitry Kalinin has decided to step down from his formal role in the CFF as the PMC Lead for the BOSH PMC. As such, nominations are now open for that roll.

Dmitry has nominated Marco Voelz (from SAP) to take on this roll (and Marco has acknowledged his interest).

If any CFF member participating in a BOSH PMC project wishes to nominate someone else, please do so by the end of the week by contacting me directly. Nominations will close by Monday July 23. After the nomination window, we will hold a vote of the BOSH PMC to select the new lead.

Thanks, and please let me know if you have any questions about this.

For reference, the PMC lead is defined in the CFF's Dev Governance Policy here > https://www.cloudfoundry.org/wp-content/uploads/2017/01/CFF_Development_Governance.pdf 

Relevant text here:
"The PMC Lead is responsible for coordinating the activities of their respective PMCs, assisting in prioritizing that PMC’s Projects’ Backlog, assisting in resolving disputes within that PMC, and meeting with their respective PMC members. [snip] (PMC Leads) shall be either (1) a Project Lead participating in one of the PMC’s Projects or (2) a participant from a Member that has at least one Dedicated Committer in that PMC’s Active Projects. PMC Leads should generally be the most qualified Project Lead in that PMC. [snip] the PMC Lead/s may be nominated by any PMC Member, and elected by the PMC members using Governance by Contribution within that PMC. "

-chip


--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815