Date   

Re: region qualifier for organizations

Bharath Sekar
 

Sounds good. Thanks Sebastien. I'll watch the thread [1] for updates

[1] https://github.com/cloudfoundry-incubator/cf-abacus/issues/110


Re: HM9000 gets stuck in bad state

Amit Kumar Gupta
 

This is not a known issue. Can you copy full log lines (including
timestamps, other metadata, error message, etc.) and paste them into a Gist
or Pastebin, and share the link?

Also, can you get a session on one of your etcd nodes (so that etcd is
reachable via localhost) and share the output of the following queries?

curl http://localhost:4001/v2/keys/hm/v4/actual-fresh
curl http://localhost:4001/v2/keys/hm/v4/desired-fresh

Note, you might need a different version than v4. You can figure out the
correct version by querying:

curl http://localhost:4001/v2/keys/hm

When I do so, I get the output:

{"action":"get","node":{"key":"/hm","dir":true,"nodes":[{"key":"/hm/locks","dir":true,"modifiedIndex":5,"createdIndex":5},{"key":"/hm/v4","dir":true,"modifiedIndex":15,"createdIndex":15}],"modifiedIndex":5,"createdIndex":5}}

Note the part that says "key":"/hm/v4", that's how you can determine
whether you need to query the v4 API or some other version.

On Wed, Oct 21, 2015 at 9:16 AM, kyle havlovitz <kylehav(a)gmail.com> wrote:

I'm having an issue where after a day or two or running, the health
manager is getting stuck in a bad state and doesn't display the state of
apps correctly. The logs show messages like this: "Store is not fresh -
Error:Actual and desired state are not fresh" and "Daemon returned an
error. Continuining... - Error:Actual and desired state are not fresh".

Restarting the process fixes the issue, but I'm wondering how to avoid
this problem altogether. Is this a known issue?


Re: region qualifier for organizations

Jean-Sebastien Delfino
 

So, since we're not sure about that region field, I'll wait for the
discussion to settle before making any additions to the API.

In the meantime, Bharath, the convention you've described (or another one
like us:86d0482c-7208-4f2f-8606-935c080cad41) should just work.

HTH

- Jean-Sebastien

On Wed, Oct 21, 2015 at 12:41 PM, Jean-Sebastien Delfino <
jsdelfino(a)gmail.com> wrote:

I could argue that region is actually a pretty generic term, as it's used
in a wide range of domains from geography (parts of the world or parts of a
country) to networking and datacenters (a region as a group of IP
addresses) and even memory management in garbage collectors for example :)
... but I was also wondering about a potential confusion where our users
could just assume that region always has to be a part of the world.

So we could either make clear that region is used in its generic sense and
not necessarily a geographical region in an Abacus doc on that topic, or
attempt to find another term like cluster for example, or zone or something
else... I've created Github issue #110 [1] to help folks submit their ideas
on this.

[1] https://github.com/cloudfoundry-incubator/cf-abacus/issues/110

- Jean-Sebastien

On Wed, Oct 21, 2015 at 10:32 AM, Dieu Cao <dcao(a)pivotal.io> wrote:

I'm curious if region is perhaps too specific?
Perhaps some other generic word would be better so that it's not
prescriptive.

-Dieu

On Wed, Oct 21, 2015 at 10:10 AM, Jean-Sebastien Delfino <
jsdelfino(a)gmail.com> wrote:

Hi all,

If there's no objection and nobody comes up with a better idea, I'll
start to work on adding a GET /v1/regions/us/orgs/ path as discussed
here sometime today.

- Jean-Sebastien

On Tue, Oct 20, 2015 at 10:11 PM, Jean-Sebastien Delfino <
jsdelfino(a)gmail.com> wrote:

Hi Bharath,

Sorry for the delay, I didn't realize this was a question for the
Abacus project as it didn't have the [abacus] subject tag we've been using
for Abacus discussions recently. I guess from now on I'll just check all
threads just in case :)

This is a good question. With independent deployments of CF in multiple
datacenters or regions you may need to distinguish between organization
86d0482c-7208-4f2f-8606-935c080cad41 in region 'us' and the same
organization id in region 'eu' for example.

