Bug 1118522 - oo-admin-usage reports different gear IDS vs what REST API gear_groups in devenvs
Summary: oo-admin-usage reports different gear IDS vs what REST API gear_groups in dev...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: OpenShift Online
Classification: Red Hat
Component: Pod
Version: 2.x
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: ---
: ---
Assignee: Abhishek Gupta
QA Contact: libra bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-10 23:55 UTC by Peter Ruan
Modified: 2015-05-15 00:29 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-10-10 00:48:34 UTC


Attachments (Terms of Use)

Description Peter Ruan 2014-07-10 23:55:15 UTC
Description of problem:
oo-admin-usage reports different gear IDS vs what REST API gear_groups in devenvs



Version-Release number of selected component (if applicable):
current

How reproducible:
always.

Steps to Reproduce:
1. create a scaleable php app
2. disable auto-scaling
3. scale up app
4. run oo-admin-usage --login <username> --app <app_name>
5. query the gear_group REST url


Actual results:
[root@ip-10-184-167-156 ~]# oo-admin-usage --login pruan@redhat.com --app hlaqqfag

Usage for pruan@redhat.com (Plan: free)
-------------------
#1
 Usage Type: GEAR_USAGE (small)
    Gear ID: 53bf5937ddf44d3eb3000056 (hlaqqfag)
   Duration: 6 minutes and 38 seconds (2014-07-11 03:26:10 - PRESENT)

#2
 Usage Type: GEAR_USAGE (small)
    Gear ID: 53bf5982ddf44d3eb3000075 (hlaqqfag)
   Duration: 5 minutes and 30 seconds (2014-07-11 03:27:18 - PRESENT)

via REST API gear_groups



gears": [

    {
        "id": "53bf5937ddf44d3eb3000056",
        "state": "started",
        "ssh_url": "ssh://53bf5937ddf44d3eb3000056@hlaqqfag-etnocw.dev.rhcloud.com",
        "region": null,
        "zone": null
    },
    {
        "id": "53bf5982ddf44d0060000008",
        "state": "started",
        "ssh_url": "ssh://53bf5982ddf44d0060000008@53bf5982ddf44d0060000008-etnocw.dev.rhcloud.com",
        "region": null,
        "zone": null
    }

],
"id": "53bf5937ddf44d3eb3000058",
"name": "53bf5937ddf44d3eb3000058",

