Closed svenefftinge closed 1 year ago
What about the storage for /workspace
? Is it limited to 5 GB (like in Google Cloud Shell for /home/<your-gmail-username-over-here-probably>
)?
How would this affect users with unleashed/unlimited plans?
What about the storage for
/workspace
? Is it limited to 5 GB (like in Google Cloud Shell for/home/<your-gmail-username-over-here-probably>
)?
I believe they allow 30 gb to persist in that directory and the allowed space in a running workspace might be higher but will be deleted when the workspace stops.
We should generalise a tad and move to "workspace classes"
@csweichel that last link is not accessible to the public
We won't be able to offer unlimited hours with this, so need to think about changes to our plans that are more usage-based than seat-based.
Currently, in the Personal
plan, we get unlimited hours of usage and we can run up to 8 parallel workspaces. So currently, a user who has purchased the Personal
plan gets 24 * 30 * 8 = 5760
hours technically. Now, if the plans get changed to be usage-based, then will a user get 5780 / 4 = 1440
hours if they enable 4X mode?
IMHO, the current pricing strategy is the biggest draw for Gitpod over something like Codespaces. I know that Gitpod also offers a host of other features including integration with Jetbrains (extremely useful), but the ability to just use Gitpod without worrying about how many hours I am using is so amazing for me as someone using it for personal projects, school, and contributing to open-source projects.
I would suggest something like the following: highest tier plan: unlimited hours on S and then x flexible hours per month to use towards more powerful instances following the pricing in the original post and if someone needs more flexible hours, they can purchase more.
Currently, in the Personal plan, we get unlimited hours of usage and we can run up to 8 parallel workspaces. So currently, a user who has purchased the Personal plan gets 24 30 8 = 5760 hours technically. Now, if the plans get changed to be usage-based, then will a user get 5780 / 4 = 1440 hours if they enable 4X mode?
We are going to fade out the existing plans. That means new users cannot subscribe to personal or unlimited plans anymore. Users who are today on such a plan cannot use different workspace sizes. If you want to use them and you are on a personal plan you'll need to switch to the new usage-based plan, that we are going release together with this epic.
Regarding taxonomy:
There has been an ongoing discussion regarding how to name what we have been calling "workspace classes" or "workspace sizes". Multiple options were explored:
For simplicity, and since sizes didn't "stick", I propose we use "workspace classes".
My only concern is that it may not be very intuitive for SaaS users. If when collecting feedback or after launching we figure out that is the case, we can change the copy in our website while keeping the underlying technical mechanism named as "workspace classes".
Posting some early design specs for future reference. Cc @Furisto @atduarte
v1 | v2 |
---|---|
![]() |
![]() |
Let me know if this is off-topic and we can discuss it elsewhere! I love the work done in those screenshots @gtsiolis - looks great!
Was there a reason we decided on two workspace classes? How come not 3? I ask because in v1 I see 3 dots so that's what got me thinking.
Hey @jimmybrancaccio, thanks for the feedback! 🙏
Was there a reason we decided on two workspace classes? How come not 3? I ask because in v1 I see 3 dots so that's what got me thinking.
The MVC starting point for this feature includes two workspace classes as described in the epic description and other internal documents[1][2][...]. See also relevant discussion (internal).
"Standard" confuses me a bit. How about using those labels to provide a bit more info about what the shorter ones mean?
About that, I find "XL / HIGH MEMORY" clearer than "M2 / LARGE", and I'd like to see something different from "SM / STANDARD" for the other couple.
Maybe along the lines of "SM / BASELINE SPECS" or "SM / BASELINE".
Was there a reason we decided on two workspace classes?
@jimmybrancaccio because we already have 2 workspace classes in production but one (the Large) is only available to a small fraction of the users.
@Furisto Could you please include the updates to the Large and Standard limits, as well as their relation to the release, to the plan?
Changing status to in-validation, as we're testing internally and socializing early access, and will use as feedback to plan GA. cc: @atduarte
@atduarte as this is successfully in early preview now, can we move to done?
When working on Rust, 50GB might not be enough for large projects such as arrow-datafusion
Summary
Provide users with the ability to select between two different workspace classes for all their workspaces. On SaaS, the options are:
⚠️ Note that because of the storage size differences, a XL workspace can't be restarted as Standard, and neither can a Standard workspace be started from an XL prebuild.
Context
Different projects require different resources. To allow developers to fully leverage the power and scalability of the cloud, we want to allow for different workspace classes.
Internal Signal
Value
Users will have access to better performance, that supports heavier workloads.
Acceptance Criteria
excludeFromMoreResources
as they do today.Measurement
Growth Area
Expansion.
Persona(s)
Users that have heavier workloads.
Out of Scope
See https://github.com/gitpod-io/gitpod/issues/10805 to check what will follow.
Tasks