We could add another path to the API for the cases where you care about
the region with GET /v1/regions/us/orgs/86d0482c-7208-4f2f-8606-935c080cad41/...
if that helps.

I could also sympathize with another approach, where we'd say that the
organization id being a guid should truly be *globally unique*. It looks
like the the current CF guid generation algorithm doesn't *guarantee*
uniqueness across deployments [1] but combining the region with it would
make it unique. IIUC I think that's what you're suggesting.

What do others think?

[1]
http://cf-dev.70369.x6.nabble.com/cf-dev-Pointer-to-the-CF-code-that-generates-org-and-service-instance-guids-tp2192.html

- Jean-Sebastien

On Tue, Oct 20, 2015 at 11:42 AM, Bharath Sekar <bsekar14(a)gmail.com>
wrote:

Hi,
account service implementations could need additional qualifiers to
uniquely identify an organization. For example, the implementation I'm
working on needs a region along with the guid of the org.
The API to get an account given org information looks like this

GET /v1/orgs/:org_id/account

How do we want to support the additional qualifier in abacus? One
solution that I can think of is including the region in the guid. org_id
could be 'guid_region'. ex:
GET /v1/orgs/86d0482c-7208-4f2f-8606-935c080cad41_us/account
Thoughts?


Re: CF-RELEASE v202 UPLOAD ERROR

Amit Kumar Gupta
 

Can you share the output of "bosh vms" and "bosh task 51 --debug". It's
preferable if you copy the terminal outputs and paste them to Gists or
Pastebins and share the links.

On Tue, Oct 20, 2015 at 6:18 AM, James Bayer <jbayer(a)pivotal.io> wrote:

sometimes a message like that is due to networking issues. does the bosh
director and the VM it is creating have an available network path to reach
each other? sometimes ssh'ing in to the VM that is identified can yield
more debug clues.

On Tue, Oct 20, 2015 at 5:09 AM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:

Thanks Bharath and Amit for the helpful solutions. I have surpassed that
error. Now, bosh deploy strucks like in attached image. Could you anyone
please?

Regards

Parthiban A



On 20 October 2015 at 11:57, Amit Gupta <agupta(a)pivotal.io> wrote:

Bharath, I think you mean to increase the *disk* size on the compilation
VMs, not the memory size.

Parthiban, the error message is happening during compiling, saying "No
space left on device". This means your compilation VMs are running out of
space on disk. This means you need to increase the allocated disk for your
compilation VMs. In the "compilation" section of your deployment manifest,
you can specify "cloud_properties". This is where you will specify disk
size. These "cloud_properties" look the same as the could_properties
specified for a resource pool. Depending on your IaaS, the structure of
the cloud_properties section differs. See here:
https://bosh.io/docs/deployment-manifest.html#resource-pools-cloud-properties

On Mon, Oct 19, 2015 at 11:13 PM, Bharath Posa <bharathp(a)vedams.com>
wrote:

hi parthiban

It seems you are running out of space in your vm in which you are
compiling . try to increase the size of memory in your compilation vm .

regards
Bharath



On Mon, Oct 19, 2015 at 7:39 PM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:

Hello All,
Thanks All for the helpful suggestions. Actually, now we
r facing the following issue while kicking bosh deploy,

Done compiling packages >
nats/d3a1f853f4980682ed8b48e4706b7280e2b7ce0e (00:01:07)
Failed compiling packages >
buildpack_php/9c72be716ab8629d7e6feed43012d1d671720157: Action Failed
get_task: Task aba21e6a-2031-4a69-5b72-f238ecd07051 result: Compiling
package buildpack_php: Compressing compiled package: Shelling out to tar:
Running command: 'tar czf
/var/vcap/data/tmp/bosh-platform-disk-TarballCompressor-CompressFilesInDir762165297
-C
/var/vcap/data/packages/buildpack_php/9c72be716ab8629d7e6feed43012d1d671720157.1-
.', stdout: '', stderr: '
gzip: stdout: No space left on device
': signal: broken pipe (00:02:41)
Failed compiling packages (00:02:41)

