feat(compose/agent): add stack.agent.ports option in config.yml to publish ports for agent#1793
Conversation
pkoutsovasilis
changed the title
pkoutsovasilis
force-pushed
the
pkoutsovasilis/add_agent_publish_ports
branch
from
69a9fd5 to
3e061e8
Compare
…blish ports for agent
pkoutsovasilis
force-pushed
the
pkoutsovasilis/add_agent_publish_ports
branch
from
3e061e8 to
d92388d
Compare
|
I wonder if #1795 supersedes this one. @pkoutsovasilis is there any use case that would not be covered by defining the ports in the system test cases? |
hmmm interesting 🤔 the answer is yes when you are developing a new integration or testing something about an existing one. Sure this should end up in a system test but before you have a test you have to do certain manual steps to get there. Also, since this PR is now open for 6 days, if you needed support for custom agents deployments as this #1795 (2 days ago) does, wouldn't make sense to ask for it here than open a complete different PR? |
Makes sense. This is probably also useful in cases where the stack is used for manual testing.
Well, they likely come from two different needings, we probably need both approaches. The one here for manual tests, and the other one for testing and CI in the new custom agents. |
and for manual testing/development sometimes we need also custom volume mounts 😄 e.g. for this one we need this |
internal/profile/profile.go
Outdated
|
|
||
| // Path returns an absolute path to the given file | ||
| func (profile Profile) Path(names ...string) string { | ||
| func (profile *Profile) Path(names ...string) string { |
There was a problem hiding this comment.
Nit. Are these changed to pointer needed?
There was a problem hiding this comment.
so here it depends, it is considered an unusual pattern to have a struct definition that mixes both value and pointer receivers, and from a quick look at the code, profile is widely used as a pointer. Thus I homogenise the struct by making these pointer receivers but if there is a reason behind this divergence happy revert this change
There was a problem hiding this comment.
Good point. I think I would rather use the profile by value, but it is true that it is mostly used as pointer now, so as you prefer.
the more I look the agentdeployer the more it makes sense to me expose this through cli and someone be able to deploy "custom" agents in the stack and focus any extendability effort there, @jsoriano what do you think? |
pkoutsovasilis
force-pushed
the
pkoutsovasilis/add_agent_publish_ports
branch
from
1cf2b61 to
bc55f5d
Compare
internal/profile/profile.go
Outdated
|
|
||
| // Path returns an absolute path to the given file | ||
| func (profile Profile) Path(names ...string) string { | ||
| func (profile *Profile) Path(names ...string) string { |
There was a problem hiding this comment.
Good point. I think I would rather use the profile by value, but it is true that it is mostly used as pointer now, so as you prefer.
Yeah, I see the agent deployer as the future to deploy any kind of agents. There is still some work to do in this area though, @mrodm is now working on this. In any case we have to keep in mind that the purpose of |
…ports # Conflicts: # internal/stack/_static/docker-compose-stack.yml.tmpl
💔 Build Failed
Failed CI StepsHistory
|
|
/test |
3 participants
This PR introduces support for defining inside
config.ymlof the profile ports for agent service to be publishedconfig.yml#1262