Date   

Emails not delivered to the mailing list - connection refused error

Jean-Sebastien Delfino
 

Hi,

The emails I'm trying to send to this list are getting returned with the
following delivery error:

===
From: Mail Delivery System <MAILER-DAEMON(a)smtp1.linuxfoundation.org>
Date: Tue, Aug 11, 2015 at 4:46 AM
Subject: Undelivered Mail Returned to Sender
To: jsdelfino(a)gmail.com

This is the mail system at host smtp1.linuxfoundation.org.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

The mail system

<cf-dev(a)lists.cloudfoundry.org>: connect to 172.17.197.36[172.17.197.36]:25:
Connection refused

Final-Recipient: rfc822; cf-dev(a)lists.cloudfoundry.org
Original-Recipient: rfc822;cf-dev(a)lists.cloudfoundry.org
Action: failed
Status: 4.4.1
Diagnostic-Code: X-Postfix; connect to 172.17.197.36[172.17.197.36]:25:
Connection refused

===

Anyone else is seeing this? Is the list not accepting emails anymore?
(sending this from the nabble forum)

Thanks

- Jean-Sebastien





--
View this message in context: http://cf-dev.70369.x6.nabble.com/Emails-not-delivered-to-the-mailing-list-connection-refused-error-tp1149.html
Sent from the CF Dev mailing list archive at Nabble.com.


Running Docker private images on CF

dharmi
 

We have CF v214 with Diego deployed on AWS.

I am able to successfully create apps from Docker public repo, as per the
apidocs <http://apidocs.cloudfoundry.org/214/apps/creating_an_app.html> ,
but, while creating apps from the Docker private repos, I see the below
error from 'cf logs' when starting the app.

[API/0] OUT Updated app with guid bcb8f363-xyz
({"route"=>"5af6948b-xyz"})
[API/0] OUT Updated app with guid bcb8f363-xyz ({"state"=>"STARTED"})
[STG/0] OUT Creating container
[STG/0] OUT Successfully created container
[STG/0] OUT Staging...
[STG/0] OUT Staging process started ...
[STG/0] ERR Staging process failed: Exit trace for group:
[STG/0] ERR builder exited with error: failed to fetch metadata from
[:dockerid/go-app] with tag [latest] and insecure registries [] due to HTTP
code: 404
[STG/0] OUT Exit status 2
[STG/0] ERR Staging Failed: Exited with status 2
[API/0] ERR Failed to stage application: staging failed


cf curl command for reference.

cf curl /v2/apps -X POST -H "Content-Type: application/json" -H
"Authorization: bearer *accessToken*" -d '
{"name": "myapp",
"space_guid": "71b22eba-xyz",
"docker_image": ":dockerid/go-app",
"diego": true,
"docker_credentials_json":
{"docker_login_server": "https://index.docker.io/v1/",
"docker_user": ":dockerid",
"docker_password": ":dockerpwd",
"docker_email": ":email"
}
}'