Error 450001: Action Failed get_task: Task
aba21e6a-2031-4a69-5b72-f238ecd07051 result: Compiling package
buildpack_php: Compressing compiled package: Shelling out to tar: Running
command: 'tar czf
/var/vcap/data/tmp/bosh-platform-disk-TarballCompressor-CompressFilesInDir762165297
-C
/var/vcap/data/packages/buildpack_php/9c72be716ab8629d7e6feed43012d1d671720157.1-
.', stdout: '', stderr: '
gzip: stdout: No space left on device
': signal: broken pipe

Could Anyone on this issue?

Regards

Parthiban A

On 19 October 2015 at 14:30, Bharath Posa <bharathp(a)vedams.com> wrote:

Hi partiban

can u do a checksum of the tar file .


it should come like this *sha1:
b6f596eaff4c7af21cc18a52ef97e19debb00403*

example:

*sha1sum {file}*

regards
Bharath

On Mon, Oct 19, 2015 at 1:12 PM, Eric Poelke <epoelke(a)gmail.com>
wrote:

You actually do not need to download it. if you just run --

`bosh upload release
https://bosh.io/d/github.com/cloudfoundry/cf-release?v=202`
<https://bosh.io/d/github.com/cloudfoundry/cf-release?v=202>

The director will pull in the release directly from bosh.io.

--
Thank you,

James Bayer


Re: [cf-abacus] Database Prefixes

Jean-Sebastien Delfino
 

Do you want to open a Github issue for that?

Using that COUCHDB env var may be an option, but perhaps we could also add
a cleaner way for you to specify a name prefix.

Thanks!

- Jean-Sebastien

On Wed, Oct 21, 2015 at 11:51 AM, rajkiranrbala <rajkiranrbala(a)hotmail.com>
wrote:

Is there a way to provide a prefix to the databases?

I am using Cloudant as my database provider.

If I set the COUCHDB env var to
http:s//username:password(a)username.cloudant.com it works fine but if I set
it to https://username:password(a)username.cloudant.com/prefix- it doesn't
work. When I look at the abacus-dbclient logs I see that it appends '/'

https://username:password(a)username.cloudant.com/prefix-/abacus-collector-collected-usage-0-201510

Thanks
Rajkiran




--
View this message in context:
http://cf-dev.70369.x6.nabble.com/cf-abacus-Database-Prefixes-tp2377.html
Sent from the CF Dev mailing list archive at Nabble.com.


Re: Cloud Foundry DEA to Diego switch - when?

R M
 

Thanks Amit - this helps a lot.


Re: region qualifier for organizations

Jean-Sebastien Delfino
 

I could argue that region is actually a pretty generic term, as it's used
in a wide range of domains from geography (parts of the world or parts of a
country) to networking and datacenters (a region as a group of IP
addresses) and even memory management in garbage collectors for example :)
... but I was also wondering about a potential confusion where our users
could just assume that region always has to be a part of the world.

So we could either make clear that region is used in its generic sense and
not necessarily a geographical region in an Abacus doc on that topic, or
attempt to find another term like cluster for example, or zone or something
else... I've created Github issue #110 [1] to help folks submit their ideas
on this.

[1] https://github.com/cloudfoundry-incubator/cf-abacus/issues/110

- Jean-Sebastien

On Wed, Oct 21, 2015 at 10:32 AM, Dieu Cao <dcao(a)pivotal.io> wrote:

I'm curious if region is perhaps too specific?
Perhaps some other generic word would be better so that it's not
prescriptive.

-Dieu

On Wed, Oct 21, 2015 at 10:10 AM, Jean-Sebastien Delfino <
jsdelfino(a)gmail.com> wrote:

Hi all,

If there's no objection and nobody comes up with a better idea, I'll
start to work on adding a GET /v1/regions/us/orgs/ path as discussed
here sometime today.

- Jean-Sebastien

On Tue, Oct 20, 2015 at 10:11 PM, Jean-Sebastien Delfino <
jsdelfino(a)gmail.com> wrote:

