-
Notifications
You must be signed in to change notification settings - Fork 428
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
chore(manifest): add from_tag for workload #3727
Conversation
8d63001
to
c04895a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Posting here as well for increase visibility. We were discussing offline how we can make adding the from_tags
option to other fields easier and here is our code specification proposal:
https://gist.github.com/efekarakus/5859927876e87528f14117cfbd779833
@@ -50,6 +50,17 @@ type Filter struct { | |||
Values []string | |||
} | |||
|
|||
// FilterForTags takes a key and optional values to construct an EC2 filter. | |||
func FilterForTags(key string, values ...string) Filter { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, this is a really clean function signature 👍 😍
c04895a
to
36a67d6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice work boss, looks good to me
@@ -44,6 +45,7 @@ type deployJobOpts struct { | |||
// cached variables | |||
targetApp *config.Application | |||
targetEnv *config.Environment | |||
envSess *session.Session |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😰 were we not using the correct session for job deploy this entire time>>>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it is actually used here
} | ||
|
||
// DynamicWorkloadManifest represents a dynamically populated workload manifest. | ||
type DynamicWorkloadManifest struct { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this makes so much sense as the next evolution of the manifest types
36a67d6
to
e0b4f40
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Late to the party but 😂 adding the comments just for your reference
case *yaml.TypeError: | ||
break | ||
default: | ||
var yamlTypeErr *yaml.TypeError |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
:+1_cat
@@ -333,7 +344,9 @@ func (c *EC2) subnets(filters ...Filter) ([]*ec2.Subnet, error) { | |||
} | |||
subnets = append(subnets, response.Subnets...) | |||
} | |||
|
|||
if len(subnets) == 0 { | |||
return nil, fmt.Errorf("cannot find any subnets") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
return nil, fmt.Errorf("cannot find any subnets") | |
return nil, errors.New("cannot find any subnets") |
err = envMft.Validate() | ||
require.NoError(t, err) | ||
content := envMft.Manifest() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you thing we also want to add the .Load
step to these local integration test? I feel like otherwise they wouldn't be testing the right thing because in real executions their output template would be one that has gone through .Load
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we add it it is not local anymore lol
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is not local only if it has subnet.from_tags
and not subnet.ids
right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Load
is supposed to load dynamic contents that requires API calls. If the test itself is supposed to be run locally then it doesn't make sense to me to add .Load
step 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like the only reason why these tests have all these Validate
, ApplyEnv
calls is because we didn't have a better way to mimic how cli
package would have manipulate the manifest, than to just hardcoding-ly repeating the codes in cli
. Without calling Load
, we are not effectively "mimicking" it.
Another way that I think about it is that I think these integration tests were meant to test that "given a manifest input, do I eventually get an expected template". Without calling Load
like cli
does, we can't be confident with our test result.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that's true. IMO we need to
- remove some of our existing integ tests because we have e2e tests now
- make current local integ tests to be integ tests because we can't generate expected template without making internet.
@@ -20,10 +20,11 @@ var defaultTransformers = []mergo.Transformers{ | |||
imageTransformer{}, | |||
buildArgsOrStringTransformer{}, | |||
aliasTransformer{}, | |||
stringSliceOrStringTransformer{}, | |||
StringSliceOrStringTransformer{}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this transformer need to be exported?
@@ -23,8 +23,8 @@ const ( | |||
|
|||
// Names for tag filters | |||
var ( | |||
tagFilterNameForApp = fmt.Sprintf(ec2.TagFilterName, deploy.AppTagKey) | |||
tagFilterNameForEnv = fmt.Sprintf(ec2.TagFilterName, deploy.EnvTagKey) | |||
FmtTagFilterForApp = fmt.Sprintf(ec2.FmtTagFilter, deploy.AppTagKey) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might be missing something - do they need to be exported?
// UnmarshalYAML overrides the default YAML unmarshaling logic for the StringSliceOrString | ||
// struct, allowing it to perform more complex unmarshaling behavior. | ||
// This method implements the yaml.Unmarshaler (v3) interface. | ||
func (s *StringSliceOrString) UnmarshalYAML(value *yaml.Node) error { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is essentially the same method as unmarshalYAMLToStringSliceOrString(s *StringSliceOrString, value *yaml.Node) error
. Maybe we can keep this one and remove that one. Then we can replace all
unmarshalYAMLToStringSliceOrString((*stringSliceOrString)(e), value)
to
(*stringSliceOrString)(e).UnmarshalYAML(value)
values := v.StringSlice | ||
if v.String != nil { | ||
values = []string{aws.StringValue(v.String)} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does
values := v.toStringSlice()
do what you want here?
} | ||
|
||
// Load populates the subnet's IDs field if the client is using tags. | ||
func (dyn *dynamicSubnets) load() error { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see this method is tested in the DynamicWorkload
's Load
's test. I think it makes sense. In the future, when we have more and more loader though, we probably would want to test each individual loader separately 💭
} | ||
|
||
type workloadManifest interface { | ||
Validate() error |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could this be an unexported function as well?
} | ||
opts.SubnetsType = subnetPlacementForTemplate[*placement.PlacementString] | ||
opts.AssignPublicIP = template.DisablePublicIP | ||
opts.SubnetsType = "" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tiny nit: is this line here just to be sure we aren't setting SubnetsType
? we could probably remove it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is actually to unset the subnet types since it is contradictory to subnetIDs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh lol didn't realize it was set to template.PublicSubnetsPlacement
by default. I feel like this function probably also needs some refactoring in the future 😂
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the Apache 2.0 License.
Also addresses fb from #3727 (review) By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the Apache 2.0 License.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the Apache 2.0 License.