Dear all, Their are other details to be discussed, and hopefully lead to agreement, but lets get to issue #1. The style issues still apply to ceph and ceph-deploy. >From what you said, in my opinion the "boat anchor" in ceph-deploy is redefined, as coupling of facade pattern, where all data is available, to the ssh loop in a connection. This is probably the biggest single architectural issue in ceph-deploy. Travis Rhoden stated that the modules are imported as objects as they are "instantiated", I should check this, this is very good news and removes many objections to the outcome. The discussion of point (3) is still worth continuing though in a separate thread as it is still important enough to require discussion, but it is of a style and good practice discussion rather than Boat Anchor problem level. Many other topics are unaffected. On 07/09/2015 07:00 PM, Travis Rhoden wrote: >> (1A) You have to close one facade to start anouther, eg in ceph-deploy >> > you have to close each connection before connecting to the next server >> > so making it slow to use as all state has to be gathered. > concurrency has come up before in ceph-deploy. It has been our explicit goal to make ceph-deploy as simple and *clear* as possible for users, with one of the main purposes to be extremely verbose and essentially *teach* a user how to deploy a Ceph cluster. That’s why it prints everything it does by default, shows every remote command, and prints the output back in order. Concurrency would muddy those waters, though we do all want things to go faster. > > It is not necessarily the facade pattern that is the limitation there — it is the implementation within ceph-deploy. We simply do a “for host is hostnames…” loop everywhere — it doesn’t matter what we are using underneath, we are doing one SSH connection at a time. Best regards Owen -- 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
