A ramble on composites and local

Habitat Help
#1

Hi,

I’ve been using composite packages quite a bit, I really like the idea - but they do seem to fall apart some times (especially when things are loaded manually over the top). Someone recently commented in chat that they were perhaps regretted because of the large number of edge cases - which got me thinking.

99% of my use case is sidecars (eg: PostgreSQL + WALE). The idea of starting and stopping with a group is nice, but not a dealbreaker.

To me something like --bind=backup:wale.local would make the most sense, but that would suck for people who use a group name of local at the moment.

Thoughts?

#2

Maybe even allow a host?

--bind=backup:localhost://wale.default

or

--bind=backup:wale.default@localhost

Seems a bit strange though

#3

@jamessewell Just to clarify, your “local bind” idea would be a way to replace the majority of your own uses of composites as a way to say “bind to this other service which should also be running on my same Supervisor, and do not bind to any such services running on any other Supervisors in the same Habitat network”, correct?

Alternatively, you could think of this as creating a variation of a service group that only exists (by definition) on the same Supervisor.

It’s an interesting idea.

We’re having some internal discussions of composites this week (tomorrow, actually), so hopefully we’ll have some clear direction on this very soon.

#4

Hi! Was a direction nominated?

And yeah - it would replace all my use cases.

It is nice to be able to load multiple services with a composite - but in reality you don’t actually do that so often so it’s a loss we can take.

#5

Yeah, we’re going to be removing composites from the codebase for the time being. After 1.0, we’ll be looking to work alongside customers and users to sort out what the final shape of the feature should be. I suspect that some notion of “local binds” may figure in that, since that actually seems to address a key aspect of the desired composites usecase that the current implementation doesn’t actually cover.

We’ll have some more formal messaging on this going out soon, but that’s it in a nutshell.

#6

Would a PR for local binds be welcome if I can manage it, or should I hold off for now?

#7

There are a lot of things in flight at the moment; I don’t know that we’ve got the bandwidth at the moment to fully consider what seems (initially, at least) a rather significant change like this, so I’d hold off for right now.

If you’d like to open an issue, though, with the kinds of behaviors you think would be useful, with examples from usecases you have, that would be incredibly helpful.

Thanks!