[pve-devel] [RFC cluster 1/1] add generic data broadcast interface

[Dominik Csapak]

>>>
>>> not yet really sure about this, or better said, I'm sure I don't want this for
>>> locks, but for things like ceph service states it could be OK.
>>
>> yeah i am not sure about this either, hence i sent it as RFC ;)
>> i would prefer it for locks over the config parsing in the api call though
> 
> hmm, I'm not sure, this approach increases cluster traffic (corosync),
> the other didn't, as it just used what's here already...
> 
> You just moved the overhead from loading through IPCC + parsing (read only)
> on the wire by writing states out, I'm not 100% sure it's better you get
> 
> * edge triggered,
> * constant writes of information already known to the pmxcfs (at least with
>    locks)
> * possibility that data is completely out of date and wrong (statd hangs,
>    restart but no sync, ...?)
> 
> against
> 
> * (currently) slower with a lot of VMs, mostly due to the nature of getting
>    all configs one after the other first
> * always correct, if quorate
> * possibility to make fast by adding IPCC calls helping with getting data in
>    bulk from VM configs (as you know I'm on this, and have a somewhat working
>    prototype, but currently not too much time)
> 
> 
> So can we agree that this won't be the lock, other config, or pmxcfs file
> backed information exchanger, but let's work it in direction of things like
> the ceph service state broad cast (for which this seems like a really nice
> and simple solution, reusing what we have) and possible (ephemeral)
> notifications, and the like, not already handled by files from pmxcfs?

yes makes sense to me

> 
>>
>>>
>>>> +    }
>>>> +
>>>> +    return $res;
>>>> +}
>>>> +
>>>>    # $data must be a chronological descending ordered array of tasks
>>>>    sub broadcast_tasklist {
>>>>        my ($data) = @_;
>>>>
>>>
>>
>>
> 

did you have a look at the other thins i mentioned in my cover letter?
(especially the data merging part)
i will try to send a v2 this week