Hi! On Tue, Mar 5, 2013 at 6:27 PM, Guido Trotter <[email protected]> wrote:
> On Tue, Mar 5, 2013 at 9:14 AM, Guido Trotter <[email protected]> > wrote: > > On Tue, Mar 5, 2013 at 5:18 AM, Helga Velroyen <[email protected]> > wrote: > >> I fixed your comments and also added the keys back to the RPC call. > From my > >> notes of two weeks ago (I should have written that right away), I get > that > >> this was what Guido had in mind: the enabled storage methods as list on > >> cluster level, but the (method,key) tuple in the call. > >> > > > > Indeed, thanks&LGTM to this: that means that the storage pools > > implementation can use the RPC, while we don't need to implment those > > "immediately" while starting to have the first benefits. > > > > Quick sync with iustin: > > - It's ok to change the RPC as said > - For gnt-node list we can follow your proposal, and when we insert > storage pool, we'll call by default the drbd storage pool "drbd", of > course it will be possible to rename it. gnt-node list will by default > report on the default storage pool, and of course you'll be able to > ask about any of them (and there will be a new query to ask "what > storage pools are there, and of what type). > - For the iallocator interface, changes should also take care of being > forward-compatible, which should also be fine as we'll be able to add > the storage pools later as explicit objects and report space for all > available ones too (for now we'll report space for all available > storage types, in the future for all available storage pools). > Good points, thank you. Although the design doc technically does not cover the specifics of the storage pools, I added comments about the forward-compatibility and relationship to storage pools, so that the context of the decisions is more clear. Cheers, Helga
