-
Notifications
You must be signed in to change notification settings - Fork 1
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
Run scenarios with CHC enabled #92
base: main
Are you sure you want to change the base?
Conversation
8c901de
to
9287afb
Compare
conductor-config-ci.yaml
Outdated
@@ -4,3 +4,4 @@ network: | |||
- type: webrtc | |||
signal_url: "ws://localhost:4423" | |||
bootstrap_service: "http://localhost:4422" | |||
# chc_url: "http://localhost:8181" |
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.
What are we going to do about needing different config for some scenarios?
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 think the embed_conductor_config
function might need to be refactored slightly, it should return a type rather than the yaml in the form of a string, so that values can be mutated by scenarios that need custom conductor config different from the one in the yaml files.
What do you think?
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'm not sure about the scenario modifying the config. We want to be able to run scenarios with different config. In this case that means we want to run with CHC on and off. We don't then want to be modifying the scenario code to run in different environments etc.
What would be really nice is if you could provide a conductor configuration "overlay". So the embed_conductor_config
would load a base configuration then at runtime you could configure which overlay to load. It might make sense to merge those as conductor configuration objects rather than yaml.
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.
Sorry I am late, got distracted with other work
I'm not sure about the scenario modifying the config. We want to be able to run scenarios with different config. In this case that means we want to run with CHC on and off. We don't then want to be modifying the scenario code to run in different environments etc.
I see what you mean, what would a good compromise be? perhaps having -chc
variants of the existing yaml configs, not the cleanest approach.
Or rather than reading from the conductor config files, we programmatically build the conductor configs from the scenario, with an env var i.e CHC_ENABLED
determining whether a chc_url
should be set.
I am open to discuss this further
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.
When I'm talking about overlays, I mean this kind concept -> https://carvel.dev/ytt/
Not necessarily that tool but something along those lines. So we could have a with-chc.yaml
and a with-dpki.yaml
that we can choose to load.
I think choosing to load that with an environment variable like CHC_ENABLED
is good. So the current macro can load all the config files and embed them. Then we can choose at runtime which ones we merge with the base conductor config.
I know that YAML merging is a bit of a pain in general but if it's purely additive for now, then it shouldn't be so bad I hope.
What do you think?
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, would the contents of the with-chc.yaml
and with-dpki.yaml
only contain the CHC and DPKI configurations?
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.
Exactly that, they'd just bring in the piece that they configure. So we might do other things the same way, like different tunings of the network or the conductor itself.
We probably couldn't easily guarantee that a given combination of overlays makes sense but I'm okay with leaving that up to the user for now
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.
Understood. The only question I have now is how to run scenarios with CHC enabled via trycp. I believe the holoports would need to have the reference implementation running?
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 think we need to deploy somewhere that the HoloPorts can see yes. We have a couple of servers but nowhere ideal really. I think this might need to be a question we ask to techops
set -x | ||
|
||
# start the CHC reference implementation service | ||
nix develop .#ci -c bash -c "hc-chc-service --port 8181 &" |
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 a section be added to the README on running the CHC service? There are a couple already that just give a recommended command for things like hc-run-local-services
or the sandbox. It would be useful to have these two steps documented where you start the service and ask the sandbox to use it
0c98a98
to
3fb149b
Compare
3fb149b
to
7e0f152
Compare
95e2067
to
2a25434
Compare
This PR addreses #69