Need to avoid setting 'all-bricks-in-cluster' in transaction context for volumer {create,expand,replace-brick} about glusterd2 HOT 7 CLOSED

For now second option looks good. But to support mix of manually provisioned volume and smart volumes we need to validate the brick path to prevent use by multiple volumes.

from glusterd2.

@kshlm regarding option 2, if we end up having a bad bug introduced in the brick allocation logic in smart volumes, then this might be dangerous, isn't it? Or do you see that can never happen?

Isn't there a way (I'm not sure) if we can actually query etcd on batches like fetch 1-300 bricks at 1 batch and then 301-600 bricks in 2nd and so on and then consolidate?

from glusterd2.

@atinmu we can use ETCD pagination for querying

from glusterd2.

For now second option looks good. But to support mix of manually provisioned volume and smart volumes we need to validate the brick path to prevent use by multiple volumes.

I'm not proposing that we remove brick validation completely. The validation would be skipped when the request is detected to be a smart vol request. A normal request would include the validation step.

@kshlm regarding option 2, if we end up having a bad bug introduced in the brick allocation logic in smart volumes, then this might be dangerous, isn't it? Or do you see that can never happen?

The brick paths are generated by the bricksplanner should be unique based on the the volume name. There may be issues with parallel requests to the same volume, but the locking should help avoid this. But we could make it even more by using use the volume uuid and brick uuid, which should give unique brick paths.

Isn't there a way (I'm not sure) if we can actually query etcd on batches like fetch 1-300 bricks at 1 batch and then 301-600 bricks in 2nd and so on and then consolidate?

That is part of the problem here. The initial fetch performed by the txn leader before setting 'all-bricks-in-cluster' will be helped by the pagination as @Madhu-1 suggested. The other problem is that once all the bricks are fetched, we're setting a single large value with in the txn context. Pagination will not help with this.

from glusterd2.

@kshlm regarding option 2, if we end up having a bad bug introduced in the brick allocation logic in smart volumes, then this might be dangerous, isn't it? Or do you see that can never happen?

All generated brick path will contain volume name so collision will not happen. But collision can happen if manually provisioned volumes are allowed.

Isn't there a way (I'm not sure) if we can actually query etcd on batches like fetch 1-300 bricks at 1 batch and then 301-600 bricks in 2nd and so on and then consolidate?

@atinmu we can use ETCD pagination for querying

I think etcd response size is not the problem. We should make bricks validation as single node transaction step and avoid setting the response again in context for next transaction.

from glusterd2.

#1478 fixes it.

from glusterd2.

Fixed through #1478

from glusterd2.