Hive scripts and the cilium shell #35154
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
cbc0982 to
b361d0f
Compare
7adef17 to
6bedb3f
Compare
6bedb3f to
df77ad1
Compare
|
/test |
|
Here's some of the follow-ups on this that I have in mind:
|
learnitall
approved these changes
Oct 17, 2024
There was a problem hiding this comment.
Great idea! I'm excited about this. I read through the blog post and the rest of the links that you added and I'm on board with the vision. I have a couple of questions for you, but they may be more appropriate for discussion in slack:
- One of the core concepts that was mentioned in the blog post was the idea that these tests are able to be sandboxed and can be executed in parallel. Is this a goal for use with Cilium? If so, how will tests that rely on datapath state be implemented?
- What is the migration plan for existing tests, if any? Will this framework be expected as the primary method for testing hive cells, while other integration test frameworks that Cilium currently uses will be utilized for non-modularized code?
- IIUC the framework is not reliant on a kubernetes cluster, therefore coverage for integration with kubernetes or other external APIs is missing. Is this a future use case that the framework will handle? Or will this type of testing continue to be handled by existing integration testing code?
ovidiutirla
approved these changes
Oct 18, 2024
Yep,
None at the moment. This isn't (yet) trying to be the primary way of testing hive cells, but just one of the options for more complicated tests. I'd get some more experience first with this and then see where it makes sense to apply it or migrate to it.
My main reason for looking into test scripts was an integration test that inserted many k8s objects, so this is actually the primary use-case I had in mind. The code for this is coming right after this PR, e.g. commands for messing with the client-go's fake client to populate the object trackers. |
df77ad1 to
c8a3c51
Compare
|
/test |
e6ab120 to
8a338b9
Compare
|
/test |
8a338b9 to
30d0d68
Compare
|
/test |
Cilium shell is a new simpler way for implementing debugging abilities
for the cilium-agent based on a simple script language. The same scripting
language can also be used to implement complex integration tests. By sharing
the same language for debugging and testing it becomes easier to write complex
integration tests (as the commands become familiar from debugging) and it makes
sure our debugging commands are actually tested.
Commands can be added by any cell by calling cell.Provide with hive.NewScriptCmd:
var Cell = cell.Module(
...
cell.Provide(newScriptCommand),
)
func newScriptCommand(t *Thing) hive.ScriptCmdOut {
return hive.NewScriptCmd(
"thing",
script.Command(
script.CmdUsage{Summary: "Inspect the thing"},
func(s *script.State, args ...string) (script.WaitFunc, error) {
return func(*script.State) (stdout, stderr string, err error) {
stdout = fmt.Sprintf("Thing status: %s\n", t.Status())
return
}, nil
},
),
)
}
This can be now used in "cilium-dbg shell":
$ kubectl exec -it -n kube-system ds/cilium -- cilium-dbg shell
...
cilium> thing
[stdout]
Thing status: ...
The same command can be used in an integration test:
func TestThing(t *testing.T) {
ctx := context.Background()
log := hivetest.Logger(t)
h := hive.New(thing.Cell, <deps>...)
engine := &script.Engine{
Cmds: h.ScriptCommands(log),
}
require.NoError(t, h.Start(log, ctx), "Start")
t.Cleanup(func() {
assert.NoError(t, h.Stop(log, ctx), "Stop")
})
scripttest.Test(
t,
context.Background(),
func() *script.Engine { return engine },
[]string{},
"testdata/*.txtar",
)
}
An example test script "testdata/test.txtar" count now look something like:
thing
grep '^Thing status: OK$'
Signed-off-by: Jussi Maki <jussi@isovalent.com>
30d0d68 to
19ccb0a
Compare
|
/test |
tommyp1ckles
approved these changes
Oct 23, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Cilium shell is a new simpler way for implementing debugging abilities for the cilium-agent based on a simple command language. The same command language can also be used to implement complex integration tests. By sharing the same language for debugging and testing it becomes easier to write complex integration tests (as the commands become familiar from debugging) and it makes sure our debugging commands are also tested. The simple way of adding commands (compared to editing openapi.yaml and modifying cilium-dbg) also significantly lowers the barrier for adding debug tooling and also as an added bonus reduces the maintenance overhead of Cilium derivatives.
See the "asciinema" links at the bottom for demos!
Commands can be added by any cell by calling cell.Provide with hive.NewScriptCmd:
This can be now used in "cilium-dbg shell":
The same command can be used in an integration test:
An example test script "testdata/test.txtar" could now look something like:
More information about this can be found from: