On Thu, Aug 8, 2013 at 7:38 PM, Iustin Pop <[email protected]> wrote: > On Thu, Aug 08, 2013 at 05:32:26PM +0200, Guido Trotter wrote: >> +list >> >> >> ---------- Forwarded message ---------- >> From: Guido Trotter <[email protected]> >> Date: Thu, Aug 8, 2013 at 5:32 PM >> Subject: Re: Extend hail interface >> To: Spyros Trigazis <[email protected]> >> >> >> On Thu, Aug 8, 2013 at 4:48 PM, Spyros Trigazis <[email protected]> wrote: >> > >> > Στις 8 Αυγ 2013, 5:22 μ.μ., ο/η Michele Tartara <[email protected]> >> > έγραψε: >> > >> > On Thu, Aug 8, 2013 at 4:09 PM, Spyros Trigazis <[email protected]> wrote: >> >> >> >> >> >> Στις 8 Αυγ 2013, 4:51 μ.μ., ο/η Michele Tartara <[email protected]> >> >> έγραψε: >> >> >> >> On Thu, Aug 8, 2013 at 1:22 PM, Spyros Trigazis <[email protected]> >> >> wrote: >> >>> >> >>> Hi Michele, >> >>> >> >>> I've seen the implementation of iallocator and how masterd makes RPCs to >> >>> all nodes. I think it is better to use noded to collect data from the >> >>> local mond, as we discussed during our last hangout. >> >> >> >> >> >> As I said the other day, I don't really see a reason for reading the data >> >> from MonD though the node daemon, instead of directly accessing it from >> >> where you need it. >> >> >> >> It's not impossible (and that's why I didn't just say no), but it adds a >> >> new level of indirection, thus adding more delay and an extra point of >> >> failure in between. Therefore, my question is: why do you think it's >> >> better >> >> to route the query through NodeD? Unless there is a really good reason, I >> >> think just contacting MonD directly could be better. >> >> >> >> >> >> I don't think I understand what you mean by saying "contact Mond >> >> directly". Sould we contact MonD directly from Hail or MasterD? >> > >> > >> > With "directly" I mean contacting MonD using it's own protocol (that is, >> > just an HTTP GET request at the right address) and getting the JSON as a >> > result, as opposed to contacting MonD through NodeD. >> > >> > Given that hail operates taking its input from a file, I guess this should >> > be done by who's generating that file and passing it to hail, which should >> > be MasterD. >> > >> > >> > I was confused because you mentioned Network.Curl which is a Haskell >> > library and MasterD is written in python. So, I will query all monds >> > included in the nodes list from lib/masterd/iallocator.py right after >> > the RPCs and before constructing the final dict. Since this part of the >> > code is written in Python, I will use PyCurl as you already do in >> > lib/rapi/client.py. >> > >> >> I wonder if this makes sense at all: woudn't it be better to contact >> mond from hail? >> rationale: there will need to be code in htools to contact mond >> anyway, in order for hbal to be able to do the right thing, so it >> makes sense for hail to also contact mond directly, no? > > I haven't seen any doc about how hail/hbal will be changed (or I just > missed it), but this proposed change seems to have some layering > violation in it? >
Indeed, before the code changes Spyros needs to send a design document over the second part of his project (the actual htool changes). So it makes sense to round up this discussion and proceed analyzing the design. > In 2.7, masterd/confd have the authoritative "view" on the cluster > state. In the future, if hail talks directly to MonD, but jobs talk to > NodeD, won't that lead to inconsistencies? How will this be managed? > I don't see a layering violation for this reason: masterd/confd will keep having the authoritative view on the cluster. The htools will be able to talk to mond to extract additional information that is *not* part of that view (eg. node load) and use them for their decision. Note that the load could be ganeti related or not and it would be just an extra source of information for htools. > Just a side note: FYI, it doesn't seem like it's possible to follow > Ganeti development just from this list :/ If there are hang-outs, it > might help people to post a short summary? > Ack, agreed. I also had a few questions reading this that were clarified in person. In this case the correct "summary" I think is to write a design doc for the htools changes. Of course this thread helps as a starting point, and then we can discuss better in the design whether there are issues or not. Do you agree? Thanks, Guido