Looking at the apidocs, the 'Example value' for 'docker_credentials_json'
indicates a Hash value
(#<RspecApiDocumentation::Views::HtmlExample:0x0000000bb883e0>), but looking
inside the code, we found the below JSON format.

let(:docker_credentials) do
{
docker_login_server: login_server,
docker_user: user,
docker_password: password,
docker_email: email
}

Pls correct me if I am missing something.

Thanks,
Dharmi



--
View this message in context: http://cf-dev.70369.x6.nabble.com/Running-Docker-private-images-on-CF-tp1148.html
Sent from the CF Dev mailing list archive at Nabble.com.


Re: CAB call for August scheduled Wednesday 08/12/15

Amit Kumar Gupta
 

Hey Max,

Is there a calendar event you can invite me to?

Amit

On Tue, Aug 11, 2015 at 2:11 AM, Michael Maximilien <maxim(a)us.ibm.com>
wrote:

Hi, all,

Hope you are ready for the August CAB call. I am in Beijing but fear not,
I am ready to rock and roll.

As usual, please take some time to update the google docs (link below)
with any highlights (PMs) or any items you would like to bring up to the
community.

Find all important info here:

-------
CF community call
USA 888-426-6840; 215-861-6239 | Leader code: 66850163 | Participant
code: 1985291

All other countries can find dial-in numbers here: http://goo.gl/RnNfc1

*6 to mute/unmute

Agenda

https://docs.google.com/document/d/1SCOlAquyUmNM-AQnekCOXiwhLs6gveTxAcduvDcW_xI/edit
-------

Talk soon,

James, Chip, and Max
ibm cloud labs
silicon valley, ca


Re: How to build binaries for buildpacks?

Alexander Lomov <alexander.lomov@...>
 

I was able to solve the problem with ruby by adding --enable-load-relative to ./configure command.

Still it would be useful to know how do you build binaries for buildpacks.

Thank you,
Alex L.

On Aug 11, 2015, at 4:44 PM, Lomov Alexander <alexander.lomov(a)altoros.com<mailto:alexander.lomov(a)altoros.com>> wrote:

Hello, everyone.

I try to create custom ruby-buildpack to support Power8. This means I need to rebuild ruby binaries. I’ve wrote some scripts that build necessary binaries and upload them to S3 [1]. Here is a script that build ruby [2]. Still after I tried to run an app I’ve got this error [3], that said “`require': cannot load such file -- rubygems.rb (LoadError)”. I think that potential problem could be in the way I build ruby binary.

Could you please tell what do you use to build binaries for buildpacks?

[1] https://github.com/Altoros/ruby-buildpack/tree/power/power
[2] https://github.com/Altoros/ruby-buildpack/blob/power/power/scripts/ruby-2.1.5.sh
[3] https://gist.github.com/allomov-altoros/4cfbd463a8bde056680d

Thank you,
Alex L.


How to build binaries for buildpacks?

Alexander Lomov <alexander.lomov@...>
 

Hello, everyone.

I try to create custom ruby-buildpack to support Power8. This means I need to rebuild ruby binaries. I’ve wrote some scripts that build necessary binaries and upload them to S3 [1]. Here is a script that build ruby [2]. Still after I tried to run an app I’ve got this error [3], that said “`require': cannot load such file -- rubygems.rb (LoadError)”. I think that potential problem could be in the way I build ruby binary.

Could you please tell what do you use to build binaries for buildpacks?

[1] https://github.com/Altoros/ruby-buildpack/tree/power/power
[2] https://github.com/Altoros/ruby-buildpack/blob/power/power/scripts/ruby-2.1.5.sh
[3] https://gist.github.com/allomov-altoros/4cfbd463a8bde056680d

Thank you,
Alex L.


Re: Bizarre DEA + Spring Behaviour

Daniel Mikusa
 

On Tue, Aug 11, 2015 at 5:15 AM, Daniel Jones <
daniel.jones(a)engineerbetter.com> wrote:

Hi all,

I've witnessed behaviour caused by the combination of a DEA and a Spring
application that I can't explain. If you like a good mystery or you happen
to know a lot about Java proxies and DEA transient state, please read on!

A particular Spring app

Version of Spring? What parts of Spring are you pulling into the app?


was crashing only on specific DEAs in a Cloud Foundry.
Ever try bumping up the log level for Spring when you were getting the
problem? If so, did the problem still occur? Were you able to capture the
logs?



All DEAs were from the same CF release (PCF ERT 1.5.2)
All DEAs were up-to-date according to BOSH (ie no outstanding changes
waiting to be applied)
All DEAs were deployed with identical BOSH job config
All Warden containers were using the same root FS
lucid64 or cflinuxfs2? or didn't matter?


The droplet was the same across all DEAs
The droplet version was the same
The droplet tarballs all had the same MD5 checksum
What was the output of the Java build pack when the droplet was created?
or better yet, run `cf files <app> app/.java-buildpack.log` and include
the output.


Warden was providing the exact same env and start command to all containers
I saw the same behaviour repeat itself across 5 completely separate Cloud
Foundry installations

The crash was Spring not being able to autowire a bean, where it was
referenced by implementation rather than interface (yes, I know, but it was
not my code!).

Any chance you could include logs from the crash? Was there an exception /
stacktrace generated? Alternatively, have you been able to create a simple
test app that replicates the behavior?


There was some Javassist/CGLIB action going on, creating proxies for the
sake of transaction management.

Rebooting the troublesome DEAs did not fix the problem.

Doing a `bosh recreate` did reliably fix the problem.

Alternatively, changing the Spring code to wire by interface also reliably
fixed the problem.

I can't understand why different DEA instances, from the same BOSH
release, with the same config, on the same stemcell, running the same
version of Warden, with the same droplet, and the same root FS, and the
same env, and the same start command, yielded different behaviour. I'm even
further confused as to why a `bosh recreate` changed that behaviour. What
could possibly have changed? Something on ephemeral disk? But what else is
there on ephemeral disk that could have mattered and was likely to have
changed?

How much was on the disk? Was it getting full? How many other apps were
running on that DEA (before vs after)?


Do CGLIB/Javassist have some native dependencies that weren't in sync
between DEAs?

Anyone with a convincing explanation (that does not involve voodoo) will
receive one free beer and a high-five at the next CF Summit!
Wild guess, race condition in the code somewhere?

Dan


Re: Bizarre DEA + Spring Behaviour

Daniel Jones
 

Argh - apologies for the poor formatting. Using the web UI after getting "connection refused" bouncebacks. Am I doing something wrong?

This is the mail system at host smtp1.linuxfoundation.org.

[snip]
The mail system

<cf-dev(a)lists.cloudfoundry.org>: connect to 172.17.197.36[172.17.197.36]:25:
Connection refused


Bizarre DEA + Spring Behaviour

Daniel Jones
 

Hi all,

I've witnessed behaviour caused by the combination of a DEA and a Spring application that I can't explain. If you like a good mystery or you happen to know a lot about Java proxies and DEA transient state, please read on!

A particular Spring app was crashing only on specific DEAs in a Cloud Foundry.

All DEAs were from the same CF release (PCF ERT 1.5.2)
All DEAs were up-to-date according to BOSH (ie no outstanding changes waiting to be applied)
All DEAs were deployed with identical BOSH job config
All Warden containers were using the same root FS
The droplet was the same across all DEAs
The droplet version was the same
The droplet tarballs all had the same MD5 checksum
Warden was providing the exact same env and start command to all containers
I saw the same behaviour repeat itself across 5 completely separate Cloud Foundry installations

The crash was Spring not being able to autowire a bean, where it was referenced by implementation rather than interface (yes, I know, but it was not my code!). There was some Javassist/CGLIB action going on, creating proxies for the sake of transaction management.

Rebooting the troublesome DEAs did not fix the problem.

Doing a `bosh recreate` did reliably fix the problem.

Alternatively, changing the Spring code to wire by interface also reliably fixed the problem.

I can't understand why different DEA instances, from the same BOSH release, with the same config, on the same stemcell, running the same version of Warden, with the same droplet, and the same root FS, and the same env, and the same start command, yielded different behaviour. I'm even further confused as to why a `bosh recreate` changed that behaviour. What could possibly have changed? Something on ephemeral disk? But what else is there on ephemeral disk that could have mattered and was likely to have changed? Do CGLIB/Javassist have some native dependencies that weren't in sync between DEAs?

Anyone with a convincing explanation (that does not involve voodoo) will receive one free beer and a high-five at the next CF Summit!

Regards,

Daniel Jones
EngineerBetter.com


CAB call for August scheduled Wednesday 08/12/15

Michael Maximilien
 

Hi, all,

Hope you are ready for the August CAB call. I am in Beijing but fear not, I am ready to rock and roll.

As usual, please take some time to update the google docs (link below) with any highlights (PMs) or any items you would like to bring up to the community.

Find all important info here:

-------
CF community call
USA 888-426-6840; 215-861-6239 | Leader code: 66850163 | Participant code: 1985291

All other countries can find dial-in numbers here: http://goo.gl/RnNfc1

*6 to mute/unmute

Agenda
https://docs.google.com/document/d/1SCOlAquyUmNM-AQnekCOXiwhLs6gveTxAcduvDcW_xI/edit
-------

Talk soon,

James, Chip, and Max
ibm cloud labs
silicon valley, ca


Re: [CF-Abacus] Billing & Metering of app usage

Michael Maximilien
 

Hi, Hristo,

Have you tried the CF-Abacus release: https://github.com/cloudfoundry-incubator/cf-abacus

If not please do so and see if it matches your need. And after you do, let's have a discussion on what gaps exists with your use case.

Thanks,

dr.max
ibm cloud labs
silicon valley, ca


Re: Doubt using the REST method: "/v2/resource_match"

Juan Antonio Breña Moral <bren at juanantonio.info...>
 

Hi Amit,

yes, I do a PUT Multipart, uploading the application in a zip.

This week, I will do some stress test for this method.
https://github.com/jabrena/cf-nodejs-client/blob/master/lib/model/Apps.js#L289-L312


Running Docker private images on CF

dharmi
 

We have CF v214 with Diego deployed on AWS.

I am able to successfully create apps from Docker public repo, as per the apidocs, but, while creating apps from the Docker private repos, I see the below error from 'cf logs' when starting the app. 'appreciate any pointers.

[API/0] OUT Updated app with guid bcb8f363-xyz ({"route"=>"5af6948b-xyz"})
[API/0] OUT Updated app with guid bcb8f363-xyz ({"state"=>"STARTED"})
[STG/0] OUT Creating container
[STG/0] OUT Successfully created container
[STG/0] OUT Staging...
[STG/0] OUT Staging process started ...
[STG/0] ERR Staging process failed: Exit trace for group:
[STG/0] ERR builder exited with error: failed to fetch metadata from [adobecloud/go-app] with tag [latest] and insecure registries [] due to HTTP code: 404
[STG/0] OUT Exit status 2
[STG/0] ERR Staging Failed: Exited with status 2
[API/0] ERR Failed to stage application: staging failed


cf curl command for reference.

cf curl /v2/apps -X POST -H "Content-Type: application/json" -H "Authorization: bearer *accessToken*" -d '
{"name": "myapp",
"space_guid": "71b22eba-xyz",
"docker_image": "adobecloud/go-app",
"diego": true,
"docker_credentials_json":
{"docker_login_server": "https://index.docker.io/v1/",
"docker_user": ":dockerid",
"docker_password": ":dockerpwd",
"docker_email": ":email"
}
}'

Looking at the apidocs, the 'Example value' for 'docker_credentials_json' indicates a Hash value (#<RspecApiDocumentation::Views::HtmlExample:0x0000000bb883e0>), but looking inside the code, 'found the below JSON format.

let(:docker_credentials) do
{
docker_login_server: login_server,
docker_user: user,
docker_password: password,
docker_email: email
}

Pls correct me if I am missing something.

Thanks,
Dharmi


Re: cannot access director, trying 4 more times...

Qing Gong
 

How to find out where bosh-lite directory is? I tried "which bosh" and it shows:
/install/users/cfg/.rubies/ruby-2.1.3/bin/bosh

But that's not a directory.
Thanks.


Re: cannot access director, trying 4 more times...

Simon D Moser
 

i had a similar problem this week, related to a VPN client that was running on my machine (that was somehow blocking the traffic) Here"s the steps that I that solved it 
 
a) reboot the box
b) after that, first run a bin/add-route from the boshlite dir
c) then do a vagrant up to bring the vm up and do a bosh target lite 
d) only then start your VPN if you need one

