2014-03-05 20:09 GMT+01:00 Simo Sorce <simo@redhat.com>:

On Wed, 2014-03-05 at 15:35 +0100, Miloslav Trmač wrote:

I do not understand what you mean. If you deploy a domain controller do
you expect it to be in full working condition when you are done
configuring it through the role deploy command ?

If, say, one week ago I have used exactly the same command to deploy a database, and I still remember that I had to manually modify the firewall, why wouldn't I expect the same command to do the same thing about the domain controller? I'd like the OS commands to behave consistently so that I don't have to remember too much.

> > For example I think the best default for the domain controller role will
> > be to open the firewall, while the best default for the database role
> > will be to keep it closed.
>

> That may be *individually* true, but the user gets differing behavior

> without having clearly acknowledged or caused such a difference, put
> together into a single product doesn't give the user sufficient visibility.

I do not understand your point here. Different roles have different
characteristics. Roles that do not open ports by default can warn the
user that they did not do so and tell them what is the role-command to
use to open the default ports for the role.

OK, informing the user[1] would resolve my concern. I'd still prefer the behavior to be consistent, but this would work.

Mirek

[1] It seems to me that the user needs to be informed both when the service needs the user to modify the firewall, and when it has modified the firewall without asking, but that's really an UI design question that I shouldn't be bikeshedding I suppose.