rocks name vs name

[laszewsk]

old:

rocks_name name

new:

name lable

[rpwagner]

What is meant by "name" and "label"? The virtual compute nodes should only have one name via the API and any clients, like "compute-2-3" or "bob".

[tcooper]

You missed this in the meeting yesterday as you were traveling...

From the API URL... https://comet-nucleus.sdsc.edu/nucleus/v1/cluster/vc3/

You get back the following JSON...

{
    "name": "vc3",
    "description": "",
    "computes": [
        {
            "name": "vm-vc3-0",
            "rocks_name": "vm-vc3-0",
            "host": null,
            "ip": null,
            "memory": null,
            "cpus": null,
            "cluster": "vc3",
            "type": "VM",
            "state": "active"
        },
        ...

...where "name": is the common name the cluster admin could use to identify the node and could match their cluster internal node name and "rocks_name": is the name of the virtual compute node in Rocks that users wouldn't see in the API but we might see in other tools/views.

Additionally, "host": is the physical comet node the virtual node is running on that would not be visible to virtual cluster admins but could be visible/used by us.

[rpwagner]

Thanks for the explanation. So what is label intended for?

[tcooper]

I believe Gregor is suggesting a change in the JSON keys...

• from "name": to "label":
• from "rocks_name": to "name":.

[laszewsk]

conceptually the cluster has a name, the name is not changable. The name is given by comet.

This is at this time refrrred to as rocks_name

Than the cluster admin seems to be able to assign a cluster a label, this is refred to as name, to use more consistent naing, i think it should be

{ "name": "vc3", "description": "", "computes": [ { “label": "vm-vc3-0", "name": "vm-vc3-0", "host": null, "ip": null, "memory": null, "cpus": null, "cluster": "vc3", "type": "VM", "state": "active" }, ...

instead of

{ "name": "vc3", "description": "", "computes": [ { "name": "vm-vc3-0", "rocks_name": "vm-vc3-0", "host": null, "ip": null, "memory": null, "cpus": null, "cluster": "vc3", "type": "VM", "state": "active" }, ...

as you can see the “name” is now used in both object portions as assigned by us and not one assigned by us, the other not, but we do a rocks name instea and use the name now in the second level a s a label that can be assigned by the user, while the first name from the outer object can not.

As we have the user in mind, we shoudl make sure to to simple naming conventions that are consistane within the bject hierarchy we introduce.

Internally you may in teh rock software called is a rocks anme, but thats somewhat irrelevant as we shoudl look at a consistent REST API. The point here is to have an abstraction that “hides” those details, so this name is caled a name and not a rocks name

just my 2c

On Nov 11, 2015, at 10:47 PM, Rick Wagner notifications@github.com wrote:

Thanks for the explanation. So what is label intended for?

— Reply to this email directly or view it on GitHub https://github.com/sdsc/nucleus-service/issues/6#issuecomment-155988237.

[laszewsk]

sorry spell checker of

summary

mv rocks_name name mv name label

;-)

On Nov 11, 2015, at 10:55 PM, Gregor von Laszewski laszewski@gmail.com wrote:

conceptually the cluster has a name, the name is not changable. The name is given by comet.

This is at this time refrrred to as rocks_name

Than the cluster admin seems to be able to assign a cluster a label, this is refred to as name, to use more consistent naing, i think it should be

{ "name": "vc3", "description": "", "computes": [ { “label": "vm-vc3-0", "name": "vm-vc3-0", "host": null, "ip": null, "memory": null, "cpus": null, "cluster": "vc3", "type": "VM", "state": "active" }, ...

instead of

{ "name": "vc3", "description": "", "computes": [ { "name": "vm-vc3-0", "rocks_name": "vm-vc3-0", "host": null, "ip": null, "memory": null, "cpus": null, "cluster": "vc3", "type": "VM", "state": "active" }, ...

as you can see the “name” is now used in both object portions as assigned by us and not one assigned by us, the other not, but we do a rocks name instea and use the name now in the second level a s a label that can be assigned by the user, while the first name from the outer object can not.

As we have the user in mind, we shoudl make sure to to simple naming conventions that are consistane within the bject hierarchy we introduce.

Internally you may in teh rock software called is a rocks anme, but thats somewhat irrelevant as we shoudl look at a consistent REST API. The point here is to have an abstraction that “hides” those details, so this name is caled a name and not a rocks name

just my 2c

On Nov 11, 2015, at 10:47 PM, Rick Wagner <notifications@github.com mailto:notifications@github.com> wrote:

Thanks for the explanation. So what is label intended for?

— Reply to this email directly or view it on GitHub https://github.com/sdsc/nucleus-service/issues/6#issuecomment-155988237.

[dimm0]

Only using 'name' which is user defined name in the API