Mit freundlichen Grüßen / Kind regards

Simon Moser

Cloud Computing Architect
Dept. C453, IBM Research & Development Boeblingen

-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland
Schoenaicher Str. 220
71032 Boeblingen
Phone: +49-7031-16-4304
Fax: +49-7031-16-4890
E-Mail: smoser@...
-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland Research & Development GmbH / Vorsitzender des
Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht
Stuttgart, HRB 243294
 
 

----- Original message -----
From: "Qing Gong" <qinggong@...>
To: cf-dev@...
Cc:
Subject: [cf-dev] cannot access director, trying 4 more times...
Date: Fri, Aug 7, 2015 6:15 PM
 
I am very new to CF. Trying to set up one using the directions here:
https://github.com/cloudfoundry/bosh-lite

After running the following commands:

$ vagrant init hashicorp/precise64 (I tried both 32 and 64)
$ vagrant up --provider=virtualbox

The console shows:
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'hashicorp/precise64' is up to date...
==> default: Setting the name of the VM: xxxxxx_default_1438889867528_29074
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 => 2222 (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Warning: Connection timeout. Retrying...
    default:
    default: Vagrant insecure key detected. Vagrant will automatically replace
    default: this with a newly generated keypair for better security.
    default:
    default: Inserting generated public key within guest...
    default: Removing insecure key from the guest if it's present...
    default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
    default: The guest additions on this VM do not match the installed version of
    default: VirtualBox! In most cases this is fine, but in rare cases it can
    default: prevent things such as shared folders from working properly. If you see
    default: shared folder errors, please make sure the guest additions within the
    default: virtual machine match the version of VirtualBox you have installed on
    default: your host and reload your VM.
    default:
    default: Guest Additions Version: 4.2.0
    default: VirtualBox Version: 5.0
==> default: Mounting shared folders...
    default: /vagrant => /local/install/users/xxxxxx

Then, I tried to set the target for the bosh director but it was unsuccessful. I am not sure what's wrong. Searched around online and still could not figure out why.

I followed what's said below:
Target the BOSH Director and login with admin/admin.
# if behind a proxy, exclude both the VM's private IP and xip.io by setting no_proxy (xip.io is introduced later)
$ export no_proxy=192.168.50.4,xip.io
 (or export no_proxy=192.168.50.4.xip.io)

$ bosh target 192.168.50.4 lite
I always got the message shown in the subject,

cannot access director, trying 4 more times...
cannot access director, trying 3 more times...
cannot access director, trying 2 more times...

I wonder if the IP was not right. I tried 192.168.50.4 and a few other IP.  I also tried to customize the IP in the Vagrantfile file.

How can I debug what's going wrong?  Really appreciate any help or guidance.

TIA!

Qing

 


Questions about removal of the heartbeat message type from dropsonde-protocol

Mike Youngstrom
 

I noticed that heartbeat messages are no longer a part of the
dropsonde-protocol.

Can I get a quick summary of the thinking behind this change?

Is there an assumption that we should be using the bosh health manager and
not the firehose for this type of thing?

I'm just like some background and help understanding the LAMB team's
monitoring mindset regarding the removal of this message.

Thanks,
Mike


Re: Strategies for limiting metric updates with a clustered nozzle

Mike Youngstrom
 

Thanks James,

A little more complicated with more moving parts than I was hoping for but
if I don't want to miss anything I probably don't have much of a choice.

I think for now I'm going to go with some kind of random approach. At
least for the dropsonde generated metrics since they are by far the most
frequent/expensive and I think grabbing a random smattering of them will be
good enough for my current uses.

Mike

On Sat, Aug 8, 2015 at 7:02 AM, James Bayer <jbayer(a)pivotal.io> wrote:

warning, thinking out loud here...

your nozzle will tap the firehose, and filter for the metrics you care
about

currently you're publishing theses events to your metrics backend as fast
as they come in across a horizontally scalable tier that doesn't coordinate
and that can be expensive if your backend charges by the transaction

to slow down the stream, you could consider having the work in two phases:
1) aggregation phase
2) publish phase

