Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Per alias resourcing does not appear to work #49

Open
quot-zz opened this issue May 30, 2017 · 13 comments
Open

Per alias resourcing does not appear to work #49

quot-zz opened this issue May 30, 2017 · 13 comments

Comments

@quot-zz
Copy link

quot-zz commented May 30, 2017

Attempting to deploy a previously packaged serverless build that makes use of the example under Use with per alias resource heading in the README results in the error -

Template format error: Resource name myKinesis${self:provider.alias} is non alphanumeric.

Section in question:

 resources:
  Resources:
    myKinesis${self:provider.alias}:
	  Type: AWS::Kinesis::Stream
		Properties:
		  Name: my-kinesis-${self.provider.alias}
		  ShardCount: 1
@HyperBrain
Copy link
Member

Ok. I'll check. Maybe the provider variable git broken with another fix.

@HyperBrain HyperBrain added the bug label May 30, 2017
@HyperBrain HyperBrain added this to the 1.2.1 milestone May 30, 2017
@HyperBrain HyperBrain added this to TODO in Plugin May 30, 2017
@HyperBrain
Copy link
Member

I tested the behavior and committed a fix into a separate branch. The table name (and other properties) are now substituted correctly (e.g. TableName: ${self:provider.alias}.

Nevertheless the resource name (myKinesis${self:provider.alias}) does not get replaced correctly. This seems to be a bug (maybe missing feature) in the Serverless framework. IMO it would be correct if Serverless would apply the variable substitution not only to variable values, but also to resource names.
/cc @pmuens @eahefnawy

@HyperBrain HyperBrain moved this from TODO to In Progress in Plugin Jun 4, 2017
@eahefnawy
Copy link

@HyperBrain by resource names, you mean the logical IDs? That's interesting, but it's something that we've explicitly ignored for now. If you see a strong use case for that could you open an issue about it?

From the docs:

Note: You can only use variables in serverless.yml property values, not property keys. So you can't use variables to generate dynamic logical IDs in the custom resources section for example.Note: You can only use variables in serverless.yml property values, not property keys. So you can't use variables to generate dynamic logical IDs in the custom resources section for example.

@pmuens
Copy link

pmuens commented Jun 5, 2017

Yes, currently we don't have support to use variables in keys (as @eahefnawy mentioned).

Here's the issue where we track this feature: serverless/serverless#2892

Could be an interesting addition though!

@HyperBrain
Copy link
Member

HyperBrain commented Jun 5, 2017

@eahefnawy @pmuens The use case here is the creation of per-alias resources (defined by the user). This would automatically rename the logical resource ids to include the alias name (see my example in the README). This feature is very interesting for feature development, where one would add an per-alias resource, to make sure that every other developer would have it's own instance of the resource when he deploys to his alias. I will have a look at the feature issue in Serverless and check if I can do anything there.

@eahefnawy
Copy link

hmmm actually if I remember correctly we've ignored it because its not supported by the traverse module we were using back then, but now we ditched and might work out!

@HyperBrain
Copy link
Member

I merged the fix for the property values part. The issue will be kept open until the property based variable substitution has been added to the Serverless framework.
In the mean-time I will change the README and add a not that the example is currently not functional with a reference to this issue.

HyperBrain pushed a commit that referenced this issue Jun 6, 2017
@HyperBrain HyperBrain removed this from the 1.2.1 milestone Jun 7, 2017
@HyperBrain HyperBrain moved this from In Progress to TODO in Plugin Jun 7, 2017
@HyperBrain HyperBrain removed this from TODO in Plugin Jun 7, 2017
@pmuens
Copy link

pmuens commented Jun 7, 2017

I merged the fix for the property values part. The issue will be kept open until the property based variable substitution has been added to the Serverless framework.
In the mean-time I will change the README and add a not that the example is currently not functional with a reference to this issue.

Sounds good. Thanks for the update on this one @HyperBrain 👍

For everyone reading through this: The Framework issue can be found here.

@HyperBrain
Copy link
Member

An alternative here would be that we create a new configuration section in serverless.yml named aliasResources with the same layout as the resources property. The difference would be that all resources defined in there will be deployed per alias.

This would also allow to reference these resources in the same way as the standard CF resources (e.g. function event subscriptions, environment variables, etc.)

@mekwall
Copy link

mekwall commented Aug 2, 2019

Any ideas on how to best solve this? I'm trying to get this plugin to work with serverless-nextjs-plugin but getting resource id conflicts when I try to deploy a second alias.

@Enase
Copy link
Contributor

Enase commented Aug 5, 2019

You have two ways (as I know) to define per alias resources:

  1. You can have separate configurations (per alias). Use --config option, it's a new feature --config option serverless/serverless#6216
  2. Use serverless-plugin-ifelse plugin.

@mekwall
Copy link

mekwall commented Aug 5, 2019

@Enase Thanks, but some of the resources are generated by another plugin, so I don't have control over their resource ids.

@Enase
Copy link
Contributor

Enase commented Aug 7, 2019

all the plugins generate resources based on some parameters, you can manage it I believe

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants