Hello Iustin! Thanks for your detailed description of upcoming plans, some comments are inline.
On Thu, Apr 19, 2012 at 07:18:20pm +0200, Iustin Pop wrote: > Over the past 6 months, we have discussed (at length) on what is the > best direction for Ganeti, given that the current code-base, while > working well for us, has accumulated a lot of technical debt in terms > of internal architecture deficiencies, programming language issues, > testability, etc. > > The main pain points we have identified are: > > - the master daemon is a big, monolithic entity that contains a lot of > components; changes in any component (OpCodes, Logical Units, > objects, etc.) have cascading and sometimes unpredictable effects on > the other components > - the dynamic nature of Python makes any static analysis very hard (or > impossible), which makes the previous point even more painful > - the multi-threaded nature of the master daemon creates scalability > problems in Python (which cannot take advantage of SMP/multi-core > environments) With regard to this, have you identified problems with Python's not supporting kernel-level multithreading? Our impression is multi-threading is used in the master to provide multiple execution contexts, rather than to take advantage of SMPs/multicores. To put it differently, it's more of a matter of non-blocking operation of the daemon: the daemon issues requests and blocks for responses. To make the analogy, wouldn't the model of a select()-based event loop inside a *single* process work for the master? Is there something that makes it computationally intensive, so scalability with python-based threading suffers? It seems the master's scalability is more impacted by locking, more on this below. > - currently, the internal architecture relies on mutable objects, > which creates additional problems regarding the consistency of > internal data structures > > >From the point of view of building Ganeti from source and using it, it > will mean that: > > - the Haskell compiler/platform will be needed at ./configure and > build time, together will all libraries > - on the machines that Ganeti will actually run on, there will be no > extra dependencies, on the contrary, we might have some reduction in > libraries needed at run-time > > >From the point of view of using Ganeti from a distribution: > > - we will continue to provide Ganeti packages in Debian, and if > possible, in backports > - any distribution that has the Haskell platform plus the list of > libraries we use (not too long) should have no issues in building > and providing packages > - if you are a distribution user, installing Ganeti should bring it at > worse the same dependency list, at best fewer dependencies > This is great! As long as you continue to provide Debian packages, and your dependencies are part of Debian, or are backported, we'll be able to run Ganeti and experiment with own additions/contributions. > This is a long-term plan (2.7 will not come before autumn), so it > would be a good idea to discuss this now. We're especially looking at > feedback from users and contributors/developers on: > > - as an end-user, would this change impact you at all? do you have any > concerns regarding it? > - would it impact you if Ganeti requires Haskell to build/install? do > you see deployment issues or such? > - would it impact you if the Ganeti code-base is written mostly in > Haskell, with regards to contributing small patches or adding new > features? > Haskell does create a steeper learning curve and raises the entry barrier significantly. Python is ubiquitous, every sysadmin knows a bit, every sysadmin can dabble in the code and fix minor issues. On the other hand, if you believe this is the way to go, and ensure a proper fallback plan along the way, we trust your judgement completely. You seem to have a solid plan to introduce Haskell gradually. > Of course, any other feedback on this topic is welcome. > Regarding the focus of 2.7, I think you have also mentioned it, we've begun looking into scalability of the locking mechanism in the master daemon. How do you believe the transition to Haskell is going to impact this? Currently, there are places where the master daemon locks the whole cluster, e.g., while the iallocator runs. How do you see handling locking evolve in the future, with and without Haskell's increased presence in the code? you mentioned separating the locking mechanism from the rest of the master daemon. How would this impact lock handling, and do you have plans to explore less strict locking in favor of higher-throughput processing? Thanks, Vangelis
signature.asc
Description: Digital signature