Hi Bharath,

Sorry for the delay, I didn't realize this was a question for the Abacus
project as it didn't have the [abacus] subject tag we've been using for
Abacus discussions recently. I guess from now on I'll just check all
threads just in case :)

This is a good question. With independent deployments of CF in multiple
datacenters or regions you may need to distinguish between organization
86d0482c-7208-4f2f-8606-935c080cad41 in region 'us' and the same
organization id in region 'eu' for example.

We could add another path to the API for the cases where you care about
the region with GET /v1/regions/us/orgs/86d0482c-7208-4f2f-8606-935c080cad41/...
if that helps.

I could also sympathize with another approach, where we'd say that the
organization id being a guid should truly be *globally unique*. It looks
like the the current CF guid generation algorithm doesn't *guarantee*
uniqueness across deployments [1] but combining the region with it would
make it unique. IIUC I think that's what you're suggesting.

What do others think?

[1]
http://cf-dev.70369.x6.nabble.com/cf-dev-Pointer-to-the-CF-code-that-generates-org-and-service-instance-guids-tp2192.html

- Jean-Sebastien

On Tue, Oct 20, 2015 at 11:42 AM, Bharath Sekar <bsekar14(a)gmail.com>
wrote:

Hi,
account service implementations could need additional qualifiers to
uniquely identify an organization. For example, the implementation I'm
working on needs a region along with the guid of the org.
The API to get an account given org information looks like this

GET /v1/orgs/:org_id/account

How do we want to support the additional qualifier in abacus? One
solution that I can think of is including the region in the guid. org_id
could be 'guid_region'. ex:
GET /v1/orgs/86d0482c-7208-4f2f-8606-935c080cad41_us/account
Thoughts?


Re: Cloud Foundry DEA to Diego switch - when?

Amit Kumar Gupta
 

Hi Rishi,

Thanks for your question. Let's first clarify the distinction between what
you deploy -- bosh releases (versioned packages of source code and
binaries) -- and how you deploy things -- bosh deployment (a manifest of
which releases to use, what code/binaries from those releases to place on
nodes in your deployment cluster, property/credential configuration,
networking and compute resources, etc.).

diego-release may not change, although it may be split into smaller
releases, e.g. the cc-bridge part consisting of the components which talk
to CC, and the diego runtime part consisting of components responsible for
scheduling, running, and health-monitoring containerized workloads.

cf-release will undergo heavy changes. We are currently breaking it apart
entirely, into separate releases: consul, etcd, logging-and-metrics,
identity, routing, API, nats, postgres, and existing runtime backend (DEA,
Warden, HM9k).

In addition to breaking up cf-release, we are working on cf-deployment[1],
this will give you the same ability to deploy the Cloud Foundry PaaS as you
know it today, but composed of multiple releases rather than the monolithic
cf-release. We will ensure that cf-deployment has versioning and tooling
to make it easy to deploy everything at versions that are known to work
together.

For the first major iteration of cf-deployment, it will deploy all the
existing components of cf-release, but coming from separate releases. You
can still deploy diego separately (configured to talk to the CC) as you do
today.

The second major iteration will be to leverage new BOSH features[2], such
as links, AZs, cloud config, and global networking to simplify the manifest
generation for cf-deployment. Again, you will still be able to deploy
diego separately alongside your cf deployment.

The third iteration is to fold the diego-release deployment strategies into
cf-deployment itself, so you'll have a single manifest deploying DEAs and
Diego side-by-side.

The final iteration will be to remove the DEAs from cf-deployment and stop
supporting the release that contains them.

As to your question of defaults, there are several definitions of
"default". You can set Diego to be the default backend today[3]. You have
to opt in to this, but then anyone using the platform you deployed will
have their apps run on Diego by default. Pivotal Web Services, for
example, now defaults to Diego as the backend. At some point, Diego will be
the true default backend, and you will have to opt-out of it (either at the
CC configuration level, or at the individual app level). Finally, at a
later point in time, DEAs will no longer be supported and Diego will be the
only backend option.

