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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to