| kata-irc-bot | <liuj97> With great help from @james.o.hunt @dgibson, we eventually got the `safe-path` rust library crate get merged (https://github.com/kata-containers/kata-containers/pull/3462). My sincere thanks to @james.o.hunt and @dgibson | 04:29 |
|---|---|---|
| kata-irc-bot | <liuj97> I plan to publish the `safe-path` crate to crates.io, so other projects could consume this library crate. Any process to publish crate from kata github org? | 04:30 |
| kata-irc-bot | <bergwolf> We don't have a guideline for publishing new crates. One thing on top of my head is that we could ensure that more folks are able to operation on the published crates rather than just the first publisher. What do others think? | 06:40 |
| kata-irc-bot | <fidencio> @pmores ahoj! :slightly_smiling_face: About "Drop in cfg files support" (https://github.com/kata-containers/kata-containers/pull/4109) ... :thread: | 12:34 |
| kata-irc-bot | <fidencio> I will take some time at the next week to carefully take a look at the PR, but let me say a huge thanks for working on that. This is something I wanted for a reasonable amount of time. | 12:35 |
| kata-irc-bot | <fidencio> Now, a few things to have in mind, and here I am mostly looking for ideas, rather than pointing you into a specific direction of what should or should not be done, okay? | 12:36 |
| kata-irc-bot | <fidencio> 1. We may need changes on kata-deploy's script to accommodate drop-in config files, as we may want to preserve, or not, the drop-in configuration dir. 2. It'd be very nice if we could log (Info level) that we're using drop-in configuration files, maybe even let the user know which configuration comes from each drop-in file. It can save a lot of time on debugging issues, and that's something I've already suggested to do on the CRI-O | 12:39 |
| kata-irc-bot | side as well. | 12:39 |
| kata-irc-bot | <fidencio> I really would like to hear @eric.ernst's feedback on this one as, AFAIR, he was part of the group that was looking forward for those changes. | 12:40 |
| kata-irc-bot | <pmores> Ahoj Fabiano! :slightly_smiling_face: As for 1., I think this is really more related to kata-deploy than to the drop-in mechanism that I'm proposing but as I said in the PR discussion, I'd consider how kata-deploy currently treats `configuration.toml` local modifications - does it preserve them or reset them? In my view, drop-ins are just a more automation-friendly way of local changes to the file. So drop-in handling should be no | 12:49 |
| kata-irc-bot | different from other ways of local modifications, like changing `configuration.toml` directly. | 12:49 |
| kata-irc-bot | <fidencio> And I agree, but there's a need to double-check the behaviour there and make it act accordingly, if needed. | 12:50 |
| kata-irc-bot | <pmores> As for 2. I'm very much in favour of that. I've had code in my prototype version that basically dumped the `tomlConfig`s (as JSON for pretty-printing) into log. Well that may be a bit excessive but if we can figure out how exactly those log messages should look I'll be very sure to add them. | 12:52 |
| kata-irc-bot | <fidencio> Perfect. I will take some time next week and give that PR the attention it deserves. Again, thanks for working on that. | 12:53 |
| kata-irc-bot | <pmores> I can also log the array of TOML keys that each drop-in changed - this is easy to get from BurntSushi. | 12:53 |
| kata-irc-bot | <fidencio> I'm dense, you know that, I'd need to see that in the logs to figure out how excessive it is. Maybe on info print that we're using drop-in cfg files, and then on Debug print the array of TOML keys that each file changed would be a reasonable take. | 12:55 |
| kata-irc-bot | <fidencio> It wouldn't be too intrusive, and when on debug mode it'd be very much what everyone needs to debug an issue. | 12:55 |
| kata-irc-bot | <fidencio> WDYT? | 12:55 |
| kata-irc-bot | <pmores> Logging just changed keys should be pretty light-weight - well unless you stuff you whole configuration into a drop-in! :slightly_smiling_face: - and can look like the following: ```keys changed by config.d/40-rollback_all.toml: [hypervisor.qemu hypervisor.qemu.confidential_guest agent.kata agent.kata.enable_tracing runtime runtime.enable_tracing]``` | 13:00 |
| kata-irc-bot | <pmores> The whole pretty-printed `tomlConfig` is a different story - it's almost 200 lines of JSON. OTOH it's comprehensive and easy to read. | 13:03 |
| kata-irc-bot | <fidencio> Ack, I will think about those options carefully. | 13:03 |
| kata-irc-bot | <pmores> If you'd like to _see_ the tomlConfig-as-JSON option just let me know, I can easily produce it. | 13:16 |
| kata-irc-bot | <fidencio> Send it here them (maybe as a github gist?) so we can easily check it later on | 13:16 |
| kata-irc-bot | <pmores> Here you are - it's actually not _that_ bad, just over 120 lines. I was looking previously at a testing configuration that configured two hypervisors and was thus much bigger - but that's not something that happens a lot in practice I'd assume... | 13:22 |
| kata-irc-bot | <raravena80> ICYDK. A different take on confidential computing: https://enarx.dev/ | 14:55 |
| kata-irc-bot | <gkurz> @fidencio Hey ! Is there a fast path for trivial fixes or do we still need to create an issue for them ? | 15:57 |
| kata-irc-bot | <fidencio> Still open an issue for that. | 16:04 |
| kata-irc-bot | <fidencio> To stop requiring that someone has to work in the scripts and bla bla bla | 16:05 |
| kata-irc-bot | <gkurz> fair enough | 16:06 |
| kata-irc-bot | <gkurz> @fidencio I'll do that later when I'm done with my current work then ;) | 16:07 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!