Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Nix expressions to build Snabb #876

Merged
merged 95 commits into from
Apr 29, 2016
Merged

Add Nix expressions to build Snabb #876

merged 95 commits into from
Apr 29, 2016

Conversation

domenkozar
Copy link
Member

Hydra is currently using these in release.nix and they build successfully at https://hydra.snabb.co/jobset/snabb/master

It's a good idea to put the upstream, because different Snabb versions may need different the Nix expressions. It's also handy to clone Snabb and just run nix-build release.nix and you should get the snabb, manual and tests (with logs) for that particular commit (if tests didn't fail).

There are two blockers:

  • I have no way to extract Snabb version from the repo. Running a command won't help in Nix. It needs to be statically in a file. Currently no version is added to the derivation name.
  • We depend on git for manual and also Snabb at build time. This is problematic since hash in Nix is content addressed (src = ./.; and .git mutates on each commit and thus changes regardless of the commit checkout. See my upstream comment at fetchgit with leaveDotGit = true is still not completely deterministic NixOS/nixpkgs#8567 (comment)

PS: There are lots of commits, maybe kbara-next needs to be rebase on master? Or should I just rebase on kbara-next?

wingo and others added 30 commits February 25, 2016 15:02
This will be used by the lwAFTR.
Currently shm.map() will create the file and any containing directories
if it does not exist.  This is not so great, so I split it into separate
open() and create() functions, adapt all callers, and remove map() from
the public interface of the shm module.
This commit adds a histogram facility that can record the distribution
of different sampled magnitudes.  In particular, it is useful for
recording distributions of times.  Histograms can be mapped into
/var/run/snabb, where they can be analyzed by a separate process.

This commit also wires up the app.breathe() loop to record latencies for
its breath cycles into a well-known
file (/var/run/snabb/PID/engine/latency), and wires up "snabb top" to do
some basic statistics on this data.
The idea is, there are lots of different kinds of analyses you might
want to do on a histogram, and it's too early to canonicalize one of
them.  Better to build your own on top of iterate().

Also adds tests for iterate().
Imported from Igalia/lwaftr_starfruit, up to date with commit
a87632f
@kbara
Copy link
Contributor

kbara commented Apr 18, 2016

@lukego is there anything it'd be helpful for me to do with kbara-next, like merge master into it? I'm still getting used to the upstream Snabb workflow... :-)

@lukego
Copy link
Member

lukego commented Apr 18, 2016

Hey, cool, there is actually no mess here and everybody is doing the right thing :) we are exercising a new edge in our collaboration graph here :-).

The reason we see many commits here is that downstream branch nix has merged a bunch of commits from the v2016.04 release on master but these commits are not yet in kbara-next. So Github is showing that the consequence of merging nix onto kbara-next would be to get all of these commits i.e. the v2016.04 release in addition to Domen's own change a357165.

The next steps could be either of these things:

  1. kbara-next merges from master and then this PR should automatically update to show only the commits that are still missing i.e. a357165. Then this could be merged.
  2. kbara-next merges from nix which in one fell swoop would bring in the v2016.04 release and also Domen's change i.e. all the commits we see listed above.

So @kbara it is really up to you which you prefer.

In a perfect world we might all merge master into our long-lived branches immediately when a new release is made, but this demand-driven merge may well be fine too. The main thing is to transfer all the commits between all the branches and git is good at keeping track of what is missing (provided that we don't rebase and change the commit IDs.)

@lukego
Copy link
Member

lukego commented Apr 18, 2016

Here is one git incantation to summarize the changes more succinctly:

$ git log --oneline --first-parent origin/kbara-next..origin/nix
a357165 Add Nix expressions to build Snabb project
03f5958 Merge PR #855 (v2016.04 release) onto master

Too bad there is no button on the Github UI to see --first-parent :)

@kbara
Copy link
Contributor

kbara commented Apr 18, 2016

Excellent. I've run git merge upstream/master on kbara-next and pushed that; I agree that doing that after each release sounds like a good workflow.

@kbara kbara self-assigned this Apr 18, 2016
@lukego
Copy link
Member

lukego commented Apr 18, 2016

@kbara You will need to push your branch directly to the snabbco repo now e.g. with git push snabbco kbara-next if you have a remote called snabbco. The mirroring-from-our-forks hack is gone now - see #850.

@kbara
Copy link
Contributor

kbara commented Apr 18, 2016

Interesting. I've done that, it looks to me like it's updated, but the list of commits/etc above doesn't update.

@lukego
Copy link
Member

lukego commented Apr 18, 2016

Interesting, yep. I see that you have pushed:

$ git log -1 --oneline origin/kbara-next
d5d355a Merge remote-tracking branch 'upstream/master' into kbara-next
$ git log --oneline origin/kbara-next..origin/nix
a357165 Add Nix expressions to build Snabb project

but I suppose that the Github UI does not automagically refresh in this case. Oh well, probably not a big deal.

@kbara
Copy link
Contributor

kbara commented Apr 18, 2016

Yeah; I couldn't find a way to manually do that either. All the more reason to do this right after releases, eh?

@kbara
Copy link
Contributor

kbara commented Apr 18, 2016

There is a trailing whitespace after + tar xvzf ${test_env} -C ~/.test_env/; is this something people care about on this project?

@kbara
Copy link
Contributor

kbara commented Apr 18, 2016

+      export SNABB_PCI0="0000:01:00.0"
+      export SNABB_PCI_INTEL1="0000:01:00.1"
+      export SNABB_PCI_INTEL0="0000:01:00.0"

will clearly only work on some machines. Is the intent for this to just be running on the snabblab servers? If not, how are people with other PCI IDs expected to use it - local modifications to this file?

@kbara
Copy link
Contributor

kbara commented Apr 18, 2016

Aside from those two nits, it looks good to me, with the caveat that I haven't dug deeply into nix yet. :-)

@domenkozar
Copy link
Member Author

You're right. I'll make sure the `SNABB_PCI* exports can be superseeded via bash env. And that whitespace should be gone.

@domenkozar
Copy link
Member Author

Pushed the two fixes, but the diff is bigger now:

$ git log --oneline origin/kbara-next..origin/nix
6cce8f4 release.nix: whitespace
8982625 release.nix: respect bash env, provide fallback values
e1ff0a3 Swapped in lstopo.png, replacing lstopo.pdf
aa1aac9 Renamed performance tuning file, as per review request
afc0bfb added info on mlock=on
294fc3b braindump on performance parameters
dbe9a9a Initial stub on performance tuning
a357165 Add Nix expressions to build Snabb project

@domenkozar domenkozar changed the title [WIP] Add Nix expressions to build Snabb Add Nix expressions to build Snabb Apr 29, 2016
@domenkozar
Copy link
Member Author

I've removed WIP, the two issues I mentioned can be addressed later.

@kbara kbara added the merged label Apr 29, 2016
kbara pushed a commit to kbara/snabb that referenced this pull request Apr 29, 2016
@kbara kbara merged commit 6cce8f4 into kbara-next Apr 29, 2016
takikawa pushed a commit to takikawa/snabb that referenced this pull request Aug 5, 2017
Each migration is now only responsible for progressing to the next version
which then will run the subsequent migration to progress further. This is
done as a long chain until the configuration has been migrated to the latest
configuration schema.

This also fixes an issue with the 3.2.0 -> 2017.07.01 migration which no
longer functioned correctly.
takikawa pushed a commit to takikawa/snabb that referenced this pull request Aug 5, 2017
Fix snabbco#876 - Improve config migration by chaining together
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants