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 > > This is not good because this add operation will also remove a role from > different master which could be unexpected. I.e. set-renewal-master might be a > separate command. Same would apply to DNSSec generation masters. I am not sure if having a separate command for every role scale well, but I am not that strong opposed. > Idea 2: > $ ipa serverrole-add ipa.example.com ca-renewal-master > $ ipa serverrole-find ipa.example.com > Role: dns-server > Role: cs-server > Role: ca-renewal-master > Role: trust-controller > > All variants alone are fine for Web UI. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
