Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
2. Scope of request
AWS::CloudFormation::Type - can create resource via API, but not via CloudFormation
3. Expected behavior
In Create, the RegisterType should be registered, and in Delete it should be unregistered. It seems that updates are not supported.
4. Suggest specific test cases
Just being able to do the same stuff as with the API / CLI.
5. Helpful Links to speed up research and evaluation
6. Category (required) - Will help with tagging and be easier to find by other users to +1
So the way we are thinking about this type is that you'd have a model something like below (represented as a CloudFormation template snippet);
I think that's the gist of the discussion I have had with @aygold92 so far.
After you invoke
I think I got it. So the DefaultVersion could point to a different (previous) version than the version that's provided in
What about skipping the DefaultVersion completely (in the
A few questions for @rjlohan about this.
Right now the Registry only supports the ability to (De)RegisterType, however we designed it intentionally to be as agnostic of CloudFormation (the service) as we could. Certainly there will be abstraction leaks, but we intend to separate concerns so that we have the ability to cleanly build out other capabilities in the future. I'm OK with modelling the current
For now, we have a rolling, immutable versioned history of the evolution of a
That would be a leaky abstraction. The Resource platform does not know anything about CloudFormation's stack-level concerns. (To be fair a couple of things leaked through, but again the intent was to design the Registry and the resource platform to be completely oblivious to CloudFormation the service.
Yeah this is the one bit I don't have a good canned answer on. Vote?
Yes, we'll have to model this correctly in the
I have some thoughts to add:
Types and Versions should be separate resources, because they have separate lifetimes:
Having to specify a Kind seems a bit strange too, I don't think I would mind having a different resource for each (future) kind. Assuming this is expected to be a limited list. I'm going to write the rest of this comment with Kind as a Property, but I think there is an argument to be made for making it a resource level distinction (similar to how API-GW has different resources for different kinds of APIs and ELB has ALB/NLB as different resources).
This could be a way to address versioning: