Need to differentiate kvm vs lx in "triton images" output about node-triton HOT 11 CLOSED

We can't re-purpose the OS column as you can have windows/kvm, freebsd/kvm, etc.
The unfortunately/poorly-named attribute for this purpose is "type", which returns either "smartmachine" or "virtualmachine". We can expose that and hide pubdate to make space for it. Down the road, it'll be good to be able to rename the type field and values to something better but it can be done only if we support versioning.

from node-triton.

It would not be ok to overload any existing column for that purpose. A new column is required.

from node-triton.

In the TODO.txt I'd had this: *type*: cloudapi changes to clarify: LX, docker, smartos, kvm instances

I don't have a solid proposal yet. Cloudapi's renaming of "type" values sucks. Would could have a triton client-side translation to a typ or kind column that had nicer values: container/vm or lx/smartos/kvm or whatever.

from node-triton.

I'd like to make sure we talk about three "types" of compute instances:

Docker containers

Docker containers on Triton can run images from a variety of registries, including public and private. See detailed documentation for connecting to those registries in containers → Docker → registries.

Infrastructure containers

Infrastructure containers running container-native Linux and SmartOS, or pre-configured installations of up-stack software such as databases or load balancers offer the advantage of bare-metal performance with the elasticity of containers and security that's only available using Triton.

See information about available images, including bare operating systems and configured applications in containers → infrastructure containers → images. Also see details about creating a custom container-native image.

Hardware virtual machines

Not every workload can be deployed as a container. We also offer images for KVM-based hardware virtual machines to support the broadest range of legacy or special purpose operating systems.

Available images include FreeBSD, Linux (not container-native), and Windows.

Specifically, we don't want to differentiate between "lx" and "smartos" instances, as the way they fit into people's infrastructure needs is identical: they're infrastructure containers.

Some docs references from language:

• https://docs.joyent.com/images
• https://docs.joyent.com/public-cloud/instances

from node-triton.

@askfongjojo , @misterbisson what are the scenarios of concerns for the the ascii output prepending "kvm" for this new tool? "kvm windows" and "kvm bsd" seem fine. Seems like an elegant hack. Another column is not human-friendly particularly when the collision is only currently in linux; docker images all are named "docker*".

1. OT: is there recent discussion about naming new kvm linux images with "kvm" in the name? The dropping of "lx" for ubuntu has caused much fun.
2. OT: is there a cloudapi jira related to a field for the three "types": inf containers, docker, and kvm?
3. OT: for docker images any plan to make human friendly column exposing the docker image name? I'd like to incorperate this in adminui search if possible.

from node-triton.

@lloydde Re: docker images: The get the "friendly" docker name is user specific and needs to talk to sdc-docker to get that info. That docker images live in imgapi is (at least currently) an implementation detail.

from node-triton.

@misterbisson Suggestions for the short names for those three types/kinds/flavours of instances?

from node-triton.

needs to talk to sdc-docker to get that info

Prime! Tx.

from node-triton.

@trentm, re: short names. It depends on how short you want.

Instance types of different lengths:

• Docker c.
• Infrastructure c.
• Hardware VM

• Docker c.
• Infrastruct. c.
• Hardware VM

• DC
• IC
• HVM

Side questions:

• Can we use ©️ to indicate "container?"
• What about (the amphora symbol)?

More seriously, I should point out that I use "hardware virtual machine" instead of just "virtual machine" to distinguish the instance type from our language in the admin UI and CloudAPI where we call every instance type a "machine."

from node-triton.

Per discussion on PUBAPI-1161 (https://smartos.org/bugview/PUBAPI-1161), just going to expose the 'type' field in default triton images output. See write up on output changes (for this and triton instances changes that are similar) here: https://gist.github.com/trentm/62f78bb5141e75ec6abe

The question of exposing Docker image details in triton images is a larger separate discussion.

from node-triton.

This will be in [email protected] (probably later today)

from node-triton.