1,116 karma · joined March 30, 2011
A while ago (like ~10 years ago) VMWare workstation, or some of the things virtualbox graphics drivers did, seemed to be the only reasonable ways to run a virtualised desktop with 3d or at more than 5fps. But these days virtio and spice seems to work just fine.
Anyone can propose changes to practically all of the infrastructure via the https://opendev.org/opendev/system-config project.
Anyone can look through all of the changes; https://review.opendev.org/q/project:opendev/system-config+s...
Every change gets run through an extremely thorough CI system that tests the change and reports results, e.g. https://zuul.opendev.org/t/openstack/buildset/50ce144851224b...
Most of these CI jobs do things like apply your proposed change, deploy the service, then connect up a headless client and take screenshots of the results so you can confirm the correct behaviour of your change; e.g. http://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b62... is from a job that was modifying the gita deployment.
Humans approve changes for merge with Zuul, but Zuul commits the code. When Zuul merges the change, another set of jobs will push things to the production hosts automatically. There is a talk on the overall process at https://www.youtube.com/watch?v=apLHQ4DkIHU
There are obviously bastion hosts and private components to the production deployment, but as much as practical is completely open. There have been contributors with no special access that have developed the deployment of infrastructure services and admins helped only at the end committing some secrets and providing production hardware resources. More commonly, people who have CI issues can jump in and fix their own problems, especially relating to things specific to them (e.g. mirror setup on CI nodes, software versions used, etc.)
One cool thing is that the Zuul jobs publish their production deployment logs in public, but encrypted (these might contain secrets, so are not made open by default). If you work on a particular system, you can request to commit your public key to the service you like and access all the deployment logs. For example, say you are interested in maintaining codesearch.opendev.org. The "infra-prod-codesearch" job deploys changes relating to this service. You can look at all the jobs at https://zuul.opendev.org/t/openstack/builds?job_name=infra-p..., and every job has an artifact that lets you download the logs; e.g. https://zuul.opendev.org/t/openstack/build/c76ec695d19a4e9e9.... Details are at https://docs.opendev.org/opendev/system-config/latest/open-i...
Wikimedia is the only other platform I've seen with a comparable commitment to open infrastructure (unsurprisingly there has been collaboration between the two over the years)
[1] https://twitter.com/ethan_iverson/status/1479513450900377603
Is all the best ideas of keybase. Basically if you trust someone has control over multiple different accounts you can also trust their pgp key.
https://www.merriam-webster.com/words-at-play/what-does-crom...
https://www.google.com/maps/@-37.9293496,145.0051951,3a,59y,...
https://www.google.com/maps/@-33.7710688,151.0985503,3a,75y,...
As the usual speed limit is quite a bit higher at 70km/h, driving at 40km/h (25mph) outside these times would make you, at best, a rather annoying obstacle to surrounding traffic.
https://opendev.org/opendev/system-config/src/commit/0a27974...
is really nice practical example. What it does isn't even really that important; but it runs a simulation of deploying production code in OpenDev. This is a "devel" job, we deliberately test any changes against all the latest HEADs of the master/main/development branches of projects we use. This is a non-voting job -- a notice that what you're introducing might be fine now, but there is trouble brewing when our dependencies release their next version. Sometimes that's fine and a known issue, or upstream is broken, and other times it's something totally unique and needs to be fixed (this is why, despite AI being able to write code for you, so far the implications of using that code still need a human in the loop :)
The "required-projects" in the job definition tells Zuul what repositories this test needs.
You can clearly see how it handles various projects having "devel", "main" or "master" branches to pull from to get their latest versions.
In the "vars" section you can see we're setting variables that get passed to the job roles flagging "this is the devel job, don't install the latest release but use the source Zuul will checkout for you from here".
The amazing thing? If I make a change and this job fails, I may debug it and find that it wasn't actually my fault, but something in upstream Ansible committed recently. I can propose the fix upstream. They do all their CI, and that's fine. But I now put in my change comment
Depends-On: https://github.com/ansible/ansible/pull/1234
and magically Zuul will recognise that I want to apply that pull request to the Ansible tree in testing and set it up for me (as noted, Zuul can do this for all sorts of systems, not just github). Additionally, Zuul will not merge the change until the dependency is satisfied -- I can NOT commit broken code!
The podcast below sums it up perfectly:
Three years ago, tobacco giant Philip Morris announced they were moving away from cigarettes and that they were campaigning to "unsmoke the world".
They said they would offer people a better alternative to the cigarette, a device that would give you your nicotine fix from a "HeatStick".
Author and documentary maker John Safran discovered the HeatStick is made primarily from tobacco, and that it still generates carcinogenic tar.
John soon found that Philip Morris were financing "anti-smoking" initiatives all over the world.
They look just like conventional Quit programs, but they are designed to shift people onto this new device.
https://www.abc.net.au/radio/programs/conversations/john-saf...
Although I had to laugh at https://en.wikipedia.org/wiki/Firewalker_(The_X-Files) which is about a contagious alien(?) virus which I remember being super scary. The whole idea of viruses, pandemics and quarantine didn't really phase the kids at all. How times have changed.
Weirdly there's some stock footage scenes that aren't HD. This led me to finding https://www.reddit.com/r/XFiles/comments/3w3lxl/the_blurays_... which is a great thread with lots of info on how the restoration was done.
I seem to remember the later parts of the series going a little off the rails. But so far it's great family watching for the right age.
I think you'll find better UFOs and conspiracy theories rewatching this than grainy fighter jet videos.
I would encourage anyone to get involved in real open infrastructure through efforts such as https://opendev.org. Yes, resources are donated, but by a range of providers who have a vested in interest in what the community is producing. ARM64 has been a great example; Linaro providing hardware resources, which has enabled services to perform functional testing and build ARM64 Python wheels for publishing for a number of projects. This is a rising tide that floats all boats. No need to send a resume [2] and you can start contributing immediately [3,4].
It has been good run with IRC but I forsee moving to Matrix as the medium-term future and there's plenty of opportunity for others to get involved with that (building home servers, admining, writing bots that provide the services we current provide on IRC, doc updates, community building).
[1] https://fosshost.org/news/freenode-faq
[2] https://docs.fosshost.org/en/home/volunteering-opportunities
[3] https://opendev.org/opendev/system-config/
[4] https://review.opendev.org/q/project:opendev%252Fsystem-conf...
You simply create a change and in the footer say
Depends-On: <pull request URL/gerrit URL/gitlab URL/etc>
Zuul will pull everything together, merge it all, and provide your tests with repos on disk that reflect the entire dependency chain. You write your test to install/run/etc. from these repos that have been prepared for you. The test might have only your change, or it might have 20 other changes; Zuul handles all this. This way you test everything together.
You don't need to spend resources speculatively running every possible combination; most changes probably don't affect each other (when you know they do; setup dependencies). But the trick is, you don't commit, Zuul does. It puts all approved changes in a queue, merges them and runs the "gate" tests. It does this in a smart way to try and batch as much as possible. When they pass, it commits the change. When something fails; either it won't merge with HEAD, or it's tests fail against HEAD, it gets rejected and you fix it up and go through the cycle again. It's impossible to commit anything broken to HEAD, because everything that is committed has been tested.
An older tour discussing how to contact Voyager 2 he gave at https://www.eevblog.com/2017/04/19/how-to-contact-the-voyage...
$ git checkout -b my-feature-branch
$ emacs ... <edit edit edit>
$ git add -i ...
$ git commit
$ git review
read reviews, edit
$ git add -i ...
$ git commit --amend
$ git review # push new change revisions
[1] https://docs.openstack.org/infra/git-review/ [2] https://www.mediawiki.org/wiki/Gerrit/git-review
a) The clouds are a static map that is placed at a fixed location and moves over in a known pattern per time-step. So by extracting the cloud map and correlating that to what you see in the image, because you know where the clouds started you can get a good idea of where you are in the map.
b) A high-up waterfall has a low chance of spawning because high waterfalls are rare to even try generating; and additionally it requires rock and air around it, further reducing the chance it can actually occur.
So (a) lets you know where you are, then you figure out the waterfall location from that (a lot of tricks described above to figure out perspective, etc.), then use elements of (b) as a fairly fine sieve on the generator ("could a waterfall generate at xyz") and you have a tractable way to find possible world seeds.
Maybe? A very fun project, anyway.