Support configure resources #48
Conversation
clyang82
force-pushed
the
support_resources
branch
4 times, most recently
from
fdc217e
to
4c513c8
Compare
Signed-off-by: clyang82 <[email protected]>
clyang82
force-pushed
the
support_resources
branch
from
4c513c8
to
07d7a4b
Compare
There was a problem hiding this comment.
LGTM. However, I have long term concerns.
First of all these reviews are getting challenging. We need to define clear ownership of this component and what we would like to achieve. We need to build context and knowledge.
Second, jsonnet files for optional attributes are getting out of control. They are cumbersome and not easy to digest. We should come up with a better pattern.
And last we are getting reckless with the API, we just keep adding things to CRD. The existing API already seems archaic comparing our recent configuration. Moreover, we don't think about the future that we plan, we might need to rewrite the whole CRD to support other signals.
Adding my thoughts here to make them visible, these don't particularly concern things introduce in this PR.
|
Agree with @kakkoyun. We should find a way to define way forward that does not block experimentation but does not trash API CRD that suppose to serve some purpose |
|
cc @paulfantom |
Currently, merging to master triggers the tagged-master job, because it seems that CircleCI filters are ORed. This causes the Makefile to try to tag a docker container with a trailing `:` since the Git tag is emtpy. This commit changes the logic so that the tagged-master job is only triggered on a valid SemVer tag. Signed-off-by: Lucas Servén Marín <[email protected]>
Enable configure resources for each component.
Signed-off-by: clyang82 [email protected]