Quantity has wrong `FromJSON` instance

[akshaymankar]

This causes something as simple as getting a pod to fail. Here is the definition of V1ResourceRequirements from the code.

data V1ResourceRequirements = V1ResourceRequirements
  { v1ResourceRequirementsLimits :: !(Maybe (Map.Map String Quantity)) -- ^ "limits" - Limits describes the maximum amount of compute resources allowed. More info: https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/
  , v1ResourceRequirementsRequests :: !(Maybe (Map.Map String Quantity)) -- ^ "requests" - Requests describes the minimum amount of compute resources required. If Requests is omitted for a container, it defaults to Limits if that is explicitly specified, otherwise to an implementation-defined value. More info: https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/
  } deriving (P.Show, P.Eq, P.Typeable)

-- | FromJSON V1ResourceRequirements
instance A.FromJSON V1ResourceRequirements where
  parseJSON = A.withObject "V1ResourceRequirements" $ \o ->
    V1ResourceRequirements
      <$> (o .:? "limits")
      <*> (o .:? "requests")

The requests and limits are defined in terms of Quantity. And here is the definition of Quantity:

newtype Quantity = Quantity { unQuantity :: Text }
  deriving (Show, Eq, ToJSON, FromJSON, Typeable, Generic)

The YAML I get from the server looks like this:

...
      resources:
        requests:
          cpu: 100m
...

When I try to parse it, I get this error:

"Error in $.requests.cpu: expected unary record, encountered Boolean"

If I try to parse 100m as Quantity, I get the same error. However if I decode {"unQuantity": "100m"}, I get the proper quantity. So, I think we need to just change the FromJSON instance of Quantity to just expect a string.

I also see that Quantity is defined in CustomTypes module. I was wondering if I can just send a PR by writing FromJSON by hand, or should this be an issue with either the openapi-generator or the open-api spec itself.

[guoshimin]

There is already a PR for it: #43

[akshaymankar]

Now that #43 is merged, I will close it.