On Fri, Jan 09, 2015 at 01:05:01PM +0100, Aaron Karper wrote: > Thanks for the feedback! > > > On Fri, Jan 09, 2015 at 10:59:02AM +0100, Klaus Aehlig wrote: > > > +This behaviour is clearly wrong, but the problem doesn't arise often in > > > current > > > +setup, due to the fact that instances currently only have a single > > > +storage type. > > > > I guess, the main reason why it works in practise is that admins tend to > > group instances > > on node groups by needs. Otherwise, a single storage type per instance > > wouldn't suffice > > if we freely mix and match, e.g., file storage and DRBD. > > > > That is another reason. Should I add it?
Yes, please. > > > +LUXI extension > > > +-------------- > > > + > > > +The LUXI protocol is extended to include: > > > > please specify for which entity this information is included. > > > > + in the ``node`` ACK > > "instance" or "node". Note that, since "instance" has a special meaning in > > Ganeti, > > if you use that word in its normal English meaning you have to specify of > > what > > it is an instance of. > > > > s/instance/node/ OK, that way it makes sense. > > > + drbd8,2000,4000;file,5000,10000;file,1000,20000;lvm-vg,1024,1024 > > > > That looks more like the text format. The IAllocator protocol is a JSON > > protocol. > > > > True, the LUXI and IAllocator protocols are extended in the same way > however, so I'll modify the LUXI section to specify 'LUXI and IAllocator > protocol'. This section is the 'Text protocol extension'. OK, thanks. > > > +Interpretation > > > +-------------- > > > + > > > +hbal and hail will use this information only if available, if the data > > > file > > > +doesn't contain the ``storage`` field the old algorithm is used. > > > + > > > +If the node information contains the ``storage`` field, hbal and hail > > > will > > > +assume that only the space compatible with the disk's requirements is > > > +available. For an instance to fit a node, all it's disks need to fit > > > there > > > +separately. For a disk to fit a node, a storage unit of the type of > > > +the disk needs to have enough free space to contain it. > > > > Please also specify what is supposed to happen if the new ``storage`` field > > promisses > > more space than the current total sum fields. > > > > > + The case of the total free space being smaller than the free space reported > by > + the ``storage`` field can occur with shared storage. To accommodate for this > + case, we ignore the total free space if the ``storage`` field is present. Shared storage is a separate issue, not yet addressed in this design. But my question was about inconsistencies in the other direction: assume the total free space for a node shows a very small value, but the storage field shows a huge value of the desired storage unit. (Ususally that would mean we're provided with wrong data---unless we do some overcommitment with on-the-fly lvm magic.) Should we allow an instance to come on this node or not? Beeing backwards-compatible would require us to check both, the values provided in the storage field and the old values describing the total available storage. A "new trumps old" principle would require us to only check the values in the storage field. So, there's a design choice to be made (I don't think it matters implementation wise)---and that design choice is to be clearly documented. > This section is confusing, [...] Indeed. And I'm even more confused by the additional explanation. -- Klaus Aehlig Google Germany GmbH, Dienerstr. 12, 80331 Muenchen Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschaeftsfuehrer: Graham Law, Christine Elizabeth Flores
