[DRAFT] Co-located services

[Gustavo Niemeyer]

> I'm fine with that, but it makes sense to me that this abstraction
> would be a portable way to address this. In a sense I see it like
> adding an aspect in AoP to a class where its possible that the aspect
> is available on many classes. In the case of something like storage I
> can imagine a single storage service with a single config made
> available to many services through this mechanism.

Storage has a lot of edge cases that have to be taken into account.
The whole container must be able to be deployed in a specific FS,
for instance.  A formula that is being deployed within the container
cannot take care of that.

> The reason I went with the notion of a primary containing service has
> to do with the idea that
>
> - co-located services know they can co-locate, the containing service
> isn't always aware of this
> - the relationship (because of the above) is generally asymmetric
> - a peer model implies equals which isn't the intention. The lifecycle
> of the primary service's units arei not bound to the co-located
> services lifecycle (picture logging/status services for example) but
> the reverse is true

Ah, that's quite interesting indeed.  Good ideas.

Can we extract the primary/secondary relationship out of the original
plan we laid down in the sprint, using requires/provides + colocated?

>> Optional parameters on arguments generally don't work very well in
>> practice. E.g.:
>>
>>    ensemble deploy --with a b c
>>
>> Is b a service name, or a formula name?
>
> In this case it might be syntax that is causing the issue, there is a
> single optional param per stanza much like we use today with optional
> service names

This does not answer the problem in the ambiguity above. What is "b"?

Service names are arguments to "deploy", not to a command line switch.

> I agree its possible, I also think this syntax makes it very clear
> what the user is intending to do. I feel like its very reasonable cli.
> I would need to see a counter proposal to evaluate it.

I was hoping we could all come up with a proposal that solves
the problem described, so that we could use for both situations.

>>> While the co-located services have relationships with the parent
>>> service (and the parent service may supply them with general
>>> information) its is generally considered a usage error for the parent
>>> service to ever query the co-located service's relation-data.
>>
>> Why?  How's that different from a normal relation?
>
> A design goal was that the primary service wouldn't have to know that
> a logging/monitoring service was co-located within its container and

It's not clear why that would be a goal.  If we establish a way for
formulas to communicate with a contained service (e.g. where
are your logs?), it feels reasonable to have the service answering
through the standard mechanism of relations.

> It could be, I worry that seeing n wordpress services with n logging
> and n monitoring (and n storage?) services co-located within them will
> pollute what the admin is trying to grok with status.

Agreed.  We should evaluate options to make it clean indeed.

>> This section is diverging significantly from what we agreed in the sprint.
>> IIRC, the idea was simply to allow defining a relation as co-located. E.g.:
(...)
> This avoids the design goal of the primary service not having to know
> much (if anything) about what can possibly co-locate with it. The

That's where promiscuous relationships come in.  We did cover this
in the sprint.  We also covered cases where we did want services
to communicate to each other so that they could learn about
what they should be doing within the container.

-- 
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/plus
http://niemeyer.net/twitter
http://niemeyer.net/blog

-- I never filed a patent.