Yeah I'm using `cloudAws.Service`.
# general
f
Yeah I'm using
cloudAws.Service
.
b
Yeah, doesn't look like we expose anything that would flow to it. https://github.com/pulumi/pulumi-cloud/blob/master/aws/service.ts#L742-L755 @lemon-spoon-91807 Do you know how we plan to expose the cloud specific options at this layer?
w
Yes - the
healthCheckGracePeriodSeconds
property is not yet exposed in the
cloud.Service
API. And in fact more generally, configuring health checks is not yet exposed through that API. This is part of https://github.com/pulumi/pulumi-cloud/issues/498, I'll add the note on
healthCheckGracePeriodSeconds
specifically. PRs definitely welcome here - but something we'll take a look at soon.
b
For context, this is about setting healthCheckGracePeriodSeconds on the service.
f
Is there a workaround for now? Like maybe a way to manually add a value to the service JSON before sending to ECS.
Hi. It appears the inability to set
healthCheckGracePeriodSeconds
is causing continuous task restarts. I am interested in investigating submitting a PR to add support for this. I write Clojure at my company, so it has been a long time since I have needed to dive into a TS project. Would one of you be able to provide some guidance as to where to look to start implementing this? Given Terraform supports this operation (https://www.terraform.io/docs/providers/aws/r/ecs_service.html#health_check_grace_period_seconds), I imagine the implementation must be somewhat straightforward. Thanks 🙂
l
Hey Kenny! Let me take a quick look
the primary issue is that cloud.Service is a cross platform API.
so any changes there need to be figured out for both AWS and Azure.
Let me investigate a bit, then i'll report back!
❤️ 1
f
I am actually using the cloud-aws
Service
. Is that also cross platform?
l
the cloud-aws Service is an implementatoin of cloud.Service
in general, we've kept these close. but it's potentially possible we could expose cloud-specific customization in a particular layer 🙂
f
Side note: I have seen your response on pulumi-docker #23 and have an item on my list to provide more info. Because that issue is more of an optimization and I have had higher priorities, I haven't been able to get to it yet.
l
no worries 🙂
ok. easiest way i can think to support this, for now, would be to just allow a config variable for this
because i don't know a clean way to actually add this as part of hte API
but you could then have a config variable we'll look for, and which will provide this value.
f
A config var would work!
l
note: our medium term plans here are that this sort of functionality would be exposed directly from a place like pulumi/aws.
f
As part of
Service
?
l
effectively, we'd have a similar API to pulumi/cloud, except that it would be more AWS specific, and would expose more of the AWS side o things
imagine instead of cloud.Service (which needs to work across aws/azre) you'd have something more like:
aws.ecs.AwesomeService
which would set all this stuff up like what we do in cloud (i.e. setting up the load balancers, task definitions, etc. etc.)
except it wouldn't be as abstracted away
f
Makes sense. How come that would be placed in pulumi/aws and not pulumi/cloud-aws?
l
so we could take all the args you might want to override for an AWS ecs service
well, "pulumi/cloud" is specifically about hte implementatoins of APIs that are intended to be cross-plat
so it kinda goes against that philosophy to them make it plat-specific
but we could do it there if ew changed our philosophy a bit 🙂
f
I see. I thought of pulumi/aws as all the low level constructs and pulumi/cloud-aws as abstractions over the lower level stuff.
l
gotcha!
we're changing that a bit currently
instead of being 'low level', it's more that it's: cloud-specific. so, if you're targetting AWS and want all the power of that, pulumi/aws is a good choice.
it's both the real resources you can create, as well as useful cloud-specific abstractions over those resources
as opposed to cloud-neutral abstractions
note: perhaps doing this at the pulumi/cloud-aws layer also makes sense 🙂
we'll definitely consider that, and thanks for sharing your perspective there!
f
Of course! So short term, what is involved in adding a config prop to set
healthCheckGracePeriodSeconds
?
l
in terms of a PR?
f
Yes
l
it would be really simple
i'm going to just check with Luke if this is ok, and then whip it up if so
👍 1
i'll see if he has other ideas on the best short term way to unblock you
f
Technically I unblock myself my going to the ECS UI and updating the service manually after running
pulumi update
. But that does not scale, requires my memory to not fail, and is pretty painful 😬
l
That's where we pullin our config values, which can then be used in the file
so we'd just add a new value for this, and read it at the appropriate point 🙂
from a code level, super simple
i just want to make sure i'm not going down a bad path.
f
Right. Let me know if there's anything I can do to help.
l
I'm wrong, you're right 🙂
1
so, we're going to go the route of fixing this up at the cloud-aws layer. i'm going to whip up a quick PR to unblock this. and it will also show the pattern of what we'd generally need to do if more configuration is needed.
so if you run into more stuff, you can also open PRs to unblock yourself
f
Sounds great!
l
f
Woah, that was fast. Super simple. So Pulumi knows to pull and set the value from that prop?
Oh I see. Line 756 is where you set it.
once this build is done the code will be available on npm 🙂
f
Awesome. Thank you so much for the speedy work!