We are actively working on a timeline for all these things. You can see
the Diego team's public tracker has a release marker[4] for when Diego will
be capable of replacing the DEAs. After reaching that release marker,
there will be some time given for the rest of the community to switch over
before declaring end-of-life for the DEAs.

[1] https://github.com/cloudfoundry/cf-deployment
[2] https://github.com/cloudfoundry/bosh-notes/
[3]
https://github.com/cloudfoundry/cf-release/blob/v222/jobs/cloud_controller_ng/spec#L396-L398
[4] https://www.pivotaltracker.com/story/show/76376202

Thanks,
Amit, OSS Release Integration PM

On Wed, Oct 21, 2015 at 10:31 AM, R M <rishi.investigate(a)gmail.com> wrote:

I am trying to understand when will Diego become default runtime of Cloud
Foundry. Latest cf-release is still using DEA and if my understanding is
correct, at some stage, a new cf-release version will come out with Diego
and perhaps change to v3. Do we have any ideas on when/if this will
happen? Is it safe to assume that diego-release on github will slowly
transition to cf-release?

Thanks.


Re: Diego and Maven support

Daniel Mikusa
 

Krzysztof,

Ah, OK. That explains it then. I don't believe that the cf java client
v1.x or the Maven plugin have support for the health check functions. You
would need to do that with the cf cli. Version 6.13+ has it in the core.
Older versions require the Diego-Beta plugin.

Fortunately, you only need to set the health check once. As long as your
not deleting and recreating the application, it'll remember the selection
and you should be able to continue pushing with Maven.

Thanks for pointing this out though. I'll make a note of this use case in
our migration KB.

Dan


On Wed, Oct 21, 2015 at 2:32 AM, Krzysztof Wilk <chris.m.wilk(a)gmail.com>
wrote:

Hello Dan,

In my recent log I have found the following issue:
[INFO] 2015-10-18T14:16:02.329+0200 [HEALTH] OUT healthcheck failed
[INFO] 2015-10-18T14:16:02.330+0200 [HEALTH] OUT Exit status 1

Prior attempting to push application with Maven I have disabled health
check:
cf set-health-check KrzysztofWilkCurrencyConverter none


Relevant snippet of my Maven configuration (pom.xml) looks as follows:
<plugin>
<groupId>org.cloudfoundry</groupId>
<artifactId>cf-maven-plugin</artifactId>
<version>${cloudfoundry.maven.version}</version>
<configuration>
<server>mycloudfoundry-instance</server>
<target>http://api.run.pivotal.io</target>
<org>krzysztofwilk.pl</org>
<space>development</space>
<appname>KrzysztofWilkCurrencyConverter</appname>
<url>krzysztofwilkcurrencyconverter.cfapps.io</url>
<env>
<JDBC_DB_URL>${jdbc.db.url}</JDBC_DB_URL>
<JDBC_USERNAME>${jdbc.username}</JDBC_USERNAME>
<JDBC_PASSWORD>${jdbc.password}</JDBC_PASSWORD>
</env>
<services>
<service>
<name>CurrencyConverterDB</name>
<label>MySQL</label>
<plan>spark</plan>
</service>
</services>
</configuration>
</plugin>

All variables are resolved correctly.

Should I also disable health check via Maven? How should I do it?

Best regards,
Krzysztof


[cf-abacus] Database Prefixes

rajkiranrbala <rajkiranrbala@...>
 

Is there a way to provide a prefix to the databases?

I am using Cloudant as my database provider.

If I set the COUCHDB env var to
http:s//username:password(a)username.cloudant.com it works fine but if I set
it to https://username:password(a)username.cloudant.com/prefix- it doesn't
work. When I look at the abacus-dbclient logs I see that it appends '/'
https://username:password(a)username.cloudant.com/prefix-/abacus-collector-collected-usage-0-201510

Thanks
Rajkiran




--
View this message in context: http://cf-dev.70369.x6.nabble.com/cf-abacus-Database-Prefixes-tp2377.html
Sent from the CF Dev mailing list archive at Nabble.com.


Re: region qualifier for organizations