the aggregation phase could have each instance of the horizontally scale
out tier put the metric in a temporary data store such as redis or other
in-memory data grid with HA like apache geode [1].

the publish phase would have something like a cron / spring batch
capability to occasionally (as often as made sense for your costs) flush
the metrics from the temporary data store to the backend per-transaction
cost backend

[1] http://geode.incubator.apache.org/

On Fri, Aug 7, 2015 at 9:26 AM, Mike Youngstrom <youngm(a)gmail.com> wrote:

I suppose one relatively simple solution to this problem is I can have
each cluster member randomly decide if it should log each metric. :) If I
pick a number between 1 and 6 I suppose odds are I would log about every
6th message on average or something like that. :)

Another idea, I could have each member pick a random number between 1 and
10 and I would skip that many messages before publishing then pick a new
random number.

I think it is mostly the dropsonde messages that are killing me. A
technique like this probably wouldn't really work for metrics derived from
http events and such.

Anyone have any other ideas?

MIke

On Wed, Aug 5, 2015 at 12:06 PM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

I'm working on adding support for Firehose metrics to our monitoring
solution. The firehose is working great. However, it appears each
component seems to send updates every 10 seconds or so. This might be a
great interval for some use cases but for my monitoring provider it can get
expensive. Any ideas on how I might limit the frequency of metric updates
from the firehose?

