Mihir Soni

From X-Pack Removal to GA: Five Months, 82 PRs

mihirsoni.123@gmail.com (Mihir Soni) — Mon, 12 Jul 2021 09:00:00 +0000

On January 30th, 2021, I merged a PR called “Remove x-pack directory” into a repo that had existed for about five hours. Today, July 12th, AWS put out “OpenSearch 1.0 launches”, and opensearch.org posted its own GA announcement. Between those two dates I merged 82 pull requests into OpenSearch Dashboards. Writing down the whole arc here while it’s still fresh:

January 30 – February 23: pulling Elastic out. Eleven PRs stripping the x-pack directory, disabling telemetry that phoned home to Elastic, getting a basic CI pipeline running. Nobody outside the team saw any of this. The repo was private, the project didn’t have a name people knew yet, and the work was entirely “make sure this thing legally and technically stands on its own.”

March 3 – March 19: the rename. This is the biggest single chunk — 49 PRs in seventeen days, renaming every kbn-* package to osd-*, directory by directory, because doing it all at once would have made a broken build impossible to debug. Sixty percent of everything I shipped on this project happened in these seventeen days.

March 22 – April 10: getting ready to be looked at. License headers, README and CONTRIBUTING updates, a URL that still pointed at opensearch.co two days before launch and needed fixing. Eighteen PRs of the kind of housekeeping you only do once you know strangers are about to show up.

April 12: the announcement. “Introducing OpenSearch” went out to the world. I watched it happen from the inside, already knowing every commit that made it true.

April 15 – May 13: the last stretch. Bumping the version to 1.0.0, a typo fix in a rename script, one more docs pass on the README and CONTRIBUTING guide. Small PRs, but the kind that matter when you’re closing out a release.

July 12: GA. OpenSearch 1.0 was generally available. Five months and change after that first commit.

Most of the five months wasn’t glamorous — directory-by-directory renames, license header updates, fixing a URL two days before launch. No single PR in that list is interesting on its own. It’s 82 PRs, done mostly by hand, that happened to hold together when people looked at it on April 12th and again today.

Not sure what happens to it from here. That’s up to whoever picks it up and runs it. But it’s a good feeling to sit here on GA day and remember it started with a directory called x-pack that needed to come out.

Repo history

The 48 Hours Before OpenSearch Went Public

mihirsoni.123@gmail.com (Mihir Soni) — Mon, 12 Apr 2021 09:00:00 +0000

AWS announced OpenSearch today with a post called “Introducing OpenSearch”. Reading it, you wouldn’t know what the repo looked like from the inside in the days right before it went out.

My last PR before the announcement was #277, a README update, merged April 10th. Two days later the announcement went live. In the weeks before that, the PRs stopped being about renaming packages and started being about the kind of stuff you only think of once you realize actual strangers are about to look at this thing:

Removing the OSS build flag so the default build didn’t secretly assume you were building the old Elastic-licensed version
Fixing eslint errors that had been ignored because who’s going to fix a lint warning nobody outside the team could see
Updating the license header across the whole project and updating NOTICE.txt — the unglamorous legal housekeeping that has to be right before you publish
Fixing every URL that still pointed at opensearch.co instead of opensearch.org — caught two days before launch, which is about as late as you want to catch something like that
Updating CONTRIBUTING.md and the README so that when people showed up, there was actually somewhere for them to start

None of these are hard engineering problems. They’re the boring last mile you do because you know someone’s about to look — wrong URLs, missing license headers, a README that assumes you already know what this project is. The last two weeks felt less like building features and more like cleaning up before guests show up.

Today I read the same announcement everyone else is reading for the first time, except I already knew every PR that went into making it true — which commit fixed the URL, which one updated the license headers, all of it, from two days ago.

Repo history · “Introducing OpenSearch”

Renaming Kibana to OpenSearch Dashboards, One PR at a Time

mihirsoni.123@gmail.com (Mihir Soni) — Fri, 19 Mar 2021 09:00:00 +0000

