packet: Use c3.small.x86 by default

[johananl]

General

t1.small.x86 machines are becoming EOL and are no longer available in new Packet projects. While c3.small.x86 is significantly larger (and more expensive) than t1.small.x86, it is currently the smallest and cheapest Packet device type in general availability.

Release notes

This change modifies the default machine type from t1.small.x86 to c3.small.x86 on Packet clusters. If you haven't explicitly defined the controller_type and/or worker_pool.node_type configuration options, upgrading to this release will replace your controller and/or worker nodes with c3.small.x86 machines. To avoid this, set these configuration options to the desired values.

[ipochi]

Thanks for the PR @johananl

Should we provide a link to the Packet documentation (https://www.packet.com/cloud/servers/c3-small/) regarding the pricing so that the user is aware of the costs they may incur ? I understand the difference in pricing between t1.small.x86 and c3.small.x86 is not trivial.

[johananl]

Thanks for the PR @johananl

Should we provide a link to the Packet documentation (https://www.packet.com/cloud/servers/c3-small/) regarding the pricing so that the user is aware of the costs they may incur ? I understand the difference in pricing between t1.small.x86 and c3.small.x86 is not trivial.

I've added a note with a link. Thanks.

[ipochi]

lgtm 🎉

[iaguis]

This seems to break existing clusters that didn't have a node type explicitly defined. Let's give it more thought.

Kudos to @ipochi for finding out. Awesome catch!

[ipochi]

Upgrade concern:

What happens in case of existing clusters where machine type is not provided and the previous default (t1.small.x86) is used. I assume the nodes will get deleted and cluster recreated.

In one scenario, the cluster was lost due to the Packet facility not having provisioning capacity for c3.small.x86 servers. Old nodes were deleted.

Breaks existing clusters where default machine type is used.

[invidian]

IMO this should be resolved the same way as #642 (comment).

[iaguis]

IMO this should be resolved the same way as #642 (comment).

I agree with this, we can update the default and mention something in the release notes about users needing to define their instance type explicitly if they were using the default.

What do others think? @surajssd @johananl @rata?

[rata]

@iaguis @invidian I strongly agree, a note in the changelog is enough IMHO and we should be able to change defaults (at least in these cases where the user can have the old setup working adding a line)

It should be loud and clear, though. Like a "changes required" section or something like that, so it is very visible in the changelog.

[iaguis]

Can we get this rebased?

And please provide a "Release Notes" text to be included in the next release.

Thanks!

[johananl]

Rebased and included release notes text in the description.

[iaguis]

Thanks! LGTM

I'd do s/This change changes/This changes/g but the idea is to help with releases so it doesn't have to be perfect :)

[johananl]

Thanks! LGTM

I'd do s/This change changes/This changes/g but the idea is to help with releases so it doesn't have to be perfect :)

This is a strange phrasing indeed. Not sure why I wrote it this way. Fixed :-)

[johananl]

@iaguis I'm going to merge this without a green ARM build. The build failed due to Packet capacity problems and the change doesn't affect ARM AFAICT.

[iaguis]

Sounds good.