Dieu Cao <dcao@...>
 

I'm curious if region is perhaps too specific?
Perhaps some other generic word would be better so that it's not
prescriptive.

-Dieu

On Wed, Oct 21, 2015 at 10:10 AM, Jean-Sebastien Delfino <
jsdelfino(a)gmail.com> wrote:

Hi all,

If there's no objection and nobody comes up with a better idea, I'll start
to work on adding a GET /v1/regions/us/orgs/ path as discussed here
sometime today.

- Jean-Sebastien

On Tue, Oct 20, 2015 at 10:11 PM, Jean-Sebastien Delfino <
jsdelfino(a)gmail.com> wrote:

Hi Bharath,

Sorry for the delay, I didn't realize this was a question for the Abacus
project as it didn't have the [abacus] subject tag we've been using for
Abacus discussions recently. I guess from now on I'll just check all
threads just in case :)

This is a good question. With independent deployments of CF in multiple
datacenters or regions you may need to distinguish between organization
86d0482c-7208-4f2f-8606-935c080cad41 in region 'us' and the same
organization id in region 'eu' for example.

We could add another path to the API for the cases where you care about
the region with GET /v1/regions/us/orgs/86d0482c-7208-4f2f-8606-935c080cad41/...
if that helps.

I could also sympathize with another approach, where we'd say that the
organization id being a guid should truly be *globally unique*. It looks
like the the current CF guid generation algorithm doesn't *guarantee*
uniqueness across deployments [1] but combining the region with it would
make it unique. IIUC I think that's what you're suggesting.

What do others think?

[1]
http://cf-dev.70369.x6.nabble.com/cf-dev-Pointer-to-the-CF-code-that-generates-org-and-service-instance-guids-tp2192.html

- Jean-Sebastien

On Tue, Oct 20, 2015 at 11:42 AM, Bharath Sekar <bsekar14(a)gmail.com>
wrote:

Hi,
account service implementations could need additional qualifiers to
uniquely identify an organization. For example, the implementation I'm
working on needs a region along with the guid of the org.
The API to get an account given org information looks like this

GET /v1/orgs/:org_id/account

How do we want to support the additional qualifier in abacus? One
solution that I can think of is including the region in the guid. org_id
could be 'guid_region'. ex:
GET /v1/orgs/86d0482c-7208-4f2f-8606-935c080cad41_us/account
Thoughts?


Cloud Foundry DEA to Diego switch - when?

R M
 

I am trying to understand when will Diego become default runtime of Cloud Foundry. Latest cf-release is still using DEA and if my understanding is correct, at some stage, a new cf-release version will come out with Diego and perhaps change to v3. Do we have any ideas on when/if this will happen? Is it safe to assume that diego-release on github will slowly transition to cf-release?

Thanks.


Re: Pointer to the CF code that generates org and service instance guids?

Eric Malm <emalm@...>
 

Hi, Jean-Sebastien,

