Why mount the source instead of the service?

[rossmeissl]

@emk here's another "I'm sure you've thought of this, but why . . ." question.

If I want to make changes to my web service, I feel like the natural incantation would be:

$ cage mount web
$ $EDITOR src/web

I shouldn't have to worry about the fact that web code is provided, at the moment, by the faradayio/rails_hello GitHub repo. Perhaps one of my colleagues replaces rails_hello with node_hello someday—that's fine! What matters to me is that I'm checking out a service for inspection, local testing, and possibly amendment. cage source mount rails_hello makes me go through extra hoops to do that.

So why did you do it that way?

update by @seamusabshere: s/frontend/web/g as specified in the comments

[emk]

This is an excellent question!

The short form of this answer is that the same source tree is often used by multiple pods: If you want to change rails_hello in the frontend pod, you might also want to add some database migrations. But you'll run your database migrations using the rake pod.

Having the frontend pod and the rake pod running different versions of rails_hello source code could be pretty confusing!

Normally, this doesn't come up with our in-house app, because we name the services after the git repositories. But here, we have a web service that uses a rails_hello repo, which makes things a bit more confusing.

So that's why things are the way they are now. There are several possible ways forward if we want to tweak any of this.

[rossmeissl]

@emk gotcha. Although I think a polymorphic cage mount might still be more user-friendly. Like so:

$ cage mount rails_hello
Mounted to src/rails_hello
This source is used by frontend, rake
$ cage mount frontend
Mounted to src/rails_hello
This source is used by frontend, rake

Or something like that

[emk]

That's a nice idea, and I'll save it for future prioritization.

Note that cage mount frontend might pull source code multiple services all at once. I'm not sure that most people would want to do that.

[rossmeissl]

@emk sorry I meant web, the name of the service (as opposed to the source)

[emk]

Ah, OK, that does make more sense. So in order of lookup:

• rails_hello
• frontend/web
• web (if unique)

The latter two would actually just map to rails_hello internally, which means that cage source mount web would also mount rails_hello into the rake pod. Anything else would lead to confusion, I fear.

[rossmeissl]

I'm saying just cage mount instead of cage source mount. The point is you're switching from the service being backed by a pre-built Docker image to being backed by the filesystem, yes?

[emk]

Ah, OK, so you're also suggesting the idea of moving mount from the source subcommand to the top level, perhaps with different semantics for the two?

[rossmeissl]

Well it doesn't make sense to nest it under source if you can mount services too

[seamusabshere]

i think i just ran into this

$ cage source ls
[...]
bob                  git@github.com:myorg/bob.git
[...]
bob_max              git@github.com:myorg/bob.git#max

$ cage status
[...]
├─ bob     RUNNING mounted:bob
[...]
├─ bobbeta RUNNING

so there are 3 names:

1. bob
2. bob_max
3. bobbeta

and i confusing can't do this... i am expecting to "mount" the "bobbeta" service

$ cage source mount bobbeta
Error: unknown short alias 'bobbeta' for source tree (try `cage source ls`)