Between March 3rd and March 19th, 2021, I merged 49 pull requests into what would become OpenSearch Dashboards. That’s roughly three PRs a day for seventeen straight days, and almost all of them were doing the same kind of thing: renaming kbn-* packages to osd-*, one directory at a time.

kbn- shows up in package names, import paths, config files, build scripts, generated docs, test fixtures, and a bunch of other places that don’t all update the same way. Doing it all at once gets you a PR nobody can review and a build that’s broken in ways nobody can trace back to a single change. So we didn’t — we did it directory by directory, package by package, and shipped each piece as its own reviewable PR.

You can see the shape of it just from the PR titles:

kbn-utils → osd-utils
kbn-ui-framework → osd-ui-framework
kbn-test in four separate parts because that one package touched too much to do in one PR
refactors of src/core/server, src/core/public, src/plugins/vis_type_vega, src/plugins/vis_type_table, and on, and on
src/dev, test/, src/legacy, src/optimize, examples/

On March 15th there’s PR #167: “Fixes renaming renames and able to start Dashboards 🎉🎉🎉🎉.” After two weeks of renaming pieces one at a time, that’s the PR where the whole thing rebuilt and started up again.

Doing this in 49 separate PRs instead of one giant one wasn’t about process for its own sake. A rename this size touches thousands of files, and if something breaks after landing it all in one shot, you have no idea which change caused it. In small, reviewable pieces, when something did break — and things did break — we knew within minutes which PR to look at.

It’s the most I’ve shipped in any single stretch of this project so far — more PRs in these seventeen days than everything before them combined. Not the most interesting engineering problem I’ve worked on, but probably the one that’s required the most discipline to do carefully instead of fast.

Repo history

What It Actually Takes to De-Elastic a Codebase

mihirsoni.123@gmail.com (Mihir Soni) — Tue, 23 Feb 2021 09:00:00 +0000

Right now this is still just a checkout of Kibana with a bunch of things that need to come out. Between January 30th and February 23rd, I merged eleven PRs that we labeled [PURIFY] in the title, because that’s basically what it is — going through the codebase and taking out everything that isn’t ours to keep.

None of this is public yet. I don’t know when it will be, or what shape the announcement takes when it happens. Right now it’s a repo nobody outside the team can see, and work nobody is going to write a launch blog about — not this part, anyway.

Here’s roughly what a [PURIFY] PR looked like in practice:

Remove the x-pack directory — the actual commercial code
Remove x-pack references from the build scripts — because deleting a directory doesn’t help if six build scripts still expect it to exist
Fix the tests that broke once x-pack was gone, and make sure the test suite actually ran again
Remove x-pack from the i18n build, because internationalization tooling had its own set of x-pack hooks
Disable the telemetry network calls that phoned home to Elastic’s servers
Clean up the .ci directory and get a basic Jenkins pipeline running so we had a way to know when we broke something

That pattern shows up a lot: remove x-pack from the main directory, and it turns out the CI scripts still reference it, the i18n tooling references it, the telemetry system pings back to it, and half the test suite assumes it’s there. Each one of those had to get found and fixed on its own, because there was no automated way to know what “still depends on x-pack” meant across a codebase this size.

Slow, careful, unglamorous work — check what breaks, fix it, check again. Nothing here is going to make it into a launch announcement, if there’s ever one to write. But you can’t ship an Apache 2.0 fork of Kibana while it’s still quietly calling home to Elastic’s telemetry servers, so somebody has to go find that code and turn it off. Right now that’s me, working through a checklist that keeps growing every time I think I’ve finished it.

Repo history

The First Commit

mihirsoni.123@gmail.com (Mihir Soni) — Sat, 30 Jan 2021 09:00:00 +0000

On January 14th, 2021, Elastic announced they were changing the license on Elasticsearch and Kibana. No more Apache 2.0 — going forward it’d be the Elastic License or SSPL instead.

