* Brice Figureau <[email protected]> [091128 22:58]:
[snipped a lot]
> [snipped]
> >>> * we don't care and ask users wanting to have multiple masters to
> >>> use a
> >>> shared filesystem (whatever it is) to share the yaml dumped facts.
> >>
> >> It could work. It could also fail due to various race conditions.
> >
> >
> > This basically says that multiple masters is really complicated and
> > you shouldn't do it, which is not where we want to end up.
> >
> > IMO, the right approach is to have a node manager capable of
> > functioning as an inventory server (holdiing all fact/node data), and
> > then have the servers query that (with the same kind of caching
> > they're doing now).
> >
> > This gets you essentially everything you need, and all it says is: If
> > you want multimaster, you have to have an inventorying node manager.
>
> But people running multi master mainly do this for failure resistance,
> and we're just adding a single point of failure... Don't you think this
> is a problem?
I've not completely read this thread, but it seems like there is
confusion about what people really want. My observation is, that
people mostly want:
load sharing
and/or
fault tolerance
And both of these things are currently very complicated to do as
long as the client has only one hostname to talk to.
Why not change this?
For fault tolerance and small load sharing setups, configure a list
of servers to talk to on the client. At run-time, the client shall pick
one server at random and stick to it for the rest of the run. If the
server doesn't respond, start over with the selection mechanism.
For setups with more servers/masters (I expect that people probably
don't want to configure >2 masters in their client configs), the
initially contacted master may hand out a name of a master to talk
to. This is basically the same as suggested already very early in
this thread, but it may get combined with a node manager (whatever
that one will do).
Doing both things you can get load sharing and fault tolerance (for
single masters and the node manager).
Christian
--
christian hofstaedtler
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