===== from broker's mongodb ============

    ],
       "quarantined": false,
       "server_identity": "ip-10-184-167-156",
       "sparse_carts": [
         ObjectId("53bf5937ddf44d3eb300006a")
      ],
       "uid": null,
       "uuid": "53bf5937ddf44d3eb3000056"
    },
     {
       "_id": ObjectId("53bf5982ddf44d3eb3000075"),
       "app_dns": false,
       "group_instance_id": ObjectId("53bf5937ddf44d3eb3000058"),
       "host_singletons": false,
       "name": "53bf5982ddf44d0060000008",
       "port_interfaces": [
         {
           "_id": ObjectId("53bf598cddf44d3eb3000081"),
           "cartridge_name": "php-5.3",
           "external_port": "38051",
           "internal_port": "8080",
           "protocols": [
             "http",
             "ws"
          ],
           "type": [
             "web_framework"
          ],
           "mappings": [
             {
               "frontend": "",
               "backend": ""
            },
             {
               "frontend": "/health",
               "backend": ""
            }
          ],
           "internal_address": "127.1.246.1"
        }
      ],

Expected results:
the gear_ids to report the same result.

Additional info:

Comment 1 Meng Bo 2014-07-11 02:58:05 UTC
I did not see the issue from oo-admin-usage,


>For my two gears app app1s, the gear IDs are 53bf85388e76bd2e57000009 and 53bf85838e76bd2e57000029 and both of them can be found in mongodb.

# oo-admin-usage -l bmeng

Usage for bmeng (Plan: free)
-------------------
#1
 Usage Type: GEAR_USAGE (small)
    Gear ID: 53bf85388e76bd2e57000009 (app1s)
   Duration: 1 minutes and 40 seconds (2014-07-11 06:34:08 - PRESENT)

#2
 Usage Type: GEAR_USAGE (small)
    Gear ID: 53bf85838e76bd2e57000029 (app1s)
   Duration: 39 seconds (2014-07-11 06:35:09 - PRESENT)


>Mongodb:

   "gears"▼: [
     {
       "_id": ObjectId("53bf85388e76bd2e57000009"),
       "app_dns": true,
       "group_instance_id": ObjectId("53bf85388e76bd2e5700000b"),
       "host_singletons": true,
       "name": "app1s",
...
     {
       "_id": ObjectId("53bf85838e76bd2e57000029"),
       "app_dns": false,
       "group_instance_id": ObjectId("53bf85388e76bd2e5700000b"),
       "host_singletons": false,
       "name": "53bf85838e76bd00db000002",


>And all the two gears have the same gera_group 53bf85388e76bd2e5700000b.


>RESTAPI gear_groups:

    <gear-group>
      <id>53bf85388e76bd2e5700000b</id>
      <name>53bf85388e76bd2e5700000b</name>
      <gear-profile>small</gear-profile>
      <gears>
        <gear>
          <id>53bf85388e76bd2e57000009</id>       <-----------------------
          <state>started</state>
          <ssh-url>ssh://53bf85388e76bd2e57000009@app1s-bmeng.dev.rhcloud.com</ssh-url>
          <region nil="true"></region>
          <zone nil="true"></zone>
        </gear>
        <gear>
          <id>53bf85838e76bd00db000002</id>        <----------------------
          <state>started</state>
          <ssh-url>ssh://53bf85838e76bd00db000002@53bf85838e76bd00db000002-bmeng.dev.rhcloud.com</ssh-url>
          <region nil="true"></region>
          <zone nil="true"></zone>
        </gear>
      </gears>




The only problem for me is the gear ID returned from REST API gear_groups is actually the gear UUID. Marked in my result.

Set the bug to low, and let someone explain this for us.

Comment 2 Peter Ruan 2014-07-11 03:50:19 UTC
That's exactly the problem, it should return a matching ID, not the UUID.  I'll follow up with agupta tomorrow.

Comment 3 Abhishek Gupta 2014-07-29 00:37:31 UTC
There is some history to this bug.

UUID (32 char hex values) is the identifier that we used for our mongo documents before the model refactor in Feb 2013. Due to our adoption of MongoId, we were forced to use ID (24 char hex values) as the identifiers for our documents. This discrepancy in the unique identifiers posed certain issues for existing applications/gears/etc that had the 32 char UUID. Specifically, ssh, git (using ssh) would be inconsistent for older vs new applications/gears. Similarly, district UUID was stored on the nodes and these would now be different as well. 

To ensure backward compatibility, we maintained the UUID in the documents and ensured that UUID and ID were the same going forward. We migrated the UUID wherever possible, but SSH was going to be an issue since the user accounts were created using the UUID. To ensure that our changes over time would handle these differences correctly and to provide a means to automatically provide test scenarios, we randomized the UUID in our devenv in one of three ways:

1. UUID and ID could be the same (reflecting the latest behavior)
2. UUID could be 32 char (different from the ID)
3. UUID could be a 24 char all numeric value (to handle other test scenarios)

This randomization allowed us to mimic the production landscape in our devenv to facilitate testing to ensure that backward compatibility was not broken with pre-mongoid applications/gears.


While the current behavior is expected, one important thing to validate here would be to test the SSH url for the "head"/DNS gear as well as any other scaled/DB gear when the UUID and ID values are different.

Comment 4 zhaozhanqi 2014-07-30 06:21:50 UTC
Verified this bug on devenv_5027

when the UUID and ID values are different like d9221fda17d011e4b2965627585c07e5', The SSH URL can be accessible.
#rhc app show phps -g
ID                               State   Cartridges          Size  SSH URL
-------------------------------- ------- ------------------- ----- -------------------------------------------------------------------------------------
53d8b2f8499910aa8a000029         started php-5.4 haproxy-1.4 small 53d8b2f8499910aa8a000029@phps-zqd.dev.rhcloud.com
529716746521926728417280         started php-5.4             small 529716746521926728417280@529716746521926728417280-zqd.dev.rhcloud.com
781184188405064543502336         started php-5.4             small 781184188405064543502336@781184188405064543502336-zqd.dev.rhcloud.com
834325854605817126322176         started php-5.4             small 834325854605817126322176@834325854605817126322176-zqd.dev.rhcloud.com
d9221fda17d011e4b2965627585c07e5 started php-5.4             small d9221fda17d011e4b2965627585c07e5@d9221fda17d011e4b2965627585c07e5-zqd.dev.rhcloud.com


# ssh d9221fda17d011e4b2965627585c07e5@d9221fda17d011e4b2965627585c07e5-zqd.dev.rhcloud.com

    *********************************************************************

    You are accessing a service that is for use only by authorized users.
    If you do not have authorization, discontinue use at once.
    Any use of the services is subject to the applicable terms of the
    agreement which can be found at:
    https://www.openshift.com/legal

    *********************************************************************

    Welcome to OpenShift shell

    This shell will assist you in managing OpenShift applications.

    !!! IMPORTANT !!! IMPORTANT !!! IMPORTANT !!!
    Shell access is quite powerful and it is possible for you to
    accidentally damage your application.  Proceed with care!
    If worse comes to worst, destroy your application with "rhc app delete"
    and recreate it
    !!! IMPORTANT !!! IMPORTANT !!! IMPORTANT !!!

    Type "help" for more info.


[d9221fda17d011e4b2965627585c07e5-zqd.dev.rhcloud.com d9221fda17d011e4b2965627585c07e5]\>


Note You need to log in before you can comment on or make changes to this bug.