Unable to define reusable custom types

[awalkermiller]

Issue Summary:

Unable to define reusable custom types or define servers with more than 6.5 GB of memory per core.

Cloud Provider(s):

GCE

Environment:

Spinnaker running in GKE built through Halyard.

Feature Area (if this issue is UI/UX related, please tag @spinnaker/ui-ux-team):

@spinnaker/ui-ux-team, GCE, clouddriver

Description:

Spinnaker provides the option to use custom types; however, there is no way to add a custom type. This prevents us from using instances that use extended memory.

Since GCE allows for the use of custom types, Spinnaker should reflect this.

You can specify the CPU and memory explicitly. However this is coded to limit it to 6.5GB of Memory per code. At this time, this is an arbitrary limit, as GCE doesn't have the same issue.
This can be seen by midifiying the JSON to use something more that 6.5GB and trying to deploy (screenshot below)

Steps to Reproduce:

Try to create a server with 4 CPU ad more than 26GB of Memory

Additional Details:

---

[spinnakerbot]

This issue hasn't been updated in 45 days, so we are tagging it as 'stale'. If you want to remove this label, comment:

@spinnakerbot remove-label stale

[cah-louis-verzi]

@spinnakerbot remove-label stale

[cah-louis-verzi]

This issue remains to be a problem.

[cah-lawrence-kaufman]

Please address this limitation.

[cah-lawrence-kaufman]

We are still awaiting a mechanism to be able to use extended memory.

[spinnakerbot]

This issue hasn't been updated in 45 days, so we are tagging it as 'stale'. If you want to remove this label, comment:

@spinnakerbot remove-label stale

[cah-lawrence-kaufman]

@spinnakerbot remove-label stale
We still need to be able to create custom machine types in our spinnaker pipelines.

[spinnakerbot]

This issue hasn't been updated in 45 days, so we are tagging it as 'stale'. If you want to remove this label, comment:

@spinnakerbot remove-label stale

[cah-lawrence-kaufman]

@spinnakerbot remove-label stale

[spinnakerbot]

This issue hasn't been updated in 45 days, so we are tagging it as 'stale'. If you want to remove this label, comment:

@spinnakerbot remove-label stale

[cah-lawrence-kaufman]

@spinnakerbot<https://github.com/spinnakerbot> remove-label stale Sent from my Verizon, Samsung Galaxy smartphone

…