I remember hearing about it at work and thinking, okay, that’s a big deal, but I didn’t know yet that it was about to become my problem.

Sixteen days later, on January 30th, I merged PR #6 — “Remove x-pack directory” — into a brand new repo called opensearch-project/OpenSearch-Dashboards. The repo had been created less than five hours earlier. I checked the timestamps later: repo created 22:10 UTC, my PR merged 02:58 UTC. Under five hours from “this repo exists” to “here’s the first commit.”

There was no announcement yet. No blog post, no press release, nothing on Hacker News. As far as the outside world knew, nothing had happened. Internally, a small group of us had been told: we’re forking Elasticsearch and Kibana, keeping everything on Apache 2.0, and we’re starting now. Not “we’re starting a design doc.” Starting.

My job that first day was about as unglamorous as it gets — go into the Kibana codebase and rip out the x-pack directory, the commercial, non-Apache-2.0 part of the code. Not rewrite it, not replace it, just remove it and make sure the rest of the app still built. Delete a directory, see what breaks, fix it.

No whiteboard session, no kickoff meeting. Just a repo, a checkout, and a directory that needed to go. I merged that PR, went and looked for the next broken thing, and merged that too.

Not sure yet how long this takes, or what it’s called by the time anyone outside the team sees it. Right now it’s just a checkout of Kibana with a directory missing, and a list of things that still need to come out after it.

Repo history · PR #6

Committing to Anomaly Detection Four Days Before AWS Announced It

mihirsoni.123@gmail.com (Mihir Soni) — Tue, 26 Nov 2019 09:00:00 +0000

The anomaly-detection repo under Open Distro for Elasticsearch was created on November 15th, 2019. My first commit landed a week later, on November 22nd — a small fix to the test workflow config, the kind of unglamorous CI plumbing that has to work before anyone can trust the rest of the repo. Four days after that, on November 26th, AWS published “Introducing real-time anomaly detection in Open Distro for Elasticsearch” and the plugin became public.

I don’t think it’s a coincidence that the commit came before the announcement rather than after. By the time AWS is ready to publish a blog post like that, the code already has to be in decent enough shape to point people at. Someone has to get it there first, quietly, in the days right before — this time that someone was me, fixing a CI workflow nobody outside the team could see yet.

On the Kibana side, anomaly-detection-kibana-plugin has an interesting wrinkle: its git history goes back to July 2019, four months before the public repo existed on GitHub in November. That’s not a mistake in the dates — it’s what open-sourcing already-in-progress internal work looks like. The commits are real, the dates are real, they just predate the repo being something the public could see.

Not a big dramatic story — a CI fix, four days, and a blog post. But it’s the same pattern I keep noticing: the public announcement is the last step, not the first one, and by the time you read it, someone’s already been living inside that code for weeks.

anomaly-detection repo · AWS announcement

Building a CLI So I Didn't Have to Click Through Kibana

mihirsoni.123@gmail.com (Mihir Soni) — Mon, 23 Sep 2019 09:00:00 +0000

Open Distro for Elasticsearch launched on March 11th, 2019, and Alerting was one of the plugins that shipped on day one. Two weeks after that, on March 25th, I merged my first PR against it — support for Kibana 6.6.2. Over the next six months I kept shipping PRs against the alerting Kibana plugin, mostly chasing whatever Kibana version had just shipped: 6.7.1 in April, 7.0.1 in May, plus a steady stream of smaller fixes — where-clause support for visual monitors, a monitor update bug, moving the schedule field per UX feedback.

Somewhere in the middle of all that, I got annoyed at how I was actually managing monitors day to day. Alerting monitors — the rules that watch your data and fire notifications — lived entirely in the Kibana UI. If you wanted the same monitor on two clusters, you clicked through the UI twice, by hand, and hoped you didn’t fat-finger a threshold. If you wanted to know what changed in a monitor over time, you didn’t, because there was no history — just whatever state it was currently in.

