Hi Gregory, On 07/14/2015 01:03 PM, Gregory Farnum wrote: > Hey Owen, > I haven't followed any of the conversations you've had in ceph-deploy > land, but I've been trying to keep track of the ones on ceph-devel et > al. I can't comment on very much of it because I suck at Python — I > can write C in any language, and do so! ;) /me giggles Much much better than Fortran in any language. On this subject: I have to brush up my C++ myself and look forward to helping when I get the opportunity and totally understand where you are coming from. I look forward to getting back to C++, so when I get to this area I will need lot of help from you guys who will probably pull your hair out and say I am programming C++ like its 2005 even when it all comes back. > I interject this comment because there are a lot of C developers in > the community who are doing their best in Python, and it has > historically been important (and, I think, still is?) that they be > able to contribute meaningful change to our python codebases. I think > that has biased a lot of the architecture decisions our python > developers made over the years and I'm not sure if everybody's on the > same page about it. Of this I am sure. > As an example, I can follow the include chains in ceph-deploy without > any problem and make appropriate changes to them. The in-memory > SQLAlchemy code you posted just left me scratching my head trying to > figure out how any of it worked. That doesn't make it *bad*, but > there's definitely a higher assumed knowledge base/learning curve > which we'd need to decide we want to adopt. In ceph-deploy > particularly that's a bit of a problem since it's (at least nominally, > although that mission has been slowly eroded) supposed to be a model > for people building their configuration management or other deployment > systems. For me this thread is about the façade pattern, which for me is a separate discussion. Both these discussions got intertwined, and I wish they could be unlinked. I wish I had never even talked of or mentioned SQLAlchemy, as this is a very tiny detail that is almost unimportant compared to the use of design patterns and in that discussion MVC in particular. It is one of many ways we could implement a model and my ideal of how _I_ would do things, and am still happy if people are keen on MVC but not SQLAlchemy. I hope this thread can be limited to the discussion of the façade, and we move all MVC discussion to the MVC thread I started. > Anyway, I hope this outside observation is helpful to everybody; if > not please ignore. :) It is helpful, I have been programming python for 12 years, and forget that this has had an impact, and led me to not make issues cross language enough. Thanks Owen PS Realising it is actually 12 years since some a collaborator at CERN gave me python test scripts to maintain when they left CERN, for the C++ project I was working on, is really scary. > -Greg > > On Tue, Jul 14, 2015 at 11:41 AM, Owen Synge <osynge@xxxxxxxx> wrote: >> Dear Travis, >> >> We clearly disagree in this area. >> >> I hope me explaining my perspective is not seen as unhelpful. >> >> On 07/09/2015 07:00 PM, Travis Rhoden wrote: >>>> (2B) inflexible / complex include paths for shared code between facade >>>>> implementations. >>>>> >>> I disagree here. There are plenty of places to put code that is common and does not have to be duplicated. I definitely don’t want code in each host module that knows how to deal with systemd. The code that does have to be in each host module is how to detect/assign what init system is being used, and how to call into the appropriate (common) module to do what it needs. >>> >>> As for complex include paths, I’m not sure I have much of an argument here other than to say that all frameworks have their conventions. I don’t see what we are doing as anything different than what is enforced/recommended by many frameworks/scaffolds popular in Web app and MVC paradigms like RoR, Pyramid, Django, etc. It’s just convention to learn. >> >> I don't understand why you chose to defend this. Please expand your >> argument. >> >> I will not go into the negative side effects of importing modules as >> objects in the include paths, as a work around for potential side >> effects of our current façade model, as this topic is more complex than >> the points I do raise in this email, but I will expand them should these >> arguments not be valid, as I would like to understand where we intend to >> go, and how we minimise long term maintenance and maximise extensibility. >> >> Here are the simpler reasons why I don't agree: >> >> I hate the enforced code structures used my many "popular" frameworks >> especially common in web frameworks but I accept that these enforce very >> clear standard design patterns that are known to scale and be extensible >> and you acknowledge this difference to the ceph-deploy code base simply >> by calling them MVC. * >> >> Having enforced relative paths between code files defined by the >> implementation of the code is a great limitation. >> >> While one can place code modules in the correct location if only one >> thing defines the correct location, one can easily get into difficulties >> 2 obvious limitations in tolerating this are: >> >> (1) by having two parts of the code base enforcing relative paths >> between modules. >> >> (2) by having relationships between modules become needlessly complex >> because the enforced relationship says the code must go in a place that >> is not correct to solve the problem. (this is analogous to the death of >> hierarchical databases and their replacement with relational databases) >> >> So since the issue is most serious if you have 2 components in the code >> base that "enforce" module layout, and we only have one, we are only >> preventing further components that "enforce" module layout. >> >> Admittedly neither of these issues has _prevented_ development on >> ceph-deploy so far, or led to duplication now you withdrew your comments >> about all façades being the same. >> >> Due to the façade defining module location we so far have, some things >> have become confused in where the module can be placed that are clearly >> OS specific. >> >> Examples include: >> >> ceph_deploy/util/constants.py which is clearly includes constants that >> are OS specific, such as package names. >> >> ceph_deploy/util/pkg_managers.py which clearly is a set of OS specific >> implementations. >> >> Both of these lead to unnecessary complications, when they could be >> façades in their own right and should have the modules moved if we >> continue to have this enforced module location in the façade implementation. >> >> This inconsistency will not effect customers but does effect the clarity >> of the code, and leads to more conditionals than we might have if we >> took in my opinion a cleaner implementation to our model. >> >> I will _not_ provide sample code of improvements, as this may lead to >> people discussing irrelevant issues, until this point is resolved as my >> mistake, or an area that is agreed can be improved. >> >> Best regards >> >> Owen >> >> >> * It is one the many reasons I abandoned django in favour of Pyramid for >> my personal projects, even though django only enforced separation of >> components Model View and controller, pyramid to my recollection (its >> been 3 years at least) only recommended a module relationship path . >> -- >> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html > -- SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
