[Freeipa-devel] [PATCH 0090] show optionally configured components in server-find/show command output

[Petr Spacek]

On 6.11.2015 09:25, Martin Kosek wrote:
> On 11/05/2015 07:02 PM, Petr Vobornik wrote:
>> > On 11/02/2015 12:37 PM, Martin Kosek wrote:
>>> >> On 11/02/2015 06:10 AM, Jan Cholasta wrote:
>>>> >>> Hi,
>>>> >>>
>>>> >>> On 22.10.2015 10:44, Martin Babinsky wrote:
>>>>> >>>> https://fedorahosted.org/freeipa/ticket/5181
>>>> >>>
>>>> >>> This should be handled by a separate object plugin:
>>>> >>>
>>>> >>> $ ipa servercomponent-find master.ipa.test
>>>> >>> ---------------------------
>>>> >>> 6 server components matched
>>>> >>> ---------------------------
>>>> >>>    Component name: CA
>>>> >>>    Enabled: TRUE
>>>> >>>    Start order: 50
>>>> >>>
>>>> >>>    Component name: KDC
>>>> >>>    Enabled: TRUE
>>>> >>>    Start order: 10
>>>> >>>
>>>> >>>    Component name: KPASSWD
>>>> >>>    Enabled: TRUE
>>>> >>>    Start order: 20
>>>> >>>
>>>> >>>    Component name: MEMCACHE
>>>> >>>    Enabled: TRUE
>>>> >>>    Start order: 39
>>>> >>>
>>>> >>>    Component name: OTPD
>>>> >>>    Enabled: TRUE
>>>> >>>    Start order: 80
>>>> >>>
>>>> >>>    Component name: HTTP
>>>> >>>    Enabled: TRUE
>>>> >>>    Start order: 40
>>>> >>> ----------------------------
>>>> >>> Number of entries returned 6
>>>> >>> ----------------------------
>>>> >>>
>>>> >>> This will allow us to consolidate all the ad-hoc component-related code
>>>> >>> scattered throughout IPA (search for enable component, enable/disable
>>>> >>> component, ...) into IPA command calls.
>>>> >>>
>>>> >>> I'm not opposed to showing a summary in server-show (although we don't do
>>>> >>> anything like this for any other hierarchical objects), but it should be done
>>>> >>> just for the users' sake, not for internal use (the ticket suggests to use this
>>>> >>> for topology visualisation).
>>>> >>>
>>>> >>> BTW as far as the scalability of the current solution goes, you should have a
>>>> >>> list of all the *non*-optional components and display everything else.
>>> >>
>>> >> The API proposal should be in line with our future extensions of the API. We
>>> >> for example want to move "ipa-csreplica-manage" set-renewal-master command to
>>> >> API call. Or DNSSEC generation master. Or we may want to change some other
>>> >> flag/role of a master via this interface.
>>> >>
>>> >> So we will need something like
>>> >> $ ipa server-add-role ipa.example.com --role "ca-renewal-master"
>>> >> or
>>> >> $ ipa servercomponent-add-role ipa.example.com CA --role=renewal-master
>> > 
>> > Depends on usage. If we want to internally unify manipulation with configs for
>> > component we can create low-level commands which won't be exposed to CLI.
>> > 
>> > E.g. ipa servercomponent-find ipa.example.com
>> > Component name: ADTRUST
>> > Config: enabledService, startOrder 60
>> > 
>> > <other services>
>> > 
>> > This is all what Web UI needs.
>> > 
>> > 
>> > From user perspective, for CLI, something different is better. Martin used term
>> > 'role', lets go with that.
>> > 
>> > Idea 1:
>> > $ ipa server-show ipa.example.com --roles
>> > Server name: vm-073.idm.lab.eng.brq.redhat.com
>> >   Managed suffix: dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com, o=ipaca
>> >   Min domain level: 0
>> >   Max domain level: 1
>> >   Role: dns-server, cs-server, ca-renewal-master, trust-controller
>> > 
>> > --all would imply --roles
> I am thinking "Roles" could be printed out even in default listing. It looks as
> an important piece of information you want to know about your master. I also
> originally used that with servercomponent, you moved it to server itself. It
> makes also sense.
> 
> We will need a design for this servercomponent/roles anyway, to agree on the
> API with all stakeholders.
> 
>> > $ ipa server-add-role ipa.example.com --roles=ca-renewal-master

Just keep in mind that 'role' design requires yet another layer of indirection
because there is no 1:1 mapping between services and roles. E.g. 'DNSSEC key
master' role consists of several services, as 'DNS server' role etc.

Also, we can get into trouble because role 'DNS server' in IPA 4.2 can contain
different set of services than 'DNS server' in IPA 5.0 etc.

For these reasons I question necessity of 'role' abstraction. Is it worth?

-- 
Petr^2 Spacek