So I built odfe-monitor-cli, a command-line tool that let you define monitors as YAML files instead. Write the monitor once, commit it to git, and push it to as many clusters as you wanted. Diff it before you applied a change. Actually know what changed and when, because now it was a file in version control instead of a state hidden inside Kibana.

On June 12th, 2019, I wrote it up for the AWS Open Source Blog — the first time I had a byline on an official AWS blog post. Then in July, at OSCON 2019 in Portland, I gave a talk on the same idea, “Gourmet Alerting with Open Distro for Elasticsearch”. Same tool, same argument: alerting rules are configuration, and configuration belongs in version control, not locked inside a UI you have to click through by hand.

I spent months in the actual UI, fixing the actual bugs real users hit, and the CLI came directly out of being annoyed at my own workflow while doing that. It wasn’t a roadmap item — I was the one shipping the plugin every week, had to live with how clunky it was to operate, and eventually just built the thing I wanted.

odfe-monitor-cli on GitHub · AWS blog post · OSCON 2019 talk

Wrapping Up: Last Commits to Ubuntu Touch

mihirsoni.123@gmail.com (Mihir Soni) — Fri, 03 Apr 2015 09:00:00 +0530

Hello,

Landed bug 1438910 on Calendar today — almost exactly two years since I first showed up to help close out bugs on the Calculator app back in July 2013. Between those two dates: a full app rebuilt from a half-finished blueprint, an Ubuntu Membership, a lot of design arguments over IRC, more Autopilot test debugging than I ever expected to do for a phone calendar.

Haven’t been as consistent the last couple of months as I was through most of last year — work’s gotten busier, and the commits have been getting further apart. Not stopping exactly, just slower than I’d like to admit.

Whatever happens next with the app, it feels worth writing down that two years ago this was just a bug I filed on an app I barely used, and somewhere in there it turned into something I actually cared about finishing properly. Riccardo’s own two-year post went up a couple of weeks ago — 660+ commits and a couple of Canonical Sprints in, still going strong. Wouldn’t mind having that kind of staying power.

The Calculator I Helped Ship Is Getting a Reboot

mihirsoni.123@gmail.com (Mihir Soni) — Wed, 24 Dec 2014 09:00:00 +0530

Hello,

Riccardo’s writing up the Calculator app reboot — scientific mode, a favourites/history feature, a cleaner design, all built on MathJs. Feels a bit strange in a good way: the app we scraped together the first release of back in 2013 is outdated enough now to need a proper rebuild.

He signed off the post with:

“If you need help, or have feedback, write me a mail or join #ubuntu-app-devel on Freenode and ping me (rpadovani) or Bartosk (gang65) or Mihir (mihir).”

Haven’t touched the Calculator codebase in over a year — I’ve been heads down on Calendar since late 2013 — but apparently I’m still one of three names people get pointed to on that app. Good excuse to go poke around the new scientific mode once it’s further along.

The Bug That Followed Me Across Six Projects

mihirsoni.123@gmail.com (Mihir Soni) — Thu, 06 Nov 2014 09:00:00 +0530

Hello,

Landed DesignFixDefaultWeekView-5 today, but the thing that’s actually eaten most of my week is bug 1362962 — “Calendar icon usually shows the wrong date.” Sounds trivial. The little calendar icon in the launcher is supposed to show today’s date, and sometimes it just doesn’t. Except the fix touches indicator-datetime, ubuntu-ui-toolkit, qtorganizer5-eds, and a few other projects besides Calendar, and it’s been sitting near the top of the importance list across all of them for weeks now.

Turns out the icon isn’t owned by the Calendar app at all — it’s a system indicator that several apps and toolkit components all have a hand in updating. What looks like “wrong date on an icon” is actually a question of which component is responsible for refreshing state, and how many of them are quietly assuming someone else already did.

Learning more about how the stack actually fits together chasing this one bug than I have from most of the features I’ve shipped.