#Dagger talk q's
1 messages · Page 1 of 1 (latest)
Found this deck floating around on here: https://docs.google.com/presentation/d/1VUPTvajY-RXlByUA9hyybDve5slVvqGCGDBbwpfciM4/edit#slide=id.g2d1b97cf0e2_0_83. Is this for public consumption? Looks to be - could I use this as an intro before moving into a demonstration? It's far better than any slides I could produce.
Yeah absolutely please feel free to use this deck - and it would also be great to hear any feedback if you think anythign is missing. cc @digital shoal
The core of the talk is likely to be a practical example of Dagger in use, so local + gitlab (demonstrating the ease of execution, and provisioning), modules/functions (demonstrating ease of distribution), and module composition (extensibility and application of dagger). Is there anything in particular that Dagger would like to be a talking point in such a demonstration?
modules/functions (demonstrating ease of distribution)
I think it would be great to highlight the cross language capabilities. i.e. you can write a module in go and consume it in python and vice versa.
I plan to skate over details on the engine (basically introduce that it's an OCI compliant container, you can provision it with docker but that docker is not necessary once it's provisioned) and move on. Whilst it will be a technical audience I don't want/plan to get into any more technical detail than that.
I also plan to briefly touch on cloud at the end of the talk, specifically to answer the question "how do I scale this". Dagger engine instances in an autoscaling group works out of the box, but you're clearly going to lose the cache as you're assigned across instances. Dagger cloud resolves that, with a side bonus of basically turning your laptop into a runner because you can access the cache there too
I did consider talking about multi-language, but the teams I've talked/demonstrated Dagger with so far really only see the benefit of using one language to reduce cognitive demand, so the multi-language really only matters when demonstrating extensibility from the Daggerverse. I'll make a point to show that.
That is fair, I think one place where this really shines is when you gave a great library that is only available in one language. For example a bunch of the data science libraries in python.
Wrapping that in a module makes it available to consumers in other languages without needing to reimplement the library.
Very true, though not something I expect I/we will encounter much if at all. Does strengthen the multi-lang argument though, I'll add that to my notes
I think in larger teams there is often people who want to do things their way, Instead of forcing them down a specific pathway, Dagger provides the best of both worlds by allowing people to choose their own language but still giving this standard interface. Today we support Go, Python, Typescript, but we aim to support any typed (or at least somethign with type hints) language so this concept will be even more powerful in the future.
I can see that being the case yep, I'm just at the opposite end of the scale where each new language a team might use adds more supporting software, more updating, more maintenance, more documentation etc, so the fewer the better in most cases
I'll definitely highlight the multi-language capability, but I probably won't actually demonstrate it beyond extending say a Go module from Python
I have used https://github.com/jpadams/daggerverse/tree/main/infisical as part of a demonstration in the past (contrived demo of modules as dependencies of other modules). Any chance this'll be updated @sharp jetty?
(If not it's Apache 2.0 so I'm happy to copy and update it)
Happy to coordinate with you on that @versed reef
Is there a way to see cache hits/misses in the traces view?
They show requests, but not responses? E.g. cache request: pull docker.io/checkmarx/kics:latest
@cobalt oyster 👆
yeah these are kind of funny looking, known issue; buildkit emits that, we'd like to tidy it up and show proper cache hits, but haven't prioritized it yet
Any estimate on that work starting?
Not at the moment sorry - parts of it might be easy enough, but we've got a lot of competing priorities. We're currently focusing on better navigation (grouping traces by PR/commit, local vs. CI, etc), browsing by function calls, and function analytics (showing perf over time for function calls)
All useful enough, sounds good 🙂
@versed reef is there a need to update to Infisical's machine identities?
Not for this, no. I'm only using that Infisical module to demonstrate a module as a dependency of another module, and only running it locally
Ah, okay, so do I just need some more basic maintenance 😄
Taking a look
Engine upgrade I think, yep
Looking forward to hearing how it goes @versed reef ! Once you have the link, let me know and I'll be happy to promote it.
Just in talks with venues at the moment so none of this is concrete yet. Organiser has an initial venue + date (Wednesday 19th June) and initial sponsorship stuff approved (materials, funds), think there's another source of funds potentially available (from TechNExt themselves), just waiting on an update for that.
Here is a great resource from @viral harbor too. It is a recording of one of his latest Dagger talks - https://www.youtube.com/watch?v=J8QHxuhDNMM
You've just perfected CI and/or CD for your organization, again. It was a huge, frustrating effort, and learning another proprietary DSL or YAML didn't deliver the promised tenfold increase in release frequency. It wasn't the first re-platform and it won’t be the last. Now that things have calmed down, there must be a way to prepare, to future-p...