Date   
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@...

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?

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

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: 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

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

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
 
 

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?

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?


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: 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 verify_multidigest on s390x

R M
 

Hi there - I am trying to create verify-multidigest-0.0.29-linux-amd64 on s390x but unable to to locate source code for verify-mutidigest.  I understand that x86 comes from S3 blob but I would like create a local one for s390x - bosh/packages/verify_multidigest/[packaging/spec] does not provide much hint.  Please let me know where can I find it.

Thanks.

Re: Building verify_multidigest on s390x

Tyler Schultz
 

On Tue, Feb 27, 2018 at 2:13 PM, R M <rishi.investigate@...> wrote:
Hi there - I am trying to create verify-multidigest-0.0.29-linux-amd64 on s390x but unable to to locate source code for verify-mutidigest.  I understand that x86 comes from S3 blob but I would like create a local one for s390x - bosh/packages/verify_multidigest/[packaging/spec] does not provide much hint.  Please let me know where can I find it.

Thanks.


Re: Creating vm with stemcell failed.... No valid host was found. There are not enough hosts available..Filter ImagePropertiesFilter returned 0 hosts

sunjingying@...
 

I met the same problem as you, my colleague told me it was instance_type inappropriate, but I changed it and still had that problem.

How to config use-haproxy when your deploy cloudfoundry using bosh

jun zhong
 

bosh -e bosh-1 -d cf deploy cf-deployment/cf-deployment.yml \
--vars-store cf-vars.yml \
-v system_domain=cloudfoundry.com \
-v haproxy_public_ip=xxx.xxx.xxx.xxx  \
-v haproxy_public_network_name= bosh \
-v haproxy_ssl.private_key=./bosh.pem \
-o cf-deployment/operations/openstack.yml \
-o cf-deployment/operations/use-haproxy.yml \
-o cf-deployment/operations/use-haproxy-public-network.yml \

I am a new guy to deploy the cf.
When I run the above command, I got error about  "cf-haproxy-network-properties" doesn't config.

1. Do you know how to config the cf-haproxy-network-properties in use-haproxy-public-network.yml. Is there an example?

2.  Do we have a simplest yml file to deploy the cf in openstack. I don't want to support loadbalancer or something else. I just want to deploy a simplest cloudfoundry in openstack and this cloudfoundry just need to push a simplest application.

Thanks!!!!


rabbitmq LDAP authentication issues

svue3@...
 

I am having an issue with getting my ldap config to work on rabbitmq cluster. We are authenticating against the internal server first then ldap. Heres a copy of our current config:

[

    {rabbit, [ {collect_statistics_interval, 60000}] },

    {rabbitmq_management, [ {rates_mode, basic}] },

    {rabbit,

        [ {auth_backends, [rabbit_auth_backend_internal, rabbit_auth_backend_ldap]},

          {auth_mechanisms, ['PLAIN','AMQPLAIN']}

        ]

    },

    {rabbitmq_auth_backend_ldap,

        [ {servers, ["ourcompany.com.us"]},

          {dn_lookup_attribute, "cn"},

          {dn_lookup_base, "DC=com,DC=us"},

          {use_ssl, false},

          {port, 636},

          {log, true},

 

          {tag_queries,

                [ {administrator, {in_group, "CN=team,OU=IT,OU=Engineering,OU=Global,DC=ourcompany,DC=com,DC=us"}},

                {administrator, {constant, true}}

                ]

          }

        ]

    }

].

I've checked the logs and saw error messages that LDAP plugin was not installed or is not part of the list in auth_backends but then I confirmed in same log file that it is there and ran rabbitmq-plugins to verify:

home dir       : /var/vcap/store/rabbitmq

config file(s) : /var/vcap/jobs/rabbitmq-server/bin/../etc/rabbitmq.config

log            : /var/vcap/sys/log/rabbitmq-server/rabbit@...

sasl log       : /var/vcap/sys/log/rabbitmq-server/rabbit@...



=WARNING REPORT==== 10-Apr-2018::14:36:54 ===

 

LDAP plugin loaded, but rabbit_auth_backend_ldap is not in the list of auth_backends. LDAP auth will not work.

=INFO REPORT==== 10-Apr-2018::14:36:54 ===

Server startup complete; 9 plugins started.

 * rabbitmq_shovel_management

 * rabbitmq_management

 * rabbitmq_management_agent

 * rabbitmq_web_dispatch

 * cowboy

 * rabbitmq_auth_backend_ldap

 * rabbitmq_shovel

 * cowlib

 

 * amqp_client

Any feedback or suggestions is appreciated!

-Steve

CF Summit EU contributor reg code

Chip Childers
 

Hey all,

Whew... we just got done with CF Summit NA in Boston, but it's time to turn towards Europe! For those that don'e know, we'll be headed back to Basel Switzerland again this year, October 10 to 12.

Contributors (those that have contributed docs, code, bug reports) are welcome to use the following code to register: CFEU18CONT

More info on the website here: https://www.cloudfoundry.org/event/eusummit2018/ 

See you all there!

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

Re: CF Summit EU contributor reg code

Chip Childers
 

Sorry... one correction. The event is Oct 10 and 11, with lots of pre-event activities on the 9th. Sorry about that. :)


On Mon, Apr 30, 2018 at 11:14 AM Chip Childers <cchilders@...> wrote:
Hey all,

Whew... we just got done with CF Summit NA in Boston, but it's time to turn towards Europe! For those that don'e know, we'll be headed back to Basel Switzerland again this year, October 10 to 12.

Contributors (those that have contributed docs, code, bug reports) are welcome to use the following code to register: CFEU18CONT

More info on the website here: https://www.cloudfoundry.org/event/eusummit2018/ 

See you all there!

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

Re: CF Summit EU contributor reg code

Swarna Podila
 

Which means…y’all should plan on joining the Day Zero activities - Cert Exams, User Day (if you’re at an end user organization), unconference, trainings, etc.

-- ​Swarna Podila
​Senior
 Director
​, Community​
 | Cloud Foundry Foundation

On Mon, Apr 30, 2018 at 5:31 PM, Chip Childers <cchilders@...> wrote:
Sorry... one correction. The event is Oct 10 and 11, with lots of pre-event activities on the 9th. Sorry about that. :)

On Mon, Apr 30, 2018 at 11:14 AM Chip Childers <cchilders@...> wrote:
Hey all,

Whew... we just got done with CF Summit NA in Boston, but it's time to turn towards Europe! For those that don'e know, we'll be headed back to Basel Switzerland again this year, October 10 to 12.

Contributors (those that have contributed docs, code, bug reports) are welcome to use the following code to register: CFEU18CONT

More info on the website here: https://www.cloudfoundry.org/event/eusummit2018/ 

See you all there!

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


Announcing BOSH Kube CPI

Michael Maximilien
 

fyi...

As the cool kids do it these days, see:


The gist are in these links:


PDF of presentation: https://bit.ly/bosh-kube-cpi

We'd love to hear your feedback.

Best,

Dmitriy and Max