Possibility to define Service name

[ayozemr]

Actually I see that Service name is calculated with application + target.name, so if I want to use this tool I have to remake my clusters and services to match this naming protocol? Would be reasonable to be able to specify service_name the same way I specify cluster, so I can tell the app "Deploy the new version of the service X on cluster Y"

Maybe I have understood something wrong.

Thanks for your time!

[camertron]

Hey @ayozemr, apologies for not responding in a timely manner. Yes, broadside asks that you use the application + target.name convention, but as I recall that was an arbitrary choice on our part and not an ECS requirement. It is absolutely reasonable to be able to provide a custom service name that doesn't hold with the convention, and we'd welcome a pull request to that effect.

[slpsys]

@ayozemr to back up @camertron, I think we'd definitely be OK with this change. Internally, we're moving many things from ECS to self-managed Kubernetes, and it's unclear how much of a role Broadside will play in that ecosystem. We have a number of applications under active development whose only deploy environment is ECS via Broadside, but this isn't a particular feature we've needed in the past (though I agree, this would be especially useful for e.g. staging vs. production).

We'd definitely welcome a patch via Pull Request, and would be happy to review.

[ayozemr]

Hello! Thanks for your time. I will check it with my team, but we work with Python and JS and we may do a bad job with Ruby :-(

If we finally code it, I will tell you for review :-)

Thanks again and good job with the tool.

[slpsys]

👍

[apurvis]

just a bit of background - the main reason the service naming works like this is to ensure that services (and task definitions) are easily recognizable by their naming, and you don't have to juggle a bunch of different configurations that are not obviously linked to each other (which often happens when developers are lazy about naming their stuff consistently).

so to answer the original question, yes, you are encouraged to hand over the naming of your services and task definitions to broadside. while it is probably annoying to transition over the naming the first time, i suspect it will save you a fair amount of headache in the medium to long term.

though I agree, this would be especially useful for e.g. staging vs. production

@slpsys this is why you can have different targets for staging and production... if you name your target staging_web then the service and task definition names will reflect that.

[slpsys]

Yeah, I'll be honest, I hadn't really looked back on the code when I wrote that, and the last time I did it was before a refactor--it's not as trivial as I'd assumed it'd be based on the request.

[apurvis]

if I want to use this tool I have to remake my clusters and services to match this naming protocol?

@ayozemr you shouldn't have to remake any clusters... it's just services (and task definitions) that broadside controls the naming of.