<hannes>
hmm 709... thinking what the actually right name would be? cidr? v4cidr?
<mato>
IMO it's fairly common to treat "IPv4 address" as "IP/CIDR"
<hannes>
k, then lets settle with "ipv4"
<mato>
eg. even freebsd ifconfig lets you do ifconfig iface 1.2.3.4/12
<hannes>
yes
<mato>
yeah, ipv4 is fine
<hannes>
I always use this
<yomimono>
yay
<hannes>
mato: if this ukvm module thing is good for you, I guess we can merge this rather insanely large PR?
<mato>
hannes: i'll try it out, give me a few minutes
<hannes>
yes, and I'll rebase
<mato>
re --ipv4, i guess the question of what to call gateway kind of comes up
<mato>
--gateway4 ? :/
<mato>
yomimono: ?
<yomimono>
atm it's gateway for ipv4 and gateways for ipv6, which is not very ideal
<hannes>
mato: yomimono settled with --ipv4 1.2.3.4/24 and --ipv4-address 1.2.3.1
<hannes>
so, #703 is rebased on current master
<mato>
what is --ipv4-address ?
<yomimono>
--ipv4-address shouldn't be exposed as a key
<hannes>
oh, ok... then --ipv4 and --gateway!
<yomimono>
hannes: where do you see that?
<hannes>
yomimono: I thought from reading briefly through 709
<yomimono>
(we need the converter for understanding the gateway, but that's separate from what we show the user)
<yomimono>
hannes: oh, ok. thought I'd left some weird dangling config somewhere for a minute
brson has quit [Read error: Connection reset by peer]
jermar has joined #mirage
<mato>
so, what do we do with --gateway and --gateways? (these are all very user-visible changes, may as well get them sorted)
brson has joined #mirage
brson has quit [Read error: Connection reset by peer]
<mato>
--gateway4 --gateways6 (ugly but obvious)
<mato>
or even ditch the 's' for v6, so just --gateway6 and document it can take multiple items?
<yomimono>
is "gateway" even the right term when it comes to ipv6?
<mato>
hmm
<yomimono>
I'd rather change it to something that actually makes sense
<mato>
not sure. for v6 we won't really know what right is until we start deploying somewhere
<yomimono>
mato: yeah, that's the problem with a lot of the ipv6 setup - I don't think the existing keys have ever been used
<mato>
i've been meaning to try it, but not yet gotten around to it
<yomimono>
I recall we talked about this but I haven't found the spare time to mess with it :(
<mato>
yeah
<yomimono>
heh, jinx
brson has joined #mirage
<mato>
maybe --default-gateway4 and --default-gateway6 ?
<mato>
what are the multiple gateways for ipv6 intended for?
<yomimono>
mato: they're called "routers" internally, I'm looking at the implementation now
<yomimono>
I don't know enough about ipv6 to say anything more intelligent than "it looks like they actually do get used in figuring out the next hop"
<mato>
ipv6 certainly has a concept of default route, that might be just the implementation allowing something more than our ipv4 does?
<mato>
i.e. an actual routing table?
brson has quit [Read error: Connection reset by peer]
<yomimono>
yes, it indeed looks like the ipv6 implementation allows for an actual routing table, and will (given >1 "gateway") attempt to find the most suitable one
<mato>
hm
<yomimono>
more correctly (I think) the first one via which the destination is reachable
<yomimono>
which is distinct from what I said initially
<mato>
do we also have support for multiple ipv6 addresses exposed?
<yomimono>
yes.
<yomimono>
hm, I said that -- definitely at the IPv6 module API and I think at the key levvel
brson has joined #mirage
<yomimono>
although getting a unikernel which gives you those keys is probably a little tricky at the moment
<mato>
hannes: ok, tested #703 with stackv4 and block, ukvm modules are set correctly
<mato>
hannes: so i think we can merge, if yomimono agrees.
<hannes>
!!
<mato>
btw is it deliberate that mirage clean does not clean the generated .opam file?
<yomimono>
I haven't driven it again yet but I trust you, go ahead
<mato>
yomimono: so, a suggestion for the v4/v6 key (option) naming: --ipv[46], --ipv[46]-gateway ? we ditch the 's' for ipv6 and ignore (for now) the fact that you can specify multiple routers since we don't know what that should do in practice...
<mato>
wdyt
<yomimono>
I think someone needs to make V1.STACKV6 (or make V1.STACK be properly parameterized over the IP module) before it matters, since the v6 keys are unusable at the moment. I'm hesitant to agree to specifying the ip/prefix stuff as tuples for ipv6 as there's a comment in the last discussion I had about it that explicitly says not to do that, if I understand it properly
<mato>
ok, so if we stick to ipv4, we're still left with what to call --gateway to be a) consistent b) future-proof
mort___ has joined #mirage
<mato>
i think it makes sense to have --ipv4 and --ipv4-gateway, with a view to future --ipv4-whatever, but am open to counter-arguments
<mato>
though if we keep calling the ipv4 gateway just --gateway then the address/cidr may as well be just --ip...
<yomimono>
--ipv4 and --ipv4-gateway, the people have spoken
insitu has joined #mirage
<mato>
how is this supposed to interop in a N-interfaces scenario, if at all?
<mato>
as in, do we have any current/proposed syntax for that?
<yomimono>
the --group keys are meant for disambiguating this
<yomimono>
I always have to look up exactly how to specify them, but they do work
<yomimono>
(or at least, they did a few months ago, and I've tried not to break them)
yegods has quit [Remote host closed the connection]
<yomimono>
IIRC you specify that one of the network interfaces has ~group:"whatever" and then you get extra keys for --whatever-ipv4, --whatever-ipv4-gateway
insitu has quit [Ping timeout: 248 seconds]
insitu has joined #mirage
<mato>
seems entirely reasonable
<yomimono>
the group name is in config.ml, which might be annoying for unikernel-runner
<hannes>
mato: clean opam file also needs the target... i'll followup on a fix with the target build and clean..
<hannes>
+1 for ipv4-gateway
<mato>
yomimono: that's no issue atm, i don't expect unikernel-runner to support >1 interface for quite some time
<yomimono>
OK, 709 now also renames gateway to ipv4-gateway
<hannes>
(I suspect a .current-target generated by mirage configure should be good, or?)
<mato>
hannes: is this for "persisting" the target from configure to build and clean?
<hannes>
yes
<hannes>
the idea at least
<mato>
.mirage-target perhaps?
<mato>
incidentally, i was thinking about the workflow. now that we have quite a few targets, i think it makes sense for a) there no longer to be a default b) you get a friendly error if you do mirage build/clean/whatever-else-depends-on-target without having done configure beforehand
<mato>
hannes: i'd use .mirage-target as a first cut. i'm sure people may want to persist more than the target, in which case that will probably change...
<hannes>
mato: ack, and detecting that you haven't run configure depends on having a .mirage-target around or not
<mato>
yeah
<hannes>
and yes, error out on build if not having run configure
<hannes>
but as said earlier, this should be a followup to 703, similar to the clean vs distclean
<mato>
yes
<hannes>
(plus i'm stuck with tons of other things atm)
<hannes>
so, mato, since I try to avoid on my own green buttons, would be great if you can merge 703 :)
<mato>
hannes: what else does it depend on? functoria#84, mirage-skeleton#200?
<mato>
is that the lot?
<hannes>
ack, and mirage-dev PR
<hannes>
just squash mirage and functoria commits, no need for the history imho