V4 UUIDs contain 122 bits of information (
https://tools.ietf.org/html/rfc4122#page-14), so there are approximately
5.3 × 10^36 distinct ones. Since the Ruby implementation that Joseph
referred to generates them randomly, we can assume them to be distributed
uniformly across the sample space. From the approximation formulas in
https://en.wikipedia.org/wiki/Birthday_problem#Cast_as_a_collision_problem,
for there to be even a one-in-a-billion probability of a collision, you
would have to be using more than 10^14 UUIDs simultaneously as organization
guids. If you have, say, only a million org guids in play, the probability
of a collision decreases to about 10^-25.

Thanks,
Eric

On Tue, Oct 20, 2015 at 10:28 PM, Jean-Sebastien Delfino <
jsdelfino(a)gmail.com> wrote:

Thanks that helps. I have a few follow up questions:

Can you quantify 'mathematically incredibly likely'?

How do you guarantee uniqueness for a single deployment (since AIUI
they're generated randomly)? Are you using the CC database for that?

What would it take to guarantee uniqueness across deployments? (I'm asking
as cloud platforms out there usually run in several datacenters or regions,
i.e. multiple deployments, so to me it would make sense to provide a way to
implement that guarantee, for example by allowing the uuid to be generated
from a namespace/name like described in RFC 4122 section 4.3 [1], but
there's probably many other ways to do this...)

[1] https://www.ietf.org/rfc/rfc4122.txt

Thanks!

- Jean-Sebastien

On Fri, Oct 9, 2015 at 11:08 PM, CF Runtime <cfruntime(a)gmail.com> wrote:

Org and Service Instance guids are generated by the Cloud Controller. It
simply uses the SecureRandom.uuid ruby method:
http://docs.ruby-lang.org/en/2.2.0/SecureRandom.html#method-c-uuid

SecureRandom.uuid implements RFC 4122 and generates guids randomly. The
guids for orgs are guaranteed to be unique for a single deployment, and
mathematically incredibly likely to be unique across all deployments.

Joseph
CF Release Integration Team

On Fri, Oct 9, 2015 at 2:51 PM, Jean-Sebastien Delfino <
jsdelfino(a)gmail.com> wrote:

Hi all,

Could somebody from the CF team point me to the CF code that generates
org and service instance guids?

Are the generated guids globally unique across multiple
deployments/instances of CF? or only unique within a single instance of CF?

Thanks!

- Jean-Sebastien


Re: region qualifier for organizations

Jean-Sebastien Delfino
 

Hi all,

If there's no objection and nobody comes up with a better idea, I'll start
to work on adding a GET /v1/regions/us/orgs/ path as discussed here
sometime today.

- Jean-Sebastien

On Tue, Oct 20, 2015 at 10:11 PM, Jean-Sebastien Delfino <
jsdelfino(a)gmail.com> wrote:

Hi Bharath,

Sorry for the delay, I didn't realize this was a question for the Abacus
project as it didn't have the [abacus] subject tag we've been using for
Abacus discussions recently. I guess from now on I'll just check all
threads just in case :)

This is a good question. With independent deployments of CF in multiple
datacenters or regions you may need to distinguish between organization
86d0482c-7208-4f2f-8606-935c080cad41 in region 'us' and the same
organization id in region 'eu' for example.

We could add another path to the API for the cases where you care about
the region with GET /v1/regions/us/orgs/86d0482c-7208-4f2f-8606-935c080cad41/...
if that helps.

I could also sympathize with another approach, where we'd say that the
organization id being a guid should truly be *globally unique*. It looks
like the the current CF guid generation algorithm doesn't *guarantee*
uniqueness across deployments [1] but combining the region with it would
make it unique. IIUC I think that's what you're suggesting.

What do others think?

[1]
http://cf-dev.70369.x6.nabble.com/cf-dev-Pointer-to-the-CF-code-that-generates-org-and-service-instance-guids-tp2192.html

- Jean-Sebastien

On Tue, Oct 20, 2015 at 11:42 AM, Bharath Sekar <bsekar14(a)gmail.com>
wrote:

Hi,
account service implementations could need additional qualifiers to
uniquely identify an organization. For example, the implementation I'm
working on needs a region along with the guid of the org.
The API to get an account given org information looks like this

GET /v1/orgs/:org_id/account

How do we want to support the additional qualifier in abacus? One
solution that I can think of is including the region in the guid. org_id
could be 'guid_region'. ex:
GET /v1/orgs/86d0482c-7208-4f2f-8606-935c080cad41_us/account
Thoughts?


HM9000 gets stuck in bad state

kyle havlovitz <kylehav@...>
 

I'm having an issue where after a day or two or running, the health manager
is getting stuck in a bad state and doesn't display the state of apps
correctly. The logs show messages like this: "Store is not fresh -
Error:Actual and desired state are not fresh" and "Daemon returned an
error. Continuining... - Error:Actual and desired state are not fresh".

Restarting the process fixes the issue, but I'm wondering how to avoid this
problem altogether. Is this a known issue?


[abacus] Configuring Abacus applications

Piotr Przybylski <piotrp@...>
 

Hi, 
couple of questions about configuring Abacus, specifically the recommended settings and how to configure them

- is there a recommended minimal number of instances of Abacus applications
- how would above depend on expected number of submissions or documents to be processed
- is there a dependency between number of instances of applications i.e. do they have to match 
- what is the default and recommended number of DB partitions and how can they be configured (time based as well as key based)
- how would above depend on expected number of documents

Thank you,

Piotr



Re: REST API endpoint for accessing application logs

Johannes Tuchscherer
 

No, that is 100 as in 100 log lines. Given that a log line is transported
as a UDP package and the UDP max package size is 64k, with a buffer of 100
log lines you require 6.3MB of memory per app on your Doppler server.

On Wednesday, October 21, 2015, Ponraj E <ponraj.e(a)gmail.com> wrote:

Hi,

Short update reg the question #2 above: I came to know from here
http://docs.cloudfoundry.org/loggregator/ops.html that the number/size of
log messages drained to the doppler can be controlled by a bosh deployment
manifest configuration : doppler.message_drain_buffer_size

It is specified that the doppler.message_drain_buffer_size default value
is 100.

Is it 100MB?


How to detect this case: CF-AppMemoryQuo taExceeded

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

Hi,

doing some tests, I detected in my testing environment the following scenario:

Error: the string "{\n \"code\": 100005,\n \"description\": \"You have ex
ceeded your organization's memory limit.\",\n \"error_code\": \"CF-AppMemoryQuo
taExceeded\"\n}\n" was thrown, throw an Error :)

Does exist some REST Call to know if the org/space has reached the limit?

Many thanks in advance

Juan Antonio


Re: Different behaviour in Login with Pivotal and Bluemix

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

Hi Matthew,

many thanks for the technical explanation.

In my tests, I discovered that at the moment it is compatible to get access using this field:
"authorization_endpoint":"https://login.run.pivotal.io"
"authorization_endpoint":"https://login.eu-gb.bluemix.net/UAALoginServerWAR"

Cheers

Juan Antonio


Re: Need Help: Seeking tutorial on CF and WordPress Multisite

Daniel Mikusa
 

On Tue, Oct 20, 2015 at 10:19 PM, v Bailey <v2bailey(a)gmail.com> wrote:

I am totally green about asking the proper question so here's what I'm
researching...

I'm a decently adept web designer who specializes in WordPress. I would
like to pursue some larger clients and offer to move their sites to the
cloud (as well as perform their makeovers, of course) but in a couple of
cases, the organizations have multiple branches, each with their own
website, and it seems to make sense to use Multisite instead of individual
websites. That said, I've never used Multisite so my concern is how does
it work to create multiple websites+database for a single client...on the
cloud?
If you have a little experience with the command prompt or a terminal it's
fairly easy to create multiple sites and even services using Cloud
Foundry. This document gives you a quick overview of the cf cli.

http://docs.cloudfoundry.org/devguide/installcf/whats-new-v6.html

The main task to run your application on CF is called "cf push". You can
see more about that here.

http://docs.cloudfoundry.org/devguide/installcf/whats-new-v6.html#push

And there's a walkthrough of deploying an app here.

http://docs.cloudfoundry.org/devguide/deploy-apps/deploy-app.html

In regards to databases, you can also create those with the cf client.
This document has some instructions on that.

https://docs.cloudfoundry.org/devguide/services/managing-services.html

Since you mentioned Wordpress, you might find this blog post useful. It
walks through running Wordpress on CF.


http://blog.pivotal.io/pivotal-cloud-foundry/products/getting-started-with-wordpress-on-cloud-foundry


I suspect I should be asking more but since I don't entirely understand
what the setup should be I'll start with a simple initial question. I'd
LOVE to hear some insight into how to setup these kind of clients.

Please be gentle with me, I bruise easy. Simple explanations get more
mileage with me. Thank you kindly in advance!!
The best thing would be to sign up for an account with a public CF provider
(PWS, Bluemix, AnyNines, etc...). It's pretty easy and most offer free
trials. That would allow you to play around with deploying an app or two
to CF and get used to the cf client.

Hope that helps!

Dan

7021 - 7040 of 9414