On 04/08/2013 09:37 AM, Rob Crittenden wrote:
> Petr Vobornik wrote:
>> On 04/08/2013 03:03 PM, Rob Crittenden wrote:
>>> Petr Vobornik wrote:
>>>> On 04/05/2013 07:59 PM, Ana Krivokapic wrote:
>>>>> Hello list,
>>>>>
>>>>> I have been thinking about the possible implementation for a
>>>>> solution of
>>>>> ticket https://fedorahosted.org/freeipa/ticket/3528. There are
>>>>> several
>>>>> options:
>>>>>
>>>>> 1. Completely remove the commands and command options related to
>>>>> source
>>>>> hosts in HBAC. This might not be a good idea as it could cause
>>>>> problems
>>>>> for older clients.
>>>>>
>>>>> 2. Hide these commands/options from the web UI, but leave them in
>>>>> CLI.
>>>>> This would keep the API intact, but I don't like the idea of
>>>>> introducing
>>>>> inconsistencies between CLI and web UI.
>>>>>
>>>>> 3. Do not remove anything, but issue deprecation warnings. The user
>>>>> will
>>>>> see a warning when using these commands/options, but everything will
>>>>> still work.
>>>>>
>>>>> 4. Do not remove anything, but raise exceptions. This would
>>>>> effectively
>>>>> prevent the user from using these commands/options, as the exception
>>>>> will break the execution of a command.
>>>>>
>>>>> In any case, any reference to source hosts should be removed from
>>>>> help
>>>>> and documentation.
>>>>>
>>>>> I am leaning towards options 3 or 4.
>>>>>
>>>>> Thoughts, comments and ideas are welcome.
>>>>>
>>>>
>>>> IMHO the main question is whether we want to deprecate it or remove
>>>> it.
>>>> SSSD is deprecating it so I would go that way too.
>>>>
>>>> #1 and #4 are basically a removal, #4 a bad one.
>>>> #2 is removal from Web UI perspective.
>>>>
>>>> I would do #3 with some changes. In both Web UI and CLI there
>>>> should be
>>>> clear label that the section/options are deprecated. We may
>>>> introduce a
>>>> deprecated flag. With this change we don't have to show the
>>>> warning. But
>>>> in CLI we might because user didn't had to read help beforehand.
>>>
>>> It has been deprecated for quite a while now. This was raised
>>> because we
>>> let users enter this data via the UI and CLI and it does absolutely
>>> nothing which is terribly misleading.
>>>
>>> I think that it should be removed from the UI completely. I'm torn with
>>> the CLI, though leaning on hiding the options.
>>
>> Removing it from UI and hiding it in CLI might work for users. I assume
>> that it will break scripts which are using CLI ('error: no such
>> option:'). API based scripts will continue to work.
>>
>> Do we want to break CLI-based scripts and keep compatibility with
>> API-based ones?
>>
>>>
>>> It might be worthwhile to also raise an exception if anyone tries to
>>> use
>>> it via a script or otherwise.
>>
>> Wouldn't removing the options raise an exception as well? I don't see a
>> point in keeping them when it will always raise an exception.
>
> You seem to be following my line of reasoning: if we remove the
> options it is going to break CLI-based scripts. If we don't remove
> them then we need to raise an exception.
>
> Or we do some odd combination of both, depending on what our goal is.
>
> I would normally argue against removing a command-line option but
> given that these literally don't do anything now, I'm actually leaning
> towards removing them.
>
> For those using the API directly then yeah, we probably want to raise
> an exception to be absolutely clear, "don't do it."
>
> rob
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel

Can we just ignore the option and warn if we encounter it?
What is the harm of ignoring is it already does not do anything?
But it also would not break anyone.
Would that be better?

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to