-------- Original message -------- From: spinnakerbot <notifications@github.com> Date: 3/22/20 1:25 PM (GMT-05:00) To: spinnaker/spinnaker <spinnaker@noreply.github.com> Cc: "Kaufman, Lawrence" <lawrence.kaufman@cardinalhealth.com>, Manual <manual@noreply.github.com> Subject: Re: [spinnaker/spinnaker] Unable to define reusable custom types (#4773) External Email – Please use caution before opening attachments or clicking links This issue hasn't been updated in 45 days, so we are tagging it as 'stale'. If you want to remove this label, comment: @spinnakerbot<https://github.com/spinnakerbot> remove-label stale — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#4773 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AEEJP4FE55GVDLCKUWDBFTDRIZCZPANCNFSM4INX7LNQ>.

_________________________________________________ This message is for the designated recipient only and may contain privileged, proprietary or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. Dansk - Deutsch - Espanol - Francais - Italiano - Japanese - Nederlands - Norsk - Portuguese - Chinese Svenska: http://www.cardinalhealth.com/en/support/terms-and-conditions-english.html

[cah-lawrence-kaufman]

@spinnakerbot remove-label stale
We still need this.

[cah-lawrence-kaufman]

@spinnakerbot remove-label stale
We still need this.

[spinnakerbot]

"stale" has not been applied, and cannot be removed.

[cah-lawrence-kaufman]

@spinnakerbot remove-label stale
We still need this. Is there any update?

[spinnakerbot]

"stale" has not been applied, and cannot be removed.

[cah-lawrence-kaufman]

We still need this. Do you have any update?

[cah-lawrence-kaufman]

Still needed.

[spinnakerbot]

This issue hasn't been updated in 45 days, so we are tagging it as 'stale'. If you want to remove this label, comment:

@spinnakerbot remove-label stale

[spinnakerbot]

This issue hasn't been updated in 45 days, so we are tagging it as 'stale'. If you want to remove this label, comment:

@spinnakerbot remove-label stale

[spinnakerbot]

This issue is tagged as 'stale' and hasn't been updated in 45 days, so we are tagging it as 'to-be-closed'. It will be closed in 45 days unless updates are made. If you want to remove this label, comment:

@spinnakerbot remove-label to-be-closed

[siddhu-opsmx]

I have been looking at this issue and I tried to implement a solution

• As shown in above image if we checked the extended memory option, it will allow the user to select memory beyond 6.5 GB per CPU.

This is similar to what we see in GCE console.
Please share your feedback on this implementation .

[plumpy]

Looks like this is handled a little differently for E2 instances, which don't allow >16GB. Does this handle that case?

Perhaps Spinnaker shouldn't try to replicate the GCE Console's business logic, instead it should just let users put in whatever they want and rely on the GCE APIs to accept or reject it?

[cah-lawrence-kaufman]

@spinnakerbot remove-label to-be-closed

[cah-lawrence-kaufman]

@spinnakerbot remove-label stale

[cah-lawrence-kaufman]

The interface @siddhu-opsmx presented would work for me, but @plumpy has a valid concern about the complexity of reproducing the GCP business logic.

It looks like E2 doesn't have the extended memory "feature."
N2 allows up to 640GB with 2 vCPUs through 80 vCPUs with extended memory, 0.5GB/vCPU minimum, with CPUs in multples of 2.
N2D allows up to 768GB with 2vCPUs through 96 vCPUs extended, 0.5GB/vCPU minimum, with vCPUs in powers of 2.
N1 allows up to 624GB with 1vCPU through 96 vCPUs extended (minimum 0.9 G per vCPU rounded up to whole GB) and CPUs in multiples of 2

[siddhu-opsmx]

What if we do it like this ?
i.e on checking the extended memory option we will show the user a text field instead of the select option, which will let users put in whatever they want and the GCE APIs may accept or reject it?

[cah-lawrence-kaufman]

I'm a spinnaker novice. So as long as it is easy to see the GCP error message(s) when an invalid combination is selected, letting the users enter what they want it fine by me.

[plumpy]

Sure, that works.

[siddhu-opsmx]

I have documented the use case for such a scenario, it would be really helpful if you could provide some feedback on it.
Use Cases Doc

[siddhu-opsmx]

@plumpy @cah-lawrence-kaufman it would be really helpful if you could provide some feedback on above "use case doc". So based on feedback I will raised PR for the same.

[plumpy]

So if you check the box, the "Memory (Gb)" field changes from a drop-down to a text entry box? I guess that works for me. Thanks.

[cah-lawrence-kaufman]

@siddhu-opsmx I've looked at the "use case doc." I'm not expert in GCP. But with extended memory, I believe that there is a requirement that -ext should be appened to the custom machine type.

https://cloud.google.com/compute/docs/instances/creating-instance-with-custom-machine-type#add_extended_memory_during_instance_creation

So if the extended memory check box is checked, the -ext should be appended as well.

Sorry for the delayed response, I was on vacation, just back today.

[spinnakerbot]

This issue hasn't been updated in 45 days, so we are tagging it as 'stale'. If you want to remove this label, comment:

@spinnakerbot remove-label stale

[spinnakerbot]

This issue is tagged as 'stale' and hasn't been updated in 45 days, so we are tagging it as 'to-be-closed'. It will be closed in 45 days unless updates are made. If you want to remove this label, comment:

@spinnakerbot remove-label to-be-closed

[spinnakerbot]

This issue is tagged as 'to-be-closed' and hasn't been updated in 45 days, so we are closing it. You can always reopen this issue if needed.