<mort___>
if anyone has last minute items, please add now
<mort___>
…and if anyone feels disposed towards creating some edited minutes, please do! The Community will Thank You! :)
avsm has joined #mirage
<mort___>
do we do canopy bot currently? if so, could appropriate runes be invoked 'cos i am lame and don't know them
<avsm>
nope, whitequark's logs are the new canopy for now :)
<dstolfa>
I have an idea I'd like to share, and am kind of curious of the general interest in Mirage for that, but it's low priority so you can take the floor, and when you're done, or in some off-time I can lay it out :)
<mato>
canopy bot has been MIA for some time now :-(
<avsm>
dstolfa: awesome!
<mort___>
dstolfa: yup! added to the end of the agenda
<mort___>
mato: aww! :(
<mort___>
everyone- right, let's start
<mort___>
first up: project updates, solo5 refactor (arm? muenSK?)
<avsm>
wow, does the ARM64 solo5 port build if we pin some PRs? or does it need associated ocaml-freestanding work on the libm etc?
<mato>
Solo5 builds. Mirage/Solo5 does not, that needs some ocaml-freestanding work (not much)
<mort___>
naively pattern matching against gh ids, kensan — anything to add re muenSK?
<avsm>
mato: nice!
<avsm>
also, what are the chances of getting meunSK into automated CI?
<mato>
Re specc'ing the APIs, I will file an issue/PR on Github for this and also a thread on the mirage list. I'm kind of surprised the current mirage-solo5 bindings work at all :)
<avsm>
most things never hit the corner cases :-)
<mato>
avsm: The Solo5 part of it is already in CI.
<kensan>
mort___: Just happy, that the port got merged so smoothly :) What is missing is automated testing as the other platforms (virtio/ukvm).
<avsm>
kensan: yeah im wondering how we might deploy an e2e test -- are there other examples of meun apps being tested?
<kensan>
avsm: For that I need to build/setup a docker container for building Muen and running it on the Bochs emulator.
<kensan>
avsm: Its certainly doable and we want a nice docker setup for upstream too as it provides an easy way to a stable build environment.
<mato>
kensan: Given that the bochs emulation is so insanely slow, if there's a chance of getting Muen to boot on new Linux kernels under nested KVM that would be worth getting to work.
<kensan>
avsm: The dependencies for Muen are a bit involved.
<kensan>
mato: Yeah, we experimented a bit and Muen started up and was running but there are some issues with nested virtualization.
<mato>
(aside/FYI) I will be in Zurich for a short trip end of next week, and will be visiting kensan
<kensan>
mato: Will have to give it another shot with the latest Linux kernel/KVM combo.
<mort___>
ok— is that all on the solo5 refactor?
<kensan>
avsm: Can you be more specific re: other examples of Muen apps
<mato>
kensan: avsm: I think we can take this OOB to #solo5 slack or elsewhere, so as to not hold up the agenda?
<kensan>
avsm: Due to limitations of Bochs everything that needs hardware and acurate time/passing time cannot currently be tested. Maybe this is possible via nested virtualization with KVM.
<avsm>
oh i was just wondering what we had to do to setup a runtime of Muen -- ive never done it before
<avsm>
can it take it OOB also
<kensan>
mato: Ok, sure.
<mort___>
ok— muenSK / solo5 being taken offline, solo5/ARM64 work considered to be progressing well
<avsm>
mato: there's one overriding reason to use jbuilder -- you can just git clone multiple repos and `jbuilder build` and `jbuilder runtest` them without mucking around with opam pins
<mort___>
djs55: thanks
<avsm>
I am tantalisingly close to getting a full build with this opam-free setup; just a few more ports to do (including mirage/mirage which I can have a PR almost ready for)
<mort___>
yomimono: ah, sorry
<thomasga>
@djs55 @mort___: I have some notes to add to that wiki page, my plan is to find some time to push them before the end of the week
<mort___>
thomasga: excellent :)
<djs55>
there has been a little bit of breakage here and there because of the findlib -> top-level opam split. The actual jbuilder-ification is fairly simple
<thomasga>
yea, jbuilder has found quite a bit of linking issues so far
<thomasga>
I guess it's good
<thomasga>
(linking issues which were existing before but never exploded … yet)
<djs55>
that's true — some things suddenly failed because they didn't declare `lwt.unix` as a dependency I think
<avsm>
yeah i am finding a few weird inconsistencies in almost every port i do
<djs55>
and certainly linking all the PPX code into unikernels wasn't intended :)
<avsm>
mato: i'll take a look at porting the solo5 repos next week probably
<avsm>
is the issue with linking ppx into unikernels fixed now?
* mort___
idly muses whether we can claim changing the build system made unikernels smaller
<avsm>
mort___: it does, since this also sets us up nicely for the LTO compiler variant. it really benefits from finer dependency control
<mort___>
ok— sounds like jbuilder-ification is well underway and generally seems to be a good thing. anything more to say on that?
<avsm>
and jbuilder passes in fewer archives to the compiler since it splits things up into more subdirs
<mort___>
avsm: well, i suppose we always claimed that the smarts was in the build process… :)
<Drup>
(when do we change the mirage tool's generated build system again ? :p)
<mort___>
just to be clear— has anyone yet come across a reason that applying jbuilder is *not* the right thing to do?
<avsm>
indeed :-)
<avsm>
drup: not a huge amount needs to change there, just generating a jbuild file alongside the opam file
<avsm>
no blockers to jbuilder for me yet. not tried mirage-xen yet, but mirage-clock and its stubs seem to work
<avsm>
the Configurator system is also a lot simpler than the old myocamlbuild.ml files
<djs55>
I've found jbuilder very easy to use and it seems to cover all the usual cases AFAICT
<mort___>
djs55 avsm: ok. i'll assume silence means there are no others either. excellent!
<thomasga>
mort___: also on the jbuiler front, integration with `topkg doc` is now working so `topkg publish` will also work and push docs on github-pages
<thomasga>
(the only remaining issue is lack of top-level index)
<talex5>
I'm currently testing interop with Python, and that seems to work too.
<mort___>
(thomasga: great; i guess this might be mentioned in your update to the wiki page djs55 pointed at?)
<talex5>
But the code is full of TODOs, so be careful!
<thomasga>
(yes)
<thomasga>
@talex5: can I use capnp in a unikernel?
<talex5>
Maybe. If core_kernel works there.
<thomasga>
e.g. any unix dependencies?
<talex5>
I hope to remove that at some point.
<mort___>
talex5: cool
<talex5>
You'll need to stop using Lwt_io for the messages, but that's easy.
<mort___>
looking at readme, `—http /tmp/http.sock` suggests maybe not?
<thomasga>
that would be great :-) I think Base is supposed to work better than Core_kernel without unix and on js
<avsm>
to add a little background to capnp: the author has created a new https://github.com/capnproto organisation for all languages to go into, and ocaml is there now thanks to talex5 and the original author
<thomasga>
yes, I guess we need to sort out how to pass channels to unikernels too
<thomasga>
but that's an other discussion
<avsm>
so there's more of a community of implementations there -- and a unikernel backend is just one option as it can be used via Lwt too
<talex5>
This is all hugely hacked up for today's demo. Next week I'll start removing the hacks...
<mort___>
thomasga: a discussion for another day i think?
<mort___>
talex5: heh, cool :)
<mort___>
ok— anything else on capnp?
<talex5>
Nope.
<mort___>
else, next up: irmin and the rest api. thomasga i presume?
<mort___>
(talex5: great, good look for demo :)
<mort___>
*luck
<Drup>
Completely orthogonal question: does the ocaml capnp lib handles reading only partial parts of the serialized data structure ?
<avsm>
also havent had much feedback on them, but we are continuing to publish datakit weekly dev reports as they asre useful for us -- they are in the reports/ directory of the repo and cover irmin and related filesystem activity as well https://github.com/moby/datakit/blob/master/reports/2017-06-04.md
<mort___>
…and, slightly ahead of schedule: next up, dev reports
<avsm>
in this age of notifications, git committing our progress seems safest :)
<mort___>
(unless more to say on irmin)
<thomasga>
also made new release of ocaml-git (0.11), Irmin (1.2.0) and soon datakit.
<avsm>
oh sorry, missed that in the agenda mort!
<mort___>
thomasga: cool.
<thomasga>
sorry, 1.11 for ocaml-git
<mort___>
avsm: that's ok, we like keen ;) so— dev reports, can we do mirage?
<mort___>
(thomasga: thanks!)
<mort___>
possibly there's an implicit, do we want to do mirage there as well?
<thomasga>
(e.g to store issues and other metadata in Git)
<avsm>
wow!
<mort___>
(y)
<avsm>
i'd missed that completely samoht -- very nice, no more daeons needed
<thomasga>
yup, all the 9p split mess was to arrive to this :-)
<avsm>
makes sense :-)
<avsm>
so.... i'm looking for volunteers to help me with mirage reports. While the report generator just about works, I dont have time to maintain linuxkit, datakit, vpnkit *and* mirage reports weekly :-)
<mato>
Random question regarding OCaml<->C bindings, before I forget. Who's our resident expert on this? Jeremy? Just thinking of who to ping about reviewing my mirage-solo5 bindings changes.
<avsm>
so i am thinking of a mirage dev report every 2 weeks, but it really needs input from the core team to be useful
<mort___>
mato: can we hold that for a second just to finish off the agenda please?
<mato>
sure
<avsm>
i think the dev reports are really useful to grow our community
<thomasga>
avsm: I am happy to help reviewing the report
<avsm>
but i'm struggling to find anyone else really pushing them out
<mort___>
avsm: perhaps worth saying what "help with mirage reports" means in practice?
<yomimono>
avsm: it might be useful to point at the tool you use to generate them (hesternus, right?)
<thomasga>
I think that means translating: that PR has been merged into a nice sentence which make sense.
<avsm>
there is the generation of the reports, which takes some time, but and is quite mechanical (I am fine doing that and automating them)
<yomimono>
"assemble a report on activity" sounds hard, but "contribute your human intelligence to this thing a robot did" is easier
hannes` has joined #mirage
<avsm>
yeah -- the second half is turning them into a story of the two weeks, and joining up all the multiple PRs into one sentence explaining what it's for
<thomasga>
and add the english prose needed to make the report easy to read (instead of just going through a list of items)
<avsm>
and what's happening next week and so on
<avsm>
I'm not sure what the right answer is here wrt distributing the work, so i'm happy to try doing it myself to start with
<thomasga>
and add blog posts, interesting links/talks, etc
<avsm>
but i just wanted to be clear that it takes a lot of time, and that i will need help eventually or stop doing them -- so getting critical feedback on them while they happen is useful
<mort___>
what tools for doing this — editing a text file and committing it somewhere? editing a wiki? editing a PR?
<avsm>
all the dev reports are in the reports/ directory of the relevant repo
<avsm>
datakit, vpnkit, hyperkit, and soon mirage/mirage
<avsm>
yeah but the tool is less important (i still need to upstream various things)
<avsm>
its more edits on the resulting text
<avsm>
one interesting aspect of this style of reporting is that the reports can be edited any time in the tree
<avsm>
so going back and fixing errors and adding clarifications helps newcomers who are browsing them
<avsm>
now, these existing reports cover a total of 15 repos
<avsm>
but the mirage trove is now *107* repos
<thomasga>
yiikes
<avsm>
so you can see why i'm reluctant to casually do one :-)
<avsm>
but also why i think its very important that we do
<thomasga>
I am happy to help review
<yomimono>
practically speaking we need at least two people (who don't often go on holiday/to conferences together) to be willing to do this
<mort___>
i guess i can chip in too
<mort___>
i have never knowingly been on holiday with thomasga
<thomasga>
(as it keeps me up-to-date on updates in the MirageOS land)
<mato>
so, the reports for X (X = mirage, datakit, ...) are a kind of "(bi)-weekly news" for project X?
<avsm>
btw, it's a superb way to keep track of whats going on in general
<avsm>
mato: yeah
<avsm>
bi-weekly dev news
<avsm>
it's been an experiment so far in datakit linuxkit and vpnkit, but i really like it
<avsm>
what i'm trying to determine is how useful it is for anyone else :-)
<thomasga>
yea me too, these reports are very useful (at least to me :p)
<yomimono>
I'm willing to help but my availability in the short term is bad (a few offline holidays coming up) and in the long term is a bit unsure
<avsm>
also i think ideally it should be someone who isn't directly maintaining a huge amount of code in the short term, as it just adds workload
<avsm>
which is why im happy to do it -- and if mort could help that would be fantastic
<avsm>
(i.e. not yomimono mato samoht who are busy hacking)
<mort___>
ok— in the interests of moving forwards: the request is there, it'll be a good way to get an overview of the project for anyone who's interested, and thomasga and myself are happy to help out. if anyone else has experience or views on how the existing reports for linuxkit, datakit, vpnkit have been, good or bad, please also feel free to make them known
<avsm>
that's a perfect summary, thanks mort :-)
<mort___>
but i figure we may end up trying these out for mirage for at least a few times anyway to see whether they seem useful
<mort___>
right
<mort___>
i think that's done— aob, dstolfa ?
<avsm>
also if you are lurking and you *dont* find them useful, thats even more useful to know
<dstolfa>
mort___: Sure thing, if all is done :)
<mort___>
(yes— all feedback welcome)
<mort___>
dstolfa: i believe it is, yes. floor is yours :)
<dstolfa>
Right, so, I've been working on using a tracing system (currently DTrace exclusively) to trace VMs in a global state, I've discussed this with you mort___ over Skype and mentioned it here previously.
<dstolfa>
So, I was wondering if MirageOS would be interested in support for something like that, so you could trace your unikernels from the host in a global state
<mato>
What does "in a global state" mean?
<dstolfa>
Of course, DTrace currently acts on CTF, which doesn't support OCaml, but to start, the C bits of Solo5 would be just fine (fbt)
<dstolfa>
mato: So, you basically get execution context every time a probe fires and you can conditionally do thnigs
<dstolfa>
things*
<avsm>
i would really like dtrace probes in ocaml
<mort___>
dstolfa: i understood that talex5 trace toolkit produced CTF already...?
<dstolfa>
You can modify the VM state, you can conditionally do things to other VMs and so on
<dstolfa>
mort___: Oh, wasn't aware :)
<avsm>
i took a look at this a while back but all the bindings were quite importable -- freebsd had diverged from osx, and so on
<dstolfa>
avsm: Yes, but the providers are generally very similar.
<mort___>
(i've had a project student doing some work on magpie-like request extraction and clustering using the tracing output this year)
<mort___>
(nearly finished now)
<dstolfa>
What would have to be done is you'd have to build a fbt-like utility in Solo5
<dstolfa>
mort___: I believe Lucian was doing something similar to what I am with Xen, but his goal was provenance analysis and kept the state host <-> guest, but not across different guests
<thomasga>
it would be great to be able to trace a unikernel :-) Although I know that a blog post is saying that it's not possible :troll:
<mort___>
thomasga: indeed, motivation comes in many forms
<mort___>
?
<dstolfa>
mort___: fbt is basically a DTrace provider that dynamically patches in kernel entry/return points and fires a probe
<mort___>
(argh, swap the last two lines)
<dstolfa>
In this case, it would be vastly simpler than it is in say, FreeBSD
<dstolfa>
Because you could virtualize DTrace (I already have that)
<avsm>
hm so we do need to look into how to get ocaml to generate dtrace probes to imprve things a lot
<avsm>
i think that would be a nice compiler project
<avsm>
but if there's a single place with dtrace interfaces it would be most useful
<dstolfa>
In essence, you can pass in virtio-dtrace on the PCI slot and have it act as DTrace
<avsm>
i.e. tracking down what freebsd vs osx do here is an exercise in some tedium :-)
<dstolfa>
So the guest itself would really just have to interface with that
<avsm>
oh nice, a virtio device is a neat trick!
* mato
is also naive about DTrace, what "flows" over that virtio device?
<dstolfa>
Basically, the flow takes a "slow" async path through the virtio device in terms of control messages (enable probes, advertise providers/probes and so on), and a fast path with VMCALL/VMMCALL to fire a probe synchronously to keep the execution context
<dstolfa>
That way, you can be sure what state you're in and conditionally do other things to other guests
<dstolfa>
So you could say, do aggregations across various guests on how many packets they're transmitting
<dstolfa>
For MirageOS, this might be interesting because you would gain access to something like DTrace out of the box, without actually having to implement DTrace in the guest and you could trace it just like a container
<dstolfa>
Of course, there's overhead, but such is life with hypervisors
<mort___>
that sounds like a useful thing. some overhead is always acceptable :)
<dstolfa>
Ideally, this would be a more generic thing to support other tracing systems such as eBPF and future ones, so we're not stuck with one tracing system's architecture, but initially it's DTrace-only
<mort___>
sounds sensible
<dstolfa>
And with unikernels, it would be even easier than say, normal guests
<dstolfa>
Because you could load the CTF at bootup time of the unikernel and be sure that no new CTF will pop up
<dstolfa>
So you can efficiently maintain CTF containers for data types
<mort___>
yes, the implication of static-ness for a dynamic tracing framework seems interesting too
<dstolfa>
Either way, for this to work, all that would need to be done is building something that will patch up Solo5 while running and hooking into the virtio device
<dstolfa>
Which isn't particularly complex, it's got a couple of control messages with limited control
<avsm>
this sounds very sensible to me - is there any integration for non unikernels?
<avsm>
this sounds useful for a virtio VM running linux
<mort___>
sounds like mato djwillia would be the people to advise on the detail…?
<dstolfa>
avsm: Yes, I'm doing this for any type of a guest
<mato>
dstolfa: On ukvm there ain't no such thing as virtio, so we'd have to invent a device to run the control messages over.
<mort___>
(and ricarkol)
<dstolfa>
mato: Right, it's definitely doable. I've added support to the DTrace framework to seamlessly create a device like that
<mato>
"device" == communication channel of some description; this is all on the medium/long-term roadmap
<mort___>
in the interests of time as we're about to hit the buffers: anyone else got anything to say or do we declare generally enthusiastic support for this fine idea? :)
<dstolfa>
The only reason it's a virtio device on my side is because it's easy to program and build asynchronously
<avsm>
i'm heading off to sell mirage/solo5 to the linux security community :-) thanks everyone! dstolfa, keen to hear more about this work, and I'd like to get ocaml dtrace support soonish and can look into that
<mort___>
ok— thanks everyone! are we done?
<thomasga>
I need to run too, thanks all. (and yes, enthusiastic suspport for tracing unikernels)
<dstolfa>
That'd be all from me without diving too much into the details of the implementation :)
<dstolfa>
mort___: If you'd like to chat more about this, I should be in Cambridge starting 1st of July and onwards 4 years or so :)
talex5 has quit [Quit: This computer has gone to sleep]
<Ricarkol>
dstolfa: can you connect over slack please? Have some questions
talex5 has joined #mirage
<dstolfa>
mort___: Sure thing. I should be in the computer lab starting 3rd of July to settle in
<dstolfa>
Ricarkol: Currently only have a FreeBSD machine in my hands, and I'm not aware of a client
<mort___>
ok— official meeting done
<yomimono>
dstolfa: I use it through a browser
<mort___>
thanks all!
<dstolfa>
yomimono: Oh.
<dstolfa>
That'll work
thomasga has quit [Quit: Leaving.]
<dstolfa>
Ricarkol: Give me a second then :)
<dstolfa>
Thanks everyone
talex5 has quit [Client Quit]
<Ricarkol>
Ah, no worries dstolfa, it doesn't have to be now
<dstolfa>
Ricarkol: No worries, I can hop in. I guess I'll need an invite to the MirageOS slack on domagoj [dot] stolfa [at] SPAMFREE gmail [dot] com (damn freenode logs lol)