The obvious initial solution is to just do that in my nozzle. However,
I plan to cluster my nozzle using a subscriptionId. My understanding is
that when using a subscriptionId events will get balanced between the
subscribers. That would mean one nozzle instance might know when it last
sent a particular metric, but, the other instances wouldn't, without making
the solution more complex than I'd like it to be.

Any thoughts on how I might approach this problem?

Mike

--
Thank you,

James Bayer


Re: Strategies for limiting metric updates with a clustered nozzle

James Bayer
 

warning, thinking out loud here...

your nozzle will tap the firehose, and filter for the metrics you care about

currently you're publishing theses events to your metrics backend as fast
as they come in across a horizontally scalable tier that doesn't coordinate
and that can be expensive if your backend charges by the transaction

to slow down the stream, you could consider having the work in two phases:
1) aggregation phase
2) publish phase

the aggregation phase could have each instance of the horizontally scale
out tier put the metric in a temporary data store such as redis or other
in-memory data grid with HA like apache geode [1].

the publish phase would have something like a cron / spring batch
capability to occasionally (as often as made sense for your costs) flush
the metrics from the temporary data store to the backend per-transaction
cost backend

[1] http://geode.incubator.apache.org/

On Fri, Aug 7, 2015 at 9:26 AM, Mike Youngstrom <youngm(a)gmail.com> wrote:

I suppose one relatively simple solution to this problem is I can have
each cluster member randomly decide if it should log each metric. :) If I
pick a number between 1 and 6 I suppose odds are I would log about every
6th message on average or something like that. :)

Another idea, I could have each member pick a random number between 1 and
10 and I would skip that many messages before publishing then pick a new
random number.

I think it is mostly the dropsonde messages that are killing me. A
technique like this probably wouldn't really work for metrics derived from
http events and such.

Anyone have any other ideas?

MIke

On Wed, Aug 5, 2015 at 12:06 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:

I'm working on adding support for Firehose metrics to our monitoring
solution. The firehose is working great. However, it appears each
component seems to send updates every 10 seconds or so. This might be a
great interval for some use cases but for my monitoring provider it can get
expensive. Any ideas on how I might limit the frequency of metric updates
from the firehose?

The obvious initial solution is to just do that in my nozzle. However, I
plan to cluster my nozzle using a subscriptionId. My understanding is that
when using a subscriptionId events will get balanced between the
subscribers. That would mean one nozzle instance might know when it last
sent a particular metric, but, the other instances wouldn't, without making
the solution more complex than I'd like it to be.

Any thoughts on how I might approach this problem?

Mike
--
Thank you,

James Bayer


Re: cannot access director, trying 4 more times...

Ronak Banka
 

Run add-route script under bin folder of bosh-lite directory.

On Aug 8, 2015 16:35, "Amit Gupta" <agupta(a)pivotal.io> wrote:

You can check to see if the director is running. From the bosh-lite
directory, you can do `vagrant ssh` and then when you're in the VM, `sudo
su -`. From there, `monit summary` will give you a summary of the
processes monit is watching, and what state they're in. You should see the
director process running, along with a handful of other processes. Are you
able to verity up to that point?

On Fri, Aug 7, 2015 at 5:05 PM, Qing Gong <qinggong(a)gmail.com> wrote:

I am very new to CF. Trying to set up one using the directions here:
https://github.com/cloudfoundry/bosh-lite

After running the following commands:

$ vagrant init hashicorp/precise64 (I tried both 32 and 64)
$ vagrant up --provider=virtualbox

The console shows:
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'hashicorp/precise64' is up to date...
==> default: Setting the name of the VM:
xxxxxx_default_1438889867528_29074
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
default: Adapter 1: nat
==> default: Forwarding ports...
default: 22 => 2222 (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
default: SSH address: 127.0.0.1:2222
default: SSH username: vagrant
default: SSH auth method: private key
default: Warning: Connection timeout. Retrying...
default:
default: Vagrant insecure key detected. Vagrant will automatically
replace
default: this with a newly generated keypair for better security.
default:
default: Inserting generated public key within guest...
default: Removing insecure key from the guest if it's present...
default: Key inserted! Disconnecting and reconnecting using new SSH
key...
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
default: The guest additions on this VM do not match the installed
version of
default: VirtualBox! In most cases this is fine, but in rare cases it
can
default: prevent things such as shared folders from working properly.
If you see
default: shared folder errors, please make sure the guest additions
within the
default: virtual machine match the version of VirtualBox you have
installed on
default: your host and reload your VM.
default:
default: Guest Additions Version: 4.2.0
default: VirtualBox Version: 5.0
==> default: Mounting shared folders...
default: /vagrant => /local/install/users/xxxxxx

Then, I tried to set the target for the bosh director but it was
unsuccessful. I am not sure what's wrong. Searched around online and still
could not figure out why.

I followed what's said below:
Target the BOSH Director and login with admin/admin.
# if behind a proxy, exclude both the VM's private IP and xip.io by
setting no_proxy (xip.io is introduced later)
$ export no_proxy=192.168.50.4,xip.io
(or export no_proxy=192.168.50.4.xip.io)

$ bosh target 192.168.50.4 lite
I always got the message shown in the subject,

cannot access director, trying 4 more times...
cannot access director, trying 3 more times...
cannot access director, trying 2 more times...

I wonder if the IP was not right. I tried 192.168.50.4 and a few other
IP. I also tried to customize the IP in the Vagrantfile file.

How can I debug what's going wrong? Really appreciate any help or
guidance.

TIA!

Qing


Re: cannot access director, trying 4 more times...

Amit Kumar Gupta
 

You can check to see if the director is running. From the bosh-lite
directory, you can do `vagrant ssh` and then when you're in the VM, `sudo
su -`. From there, `monit summary` will give you a summary of the
processes monit is watching, and what state they're in. You should see the
director process running, along with a handful of other processes. Are you
able to verity up to that point?

On Fri, Aug 7, 2015 at 5:05 PM, Qing Gong <qinggong(a)gmail.com> wrote:

I am very new to CF. Trying to set up one using the directions here:
https://github.com/cloudfoundry/bosh-lite

After running the following commands:

$ vagrant init hashicorp/precise64 (I tried both 32 and 64)
$ vagrant up --provider=virtualbox

The console shows:
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'hashicorp/precise64' is up to date...
==> default: Setting the name of the VM: xxxxxx_default_1438889867528_29074
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
default: Adapter 1: nat
==> default: Forwarding ports...
default: 22 => 2222 (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
default: SSH address: 127.0.0.1:2222
default: SSH username: vagrant
default: SSH auth method: private key
default: Warning: Connection timeout. Retrying...
default:
default: Vagrant insecure key detected. Vagrant will automatically
replace
default: this with a newly generated keypair for better security.
default:
default: Inserting generated public key within guest...
default: Removing insecure key from the guest if it's present...
default: Key inserted! Disconnecting and reconnecting using new SSH
key...
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
default: The guest additions on this VM do not match the installed
version of
default: VirtualBox! In most cases this is fine, but in rare cases it
can
default: prevent things such as shared folders from working properly.
If you see
default: shared folder errors, please make sure the guest additions
within the
default: virtual machine match the version of VirtualBox you have
installed on
default: your host and reload your VM.
default:
default: Guest Additions Version: 4.2.0
default: VirtualBox Version: 5.0
==> default: Mounting shared folders...
default: /vagrant => /local/install/users/xxxxxx

Then, I tried to set the target for the bosh director but it was
unsuccessful. I am not sure what's wrong. Searched around online and still
could not figure out why.

I followed what's said below:
Target the BOSH Director and login with admin/admin.
# if behind a proxy, exclude both the VM's private IP and xip.io by
setting no_proxy (xip.io is introduced later)
$ export no_proxy=192.168.50.4,xip.io
(or export no_proxy=192.168.50.4.xip.io)

$ bosh target 192.168.50.4 lite
I always got the message shown in the subject,

cannot access director, trying 4 more times...
cannot access director, trying 3 more times...
cannot access director, trying 2 more times...

I wonder if the IP was not right. I tried 192.168.50.4 and a few other
IP. I also tried to customize the IP in the Vagrantfile file.

How can I debug what's going wrong? Really appreciate any help or
guidance.

TIA!

Qing


Re: Doubt using the REST method: "/v2/resource_match"

Amit Kumar Gupta
 

Juan Antonio,

When you say "Currently, I am executing the method, but I receive the
following message:", what "method" are you executing? The error message
suggests that the "resources" param you're providing in your request body
(whatever your request may be) is invalid. In a previous email, you
mentioned you were setting the value to JSON.stringify("[]") which I
pointed out as incorrect. Did you fix that?

In response to "But it is a bit rare, because in another reply, you said
that it is not necessary", the docs say that for the "uploading bits"
endpoint you need to provide the "resources" data. In the previous email,
someone mentioned that you don't need to call the "resource_match" endpoint
first. These two facts are not contradictory. If I understand correctly,
you should always be able to just set "resources" to an empty array, the
"resources" data is just an optimization to prevent it from uploading all
the files if some have already been uploaded. Since you're still just
trying to get it to work, I would not worry about this optimization for now.

You only need to call the resources_match endpoint to figure out the
correct value to enter in the resources parameter in the app-bits-upload
request *if* you want to take advantage of the optimization of not
uploading already-uploaded bits. You should not worry about this
optimization for now.

For the uploading bits endpoint, you also need to include a file to upload
along with your curl command. Uploading a file with curl is different from
setting the body of the request. If you're using curl or some JavaScript
library to try to make requests, please research how to upload files as I
know it can be a little bit finicky. I can't recall the exact syntax to do
it using curl, but I do remember it being a bit weird.

Amit

On Fri, Aug 7, 2015 at 3:54 AM, Juan Antonio Breña Moral <
bren(a)juanantonio.info> wrote:

Hi Chris, Arthur & Amit,

Today, I continued with the tests and checking and observing CLI.

CLI when it checks that the app doesn't exist, execute the method:
/v2/resource_match

Uploading StaticWebsiteHelloWorld...

REQUEST: [2015-08-07T11:47:15+02:00]
PUT /v2/resource_match HTTP/1.1
Host: api.MY_API.xip.io
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/json
User-Agent: go-cli 6.12.1-56792aa / windows


[{"fn":"StaticWebsite_HelloWorld.zip","sha1":"63329d8506a84fe7d94b8104d1ea073065bc5ff1","size":615},{"fn":"index.html","sha1":"6d94e23263b6e29c5ad1db4d11cca92889d8cd77","size":250},{"fn":"outputAdd.txt","sha1":"b702563871feed5f502ca8f85d30d3b58e8c9012","size":12474}]

RESPONSE: [2015-08-07T11:47:16+02:00]
HTTP/1.1 200 OK
Content-Length: 2
Content-Type: application/json;charset=utf-8
Date: Fri, 07 Aug 2015 09:45:45 GMT
Server: nginx
X-Cf-Requestid: 1a6a2edf-4662-4232-5c8a-e03908ab9ba4
X-Content-Type-Options: nosniff
X-Vcap-Request-Id:
4aae4900-5cb2-4ff7-5655-ddc289585577::c9de547e-e726-4f87-9c19-12979089ca16

[]

and returns an empty array.

When CLI update an application, it does the same thing:

Uploading StaticWebsiteHelloWorld...

REQUEST: [2015-08-07T11:47:49+02:00]
PUT /v2/resource_match HTTP/1.1
Host: api.MY_API.xip.io
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/json
User-Agent: go-cli 6.12.1-56792aa / windows


[{"fn":"StaticWebsite_HelloWorld.zip","sha1":"63329d8506a84fe7d94b8104d1ea073065bc5ff1","size":615},{"fn":"index.html","sha1":"6d94e23263b6e29c5ad1db4d11cca92889d8cd77","size":250},{"fn":"outputAdd.txt","sha1":"31d74639918621e74b4ba106d1e60db4bdae2353","size":39602},{"fn":"outputUpdate.txt","sha1":"93dfd14a8c2c46cef0cde0fb1b423153174a5cd2","size":18963}]

RESPONSE: [2015-08-07T11:47:49+02:00]
HTTP/1.1 200 OK
Content-Length: 2
Content-Type: application/json;charset=utf-8
Date: Fri, 07 Aug 2015 09:46:19 GMT
Server: nginx
X-Cf-Requestid: df233fed-f221-4123-70a5-5ef4be342fd6
X-Content-Type-Options: nosniff
X-Vcap-Request-Id:
784047bd-4b34-4658-6618-a82157ba4279::d5b05c14-02ac-4f65-bc0c-64a3e272b89f

[]

Currently, I am executing the method, but I receive the following message:

{ metadata:
{ guid: '1e7e956e-4784-42c7-a82c-b56fac823a5f',
created_at: '2015-08-07T10:12:02Z',
url: '/v2/jobs/1e7e956e-4784-42c7-a82c-b56fac823a5f' },
entity:
{ guid: '1e7e956e-4784-42c7-a82c-b56fac823a5f',
status: 'failed',
error: 'Use of entity>error is deprecated in favor of
entity>error_details.',
error_details:
{ code: 160001,
description: 'The app upload is invalid: invalid :resources',
error_code: 'CF-AppBitsUploadInvalid' } } }

Error: {
"code": 150001,
"description": "The app package is invalid: bits have not been uploaded",
"error_code": "CF-AppPackageInvalid"
}

Does exist a curl way to upload an application?
In the documentation, I don't see anything.

http://apidocs.cloudfoundry.org/214/apps/uploads_the_bits_for_an_app.html

Besides, If you observe, the docs show that it is necessary to add the
details:

Content-Disposition: form-data; name="resources"


[{"fn":"path/to/content.txt","size":123,"sha1":"b907173290db6a155949ab4dc9b2d019dea0c901"},{"fn":"path/to/code.jar","size":123,"sha1":"ff84f89760317996b9dd180ab996b079f418396f"}]

But it is a bit rare, because in another reply, you said that it is not
necessary, because the method only need the response about the method:

/v2/resource_match

Doubts:
What is the right input for the field resources if the method:
"/v2/resource_match" returns []
Does exist a curl command to upload an application?

Many thanks in advance

Juan Antonio

8241 - 8260 of 9426