[heketi-devel] [heketi] Pre-existing GlusterFS cluster

[Jose A. Rivera]

On Wed, Jan 25, 2017 at 2:16 PM, Luis Pabon <lpabon at gmail.com> wrote:
> Hi José,
>   This has been asked for many many times.  Heketi was designed to "rule
> them all".  Heketi was never designed for systems that have been setup
> already because the permutations of possibilities of configurations could be
> extensive to figure out how to manage.  It is like creating a Ceph Rados
> system by yourself, then asking the pool manager to figure out what you did.
> If instead Ceph is viewed as a collection of the access+pool+storage and not
> as individual parts, then it all works well and is predictable.  In the same
> way, it should not be viewed as Heketi managing GlusterFS, but
> Heketi/GlusterFS instead.  Once this view is accepted (which is what users
> want, but old school gluster users have a hard time with), then what Heketi
> currently does makes perfect sense.
>
> So, back to the question, no, Heketi does not and will never manage such a
> model.  Any software that manages such a configuration would be hard to
> productize and guarantee.  Can you make a hack that does it? Maybe, but
> reliability and simplicity is what Heketi is after.
>
> Hope this answers your question.

I know this has been asked more than once and I believe this keeps
being asked for because the above is still an unsatisfactory answer.
:) Already we are seeing new users asking for maintenance features
that would be perfectly possible with Gluster but which are currently
out of reach when going with heketi. I think focusing too hard on
"simplicity" will quickly become limiting to heketi's desirability. It
would seem to make more sense to go with a mindset of a tailored
experience, with the ability to go in deeper if desired.

There doesn't seem to be anything technically complicated about the
idea that heketi could tolerate a peer probe coming back already
satisfied, or that a node is removed without removing it from the peer
list. I don't see how this would prove to be dangerous as long as we
maintain the understanding that you are not to go in on the backend to
mess with anything heketi is actively managing. This seems like
something we could easily test, make reliable, and productize.

--Jose

> - Luis
>
> On Tue, Jan 24, 2017 at 12:24 PM, Jose A. Rivera <jarrpa at redhat.com> wrote:
>>
>> Hey Luis, et al.,
>>
>> I talked to Ashiq about $SUBJECT, and he raised some concerns.
>> Apparently heketi can not load/import nodes that are already part of a
>> Gluster cluster? E.g. if I have an existing cluster with all the nodes
>> already peer probed, heketi will try to redo the probe and then fail
>> when it comes back already in peer list? This seems odd to me, but if
>> so sounds like a relatively easy thing to change. Thoughts?
>>
>> --Jose
>
>