Proposal: Rename disk_types.cloud_properties.type


Evan Farrar <evanfarrar@...>
 

That new error message is an excellent idea, as it addresses the specific
confusion I have witnessed and it leads the user to a resolution in fewer
steps than my proposal outlines.

On Thu, May 25, 2017 at 7:08 PM, Danny Berger <dberger(a)pivotal.io> wrote:

I agree this could be a bit confusing to both newcomers and others. I'm
not sure renaming the `disk_types.cloud_properties.type` is the correct
solution though. The values in `cloud_properties` should be values which
make sense and are native to the IaaS, so they'll all follow slightly
different conventions and should probably be more consistent to the IaaS
context than a BOSH context. VM types could have a similar discussion.

The persistent_disk_type/disk_types/disk_pool confusion should hopefully
pass with time as everyone consolidates on cloud-config-type manifests.

As a compromise to at least help give the user a better hint, I wonder if
director could say something like `Persistent disk "default" not found
(expected "small", "large", "large_gp2")`.

On Thu, May 18, 2017 at 12:12 PM, Evan Farrar <evanfarrar(a)gmail.com>
wrote:

After helping a BOSH Bootloader user today with deploying a BOSH release
I've realized that there is a small pain point in the BOSH cloud-config
schema that could be resolved.

I suggest we disambiguate the schema and terminology used within BOSH
regarding disk types. There are three closely related things that all
re-use the term “type”: persistent_disk_type, disk_types, and
disk_types.cloud_properties.type. This is a recent issue, because
previously disk_pool was renamed to disk_type to clarify the
relationship between persistent_disk_type and disk_pool.

Problem: A user receives an error message like “Persistent disk
“default” not found.” She must consult her cloud-config for an
acceptable disk type to substitute and may be led to believe that “S4” or
“gp2” would be an acceptable value when in fact the persistent_disk_type
field requires a value from disk_types.name.

Solution: Renaming disk_types.cloud_properties.type to
disk_types.cloud_properties.storage. I have based this on the
terminology used on IaaS pricing documentation, where most use the term
“volume type” or “volume storage” for this piece of information.

I'm curious what others think of this proposal. Please add comments and
suggestions on this document
<https://docs.google.com/document/d/1VpWLtVWOF38Y65WY7Zpqd2qLKYfzE4CkdlufsqbLBbA/edit?usp=sharing>[1]
or via mailing list.


[1] https://docs.google.com/document/d/1VpWLtVWOF38Y65WY7Zpqd2qL
KYfzE4CkdlufsqbLBbA/edit?usp=sharing


--
Danny Berger


Danny Berger
 

I agree this could be a bit confusing to both newcomers and others. I'm not
sure renaming the `disk_types.cloud_properties.type` is the correct
solution though. The values in `cloud_properties` should be values which
make sense and are native to the IaaS, so they'll all follow slightly
different conventions and should probably be more consistent to the IaaS
context than a BOSH context. VM types could have a similar discussion.

The persistent_disk_type/disk_types/disk_pool confusion should hopefully
pass with time as everyone consolidates on cloud-config-type manifests.

As a compromise to at least help give the user a better hint, I wonder if
director could say something like `Persistent disk "default" not found
(expected "small", "large", "large_gp2")`.

On Thu, May 18, 2017 at 12:12 PM, Evan Farrar <evanfarrar(a)gmail.com> wrote:

After helping a BOSH Bootloader user today with deploying a BOSH release
I've realized that there is a small pain point in the BOSH cloud-config
schema that could be resolved.

I suggest we disambiguate the schema and terminology used within BOSH
regarding disk types. There are three closely related things that all
re-use the term “type”: persistent_disk_type, disk_types, and
disk_types.cloud_properties.type. This is a recent issue, because
previously disk_pool was renamed to disk_type to clarify the relationship
between persistent_disk_type and disk_pool.

Problem: A user receives an error message like “Persistent disk “default”
not found.” She must consult her cloud-config for an acceptable disk type
to substitute and may be led to believe that “S4” or “gp2” would be an
acceptable value when in fact the persistent_disk_type field requires a
value from disk_types.name.

Solution: Renaming disk_types.cloud_properties.type to
disk_types.cloud_properties.storage. I have based this on the terminology
used on IaaS pricing documentation, where most use the term “volume type”
or “volume storage” for this piece of information.

I'm curious what others think of this proposal. Please add comments and
suggestions on this document
<https://docs.google.com/document/d/1VpWLtVWOF38Y65WY7Zpqd2qLKYfzE4CkdlufsqbLBbA/edit?usp=sharing>[1]
or via mailing list.


[1] https://docs.google.com/document/d/1VpWLtVWOF38Y65WY7Zpqd2qLKYfzE
4CkdlufsqbLBbA/edit?usp=sharing
--
Danny Berger


Evan Farrar <evanfarrar@...>
 

After helping a BOSH Bootloader user today with deploying a BOSH release
I've realized that there is a small pain point in the BOSH cloud-config
schema that could be resolved.

I suggest we disambiguate the schema and terminology used within BOSH
regarding disk types. There are three closely related things that all
re-use the term “type”: persistent_disk_type, disk_types, and
disk_types.cloud_properties.type. This is a recent issue, because
previously disk_pool was renamed to disk_type to clarify the relationship
between persistent_disk_type and disk_pool.

Problem: A user receives an error message like “Persistent disk “default”
not found.” She must consult her cloud-config for an acceptable disk type
to substitute and may be led to believe that “S4” or “gp2” would be an
acceptable value when in fact the persistent_disk_type field requires a
value from disk_types.name.

Solution: Renaming disk_types.cloud_properties.type to
disk_types.cloud_properties.storage. I have based this on the terminology
used on IaaS pricing documentation, where most use the term “volume type”
or “volume storage” for this piece of information.

I'm curious what others think of this proposal. Please add comments and
suggestions on this document
<https://docs.google.com/document/d/1VpWLtVWOF38Y65WY7Zpqd2qLKYfzE4CkdlufsqbLBbA/edit?usp=sharing>[1]
or via mailing list.


[1]
https://docs.google.com/document/d/1VpWLtVWOF38Y65WY7Zpqd2qLKYfzE4CkdlufsqbLBbA/edit?usp=sharing