> I don't think we should be documenting this like this, other than some
> examples perhaps.
>
> This is because clusters can and will have varying power types available
> - it's not a heterogeneous environment, especially during staged cluster
> upgrades.
>
> What I think we should do is implement an API function that returns
> available power types and each one's parameters based on the cluster and
> encourage API users to derive from that when editing/adding nodes.
An API call is probably needed indeed since some of the power types are registered dynamically.
But I still think it's worth documentation all the built-in power types. I'll change the introduction sentence to make it clear that those are the *built-in* power types and that others can be dynamically registered using clusters.
> I don't think we should be documenting this like this, other than some
> examples perhaps.
>
> This is because clusters can and will have varying power types available
> - it's not a heterogeneous environment, especially during staged cluster
> upgrades.
>
> What I think we should do is implement an API function that returns
> available power types and each one's parameters based on the cluster and
> encourage API users to derive from that when editing/adding nodes.
An API call is probably needed indeed since some of the power types are registered dynamically.
But I still think it's worth documentation all the built-in power types. I'll change the introduction sentence to make it clear that those are the *built-in* power types and that others can be dynamically registered using clusters.
What do you say?