RFD 26: discussion about rfd HOT 5 CLOSED

triton volume create --network mynetwork --name wp-uploads --size 100G -e affinity:container!=wp-server (affinity milestone)

That should be -a 'instance!=wp-server' ("container" can be used for
"instance") to match syntax for triton instance create -a AFFINITY-RULE ....

Also the affinity section mentions "~=" as an operator. This should instead
match the instance affinity rules which support ==, !=, ==~, and !=~.

triton report

FWIW there is the questionably useful:

$ triton info
login: trent...
name: ...
email: ...
url: https://us-east-3b.api.joyent.com
totalDisk: 524.5 GiB
totalMemory: 24.7 GiB
instances: 8
    stopped: 2
    running: 6

New sdc:volumes key

Update to mdata-dict docs for this? (http://eng.joyent.com/mdata/datadict.html)

Placement of volume containers

Has there been any testing how some example NFS clients (smartos, lx, docker)
react to the CN holding the NFS volume going down? Do they choke? crash?
hang? retry until the CN is back up?

Is there an operator guide plan for volumes? Seems like one might be useful
for onprem operators. Perhaps opening a DOC ticket for this.

CreateVolume
labels (mvp milestone)

Perhaps s/labels/tags?

...

Was there a mention that one cannot alter what volumes are attached to an
instance after it is created? Is that just to limit scope?

alias='volume-$volumename-$volumeuuid'

FWIW, that reduces the upper limit on the length of the given volume name
that is allowed. Should be fine, but there might be some validation code
somewhere that should account for that.

Changes to PAPI

It wasn't clear to me: This involves adding a 'type' field to packages?

volume references
...
When a VM that references a volume becomes inactive, its reference to that
volume is automatically removed. If it becomes active again, it is
automatically added.

How does an inactive VM because active again? My understanding of "inactive"
was that it means "destroyed". Oh, I guess we can have a VM state in VMAPI
go "destroyed" and then to one of the active states (like "running") again,
e.g. for a VM migration?

deleted and failed volumes are still persisted to Moray for
troubleshooting/debugging purposes. See the section Volumes state machine for
a diagram and further details about the volumes' state machine.

Thoughts on not returning deleted/failed vols by default in ListVolumes?
I know that differs from VMAPI ListVms. FWIW, IMGAPI ListImages does
this: https://mo.joyent.com/docs/imgapi/master/#ListImages
It lists 'active' ones by default. You need an explicit ?state=all to get
other states (e.g. 'failed').

My main argument for limiting the default query is to reduce large accidental
queries, both by operator tools and API clients.

from rfd.

triton volume create --network mynetwork --name wp-uploads --size 100G -e affinity:container!=wp-server (affinity milestone)

That should be -a 'instance!=wp-server' ("container" can be used for
"instance") to match syntax for triton instance create -a AFFINITY-RULE ....

Done.

Also the affinity section mentions "~=" as an operator. This should instead
match the instance affinity rules which support ==, !=, ==~, and !=~.

Done.

triton report
FWIW there is the questionably useful:

$ triton info
login: trent...
name: ...
email: ...
url: https://us-east-3b.api.joyent.com
totalDisk: 524.5 GiB
totalMemory: 24.7 GiB
instances: 8
    stopped: 2
    running: 6

I think the intention with triton report was to have something more similar to triton instance list and triton volume list.

New sdc:volumes key

Update to mdata-dict docs for this? (http://eng.joyent.com/mdata/datadict.html)

Sounds good, see https://smartos.org/bugview/TRITON-10. I wonder though how discoverable this doc is. I always forget it's there.

Placement of volume containers

Has there been any testing how some example NFS clients (smartos, lx, docker)
react to the CN holding the NFS volume going down? Do they choke? crash?
hang? retry until the CN is back up?

Programs performing operations on the remote FS hosted by the given CN would retry indefinitely and hang until the remote FS is back up. We didn't perform any extensive testing for this though, so I'll see if there are some tests we might have missed and we should perform sooner rather than later.

Is there an operator guide plan for volumes?

There's no such guide for now.

Seems like one might be useful for onprem operators. Perhaps opening a DOC ticket for this.

Yes, see https://smartos.org/bugview/TRITON-11. I did not open a DOC ticket because I couldn't find a "component" that seemed to be relevant.

CreateVolume
labels (mvp milestone)

Perhaps s/labels/tags?

Sure, the "labels" terminology comes from docker, I'm good with tags if this is more consistent with Triton. Can you confirm that?

alias='volume-$volumename-$volumeuuid'

FWIW, that reduces the upper limit on the length of the given volume name
that is allowed. Should be fine, but there might be some validation code
somewhere that should account for that.

That's a good point, created https://smartos.org/bugview/VOLAPI-82.

Changes to PAPI

It wasn't clear to me: This involves adding a 'type' field to packages?

No, it introduces a separate class of packages called "volume packages", which have a type property.

How does an inactive VM because active again? My understanding of "inactive"
was that it means "destroyed". Oh, I guess we can have a VM state in VMAPI
go "destroyed" and then to one of the active states (like "running") again,
e.g. for a VM migration?

Inactive is anything that is not stopped or running. That includes destroyed, failed, etc.. VM migrations can cause a VM to transition from inactive to active, reboots too. But really the state machine of VMs state is one where all states can transition to all states.

deleted and failed volumes are still persisted to Moray for
troubleshooting/debugging purposes. See the section Volumes state machine for
a diagram and further details about the volumes' state machine.

Thoughts on not returning deleted/failed vols by default in ListVolumes?

That was actually a mistake, I hadn't updated this part of the RFD. We don't store deleted volumes, we store only failed volumes, which should be a low number.

We could list only "active" volumes by default, that is volumes in state creating, deleting, ready or rolling_back (when snapshots are implemented). Thoughts?

from rfd.

I wonder though how discoverable this doc is. I always forget it's there.

Yah, it isn't. It might be linked to in some of our docs, but I'm not sure. jclulow has identified that it does need to find a better home.

I'm good with tags if this is more consistent with Triton. Can you confirm that?

https://apidocs.joyent.com/cloudapi/#ListMachineTags

We could list only "active" volumes by default, that is volumes in state creating, deleting, ready or rolling_back (when snapshots are implemented). Thoughts?

I think that might cause fewer surprises to users. E.g. "failed" ones are more likely to surprise client code written to handle the more common active volumes. Listing "failed" ones is, I would think, a less common action. Not like our APIs don't have pitfalls bigger than this tho. :)

from rfd.

I think that might cause fewer surprises to users. E.g. "failed" ones are more likely to surprise
client code written to handle the more common active volumes. Listing "failed" ones is, I would > think, a less common action. Not like our APIs don't have pitfalls bigger than this tho. :)

Just for the record, we agreed we didn't want to make work, and so this won't be changed before integration to master.

from rfd.

This RFD has been published and while additional feedback is welcome, this discussion issue is being closed. All changes necessary to implement the first milestone described in this RFD ("master-integration") have been integrated into the master branch of relevant code repositories.

from rfd.