BUG: With 3.0.2 sometimes hexboard doesn't properly find all sketchpods that have come up

[thoraxe]

I think this might have to do with whatever updates were made to the NodeJS builder image. I get very inconsistent behavior on scale-out in my environment. When I go from 1 to N pods (whatever the board size is), all of the pods come up, but, occasionally some of them don't turn "black".

Restarting the hexboard will show all of the hexes... but I am wondering what the root cause is.

I have never seen this issue on 3.0.1.0

[ryanj]

Thanks for setting up that new 3.0.2 env. I couldn't repro today, but I'll try again tomorrow

[ryanj]

I think I've fixed this. Please reopen the issue if you're still able to reproduce it after rebuilding your hexboard with the latest code.

[thoraxe]

Seems still broken:

12 ready pods, not all 12 showing in app. I just built this morning against whatever hexboard master is.

[ryanj]

The openshift-master.aws.* test server is gone, so I'll need to build an environment in order to try to reproduce this issue.

[thoraxe]

Actually, it's even worse in 3.1. Looks like the REST API changed:

npm info it worked if it ends with ok
npm info using npm@1.4.28
npm info using node@v0.10.35
npm info prestart hexboard@0.0.1

> hexboard@0.0.1 start /opt/app-root/src
> node server/server.js

npm info start hexboard@0.0.1
SERVER Listening on 0.0.0.0:8080
POD list options https://172.30.0.1/api/v1beta3/namespaces/foo/pods
POD Wed Oct 28 2015 02:01:14 GMT-0400 (EDT)
POD Connection error: { code: 404,
  options: 
   { url: 'https://172.30.0.1/api/v1beta3/namespaces/foo/pods',
     auth: { bearer: 'cRJecFYEpmqkYUncLB5Vqhl-taKi2feSfpzkBo5hf7s' },
     pool: 
      { domain: null,
        _events: [Object],
        _maxListeners: 10,
        options: [Object],
        requests: {},
        sockets: {},
        maxSockets: 8,
        createConnection: [Function],
        'https:false': [Object] },
     method: 'get',
     qs: {},
     rejectUnauthorized: false,
     strictSSL: false },
  msg: '{\n  "kind": "Status",\n  "apiVersion": "v1",\n  "metadata": {},\n  "status": "Failure",\n  "message": "the server could not find the requested resource",\n  "reason": "NotFound",\n  "details": {},\n  "code": 404\n}\n' }

[thoraxe]

Would you rather a 3.0.2 env or a 3.1 env, since 3.1 is basically right around the corner?

I'm not sure if there'll be a way for you to maintain backwards-compatibility, will there?

[detiber]

Keep in mind that 3.1 deprecates the v1beta3 api, so everything will need
to be updated to v1
On Oct 28, 2015 2:06 AM, "Erik M Jacobs" notifications@github.com wrote:

Would you rather a 3.0.2 env or a 3.1 env, since 3.1 is basically right
around the corner?

I'm not sure if there'll be a way for you to maintain
backwards-compatibility, will there?

—
Reply to this email directly or view it on GitHub
#20 (comment)
.

[detiber]

Also, I don't think we should strive for backward compatibility, rather
target the latest official releases if possible.
On Oct 28, 2015 9:49 AM, "Jason DeTiberus" jdetiber@redhat.com wrote:

Keep in mind that 3.1 deprecates the v1beta3 api, so everything will need
to be updated to v1
On Oct 28, 2015 2:06 AM, "Erik M Jacobs" notifications@github.com wrote:

Would you rather a 3.0.2 env or a 3.1 env, since 3.1 is basically right
around the corner?

I'm not sure if there'll be a way for you to maintain
backwards-compatibility, will there?

—
Reply to this email directly or view it on GitHub
#20 (comment)
.